Mailboxes are in Maildir format. Any good backup tips? Had success with version control?

[Lorens Kockum]

On Tue, Jul 01, 2014 at 02:06:06PM +0200, Jiri Bourek wrote:
> On 1.7.2014 13:45, Leonardo Rodrigues wrote:
> > i usually exclude the files "dovecot.index*".
> > [...]
> > On the most common situations, you'll need to restore just one or
> > other mailbox, so rebuilding those indexes wont kill the server. And by
> > excluding these, i could save 10-15% of backup space on some cases with
> > virtually no disadvantage.
> 
>
> That really depends, rebuilding indexes can increase your downtime
> for hours, so it may be better to pay a bit for extra storage space
> instead of not being paid at all by your customers.


Easy to answer that one. You are talking about two different
situations, and the solutions are different. The usual situation
is one person having lost mail (whether one mail or all his
mail), the catastrophe situation is when you as admin lose
everything. To cover both cases, keep the mail files for however
long you want/need/can, but only keep the most up-to-date
instance of the dovecot index files (maybe two if you want to
protect against corruption). That should be a lot less than
10%. I see no reason you'd need an index older than the last
known valid index even for one client, and if it's just one
client, then 1) reconstructing can't be a big problem 2) it's
just one client.

What I practise and recommend (not only for mail):

 - for the catastrophe scenario, keep at least a working day
of snapshots. Both restore speed and completeness mandate it,
and my (maybe expensive) filers (or ZFS servers) can mirror
them off-site. Integrate that cost into the disk cost as you
certainly do with RAID. (Yes, that's yet another reason you get
the "Waaah my IT guys tell me that disk space costs $xxxx per TB
but I can get a TB USB drive at WhateverMart for 1/xx of that
price!!!)

- for the individual restores, backup
non-trivially-reconstructable files for a longer term
to slower/cheaper-per-TB media, eventually compressed,
deduplicated, and/or offline.  Your cost depends on the data
size, your retention, the compression rate, your redundancy and
your churn: it's backup. Since you already have snapshots, you
can make your backup from your snapshots to preserve consistency
(and since you need snapshots for consistency, why not keep a
working day or so hanging around, right?). Bonus points for
keeping recent backups on faster storage, and staging backups
older than a week or so to cheap storage.

The only scenario I can see where I would need to very urgently
restore any significant percentage of user files to anything
but the most recent version would be some kind of not instantly
detected corruption or admin error, thus the several snapshots.

HTH, HAND