Quoting Bob Miller bob@computerisms.ca:

Hi,

...

Suggestions and warnings are most welcome.

Thanks!

Since you're using maildir, you might want to check rsync out as well, especially with --link-dest. In short, you call rsync on your backup machine like this:

rsync --link-dest=previous-backup-dir source new-backup-dir

check out rsnapshot.  Tried, tested, and true on my systems for justshort of a decade now...

rsnapshot was great until the filelists got too long for me.  Scripted ZFS snapshots &B send/receives were my solution.

Rick

On Tue, 01 Jul 2014 00:52:56 +0200 Jiri Bourek bourek@thinline.cz wrote:

On 1.7.2014 00:28, deoren wrote:

...

I'm still pretty new to running a mail server, but one thing I've come to appreciate over the years is a good backup strategy. Since I have always run my own servers for practice and for personal use I don't have access to Enterprise backup solutions. Because of that I usually just fall back to scripts and tarballs and offload the content on a regular basis.

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.

I went with Maildir format because based on my reading it is referred to as time tested and corruption resistant. Because individual emails are stored as separate files this also leads me to believe that a version control system (Git, SVN) would allow for easy point in time restores.

I'm also going to research the GNU tar utility's support for incremental archives as that sounds promising.

Suggestions and warnings are most welcome.

Thanks!

Since you're using maildir, you might want to check rsync out as well, especially with --link-dest. In short, you call rsync on your backup machine like this:

rsync --link-dest=previous-backup-dir source new-backup-dir

This compares current files with their copies in previous backup. All files which didn't change are hardlinked, saving storage space.

This is pretty much what I do. I have a backup server that rsync pulls off the Dovecot Maildir on my desktop. With a backup server, most of the processing is done on the backup server: the box with the Maildir is only being read. For reasons I've long since forgotten, in order to keep hardlink increments to old backups, I use a separate cp -al on the backup server instead of doing --link-dest=previous-backup-dir.

Theoretically, I should shut off the fetchmail that feeds my Maildir before doing such a backup (and probably shut down Dovecot too). But I'm the only user, so...

A few days ago I deleted my whole INBOX and rsync'ed it back in a matter of minutes.

Here's some info on my backup system: http://troubleshooters.com/lpm/200609/200609.htm

If anyone's interested in backing up to Blu-Ray, here's some info I wrote:

http://www.troubleshooters.com/linux/blu-ray-backup.htm

SteveT

Steve Litt * http://www.troubleshooters.com/ Troubleshooting Training * Human Performance

On 7/1/2014 4:48 AM, Infoomatic wrote:

...

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. Second that. It's great tool that keeps an actual sync (rsync-based) of the data-directory and the metadata (delta) in a seperate directory to restore data from any date.

Alternatively, you might want to take a look at bacula, which was faster in most cases (development seems to have stalled, but there is a fork I have not had time to take a look at: bareos). However, I liked the rdiff-backup way because I can restore files via scp or rsync (most of my requests were like "please restore from yesterday") or if I want to restore data from a certain date I can use rdiff-backup from command line (bacula is much more complex, and you need the admin tool to restore files - rdiff-backup works from command line locally or via ssh/keyauth)

I looked at Bacula/Amanda - which are great systems if your focus is tape or backup to disk. But neither of them had good support for "backup to disk, rsync to offsite".

rsnapshot / rdiff-backup are just better at creating backups which are rsync-friendly over the WAN. Which also means you can easily push the backups to USB drives without having to wait hours and hours.

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 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 :)

--

Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br

Minha armadilha de SPAM, NÃO mandem email
gertrudes@solutti.com.br
My SPAMTRAP, do not email it

Em 01/07/14 09:06, Jiri Bourek escreveu:

...

 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.

 Anyway, for those not running a that critical system and can afford 

for an extra half hour of slowness, i really think the tip worths. And for those who, by any reason, cannot afford that extra storage space as well.

 But you're right, it's all a matter of calculating how critical 

your mission is and take the correct decisions for it.

--

Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br

Minha armadilha de SPAM, NÃO mandem email
gertrudes@solutti.com.br
My SPAMTRAP, do not email it

Em 01/07/14 10:06, Eliezer Croitoru escreveu:

On 07/01/2014 03:06 PM, Jiri Bourek wrote:

...

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.

Building the index as far as I remember doesn't cost in downtime but in higher I/O usage which slows down the server.

 That's my knowledge as well. Rebuilt of indexes are done on-the-fly 

when the account is accessed and, thus, there's no downtime involved on that.

 Of course, with lots of big accounts and lots of initial accesses 

on the scenario where ALL accounts were restored without indexes, the I/O increase can be so high that the server will be basically unresponsive. That can happen for sure.

 But on the more common case, which will be restoring just a few 

accounts, that I/O increase will probably be unnoticable.

--

Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br

Minha armadilha de SPAM, NÃO mandem email
gertrudes@solutti.com.br
My SPAMTRAP, do not email it

On Tuesday 01 July 2014 09:55:37 Leonardo Rodrigues did opine And Gene did reply:

Em 01/07/14 10:06, Eliezer Croitoru escreveu:

...

On 07/01/2014 03:06 PM, Jiri Bourek wrote:

...

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.

Building the index as far as I remember doesn't cost in downtime but in higher I/O usage which slows down the server.

 That's my knowledge as well. Rebuilt of indexes are done

on-the-fly when the account is accessed and, thus, there's no downtime involved on that.

 Of course, with lots of big accounts and lots of initial accesses

on the scenario where ALL accounts were restored without indexes, the I/O increase can be so high that the server will be basically unresponsive. That can happen for sure.

 But on the more common case, which will be restoring just a few

accounts, that I/O increase will probably be unnoticable.

And I just got a reply from the amanda list, it IS possible to construct a "dumptype" to do that via callable scripts, see:

http://wiki.zmanda.com/index.php/Script_API

No clue if bacula or the others are that well equipt.

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

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