On Fri, Nov 15, 2019, at 5:12 PM, Deborah Pickett wrote: > Semi-related questions about how Cyrus backup servers deal with deleted > stuff. > > I have the following settings on the main mail server: > > deletedprefix: DELETED > delete_mode: delayed > expunge_mode: delayed > > My first question is about deleted folders. Scenario: I delete a folder > on the server, and it is renamed into the DELETED namespace as > expected. I cannot back these folders up to the backup server. They > are not enumerated during "XBACKUP * channel", and if I name the DELETED > namespace explicitly I get the following output: > > x xbackup DELETED/* rsync > * NO MAILBOX polyfoam.com.au!DELETED.rawmaterials.Trash.Downer > EDI.5DAD45A0 (Mailbox is locked) > * NO MAILBOX polyfoam.com.au!DELETED.support.Has Spaces.5DCA22F4 > (Mailbox is locked) > x NO Mailbox is locked > > (Which is not nearly the whole list either: it should have listed > hundreds of deleted folders.) > > Is this expected behaviour? I suppose that my backup has a copy of this > folder in its original location before it was deleted, so no one will > miss these folders, (though I can imagine scenarios where a message > arrives and is quickly put into a folder which is then deleted, and this > message will never touch the backup server). Hmm. With rolling replication to the backup server, these will be replicated as RENAMEs from "original" to "DELETED.original.hextimestamp", while remaining in the original user's backup. After "cyr_expire -D" deletes these folders from the mail server, then they will replicate as UNMAILBOXes, and the backup server will mark them in the index as having been deleted at the time the UNMAILBOX is replicated. Eventually, after a further backup_duration_days has passed, the messages in them will become eligible for compacting out of the backup (providing they're not also in some other folder where they are still valid), which will take effect according to the usual compact rules when ctl_backups compact runs. If it was a quick arrive-file-delete, it would eventually replicate as a new mailbox (already called DELETED.*) with all the messages, so nothing would be missed. But without rolling replication, or with mailboxes that were already DELETED.* before the backup service was configured, I'm not sure what to expect. I'm not sure if this is a case that I considered and did something for, but have since forgotten about, or if it's a case that I hadn't considered yet. What happens if you xbackup the user(s) they belong(ed) to, rather than the DELETED.* mailboxes directly? Does sync_client correctly detect them as renames, and replicate accordingly? If not, what if you sync_client -u them manually? If that doesn't work, what about sync_client -m with the DELETED.* names? If none of these work, I probably need to implement something... > My second question is about deleted users. Scenario: A user "alice" > departs the company, and I delete their root mailbox on the main > server. It is no longer enumerated during "XBACKUP * channel". > > What will happen to the backup file a/alice_XXXXXX on the backup > server? Will it stay there forever? Do I need to manually delete it? > Do I need to manually remove alice from /var/lib/cyrus/backups.db? I > suppose I can use "ctl_backups list -t" to detect such files. With rolling replication, the deleted user would eventually replicate as an "UNUSER", to which backupd would report success and ignore... Basically, the implementation hasn't gotten as far as removing backups -- and I want to see things working correctly and safely before I even think about starting to implement it. In the meantime, "ctl_backups list -t" is a pretty good way of identifying candidates to (thoroughly check and then) delete manually. You're right, you'd also want to remove their entry from backups.db, which you can do safely using "cyr_dbtool delete". > Any other things I should be aware of? I guess at this point you're deeper into the woods on this than anyone else has been (which is why it's called "experimental"!). For me, it's great that you're trying stuff and shaking out the issues, but you're probably gonna find more, not less, as we go along Cheers, ellie ---- 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
