DeltaCopy

To put it simply, DeltaCopy is broken. There is nothing wrong with rsync itself but the Cygwin "port" is broken. In fact, anything that using Cygwin will be broken.

Cygwin can not handle UTF-16 so it will not be able handle encodings on Windows, even if Cygwin can handle UTF-8. Any non-ASCII characters in filenames will not be understood by the program: "file has vanished.".

Deltacopy server run as SYSTEM by default, all files copied has the permission SYSTEM, which even Administrator cannot touch. You can try to fix it by taking over the backup directory permission and then run the server as Administrator. BTW, the suggested method of "chmod -r 777 ." which may be interpreted as "anyone has rights to read/write/execute", for unknown reason did not work for me. I had to take permissions as Adminstrator of the backup directories in order to access it.

Deltacopy settings are saved to the install directory "c:\Deltacopy" as suggested, which only Administrator has access to. Running the client as non-admin cannot change/save any settings and will not function properly. As such, even the client need to run as Administrator.

It depends on the Windows scheduler, again Administrator level required. Since Deltacopy cannot handle UTF-16/UCS2, any non-ASCII file paths are mis-interpreted and the default retry count (5) will keep wasting your time.

In the system log, only rsyncd shows up and not DeltaCopy. However, rsyncd is spamming the log with tons of nonsense.

What about performance? Since the whole thing is broken, it did not matter. However, I have tried Syncrify ( from the same company that makes DeltaCopy ) before I test out DeltaCopy, I should point out their performance characteristics.

Deltacopy is not memory intensive when started: about 4-8M when started. When working on "My Documents" directory of 18,000 files, it jumped to 40M usage. Both server and client jump to about 40M of memory, which is normal.

Disk I/O performance is normal and nothing spectacular, since it won't be able to read MFT or the change journal on NTFS directly. It is 4 times slower than a small program I wrote to synchronize directories for private use: a C++ program with Javascript scripting embedded: Deltacopy took 4 minutes, my program took 50 seconds. Perhaps the Cygwin overhead is killing the performance.

The actual copying of Deltacopy is fast, because of rsync. Both the server and the client is running rsync, which is cpu-intensive and is normal. If you use Deltacopy in a day to day fashion, you will still notice it is hogging your system. If the server and client are installed on different machines, the hogging will be lessen.

Now that Deltacopy is really broken, they make another product name Syncrify, for better or worst it is written in Java. Both the server and the client are memory hog: about 40M when started and idle, both of them will jump over 100M+ when working. Both of them will be I/O intensive: if both the server and client are installed on the same machine, Syncrify will hog the system to a halt. Since it is Java, it is capable to CRAWL on many platform, just don't expect it to fly. The end result is that Syncrify is not running on any platform, at least not mine. Well, for a total of 30minutes, to be exact.

Syncrify does offer a lot of features such as versioning and restore individual files. Does Syncrify work? Yes: if you don't mind Java using up a ton of memory, slowing your system down to an i386 XT level, go right ahead.