Neil Bothwick wrote:
OK - I also admit that partimage would be a superior choice to dd...On Thu, 03 Feb 2005 18:06:27 +0000, Steve wrote:
Fair comment... I stand corrected that rsync/rdiff-backup are appropriate for backup of user files. This issue is an old one of trade
off between being able to make fast backups and being able to recover quickly. IMHO the dd approach is still valid and useful as it is one of the few ways to ensure rapid disaster recovery. I agree that an rsync approach permits more frequent backups to be made for user files. Maybe a better recommendation would have been a combination of dd to take an image of the install - then rsync to keep regular copies of user files.
I'd still disagree, rsync or rdiff-backup create an exact mirror of the
file tree, so you have a backup that is extremely fast to restore from,
especially for individual files. If I want an image of the partition, I'll
use partimage as it is several orders of magnitude faster than dd and
produces smaller archives.
As a backup tool dd is about as friendly as backing up to punched cards :(
I guess my only significant point is that a backup that quickly restores devices etc. is not addressed best by trying to copy files. I guess I inferred more from the original subject than you did. For a "Simple Backup" where you want to duplicate "everything" from one drive to another I remain convinced that you want to copy the partition(s) and not the files - whereas for a more ambitious incremental backup strategy of user files we agree that rsync/rdiff approaches may well prove superior.
Among the complications involved with rsync one should consider the potential consequences of a hardware failure during an update phase; the possibility that a file is accidentally deleted and the backup is refreshed before the missing file discovered.
For a mail server, I can't help thinking that the ideal solution would be some (possibly bespoke) mechanism to push emails from the primary server to a secondary server (or maybe just a secondary disk) as it arrives (possibly with a queue as necessary) and not to delete data from the secondary server when it is deleted from the first, but rather to archive the eldest data regularly in order to ensure the disks do not fill. This, however, could not be considered a simple backup by most. [Neil - you'd impress me by naming a tool that would do this 'ideal solution' without the need for writing bespoke scripts...]
Do we still disagree? :-)
-- [email protected] mailing list
