Backup methods

[Anatoli]

Andrew,

 > For a small system with a few hundred mailboxes, a simple unix 
filesystem backup is sufficient.  You can dump the Cyrus mailboxes.db to 
a flat file every hour with cron (keep a few days worth).  Backup 
everything with your regular backup system (tar, rsync, etc).
 > If you suffer a complete loss of the system and have to restore from 
the backup, you won't care much about a few database file 
inconsistencies, which can be repaired with Cyrus' reconstruct tool.  
You would recover the whole backup, recover mailboxes.db from the most 
recent flat file export, and then run reconstruct on every mailbox.

Yepp, this is how I was (and is) doing it (hourly), so if one backup has 
something unrecoverable, I can check a previous backup (-1hr) and 
luckily it'll be in a better shape. So on the one hand this is something 
that "works", yes.

On the other, recently I've started using Cyrus xDAV functionality that 
permits to store files, calendars and contacts (BTW, some minor issues 
apart, it works great!). All this information, if inconsistent, is more 
difficult to deal with. It's more fragile than mails. Also, changes to 
this data are more important and happen with higher frequency (I have an 
accounting client where 4 users make a couple of hundreds of changes to 
a single xls file per day over Cyrus WebDAV).

It's in pre-production state in my deployments right now, but I suspect 
that to bear some inconsistencies or restore a -1hr backup would not be 
an acceptable policy for this type of data.

Regards,
Anatoli

*From:* Andrew Morgan
*Sent:* Friday, May 11, 2018 02:05
*To:* Anatoli
*Cc:* Info-cyrus
*Subject:* Re: Backup methods

On Fri, 11 May 2018, Anatoli wrote:

>> There may be an argument that could be made for 2 backup stratagies
>
> That's the point. In the context of SME environments (Small and 
> Medium-sized Enterprises, i.e. from 5 to 50 employees normally, up to 
> 250 in some countries) that we were talking about, a replication is an 
> overkill, IMO. But for large enterprises like MNCs, large 
> universities, public mail providers (Fastmail) of course multiple 
> masters and backups via replication is the way to go. For large 
> deployments there are good backup solutions in Cyrus, but for the 
> small businesses admins I don't know any to recommend.

Anatoli,

I think you're making this harder than it needs to be...

For a small system with a few hundred mailboxes, a simple unix 
filesystem backup is sufficient.  You can dump the Cyrus mailboxes.db to 
a flat file every hour with cron (keep a few days worth).  Backup 
everything with your regular backup system (tar, rsync, etc).

If you suffer a complete loss of the system and have to restore from the 
backup, you won't care much about a few database file inconsistencies, 
which can be repaired with Cyrus' reconstruct tool.  You would recover 
the whole backup, recover mailboxes.db from the most recent flat file 
export, and then run reconstruct on every mailbox.

If you need to recover some messages or mailboxes that were deleted by a 
user, then just recover those individual files or directories from you 
backup.  Run reconstruct -rf on the mailbox.

Naturally, delayed expunge and delayed delete are fantastic ways to 
avoid all this work.  Purge them only after a few weeks or a month has 
passed. It is much easier to restore using those delayed delete/expunge 
features.


Thanks,
     Andy



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20180511/40ced5b4/attachment-0001.html>