Backup methods

[Albert Shih]

Le 10/05/2018 à 10:38:28-0300, Anatoli a écrit
> > Not very sure to understand that. It's always true isn't ? If you have XTo of
> data and you want n backups you will need X*(n+1) To ?
>
> The replication as it is designed means that you create an additional (replica)
> instance of Cyrus that will be in sync with the master instance, so when you
> need to make a backup, you turn of the replica, take a backup from its data,
> then turn it on again so it comes in sync with the master. In this case there's
> no interruption to the service, you just stop a replica. But the replica will
> use the same amount of space as your master, so without even making a backup,
> you'll use 2x space. + you have to understand how the replication works, then
> set it up, control that the sync process is always working and the replica has
> the same information as the master... That's a great solution for ISP-level or
> public mail service operations, but IMO an absolute overkill for small
> deployments.

For me, if I put a replica in place it's get the role of backup. Meanning I
will put two replica and do not make another backup.

> When it comes to making a backup, the best policy IMO is to make incremental
> backups. In this case you only store the new mails + binary indexes. Once in a
> while (e.g. every month) you make a full backup, then, say, once a week a level
> 1 backup (that stores changes from the previous week, reset at lower level
> backup, i.e. every month), then daily level 2 backups and hourly level 3. This
> way you can restore up to hourly changes without using excessive amount of
> space. Of course you can compress them too (xz -9 gives a pretty good ratio).

Using ZFS, do no need to do that. Just use zfs snapshot and he going to
keep the differential at block level (much better than file level). Same as
compression. Just need to activate compression on the dataset.


>
> Uhh don't do that. Your Postfix has no problem in retaining mails if Cyrus is
> not reachable, then attempt their delivery again. I was referring to that,
> depending on the configuration of your incoming MTA, the next delivery attempt
> may be in, say, 15 minutes, so you postpone incoming mail for that time if you
> turn off Cyrus to take a backup. If you turn off your incoming MTA, the source
> MTA may have issues with delivery at all (you don't control it, you don't know
> how it's configured, when the next delivery attempt will occur, etc.), never
> turn off your incoming MTA.

Don't be a problem, I've got 2 public incoming MTA, 4 privates and the
postfix on the cyrus-server. So incoming mail, let's say gmail.com going
from gmail.com_MX to our MX, then send to cyrus-server. So if I stop the
postfix on the cyrus_server, the incoming mail going to stay on the our MX.

--
Albert SHIH
DIO bâtiment 15
Observatoire de Paris
xmpp: jas at obspm.fr
Heure local/Local time:
Thu May 10 22:27:22 CEST 2018