Acasă
» ADMIN. REȚEA
»
How to Migrate Zimbra Mailboxes to a New Server with Zextras Backup or imapsync
How to Migrate Zimbra Mailboxes to a New Server with Zextras Backup or imapsync
For a full Zimbra-to-Zimbra move, use a supported Zextras Backup migration workflow when you need mailbox data beyond email. Use imapsync when both servers expose the accounts over IMAP and your scope is messages, folders, and flags. Zextras says its older Zextras Migration Tool is no longer available. Its Zimbra migration guidance points administrators to Zextras Backup. Imapsync is a separate command-line option for copying IMAP mailboxes; it does not replace a Zimbra-aware migration for calendars, contacts, shares, or account settings.
That distinction determines how much you must provision and test on the new server. Before changing MX records or letting users work on the destination, confirm the source and destination versions, licensing, authentication, storage, and the exact data you must retain.
Documentation checked October 6, 2026. The official imapsync site lists release 2.314. Zextras’s migration article says the legacy Migration Tool is unavailable and describes a Zextras Backup route. Zextras pages and examples are version-dependent; validate them against your installed Zextras and Zimbra releases before a production run.
Choose Zextras Backup when the migration scope includes Zimbra collaboration data; choose imapsync for an IMAP mailbox copy.
1. Choose the route that matches the data you need
Route
Best fit
What to plan for
Zextras Backup
Zimbra-to-Zimbra migration where you need mail plus supported mailbox and domain data
Compatible Zimbra/Zextras releases, product entitlement, backup storage, and a Zimbra administrator comfortable with CLI operations
imapsync
Copying mailboxes between IMAP servers, including Zimbra, one mailbox at a time or in a controlled script
IMAP reachability and credentials on both servers, destination folder mapping, and separate migration of non-mail data
Zextras’s published Zimbra migration guide lists email and folders, contacts, calendars, tasks, shares, preferences, signatures, identities, and some domain or class-of-service data among the items its Backup workflow can migrate. It also says the workflow does not migrate server configuration, LDAP configuration, MTA or proxy configuration, or custom branding. Exact coverage depends on product versions and settings, so treat that list as a scope checklist and verify each required item in the current documentation.
Imapsync works through IMAP. It copies mailbox folders and messages and can synchronize message flags that the destination supports. It does not transfer a Zimbra server’s LDAP directory, account preferences, calendars, address books, shared resources, or server configuration. If any of those matter, plan another supported export/import method or select the Zextras route.
Do not build a new plan around the old Zextras Migration Tool: the Zextras migration guide says it is no longer available. Also avoid copying obsolete IMAP advice from archived Zimbra pages without checking it against the current imapsync Zimbra FAQ; that FAQ specifically warns that an older Zimbra imapsync guide is obsolete.
2. Prepare both servers before copying data
Make an inventory before provisioning the destination: domains, accounts, aliases, quotas, mailbox sizes, user passwords or reset plan, shared folders, calendars, contacts, distribution lists, retention needs, and the server features users depend on. Identify which host receives new mail during each phase. Keep this inventory as your post-migration checklist.
Confirm platform support. Verify the destination is installed, operating, and on a Zimbra/Zextras combination supported for your migration path. For Zextras Backup, the vendor’s Zimbra workflow requires a Zextras Backup destination and a source running Zextras Backup or Zimbra Suite Plus. Confirm entitlement with the vendor before relying on the feature.
Check capacity. Estimate space for the destination’s live mail store, staged source backup or export, and destination backup. The Zextras migration guide warns that the destination can need room for all three; do not size it only from users’ visible mailbox totals.
Back up and test restores. Keep a separate recoverable backup of the source. For a Zextras migration, follow the installed version’s checks and backup procedure. For imapsync, use a test mailbox on the destination first; imapsync’s tutorial emphasizes that the source is read while the destination is modified.
Test connectivity and authentication. Confirm that an administrator or test user can reach both IMAP endpoints using the intended secure connection. Do not enable clear-text authentication merely because an old guide says to; use the supported TLS/SSL and authentication settings for your Zimbra release.
Plan DNS and mail flow. If the MX record will change, lower its TTL in advance if your DNS provider permits it, then retain the old server during the transition so delayed or cached delivery can be monitored and reconciled.
Before a migration run, confirm target accounts, a recoverable source backup, and working IMAP access where imapsync will be used.
3. Use Zextras Backup for a Zimbra-aware migration
Această cale este concepută pentru administratorii care se mută între sisteme Zimbra și au nevoie de mai mult decât e-mail IMAP. Nu este o singură comandă universală: versiunile produsului sursă și destinație, aspectul căii de rezervă, permisiunile, stocarea și ordinea de migrare contează. Ghidul Zextras spune că comenzile CLI ar trebui executate ca zimbrautilizator, cu excepția cazului în care se specifică altfel în mod explicit.
Crearea și transferul unei copii de rezervă sursă
Urmați ghidul actual Zextras Backup pentru versiunea instalată. Ghidul Zextras Zimbra începe cu verificări ale integrității sursei și o scanare SmartScan aprofundată. Comanda exemplu este prezentată mai jos; verificați sintaxa comenzii și orice pași de întreținere necesari în raport cu versiunea dvs. înainte de a o rula:
zxsuite backup doSmartScan start deep true
După ce datele sursă sunt exportate, transferați datele de rezervă necesare într-un director de staging din destinație. Zextras oferă rsyncun mod de transport posibil și recomandă repetarea transferului în timp ce sursa rămâne activă, astfel încât trecerile ulterioare să mute doar datele modificate. Calea de staging a destinației trebuie să fie lizibilă de către utilizatorul Zimbra și nu trebuie confundată cu calea activă Zextras Backup a destinației. Protejați canalul de transfer și păstrați un jurnal al fiecărei treceri.
Exemplul de scanare la sursă pornește o scanare SmartScan profundă; ecranul afișează doar comanda, nu o scanare finalizată.
Aprovizionare și restaurare la destinație
Zextras documentează un import exclusiv de furnizare care creează domenii, clase de servicii și conturi, ignorând conținutul cutiei poștale. Este o fază de configurare, nu o restaurare completă a e-mailurilor:
După aprovizionare, rulați restaurarea externă completă cu o setare de concurență aleasă dintr-un test pe destinația dvs. Zextras oferă concurrent_accountsca parametru și recomandă testarea performanței, mai degrabă decât să presupună că un număr se potrivește fiecărui server. Repetați transferul copiei de rezervă sursă și restaurarea incrementală corespunzătoare, după cum este necesar, pentru a colecta modificările efectuate în timpul ferestrei de migrare. Păstrați sursa disponibilă până când utilizatorii și fluxul de e-mail au fost verificați.
Furnizorul descrie variantele cu etape și variantele cu o singură trecere, iar ordinea acestora poate depinde de planul de transfer. Folosiți procedura pentru versiunea instalată, în loc să combinați comenzi din versiuni diferite. Nu editați și nu ștergeți datele de rezervă sau fișierele de hartă importate în timp ce restaurarea este în desfășurare.
Comanda doar pentru furnizare pregătește conturile de destinație; conținutul cutiei poștale necesită etapa separată de restaurare completă.
4. Folosește imapsync când domeniul tău de aplicare este e-mailul IMAP
Imapsync este util atunci când atât cutia poștală sursă, cât și cea de destinație sunt accesibile prin IMAP și doriți să copiați mesaje și foldere fără a instala un produs de migrare specific Zimbra. Este disponibil pentru Linux, Windows și macOS. Exemplele de mai jos utilizează substituenți, nu nume reale de servere sau acreditări. Stocați parolele într-un script protejat sau altă metodă aprobată de gestionare a secretelor; nu le publicați niciodată într-un tichet, istoric shell partajat sau articol.
Începeți cu o cutie poștală sursă și o cutie poștală destinație de testare. Folosiți o simulare pentru a testa autentificările și a inspecta maparea folderelor fără a scrie în destinație. Tutorialul oficial Imapsync prezintă aceste opțiuni pentru o verificare inițială doar a folderelor:
imapsync \
--host1 SOURCE_IMAP --user1 USER --password1 SOURCE_SECRET \
--host2 DEST_IMAP --user2 USER --password2 DEST_SECRET \
--automap --justfolders --dry
Înlocuiți substituenții folosind fluxul de lucru securizat pentru acreditări al organizației dvs. Confirmați că sursa și destinația sunt gazdele dorite, ambele conectări au avut succes și că folderele precum Trimise, Schițe și Coș de gunoi sunt mapate la numele de destinație corecte. Dacă maparea este greșită, corectați-o înainte de a copia mesajele.
Șablonul de simulare verifică accesul la endpoint și maparea folderelor fără a copia conținutul cutiei poștale.
După ce testul este corect, eliminați --justfoldersși --drypentru a efectua copia propriu-zisă a cutiei poștale. Păstrați --automapnumai dacă maparea propusă este corectă pentru numele folderelor dvs.:
imapsync \
--host1 SOURCE_IMAP --user1 USER --password1 SOURCE_SECRET \
--host2 DEST_IMAP --user2 USER --password2 DEST_SECRET \
--automap
Executați comanda testată pentru fiecare cutie poștală printr-un script controlat dacă aveți mulți utilizatori. Consultați tutorialul oficial imapsync și bunele practici pentru sintaxa și opțiunile specifice platformei. Evitați semnalizările distructive, cum ar fi --delete1sau , --delete2cu excepția cazului în care doriți intenționat ștergerea pe acea parte și ați testat rezultatul pe o destinație de unică folosință. O copie de migrare nu ar trebui să șteargă în mod neașteptat e-mailul sursă sau datele exclusive ale destinației.
Comanda full-copy omite parolele din ilustrație; furnizați acreditările în siguranță și rulați-o numai după ce simularea este corectă.
5. Executați o sincronizare delta finală și comutați fluxul de e-mailuri
Pentru oricare dintre rute, o trecere inițială poate dura ceva timp, în timp ce utilizatorii continuă să lucreze. Programați o sincronizare finală aproape de trecerea la un alt loc. Cu imapsync, rulați din nou aceeași comandă testată: instrumentul este conceput pentru rulări incrementale și, în mod normal, omite mesajele deja sincronizate. Păstrați cutia poștală sursă neschimbată în timpul trecerii finale, acolo unde este posibil. Dacă utilizatorii au utilizat deja ambele servere, rezolvați separat aceste modificări divergente; imapsync nu este un instrument de îmbinare bidirecțională.
Pentru Zextras Backup, urmați procedura de import etapizat specifică versiunii și repetați pasul necesar de transfer/restaurare a backup-ului pentru a captura modificările de la etapa anterioară. Nu presupuneți că e-mailurile, calendarele sau contactele importate doar pentru furnizare; acest lucru creează structuri de cont, ignorând conținutul cutiei poștale.
Când destinația este gata să primească e-mail, modificați MX-ul și orice înregistrări webmail aferente în funcție de designul DNS și proxy. Mențineți serverul vechi în funcțiune și monitorizați ambele sisteme în timp ce expiră cache-urile DNS și sosesc e-mailuri întârziate. Utilizați o fereastră de întreținere documentată și comunicați dacă utilizatorii ar trebui să se conecteze la serverul vechi sau nou în timpul fiecărei faze.
Repetați sincronizarea IMAP testată ca o trecere delta finală, astfel încât e-mailurile primite în timpul primei copii să poată fi incluse.
6. Verificați noul server înainte de a-l dezafecta pe cel vechi
Testați un set reprezentativ de cutii poștale mici, mari, recente și mai vechi. Comparați listele de foldere și numărul de mesaje, deschideți mesajele cu atașamente, verificați starea de citire/necitire și semnalizare și confirmați că mesajele trimise apar în folderul dorit. Trimiteți mesaje atât către, cât și dinspre destinație, apoi confirmați că căutarea MX publică și jurnalele serverului arată livrarea la gazda așteptată.
Pentru o migrare Zextras, testați separat calendarele, contactele, activitățile, partajările, identitățile, semnăturile, preferințele utilizatorilor și orice setări de domeniu sau clasă de serviciu incluse în domeniul de aplicare. Zextras documentează o verificare a consistenței partajărilor cu zxsuite backup doCheckShares; utilizați procedura de reparare a corespondenței numai dacă este necesar și acceptat de versiunea instalată. Verificați din nou comportamentul accesului utilizatorului și al parolei.
Păstrați serverul sursă și o copie de rezervă recuperabilă până când părțile interesate aprobă rezultatul și se termină fereastra de retenție. Nu anulați vechea gazdă doar pentru că destinația acceptă date de conectare. Închideți proiectul numai după ce rutarea e-mailului, accesul utilizatorilor, datele non-e-mail și înregistrările de revenire la versiunea inițială sunt confirmate.
Folosește lista de verificare pentru a verifica livrarea și conținutul cutiei poștale; testează calendarele și contactele atunci când ruta Zextras este în sfera de aplicare.