On 3/24/22 19:22, ellie timoney wrote:
* First, manually create the user's full hierarchy in uuid storage (using cyradm or similar), like:
createmailbox user/foo
createmailbox user/foo/Drafts
createmailbox user/foo/Trash
createmailbox user/foo/Sent
createmailbox user/foo/whatever
createmailbox user/foo/whatever/else
and so on. I assume you know better than I how to do this; please take these instructions as "the general idea", not "specific commands to copy and paste".
* Now, on the filesystem, you'll have a bunch of new .../uuid/././.../ directories, one for each of those mailboxes you just created. mbpath will be able to tell you which is which.
* Then (carefully) copy the files from each old mailbox storage directory to its corresponding new uuid one
* Finally, a recursive reconstruct of the user should then find everything? I think you won't need -f this time, since the mailboxes already exist, we're just rediscovering their contents.
Thank you Ellie! The above steps worked. I managed to completely
recover my wife's email and another so far. It isn't fast and I expect
it will take several hours for that user with 2+gb of mail and a lot of
folders and subfolders, but it works.
Under the new uuid storage, _every mailbox is stored by its uuid_. The mailbox hierarchy is not reflected in the filesystem hierarchy at all. (The new cyr_cd.sh and cyr_ls tools, as well as the existing mbpath tool, allow you to still find your way around on the filesystem if you need to.) This greatly improves performance and safety when users with multiple gigabytes of mail decide they want to rename a big mailbox or reorganise their filing -- since now all that happens is a name change in mailboxes.db, and not a massive filesystem shuffle. It also makes renaming entire accounts cheap and more atomic, instead of expensive and precarious.
The above was a very helpful explanation. Thank you for taking the time
to describe it.
We really appreciate all your help with this.
No worries, I really appreciate you trying out the beta, so we can get these kinks ironed out before release!
I believe all this mess descends from the original segfault, so it'd be really nice to get to the bottom of that. I imagine the segfault was due to some edge case mailboxes in your environment that we don't handle properly but haven't yet stumbled across ourselves.
Once this mess is cleaned up and your users can use their mail again, if you were able to reproduce the crash in a test environment and get a core dump, that would be tremendously helpful. (Perhaps by setting up a vm with 3.4, configuring it to save core dumps, restoring data from a pre-upgrade backup into it so it has the same mailboxes as one of the systems that crashed during upgrade, and then upgrading to 3.6 and hopefully reproducing the crash, with a core.) If you manage to reproduce the crash and get a core file from it, let us know, and we can provide instructions on how to examine it and what we need to see from it.
If it doesn't happen again in the course of finishing the upgrade on our
servers and I can capture a core dump, I will definitely work on trying
to recreate the problem as you suggest above.
Andy
------------------------------------------
Cyrus: Info
Permalink: https://cyrus.topicbox.com/groups/info/T9d294f89a3d1d260-M3924e1cd330589aaa895a0ea
Delivery options: https://cyrus.topicbox.com/groups/info/subscription
