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