FTP servers and SyncBack

[copart]

I like the list of RECOMMENDED FTP servers. However, can you highly recommend any Linux FTP servers? I really think the MDTM command working 100% is extremly important. I believe all of the ones that seems decent were all Windows (except FileZilla which does not accept MDTM).

Thank you.

-Steve

[mickyj]

If anyone is using SyncBack with a Linux FTP server, and they can run all the tests to check for any problems, then I'm more than happy to add their results to this list.

[tigoluxa]

Hi uritsukidoji,

I use filezilla 0.97b as well. It works fine with syncback on port 21. I tried to add SSL/TSL connection on filezilla on port 990. It works finewhen syncback connects from a lan computer. However, people outside the lan can access the server, but they cannot logged in or browse their directories. Eventually, syncback crashes.


I tried to log in to the server using port 990 using windows explorer from remote machine and it worked fine. Which means the firewall and filezilla do accept the connection.

Do you have any clue? can you help please?

Thank you in advance.

[copart]

Perhaps an FTP MDTM Compatability Mode setting would work. When an FTP server only supports the readonly MDTM command, then set the date of the SOURCE file to match the FTP server? I imagine this is not the answer for everyone, but perhaps some would find this a great fix to the MDTM issue.

Personally I am quite annoyed that PureFTP doesn't fully support the command since my webhost replies on it. A PureFTP release hasn't come out in a couple of years, so I do not expect it ever getting fixed.

-Copart

[mickyj]

Perhaps an FTP MDTM Compatability Mode setting would work. When an FTP server only supports the readonly MDTM command, then set the date of the SOURCE file to match the FTP server? I imagine this is not the answer for everyone, but perhaps some would find this a great fix to the MDTM issue.

This is exactly what does happen (in the freeware version and SE). In SyncBackSE you can also avoid this by using Fast Backup, and also disable the option of setting the source date & time to match the one on the FTP server.

[copart]

Very cool!

[ChrisKinsman]

Does anyone know if WS_FTP has fixed the issue in one of their patches?

I am leaning towards that server right now...

[pszilard]

I think you guys are great! Such a great program and EXCELLENT support. - I mean it. I've been looking for the "best" backup program to standardize on for years, and there is such a huge choice out there.

Now for my question - which ftp server?

I have licensed WS ftp Pro Server 3.1 (old, I know) and NETFS. I really need to use SSL and your recommended lists show Raiden and Serv-U, both of whch are within my budget.

I know you have no financial interest in either, and cannot accept responsibility if things go wrong, etc. etc. but could you just help me by giving a 1 paragraph recommendation or comparison between Serv-U and Raiden. That could save me a ton of evaluation time!!!

Thanks a 1E6 (=million)...

[mickyj]

I really need to use SSL and your recommended lists show Raiden and Serv-U, both of whch are within my budget.

I know you have no financial interest in either, and cannot accept responsibility if things go wrong, etc. etc. but could you just help me by giving a 1 paragraph recommendation or comparison between Serv-U and Raiden.

First thing is that to use SSL you must use SyncBackSE (SyncBack freeware does not support SSL).

Before the new version of Serv-U came out I would have recommended Raiden, but now they've pretty much got the same functionality. I think the only thing Raiden has that Serv-U doesn't is UTF8, but that's only of any use if you have filenames in different languages. Serv-U has a better interface that Raiden, but that's not related to features. They both have good support.

What I would strongly recommend is that you download evaluation versions of both and test them in your environment with SyncBackSE.

[pszilard]

Many thanks for the quick response! I am in evaluation mode for both Raiden and Serv-U and SyncBackSE and I am hoping to find a good solution and then purchase it.

What I really want is to have my customer use ftp to backup their data to my ftp server over broadband, giving them off-site backups. I saw from other posts that versioning is on your to do list for the next release, so that will be good.

Maybe you could comment on the following...

My customers are local to my geography, so my plan is to go on-site with a USB HDD and grab their entire file data set of around 5 - 25 GB depending on the client. Then take that back to my place and copy it to their ftp home directory. From then on use SyncBackSE to just ftp (over SSL using bought license) any new or changed files. If they need a few files restored then use ftp, and go back to USB HDD in case of a huge/total restore.

It is necessary to have the customer's data encrypted on my servers, so that they feel comfortable that their security isn't exposed.

Q1) Can I use encryption + compression over ftp link with SSL?

Q2) Can SyncBack manage to backup changed/new files only, if the initial backup was not through ftp? I can of course use SyncBack to make the USB HDD backup, which is then transferred to the ftp server's HD?

Q3) Can all this be done when using encryption + compression???

Any other useful thoughts?

Thanks in advance,

---------------------
Just got your reply to the same questions from my Support Ticket. Feel free to paste your reply here so others can read it, or delete this post. As you wish.

Thnx.

[mickyj]

1) SSL is encrypted, and if the FTP server supports MODE Z then it's sent compressed. If you mean you want to store encrypted & compressed files on the FTP server then you need to create two profiles: one to compress & encrypt the files to a local directory, and one to upload them to the FTP server. You then put both into a group and scheduled/run the group.

2) If the last modification date & time isn't changed then it will only transfer new/changed files.

3) Yes, see point 1

If you have other questions it would be best to create a new topic in the SyncBackSE forum as this topic is about FTP servers tested with SyncBack freeware.

[laurel]

FileZilla 0.9.0 Server: Works, but when trying to retrieve locked files there is a read-timeout delay of 15 seconds per locked file. Note that the newer version (0.9.1b) does not work. Also, setting file date & time using MDTM is not supported.

When I backed up to FTP, ALL my local file dates changed to the backup date. We can no longer search by date modified, etc. This is a huge problem for us. Is there a way to fix the changed file dates? Is there a way to stop this from happening in the future. I have ended my trial of this product until I can resolve this problem.

[mickyj]

Hi, this is a frequently asked question:

http://www.2brightsparks.com/help/index ... id=92&c=16

[laurel]

Hi, this is a frequently asked question:

http://www.2brightsparks.com/help/index ... id=92&c=16

Oops! Bad search. Thanks.

[TheRealWaldo]

An interesting note that I've unfortunately been severally affected by:

If the FTP transfer of any file is interrupted, be it by a bad connection, a system error, a server flaw, a bad network card, interference in the case of using wireless, or otherwise, the file as it was transferred to the server (even if not all the way) will still have the last modified date of the exact moment the connection was broken, making it always newer than the local copy.

Since this software does not log these incomplete transfers and does not take them into account apon exiting/terminating the process/ending the synchronization or timing out; the next time a synchronization is run, the local (good/complete) copy is overwritten with the remote (bad/incomplete) copy of the file, thus destroying both copies of the files (permanently I might add, without insanely good recovery software), since they are overwritten.

I have no idea if the ability to recover from this very common issue was thought of, but it is certainly critical. Preventing it with a database of transfers in progress/completed/incomplete would be a much better idea in my mind.

Also, FTP transfer resuming would be a super handy feature for synchronizing large files. Transferring the same 200MB over, and over again can be really hard on a network, not to mention expensive on the bandwidth end.

It'd also be handy to support differential updates, but with current FTP technology, it'd be kinda rough.

Let me know if there is a fix in the near future, it's unusable when my data is in jeopardy!

W.