Neil Bothwick wrote:
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.
I like being the less up-to-date - it is more interesting. :-) I've
rdiff-backup on my list of man-pages to read.
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
Of course, but (I ask provocatively) - won't that use mailbox rather
than maildir format -hence introducing complications of locking? Isn't
there an issue in getting this to be a system wide setting not a
per-user thing? For a mail server with centralised administration -
isn't something closer to the MTA more appropriate?
[BTW - you didn't solve the archiving bit :-P ]
Do we still disagree? :-)
Not now, but I'm sure I can think of something, given time ;-)
That's good - people who agree with me are usually dull. :-)
Steve
|
