Backup methods

[Anatoli]

 > 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.

A replica is not a replacement for a backup. You may have your specific 
needs, but replica per-se mostly serves to cover for master's hardware 
failures. You are not protected with a replica from accidental or 
intentional deletions/changes of the data. If a user deletes some of 
his/her mails and discovers it after the expunge period, you won't be 
able to recover them as replica would also have them deleted.

 > Using ZFS, do no need to do that

Sure, if you're using ZFS :) The solution I've described serves for any 
*nix OS and fs.


 > So if I stop the postfix on the cyrus_server

You just don't need to stop it. If you expect to stop Cyrus frequently, 
just configure the cyrus_sever Postfix retry interval to something like 
1 min.

*From:* Albert Shih
*Sent:* Thursday, May 10, 2018 17:32
*To:* Anatoli
*Cc:* Info-cyrus
*Subject:* Re: Backup methods

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20180510/d7b0994f/attachment.html>