Re: Backup methods

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Cyrus SASL]     [Squirrel Mail]     [Asterisk PBX]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [KDE]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux