Re: Maildir backup
On Tue, 27 Jan 2009, Marek Podmaka wrote:
> What do you use to backup maildirs? For normal backup I use
Maildirs (when properly implemented) are always modified atomically,
so they are coherent at all times. At least when broken NFS setups
are not part of the picture.
That means you can use pretty much ANYTHING you want to backup them.
New rsync is acceptable. So are volume snapshots. Even tar would do.
But you want something that does differential backups, otherwise you
will waste extreme ammounts of backup media space (be it disk, tape,
or whatever).
Also, make sure to use something that doesn't screw with the atime if
whatever you use to read that maildir cares about atimes.
> rdiff-backup over network to different server. But don't know how to
> backup mailserver which has 146 GB of maildirs in 920.000 files. Of
We manage to do >1TB spools (with millions of files) with amanda, and
it works well. Maildirs are very backup-friendly. In out case, it is
not maildir but Cyrus IMAPd spools, which are similar to maildir, but
not atomic... so we always rebuild the cyrus indexes and caches for
any mailbox we restore from backup.
> able to cope with such huge amount of files? And would be better to
> run it for example every hour or only once per day? Or maybe run it
Depends on how much mail you're allowed to lose in case of a major
crash, doesn't it? But if you do very frequent backups, you need much
bigger rotation schedules, otherwise files will be gone from the
backup before the users notice they want them restored...
And differential backup becomes a MUST for frequent backup runs.
Also, remember that there are two types of new messages on a IMAP
spool: those that arrived via the MTA, and those that the IMAP cliend
uploaded to the spool. Your requirements for "not allowed to lose in
case of crash" might be different for those two classes of messages.
Maybe getting the MTA to store copies of all mail received on the last
24H somewhere is enough to avoid the need for backups every 5 minutes,
and you can get away with spool backups only once a day, for
example...
> from LVM snapshot? The main problem to overcome is too many files
> and filesystem with too many changes all the time.
You will find that the IO load and CPU load of going over that
filesystem is going to be the worst part of it (unless you have enough
RAM that the entire inode tree is in cache).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: