Thanks Chris, Clement and Mike
I am posting this to both rdiff-backup group and the rsnapshot group so
experts from each group can comment.
That seems to be a really good summary of the differences. I am now left
with a tough choice - which really results from fundamental problems
with heterogeneous networks - rather than any limitation of either tool.
It seems to me that rsnapshot has an "almost fatal" flaw if there is a
need to store linux files on a windows file-system. If I understand
correctly - it doesn't keep any separate metadata - so things like file
ownership cannot be retained if (say) a backup repository for a linux
system is kept on a windows system. There are probably also problems in
the other direction.
Here is a wacky thought to work around this problem...
Might it be possible to use a "loop device" or something like that to
create an ext3 file-system within a cifs file on a windows server?
rsnapshot could then keep its backup repository in that ext3
file-system. Would this solve the metadata problem when keeping a linux
snapshot repository on a windows machine? Are there any obvious pitfalls
in this approach? I guess windows couldn't see the backup files
directly, but Linux could expose them as samba files if required.
I doubt there is a similar solution for storing windows files on a linux
file-system?
rdiff-backup has a couple of "undesirable" features for my application.
If I understand correctly - you cannot have backups kept at reducing
frequency as they age. If you need (say) daily backups for short term
reasons - you have to keep daily backups for as long as you want to keep
backups. I guess the only way around this is to keep several different
rdiff-backup repositories - with different frequencies and different
final ages. This would greatly increase the storage requirement.
I am using maildir rather than mbox format for mail - so I guess there
will be little advantage to either approach for mail system backup.
At restore time - especially after a major failure - rsnapshot has the
advantage of a simple repository which can be restored with off-line
tools etc. My wacky idea (above) probably reduces this simplicity.
Decisions... decisions...
Richard.
Chris Wilson wrote:
Hi all,
On Mon, 28 Apr 2008, Mike Marseglia wrote:
A quick google turned up the following from
http://www.backupcentral.com/components/com_mambowiki/index.php/Rdiff-backup:
...
Disadvantages
Let’s be honest: rdiff-backup has some disadvantages too:
Speed
rdiff-backup consumes more CPU than rsync and is therefore slower than
most rsync scripts. This difference is often not noticeable when the
bottleneck is the network or a disk drive but can be significant for
local backups.
I would add the following:
rdiff-backup uses a lot more network bandwidth than rsync. About 1GB per
100GB covered per backup, in my estimate, in addition to the deltas. This
makes it too slow for us to use for daily offsite backups (uploading over
a 384kbit DSL, backing up about 500GB daily).
rdiff-backup is a bit fragile. It's easy to corrupt the metadata, for
example if the store disk gets full, or multiple backups run to the same
destination at the same time, and usually impossible (i.e. nobody knows
how) to recover the history after that happens.
rdiff-backup does not allow one to remove an intermediate increment (for
example if a large file accidentally got backed up that shouldn't be) or
to remove a subtree of the backup (at least not without risking metadata
corruption again).
With rsync scripts, all past backups appear as copies and are thus
easy to verify, restore, and delete. With rdiff-backup, only the current
backup appears as a true copy. (Earlier backups are stored as compressed
deltas.)
For me, this is a mixed blessing. Large numbers of small files take a lot
of space on the remote server (as with rsync too), and you can trash your
backup by accidentally modifying files in the remote repository. But it
has been useful in emergency recovery situations where I have had to boot
from a recovery CD that didn't have rdiff-backup on it.
I do like rdiff-backup and I use it extensively, but these are things that
I wish for that would make it even better.
Cheers, Chris.
------------------------------------------------------------------------
_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki