Backup methods

[Albert Shih]

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 at obspm.fr
Heure local/Local time:
Wed May 9 12:58:16 CEST 2018