Re: [rdiff-backup-users] rdiff-backup versus rsnapshot
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
[rdiff-backup-users] rdiff-backup versus rsnapshot
Hi I am planning a holistic backup system for a mixed windows/linux network. The system should provide for both disaster recovery and accidental deletion protection. It appears to me that both rdiff-backup and rsnapshot would do a good job for me. Could anyone provide their thoughts on the relative strengths and weaknesses of the two tools. I have posted a similar request on the rsnapshot list - and have had some response suggesting that rdiff-backup will need less storage - but may be slower with a lot of changing data. Also - that recovering specific files at specific ages may be easier with rsnapshot. Looking at the rdiff-backup documentation - it appears to me that rdiff-backup stores the change data indefinitely. If this is so - and there is no way to delete old data - I assume the historical change data will grow indefinitely. Is this the case - or have I missed something? I would value the opinions of users of this group also. Regards Richard. ___ 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
Re: [rdiff-backup-users] rdiff-backup versus rsnapshot
Hi Richard, Richard Chapman (Tuesday, 2008-04-29): It appears to me that both rdiff-backup and rsnapshot would do a good job for me. Could anyone provide their thoughts on the relative strengths and weaknesses of the two tools. I have posted a similar request on the rsnapshot list - and have had some response suggesting that rdiff-backup will need less storage - but may be slower with a lot of changing data. Also - that recovering specific files at specific ages may be easier with rsnapshot. I can't say anthing to that, because I don't know rsnapshot. But... Looking at the rdiff-backup documentation - it appears to me that rdiff-backup stores the change data indefinitely. If this is so - and there is no way to delete old data - I assume the historical change data will grow indefinitely. Is this the case - or have I missed something? ... there you missed the --remove-older-than option. Patrick. -- Key ID: 0x86E346D4http://patrick-nagel.net/key.asc Fingerprint: 7745 E1BE FA8B FBAD 76AB 2BFC C981 E686 86E3 46D4 signature.asc Description: This is a digitally signed message part. ___ 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
Re: [rdiff-backup-users] rdiff-backup versus rsnapshot
A quick google turned up the following from http://www.backupcentral.com/components/com_mambowiki/index.php/Rdiff-backup: Advantages Here are some advantages of using rdiff-backup instead of an rsync script or rsnapshot. Backup size Because rdiff-backup does not store complete copies of older files, but only the compressed differences between older and current files, backups generally consume less disk space. Easier-to-use Unlike rsync, rdiff-backup was written originally for backups. It has sensible defaults (so no need for the -av -delete -e ssh options) and fewer quirks (for instance, no distinction between destination, destination/, and destination/.). Preserves all information With rsync, all information is stored in the filesystem itself. If you log into your backup repository as a non-root user (generally a good idea), the rsync method forgets who owns all your files! rdiff-backup keeps a copy of all metadata in a separate file, so no information is lost, even if you arent root or if you back up to a different kind of filesystem. [edit] Handy backup features rdiff-backup has several miscellaneous handy features. For example, it keeps detailed logs on what is changing and has commands to process those logs so that you know which files are using up your space and time. Also, newer versions keep SHA-1 checksums of all files so you can verify the integrity of backups. Some rsync scripts have similar featurescheck their documentation. [edit] Disadvantages Lets 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. Transparency 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.) Requirements rdiff-backup is written in Python and requires the librsync library. Unless you use a distribution that includes rdiff-backup (most of them include it), installation could entail downloading and installing other files. -- Mike Marseglia [EMAIL PROTECTED] http://www.marseglia.org On Mon, April 28, 2008 12:02 pm, Richard Chapman wrote: Hi I am planning a holistic backup system for a mixed windows/linux network. The system should provide for both disaster recovery and accidental deletion protection. It appears to me that both rdiff-backup and rsnapshot would do a good job for me. Could anyone provide their thoughts on the relative strengths and weaknesses of the two tools. I have posted a similar request on the rsnapshot list - and have had some response suggesting that rdiff-backup will need less storage - but may be slower with a lot of changing data. Also - that recovering specific files at specific ages may be easier with rsnapshot. Looking at the rdiff-backup documentation - it appears to me that rdiff-backup stores the change data indefinitely. If this is so - and there is no way to delete old data - I assume the historical change data will grow indefinitely. Is this the case - or have I missed something? I would value the opinions of users of this group also. Regards Richard. ___ 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
Re: [rdiff-backup-users] rdiff-backup versus rsnapshot
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 Lets 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. -- _ __ _ \ __/ / ,__(_)_ | Chris Wilson at qwirx.com - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer | \ _/_/_/_//_/___/ | We are GNU : free your mind your software |___ 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
