Hi,
Quoting Albert Shih <albert.s...@obspm.fr>:
Hi everyone
I've a question about DRP (Disaster Recovery Plan), what's the easiest (=
fastest) way to rebuild a server (with the data) after a server «
disappear » (fire,
water flood, etc.).
I see three way to « backup » the data :
Replication,
Backup service (inside cyrusimapd 3),
Filesystem backup (whatever the technic)
For replication my concern is the speed of the replication, the main server
(I got only one server) got lots of RAM, got SSD, and SAS disk, the
replication got SATA disks (lots of RAM too). When I check I think
everything are indeed replicated on the « slave » but with some delays
(1/2 days).
We have distributed our users across 6 (virtual) servers in an cyrus
2.4 murder setup. The servers
are grouped in pairs, so that one is running on hardware in one
building and the other in the other.
On each server there are 3 cyrus instances running, one frontend, and
one backend and one replic.
In case of disaster, or planed maintenance we will start the replic as
normal backend (we use service
ip addresses for each backend and move this ip to the other server so
we don't have to update the
mupdate master mailbox.db.
The rolling replication is able to keep up. So normally there is only
a small delay (2-5 Secs). If there
is a traffic peak (many newsletters) it may take up to 1-2h. I have
only seen longer delays in case of a
corrupt mailbox where the replication bailed out. We are monitoring
the size of the replication log.
We have ~ 41000 Accounts ~13.5 TB Mails, The VMs are running in an
RHEV System.
Each Server has 20 GB Ram, 8 CPU-Cores, the Mails are stored on
EUROstor iSCSI Systems with SATA disks
Recently we migrated the metadata onto a new EUROstor iSCSI System
with SSDs. At the moment we plan to migrate
to Cyrus 3.0 to use archive partitions so that the recent mails will
be stored on a iSCSI System with SAS disks,
and the older mails will be moved to the old iSCSI system with SATA disks
In addition to the disaster recovery plan we use "expunge_mode:
delayed" and "delete_mode: delayed" and normal file based backup for
the "I deleted my very importent mail by accident" use case.
Regards
Michael Menge
--------------------------------------------------------------------------------
M.Menge Tel.: (49) 7071/29-70316
Universität Tübingen Fax.: (49) 7071/29-5912
Zentrum für Datenverarbeitung mail:
michael.me...@zdv.uni-tuebingen.de
Wächterstraße 76
72074 Tübingen
----
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
