<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body smarttemplateinserted="true">
<div id="smartTemplate4-quoteHeader">
<div style="font-size:10.0pt;font-family:Verdana,Arial">Andrew,<br>
<br>
> 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).<br>
> 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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
Regards,<br>
Anatoli<br>
<br>
</div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm
0cm;font-size:10.0pt;font-family:"Tahoma","sans-serif""><b>From:</b>
Andrew Morgan<br>
<b>Sent:</b> Friday, May 11, 2018 02:05<br>
<b>To:</b> Anatoli<br>
<b>Cc:</b> Info-cyrus<br>
<b>Subject:</b> Re: Backup methods<br>
</div>
<br>
</div>
<span type="cite"
cite="mid:alpine.DEB.2.11.1805102156060.21714@shell.onid.oregonstate.edu"
style="display: block; word-break: break-all; margin: 7px 0 0 0;
padding: 0; line-height:0"></span>On Fri, 11 May 2018, Anatoli
wrote:
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">There may be an argument that could be
made for 2 backup stratagies
<br>
</blockquote>
<br>
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.
<br>
</blockquote>
<br>
Anatoli,
<br>
<br>
I think you're making this harder than it needs to be...
<br>
<br>
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).
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
<br>
Thanks,
<br>
Andy
<br>
<br>
<br>
<br>
</body>
</html>