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, loose everything...etc.) 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 all. > 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. Regards -- Albert SHIH DIO bâtiment 15 Observatoire de Paris xmpp: jas@xxxxxxxx Heure local/Local time: Wed May 9 12:58:16 CEST 2018 ---- 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
