[rdiff-backup-users] Interesting Product That is Similar to Rdiff-Backup in Effect

[Richard Steven Hack]

I recently was testing various versions of rdiff-backup for use on 
Windows, but everything appeared to have problems either with large 
files > 4GB or other issues.

Then I found Vembu Storegrid: http://www.vembu.com/

This product states that it uses the rsync algorithm to transmit file 
changes over the wire. This is reasonable because they have a version 
for ISPs where obviously backup of files over the Internet can benefit 
from using the rsync algorithm. They call their version "Intelli-Data".

However, perusing the forum, where a more detailed description is 
available in response to queries, it appears that they actually do store 
only the delta diffs of the file as well as the original file, with 
version information and date/time.

This means the product is actually similar to rdiff-backup in its backup 
method.

This is important because I emailed the company asking them about large 
file support and they explicitly stated that they have tested it with 
files of up to 40GB. They didn't mention that it was a form of 
rdiff-backup, only that it used the rsync algorithm.

The product costs only $30 per PC, with an additional $20 for an open 
file plugin. They also have a free version which works on a maximum of 3 
networked PCs (the product is network aware and detects more than 3).

The product can be run in server mode, client mode, or both, and can be 
run as an application or a service under Windows. Versions are available 
for Windows, Linux, FreeBSD, and Mac OS X.

Just a heads up for anyone looking for an rdiff-type backup for Windows 
that can handle large files.

I'm currently attempting to test it on large video files. However, it 
seems that re-rendering the file (perhaps after deleting some frames or 
whatever) appears to cause the product to treat the file as requiring a 
complete backup.

This raises a question: if you delete a section of a file, I would 
expect the rsync algorithm to still be able to detect and transmit only 
the changed bytes, due to the "rolling" nature of the checksum. Surely 
rsync doesn't depend on the specific location of the bytes in the file. 
Why would re-rendering a video file onto itself change so much of the 
file that the rsync algorithm would detect all the bytes as changed?

Or am I completely wrong about how rsync works?

Any ideas?