|
> 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 ofdata 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@xxxxxxxx Heure local/Local time: Thu May 10 22:27:22 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
