Backup strategy for large mailbox stores

[Michael Menge]

Hi,

Quoting ram <ram at netcore.co.in>:

> We have cyrus servers deployed at many places where clients have varying
> mail storage.
> We have been taking backups to help in situations of  human errors
> ( where you get complaints like ..oops, I accidentaly deleted all my
> mails!! )  and in case of hardware failures
>
> Things have been working fine but off late we find that emailusage has
> grown and so our backups take too long to complete .. we use dar to take
> differential backups and take backups everynight. and transfer the
> backup files to a remote server.
>
> If the backup is still running in the morning people notice a
> considerable degradation of the server performance
>
>
> Is there a better strategy , probably within the cyrus framework , to
> take backups efficiently
>

You can use deleayed expunge and replication.

Delayed expunge (see expunge_mode and delete_mode in imapd.conf) keeps
the deleted mails on disk for some time depending on the cyr_expire -X
option.

With replication you have a nearly realtime copy of the mailserver for
disaster recovery. You also can use this copy to do the backup. As there
are no people working on this server in the normal useage performance loss
does not affact the users.

PS.: you didn't mention the version of cyrus you use, but deleayed expunge
and replication  are both features from Cyrus Imapd 2.3.x, with many bugfixes
in the last versions, so you should use 2.3.16


--------------------------------------------------------------------------------
M.Menge                                Tel.: (49) 7071/29-70316
Universität Tübingen                   Fax.: (49) 7071/29-5912
Zentrum für Datenverarbeitung          mail:  
michael.menge at zdv.uni-tuebingen.de
Wächterstraße 76
72074 Tübingen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5339 bytes
Desc: S/MIME Signatur
Url : http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20100215/736ec568/attachment.bin