On Thu, 03 Feb 2005 19:27:34 +0000, Steve wrote: > > 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 :(
> OK - I also admit that partimage would be a superior choice to dd... > 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. It depends on what you are insuring against. To cover drive failure, a partition image is best,and fastest to restore a whole drive. I make partimage backups from time to time. To insure against operator error, such as deleting a file, overwriting a working config with a broken one etc, file based backups are better. So you really need both. > 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. That's an issue with rsync, but not with rdiff-backup, which keeps older files. You can restore older versions of files, or deleted files for as long as they stay in the backup. > 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...] You can use a procmail rule to send a copy of a mail to a backup file. :0c: /mnt/backup/mail/$USER.backup > Do we still disagree? :-) Not now, but I'm sure I can think of something, given time ;-) -- Neil Bothwick Loose bits sink chips. -- [email protected] mailing list
