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

[Gene Heskett]

On Tuesday 01 July 2014 08:06:06 Jiri Bourek did opine
And Gene did reply:
> On 1.7.2014 13:45, Leonardo Rodrigues wrote:
> > Em 01/07/14 00:16, Charles Cazabon escreveu:
> >> deoren <Dovecot-mailing-list at whyaskwhy.org> wrote:
> >>> Right now I'm using LVM snapshots + tarballs for daily backups, but
> >>> I'd like to get better coverage for incremental changes that occur
> >>> throughout the day. The size of existing content is low, but
> >>> (small) changes are frequent.
> >> 
> >> If you actually want to preserve those increments (as opposed to
> >> just keeping
> >> an rsync mirror up-to-date), I like rdiff-backup.  It handles
> >> maildirs well
> >> because of the one-message-per-file design.
> >> 
> >      Some may agree with me, some may disagree. But for my Maildir
> > 
> > backups, 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.
> > 
> >      And on a worst case scenario, where i would need to restore the
> > 
> > whole server and mailboxes, things will already be screwed, so
> > knowing that dovecot would be harder on I/O for rebuilding the
> > indexes will be just another problem :)
> 
> 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.

I would like to point out that in almost any situation referred to as 
backing up, if the system is active and processing mail flow during the 
backup (by any normal backup software), the database(the mail IOW) and the 
index, will be read and appended to the backup at separate times.  
Avoiding a duff index that requires a rebuild, is only going to be 
achieved if the mail system is disabled for the duration of the backup.

That leads to the question of how, even if you have 2 systems so that 
incoming mail can still be handled, how do you go about putting the two 
back into sync before switching back to the primary server after the 
backup has been done.

This seems to be a problem that has not been well addressed in any mail 
service scheme I am aware of.  Here for instance, I could kill kmail's 
local fetching for the duration, which allows the 
fetchmail/procmail/sa/clam chain to continue to collect mail in 
/var/spool/mail, while the kmail corpus is being archived, and once that 
has been done, re-enable kmail's local pulling,  that, if properly timed 
in the backup schedual would likely be at most 10 minutes of downtime for 
incoming (the corpus is around 20G's), because once thats been done, 
whatever is in /var/spool/mail can be pulled, sorted, and made available 
to the user in just a couple minutes.

That could be accomplished by disabling the script driving inotifywait, 
but I don't have a clue how to incorporate that function into amanda, 
which I use here.

Any such scheme is also likely to be highly personalized because of the 
surplus of ways to skin this cat called backing up.

But I feel it is something that needs to be addressed, if only to prevent 
the lengthy delays when rebuilding the index.  In kmails case, it doesn't 
take too long on a per folder basis, seems to be done as a background 
process the user is just barely aware of via keyboard response times.

In fact, since I am on the amanda list too, I intend to ask if such a 
feature like establishing a handshake signal to achieve this could be 
obtained from amanda.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS