Re: Backup methods

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

[Index of Archives]     [Cyrus SASL]     [Squirrel Mail]     [Asterisk PBX]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [KDE]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux