[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[rdiff-backup-users] Interesting Product That is Similar to Rdiff-Backup
From: |
Richard Steven Hack |
Subject: |
[rdiff-backup-users] Interesting Product That is Similar to Rdiff-Backup in Effect |
Date: |
Mon, 05 Feb 2007 19:07:03 -0800 |
User-agent: |
Thunderbird 1.5.0.7 (X11/20060909) |
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?
- [rdiff-backup-users] Interesting Product That is Similar to Rdiff-Backup in Effect,
Richard Steven Hack <=