Hi all,
A few random notes that might help future readers searching the list
archives, and a question at the end:
After one struggle too many with the XBACKUP feature, I've bitten the
bullet and switched to rolling replication to do my Cyrus backups. (So I
won't be raising any more issues about XBACKUP; thanks Ellie for all the
prior help with that.)
I'm now replicating from the main server (Debian 10 buster-backports,
Cyrus 3.2.6) to a backup server at another site (Debian 11
bullseye-backports, Cyrus 3.6.0) within our VPN.
The Debian 10 buster-backports package is currently at 3.2.6, which
would normally be not recent enough to safely replicate or upgrade to
3.6.0, but there's an explicit patch at
https://sources.debian.org/src/cyrus-imapd/3.2.6-2%2Bdeb11u2/debian/patches/prepare-3.6-upgrade.patch/
which ensures that the Debian package version applies a uniqueid to
every mailbox. I ran a manual check on the 3.2.6 server and confirmed
that every folder has a uniqueid and the minor version is 16. Nice!
Replication over bare IMAP runs perfectly. I couldn't get replication to
happen over IMAPS. I've got a Let's Encrypt certificate installed on the
replica, and it's installed and working, tested with imtest. But even
changing the sync_host configuration to "remote_host_fqdn:993/tls",
which has been reported to work by some users over the years, produced a
TLS library error ("Unable to get local issuer certificate") which I am
guessing is because sync_client can't see the root CA file. I didn't try
any harder to make this work; if I think that our VPN backbone is at
risk then I'll put an SSH tunnel in.
My backup plan now is to shut down cyr_master on the replica
periodically, take a filesystem snapshot offsite, and start it up again.
The master (a live server connected to by users) will pause replication
while the replica is offline, and resume when it comes back online. At
least, that's the plan, but I've found that if I just `systemctl stop
cyrus-imapd` on the replica, then sync_client on the master logs errors
like:
cyrus/sync_client[35180]: Error in do_sync(): bailing out! Bad protocol
and doesn't resume after I restart the replica. I end up having to
`systemctl restart cyrus-imapd` on the master, which resumes
synchronization but results in downtime for users.
So I've now got a line in /etc/imapd.conf:
MyChannelName_sync_shutdown_file:
/var/lib/cyrus/sync/MyChannelName/shutdown
and touching that file indeed causes sync_client to shut down
gracefully, but I don't know how to inform cyr_master to restart
sync_client again, short of `systemctl restart cyrus-imapd`, which again
results in downtime for users. Sending a SIGHUP doesn't seem to do
anything. My sync_client entry is in the cyrus.conf STARTUP section. If
I moved it to the DAEMON section, it might start up again too soon, so I
don't want that.
Does anyone have a replication-as-backup methodology that avoids
sync_client crashing, keeps it offline while the replica is backing up,
starts it up again when the backup completes, doesn't stop the master
from processing user requests, and avoids race conditions? Thanks in
advance.
--
Deborah Pickett
System Administrator
Polyfoam Australia Pty Ltd
------------------------------------------
Cyrus: Info
Permalink: https://cyrus.topicbox.com/groups/info/T2846d85f9a3f91b8-Mb9b501be91569aaa2ae8b9b3
Delivery options: https://cyrus.topicbox.com/groups/info/subscription
