<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">Hi,<br>
<br>
<blockquote type="cite">
<pre wrap="">On larger systems with VMs i take a ZFS or LVM snapshot and mount it
externally to "fetch" a full (incremental) filesystem backup of the mail spool
and imap spool and cyrus db on a daily base. After the backup run i destroy
the snapshot.
</pre>
</blockquote>
<pre wrap="">The problem with this is that you can't be sure the data on disk is in sync. Depending on how heavy the load is during the "backup" (+ your luck), you may find unpleasant surprises when you have to restore it. And you'd only know that the backup is corrupted when you try to restore it.
</pre>
<blockquote type="cite">
<pre wrap="">Beside this and depending from your needs you may take a look at cyrus
replication features to build a "backup" or just use standard filesystem
backup tools like tar, dumpfs etc.
</pre>
</blockquote>
<br>
The replication is reasonable only if you have more than one
server in your deployment (and both servers with the same level
of security, if not you risk to compromise the user data) or
"spool size/available disk space" is low, otherwise you'd need
to dedicate 2 times more space than needed to store user data,
only to take a periodic backup (+ the space needed to store the
backup itself).<br>
<br>
I suggest you take a look at this issue:
<a class="moz-txt-link-freetext" href="https://github.com/cyrusimap/cyrus-imapd/issues/1763">https://github.com/cyrusimap/cyrus-imapd/issues/1763</a>, where
backups for small deployments were already discussed in detail.
Though, no idea if there are plans to implement it.<br>
<br>
Answering the OP's question, I'm using Cyrus for 4 years now and
I don't know about any reliable and reasonable strategy for
backups of Cyrus data in SME environments. Summing it up:<br>
<ul>
<li>FS snapshots without stopping the server: a possibility of
a corrupted backup.</li>
<li>FS snapshots after stopping the server: service downtime,
breaking open connections, delivery issues for incoming
MTAs, etc. - reasonable for daily backups in a 8/5 office,
unreasonable for 24/7 deployments (e.g. users distributed in
different time zones) or for intra-day backups.<br>
</li>
<li>Replication: unreasonable requirements for disk space,
setup overkill.<br>
</li>
</ul>
<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>
Niels Dettenbach Via Info-cyrus<br>
<b>Sent:</b> Wednesday, May 09, 2018 06:42<br>
<b>To:</b> Info-cyrus<br>
<b>Subject:</b> Re: Backup methods<br>
</div>
<br>
</div>
<span type="cite" cite="mid:3478185.KMnOgTfQ6c@gongo"
style="display: block; word-break: break-all; margin: 7px 0 0 0;
padding: 0; line-height:0"></span>
<pre wrap="">Am Mittwoch, 9. Mai 2018, 11:19:54 CEST schrieb Albert Shih:
</pre>
<blockquote type="cite">
<pre wrap="">I would like to know what's kind of backup method are recommended for
cyrus-imapd.
My cyrus-imapd host (only one currently) are running under FreeBSD jail
(something like systemd-nspawn, lxc) & ZFS so I'm intend to use this
method :
stop the vm
take a zfs snapshot
start the vm
send the zfs snapshot on a backup server.
</pre>
</blockquote>
<pre wrap="">
This is relatively inefficient, but a working option if anything from cyrus
data is on that VM - i.e. the complete mail spool and the database files
(possibly plus sieve files). We do similiar on relatively small systems or to
get "intraday backups" only.
On larger systems with VMs i take a ZFS or LVM snapshot and mount it
externally to "fetch" a full (incremental) filesystem backup of the mail spool
and imap spool and cyrus db on a daily base. After the backup run i destroy
the snapshot.
Beside this and depending from your needs you may take a look at cyrus
replication features to build a "backup" or just use standard filesystem
backup tools like tar, dumpfs etc.
On a file base you have to backup the mail spool and the cyrus database files.
If you use SIEVE, backup the SIEVE file pool too. You can restore by just
replacing the files and start cyrus. To get the common database files
"interoperable" it may makes sense to dump then into a machine independent
format for backup if they are in a machine dependent format.
If your restore such a filesystem based backup to a new system which has other
hardware / arch specs or newer / incompatible DB subsystem (instead of
skiplist) you may have to "recreate" indizes and database data. reconstruct -
f may be your friend to "clean" up the transfer / restore.
There are several strategies for backup cyrus - this are just a few.
hth a bit.
good luck,
Niels.
</pre>
<br>
</body>
</html>