Albert.Shih at obspm.fr
Wed May 9 07:20:45 EDT 2018
Le 09/05/2018 à 11:42:35+0200, Niels Dettenbach a écrit
> Am Mittwoch, 9. Mai 2018, 11:19:54 CEST schrieb Albert Shih:
> 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.
Okay. I'm totally new on Cyrus...so..
> 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.
I'm not sure what you mean by « fetch » ? And how can you make sure the
databases are consistant ? Do cyrus have something like « database lock » ?
So I can sure the snapshot I take are good ? In fact that's why I thinking
about shutdown the VM. For example with pgsql I've got a pg_dump_all but I
don't see something similar with cyrus.
> Beside this and depending from your needs you may take a look at cyrus
My needs are very simple, since Cyrus got the « delayed_expunge », my need
are basically to prevent a big crash of everything (filesystem corruptions,
Before Cyrus I'm (still currently) use Dovecot where it's very simple
because everything are plain file. So I just need to do a rsync and that's
> replication features to build a "backup" or just use standard filesystem
> backup tools like tar, dumpfs etc.
What would be the difference ? I mean, which one are the easiest to use (as
backup and/or DRP).
> 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
Well that's the point, I'm not sure I know very well where are all the «
common database ». I see
> "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
No way....If a disaster come to happen I will still the simplest way to
make the service work again...
> skiplist) you may have to "recreate" indizes and database data. reconstruct -
All my DB seem to be twoskip.
> f may be your friend to "clean" up the transfer / restore.
> There are several strategies for backup cyrus - this are just a few.
Yes...that's the problem ;-)
> hth a bit.
Yes. A lot, thanks.
DIO bâtiment 15
Observatoire de Paris
xmpp: jas at obspm.fr
Heure local/Local time:
Wed May 9 12:58:16 CEST 2018
More information about the Info-cyrus