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@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 Maildirbackups, i usually exclude the files "dovecot.index*".
On the most common situations, you'll need to restore just one orother 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 thewhole 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