Someone in the forums recently asked about ways to migrate individual accounts from one ZCS instance to another, so thought I’d share the enlightenment with all. Whether you are going from an on-premise install to a hosting provider, want to create handy archives of old employee accounts, or just need to duplicate mailbox contents of a user; the syntax in this article proves remarkably useful, and applies to all editions.
There are a multitude of comparable RFE’s on addressing this need via different approaches. (Bugzilla entries 19630, 29573, 28443 & 30163 to name a few.) Some want graphical tools to browse data and selectively migrate certain things, while others would be happy with a cross LDAP zmmailboxmove.
Depending on your situation, several backup tools can take care of a large portion of your daily needs; and there are ways to do Zimbra-to-Zimbra migrations using the Network Edition’s backup and restore capabilities – however they require admin abilities on both systems. Meanwhile, most of the frequently used open source backup solutions are simply an “all accounts at-once” approach. So what to do when you need to move from your personal setup to a hosting provider? Or if you’re a hosting provider, move a tiny handful of accounts to a separate infrastructure? Before diving into the wiki on user migration for info on Imapsync, REST exports, CURL imports, etc; there’s a handy way to avoid the “one item type at-a-time” transfer methods.
In ZCS 5.0.9+ you can export an entire mailbox with:
/opt/zimbra/bin/zmmailbox -z -m firstname.lastname@example.org getRestURL “//?fmt=tgz” > /tmp/account.tgz
Next transfer via rsync, scp, sftp, etc. You’ll also need to create the account on the 2nd server if the desired account doesn’t exist at your destination server yet.
Then import with:
/opt/zimbra/bin/zmmailbox -z -m email@example.com postRestURL “//?fmt=tgz&resolve=reset” /tmp/account.tgz
The resolve= paramater has several options:
- “skip” ignores duplicates of old items, it’s also the default conflict-resolution.
- “modify” changes old items.
- “reset” will delete the old subfolder (or entire mailbox if /).
- “replace” will delete and re-enter them.
‘Reset’ will be a bit faster on an empty destination mailbox because it skips most dupe checks.
Note: There were some duplication fixes and additional issues (mainly sync related) corrected with the tar formatter in 5.0.10.
Not a Zimbra Admin? Users can get the same zip/tar formatter on REST URL’s by visiting:
The zip format has been around for a long time, but doesn’t contain account & item metadata like the tar formatter automatically does:
Infact, this same technique is currently used in Zimbra Desktop’s alpha backup solution.
If this approach doesn’t scale performance wise for your situation, or you simply don’t want to have everyone hit a REST URL for 30GB mailboxes all at the same time, here’s a collection of helpful scripts and other ways to systematically migrate:
Mysqldump & rsync with an interesting blob management technique: Zimbra2Zimbra
Imapsync for mail + postRestURL for contacts, calendar & filters: ZimbraMigrate (Expand the concept for tasks, documents, and briefcase items.)
Another method that could be extrapolated upon for migrations: Per User Mailbox Backup (OE Version – Zimbra :: Wiki)
Most of these solutions aren’t going to respect share permissions, but when pulling an account out of an environment that’s to be expected.
– Mail backup options for end users (.eml)
– Zimlet to save email in a txt file (.txt or html)
The above Zimlets are aimed at making quick self-copies & not for restores, but there are many methods for putting messages back into Zimbra, including tools like zmmailbox addMessge, zmlmtpinject, CURL, etc; for more info checkout these threads: Recover data from store folders & Moving Folders between users
If moving your entire server, I’m a huge fan of the install.sh -s trick when using NE backups to do so isn’t an option.