The Real-Time Scanner is the most significant innovation in Backup NG. Each event on the system is recorded live to Zimbra’s RedoLog and saved by Backup NG, which means that it is always possible to rollback an account to a previous state. Thanks to the Real-Time Scanner, all the restore modes work with split-second precision.
The Real-Time Scanner reads all the events of the mail server almost real-time by following the flow of information provided by the RedoLog. Then it 'replicates' the same operations on its data structure, creating items or updating their metadata. No information in the backup gets overwritten, so every item has its complete history.
-
Select the Backup NG Tab.
-
Under Real-Time Scanner, press the
Enablebutton.
|
Note
|
When the Real-Time Scanner is enabled for the first time or re-enabled after a stop, a SmartScan is required. A warning gets displayed after enabling the Real-Time Scanner, prompting you to start the SmartScan either via the CLI or the Admin Console. |
-
Select the Backup NG Tab.
-
Under Real-Time Scanner, press the
Disablebutton.
The ZxBackup_RealTimeScanner property of the Backup NG module must be set to false to disable the Real-Time Scanner via the CLI:
zxsuite config set server `zmhostname` ZxBackup_RealTimeScanner FALSE
The only time you should disable the Real-Time Scanner is while performing an External Restore of multiple domains, as a safety measure to avoid high load on your server. After the import, re-enable the Real-Time Scanner and perform a SmartScan when prompted.
The main limitation when restoring data acquired via the Real-Time Scanner is:
-
Emptied Folder - when a user uses the
Empty Folderbutton in the right-click context menu
In this case, and any time Backup NG cannot determine the status of an item by reading the metadata saved by the Real-Time Scan, an Account Scan on the given account is triggered BEFORE the restore.
Doing so fixes any misaligned data and sanitizes the backed up metadata for the mailbox.
Blobless Backup Mode is a new feature that avoids backing up item blobs while still safeguarding all other item-related information.
This mode takes advantage of advanced storage capabilities of the storage solution, such as built-in backup or data replication, optimizing both the backup module’s disk space usage and restore speed.
These are the requirements to enable Blobless Backup Mode:
-
The server is running Zimbra 8.8.15 or higher.
-
No "independent" third-party volumes must exist: Blobless Backup Mode is only compatible with local volumes and centralized third-party volumes.
Blobless Backup Mode is storage-agnostic and can be enabled on any server or infrastructure that meets the requirements above regardless of the specific storage vendor.
Blobless Backup Mode works exactly as its default counterpart: the RealTime Scanner takes care of backing up item changes while the SmartScan manages domain/cos/account consistency.
The only difference between the two is that in Blobless Backup Mode, the backup contains no items of kind blob while still saving all metadata and transaction history.
It’s essential to consider that once enabled, Blobless Backup Mode affects the entire server, and no blobs get backed up regardless of the target volume and HSM policies.
To date, Blobless Backup Mode is only compatible with the "Raw Restore" operation. In the future, additional restore operations will become compatible with blobless datasets.
The SmartScan is the primary coherency check for the health of your backup system.
It’s Smart because it operates only on accounts modified since the last SmartScan, hence improving system performance and decreasing scan time exponentially.
The default SmartScan schedule executes each night (if Scan Operation Scheduling is enabled in the Backup NG section of the Administration Zimlet).
Once a week, on a day set by the user, a Purge executes together with the SmartScan to clear Backup NG’s datastore from any deleted item that exceeded the retention period.
The Backup NG engine scans all the items on the Zimbra Datastore, looking for items modified after the last SmartScan. It updates any outdated entry and creates any item not yet present in the backup while flagging as deleted any item found in the backup and not in the Zimbra datastore.
Finally, it updates all configuration metadata in the backup to store domains, accounts, COSs, and server configurations along with a dump of all LDAP data and config.
-
When the Backup NG module starts.
-
Daily, if the Scan Operation Scheduling is enabled in the Administration Zimlet.
-
When re-enabling the Real-Time Scanner via the Administration Zimlet after being previously disabled.
To start a SmartScan via the Administration Zimlet,
-
Open the Administration Zimlet.
-
Click the Backup NG tab (be sure to have a valid license).
-
Click
Run Smartscan.
To start a FullScan via the CLI, use the doSmartScan command:
Syntax: zxsuite backup doSmartScan [attr1 value1 [attr2 value2... PARAMETER LIST NAME TYPE notifications(O) Email Address[,..] (M) == mandatory parameter, (O) == optional parameter Usage example: zxsuite backup dosmartscan notifications [email protected],[email protected] Performs a smart scan and sends notifications to [email protected] and [email protected]
To check the status of a running scan via the CLI, use the monitor command:
Syntax:
zxsuite backup monitor {operation_uuid} [attr1 value1 [attr2 value2...
PARAMETER LIST
NAME TYPE
operation_uuid(M) Uiid
operation_host(O) String
(M) == mandatory parameter, (O) == optional parameter
The Backup Purge is a cleanup operation that removes from the Backup Path any deleted item that exceeded the retention time defined by the
Data Retention Policy.
The Purge engine scans the metadata of all deleted items, and it removes any item whose last update (deletion) timestamp is higher than the retention time.
Any item BLOB still referenced by one or more valid metadata files is not deleted, thanks to Backup NG’s built-in deduplication.
SPostfix customizations backed up by Backup NG also follow the backup path’s purge policies.
Change policies in the Backup NG section of the Administration Zimlet by unchecking the Purge old customizations checkbox.
-
Weekly, if the Scan Operation Scheduling is enabled in the Administration Zimlet.
-
When manually started either via the Administration Console or the CLI.
When the Data Retention Policy is set to 0, meaning infinite retention, the Backup Purge immediately exits since no deleted item can exceed an infinite retention time.
To start a BackupPurge via the Administration Zimlet:
-
Click the Backup NG tab (be sure to have a valid license).
-
Click the
Run Purgebutton in the top-right part of the UI.
To start a BackupPurge via the CLI, use the doPurge command:
Syntax: zxsuite backup doPurge [attr1 value1 [attr2 value2... PARAMETER LIST NAME TYPE purgeDays(O) String backup_path(O) Path (M) == mandatory parameter, (O) == optional parameter Usage example: zxsuite backup dopurge purgeDays 30 backup_path /opt/zimbra/backup/backup_name
To check the status of a running Purge via the CLI, use the monitor command:
Syntax:
zxsuite backup monitor {operation_uuid} [attr1 value1 [attr2 value2...
PARAMETER LIST
NAME TYPE
operation_uuid(M) Uiid
operation_host(O) String
(M) == mandatory parameter, (O) == optional parameter
The External Backup is one of the Backup Methods of Backup NG. It creates a snapshot of the mail system, which is ready for migration or Disaster Recovery. Exported data is deduplicated and compressed to optimize disk utilization, transfer times, and I/O rates.
The Backup NG engine scans all the data in the Zimbra datastore, saving all the items (deduplicated and compressed) into a folder of your choice.
The destination folder must be readable and writable by the zimbra user.
To create a valid export directory, run the following commands:
mkdir /opt/zimbra/backup/yourdestfolder
chown -R zimbra:zimbra /opt/zimbra/backup/yourdestfolder
To minimize the risk of errors, please perform the following maintenance procedures before migrating:
-
Double check Zimbra permissions with the following command (must run as root):
/opt/zimbra/libexec/zmfixperms --verbose --extended -
Reindex all mailboxes.
-
Check the BLOB consistency with the
zxsuite hsm doCheckBlobsutility.
To start an External Backup via the Administration Zimlet:
-
Click the Backup NG tab.
-
Click the
Export Backupbutton underImport/Exportto open the Export Backup wizard. -
Enter the Destination Path in the textbox, and press Next. The software checks if the destination folder is empty and whether the 'zimbra' user has R/W permissions.
-
Select the domains you want to export, and press Next.
-
Verify all your choices in the Operation Summary window. You can also add additional email addresses for notification when the restore operation finishes. Please note that the system sends notifications by default to the Admin account and the user who started the restore procedure.
To start an External Backup via the CLI, use doExport command:
Syntax:
zxsuite backup doExport {destination_path} [attr1 value1 [attr2 value2...
PARAMETER LIST
NAME TYPE DEFAULT
destination_path(M) Path
domains(O) Domain Name[,..] all
notifications(O) Email Address[,..]
(M) == mandatory parameter, (O) == optional parameter
Usage example:
zxsuite backup doexport /opt/zimbra/backup/ domains example.com notifications [email protected]
Exports a backup of example.com to /opt/zimbra/backup/ and notifies [email protected]
The Restore on New Account procedure allows you to restore the contents and preferences of a mailbox as it was in a moment in time, into a completely new account. The source account is unchanged in any way, so it is possible to recover one or more deleted items in a user’s account without actually rolling back the whole mailbox. When you run this kind of restore, you can choose to hide the newly created account from the GAL as a security measure.
When a Restore on New Account starts, a new account gets created (the Destination Account), with all the items existing in the source account at the moment selected, including the folder structure and all the user’s data.
All restored items are created in the current primary store unless you check the Obey HSM Policy box.
|
Warning
|
When restoring data on a new account, shared items consistency is lost, as the original share rules refer to the source account’s ID, not to the new (restored) account. |
A Restore on New Account can run in two ways.
Running Restore from the Accounts tab in the Zimbra Administration Console allows you to operate on users currently existing on the server.
If you need to restore a deleted user, please proceed to Restore via the Administration Zimlet.
-
Select
Accountsin the left pane of the Administration Console to show the Accounts List. -
Browse the list and click the account to restore (Source).
-
On the top bar, press the wheel and then the `Restore ` button.
-
Select
Restore on New Accountas the Restore Mode and enter the name of the new account (Destination) into the text box. You can then choose whether to Hide in GAL the new account or not, then pressNext. -
Choose the restore date. Day/Month/Year can be selected via a minical, the hour via a drop-down menu and minute and second via two text boxes. Click
Next. -
Verify all your choice in the Operation Summary window. You can also add additional email addresses for notification when the restore operation finishes. Please note that the system sends notifications by default to the Admin account and the user who started the restore procedure.
Click Finish to start the restore.
To start a Restore on New Account via the CLI, use the doRestoreOnNewAccount command:
Syntax:
zxsuite backup doRestoreOnNewAccount {source_account} {destination_account} {"dd/MM/yyyy HH:mm:ss"|last} [attr1 value1 [attr2 value2...
PARAMETER LIST
NAME TYPE EXPECTED VALUES
source_account(M) Account Name
destination_account(M) Account Name/ID
date(M) Date `dd/MM/yyyy HH:mm:ss`|last
restore_chat_buddies(O) Boolean true|false
notifications(O) Email Address[,..]
(M) == mandatory parameter, (O) == optional parameter
Usage example:
zxsuite backup dorestoreonnewaccount John NewJohn `28/09/2021 10:15:10`
Restores John's account in a new account named NewJohn
Undelete Restore is one of the Restore Modes available in Backup NG. It allows an administrator to restore all items deleted from a mailbox during a given period and put them into a dedicated Zimbra folder inside the mailbox itself.
During an Undelete Restore, the Backup NG engine searches the backup datastore for items flagged as DELETED and restores them in a dedicated folder in the selected mailbox.
|
Warning
|
The IMAP deleted flag is stripped from restored items so that they are visible for the user in the {product-short} {web-client}.
|
-
Select
Accountsin the left pane of the Administration Console to show the Accounts List. -
Browse the list and click the account to restore (Source).
-
On the top bar, press the wheel and then the `Restore ` button".
-
Select
Undeleteas the Restore Mode and pressNext. -
Choose the restore date-time slot. Day/Month/Year can be selected via a minical, the hour via a drop-down menu and the minute and second via two text boxes. Click
Next. -
Verify your choices in the Operation Summary window. You can also add additional email addresses for notification when the restore operation finishes. Please note that the system sends notifications by default to the Admin account and the user who started the restore procedure.
-
Click
Finishto start the Restore.
To start an Undelete Restore operation, use the doUndelete command:
Syntax:
zxsuite backup doUndelete {account} {"dd/MM/yyyy HH:mm:ss"|first} {"dd/MM/yyyy HH:mm:ss"|last} [attr1 value1 [attr2 value2...
PARAMETER LIST
NAME TYPE EXPECTED VALUES
account(M) Account Name
start_date(M) Date `dd/MM/yyyy HH:mm:ss`|first
end_date(M) Date `dd/MM/yyyy HH:mm:ss`|last
notifications(O) Email Address[,..]
(M) == mandatory parameter, (O) == optional parameter
Usage example:
zxsuite backup doundelete John `08/10/2021 10:15:00` last
Performs an undelete on John's account of all items created between 08/10/2021 10:15:00 and the latest data available
The External Restore adds to the current Zimbra server all the data, metadata, and configuration data stored on an external backup.
The workflow of the import procedure is as follows:
PHASE1
-
''Operation Started'' notification
-
Read Server Backup Data
-
Create empty Domains
-
Create needed COS (only those effectively used by the imported accounts)
-
Create empty DLs
-
Create empty Accounts
-
Restore all Accounts' attributes
-
Restore all Domains' attributes
-
Restore all DLs' attributes and share information
-
''PHASE1 Feedback'' Notification
PHASE2
-
Restore all Items
PHASE3
-
Restore all Mountpoints and Datasources
-
''Operation Ended'' notification with complete feedback
If Backup NG previously initialized on the destination server, disable the RealTime Scanner to improve both memory usage and I/O performance.
To reduce the I/O overhead and the amount of disk space used for the migration, advanced users may tweak or disable Zimbra’s RedoLog for the duration of the import.
To further reduce the amount of disk space used, it’s possible to enable compression on your current primary volume before starting the import.
If you do not wish to use a compressed primary volume after migration, it’s possible to create a new and uncompressed primary volume.
Set the new volume to Current and the old one to Secondary.
All of this is supported using the HSM NG module.
-
Click the Backup NG tab.
-
Click the
Import Backupbutton underImport/Exportto open the Import Backup wizard. -
Enter the Destination Path into the text box and press Forward. The software checks if the destination folder contains a valid backup and whether the 'zimbra' user has Read permissions.
-
Select the domains you want to import and press Forward.
-
Select the accounts you want to import and press Forward.
-
Verify all your choices in the Operation Summary window. You can also add additional email addresses for notification when the restore operation finishes. Please note that the system sends notifications by default to the Admin account and the user who started the restore procedure.
To start an External Restore operation, use the doExternalRestore command:
Syntax:
zxsuite backup doExternalRestore {source_path} [attr1 value1 [attr2 value2...
PARAMETER LIST
NAME TYPE EXPECTED VALUES DEFAULT
source_path(M) Path
accounts(O) Account Name[,..] all
domains(O) Domain Name[,..] all
filter_deleted(O) Boolean true|false true
skip_system_accounts(O) Boolean true|false true
skip_aliases(O) Boolean true|false false
skip_distribution_lists(O) Boolean true|false false
provisioning_only(O) Boolean true|false false
skip_coses(O) Boolean true|false false
notifications(O) Email Address
(M) == mandatory parameter, (O) == optional parameter
Usage example:
zxsuite backup doexternalrestore /opt/zimbra/backup/restorePath/ accounts [email protected],[email protected] domains example.com filter_deleted false skip_system_accounts false
Restores the example.com domain, including all system accounts, and the [email protected] and [email protected] accounts from a backup located in /opt/zimbra/backup/restorePath/
The concurrent_accounts parameter allows you to restore multiple accounts at the same time, thus greatly speeding up the restore process.
This feature is not available via the Administration Console.
|
Warning
|
Although resource consumption does not grow linearly with the number of accounts restored at once, it can easily become taxing. Start from a low number of concurrent accounts and raise it according to your server’s performance. |
Usage example: zxsuite backup doExternalRestore /tmp/external1 domains example0.com,example1.com concurrent_accounts 5 Restores the example0.com and example1.com domain, excluding system accounts, restoring 5 accounts at the same time from a backup located in /tmp/external1
The Restore Deleted Account procedure allows you to restore the contents and preferences of a mailbox into a completely new account, as it was when deleting the said mailbox.
When a Restore Deleted Account starts, a new account gets created (the Destination Account), with all the items existing in the source account at the moment of the deletion, including the folder structure and all the user’s data.
All restored items are created in the current primary store unless you’ve checked the Obey HSM Policy box.
|
Warning
|
When restoring data on a new account, shared items consistency is lost, as the original share rules refer to the source account’s ID, not to the new (restored) account. |
-
Select
Backup NGin the left pane of the Administration Console to show the Backup NG tab. -
On the top bar, push the
Restore Deleted Accountbutton. -
Choose the restore date. Day/Month/Year can be selected via a minical, the hour via a drop-down menu and the minute and second via two text boxes. Click
Next. -
Browse the list and click the account to restore (Source).
-
Enter the name of the new account (Destination) in the text box. You can then choose whether to Hide in GAL the new account or not then press
Next. -
Verify all your choices in the Operation Summary window. You can also add additional email addresses for notification when the restore operation finishes. Please note that the system sends notifications by default to the Admin account and the user who started the restore procedure.
-
Click
Finishto start the Restore.
A single item restores from the backup to the owner’s account. You may restore any type of item this way.
To start an Item Restore operation, use the doItemRestore command:
Syntax:
zxsuite backup doItemRestore {account_name} {item_id} [attr1 value1 [attr2 value2...
PARAMETER LIST
NAME TYPE
account_name(M) Account Name
item_id(M) Integer
restore_folder(O) String
(M) == mandatory parameter, (O) == optional parameter
Usage example:
zxsuite backup doitemrestore [email protected] 4784
Restores item 4784 in the `[email protected]` mailbox
The itemID is part of the metadata of an item, consisting of a unique code that identifies an item in a mailbox.
It resides along with all other metadata in a file inside the items directory of the proper account in
[backup path]/accounts/[accountID]/items/[last 2 digits of itemID]/[itemID]
e.g.:
Item 2057 of account 4a217bb3-6861-4c9f-80f8-f345ae2897b5, default backup path
/opt/zimbra/backup/ng/accounts/4a217bb3-6861-4c9f-80f8-f345ae2897b5/items/57/2057
Metadata storage uses a plain text file, so tools like grep and find are effective for searching contents.
To see the metadata contained in a file in a more readable format, you can use the zxsuite backup getItem command:
Syntax:
zxsuite backup getItem {account} {item} [attr1 value1 [attr2 value2...
PARAMETER LIST
NAME TYPE EXPECTED VALUES DEFAULT
account(M) Account Name/ID
item(M) Integer
backup_path(O) Path /opt/zimbra/backup/ng/
dump_blob(O) Boolean true|false false
date(O) Date dd/mm/yyyy hh:mm:ss|all last
(M) == mandatory parameter, (O) == optional parameter
Usage example:
zxsuite backup getitem a7300a00-56ec-46c3-9773-c6ef7c4f3636 1
Shows item with id = 1 belonging to account a7300a00-56ec-46c3-9773-c6ef7c4f3636
zimbra@simone:~$ zxsuite backup getitem
command getItem requires more parameters
Syntax:
zxsuite backup getItem {account} {item} [attr1 value1 [attr2 value2...
PARAMETER LIST
NAME TYPE EXPECTED VALUES DEFAULT
account(M) Account Name/ID
item(M) Integer
backup_path(O) Path /opt/zimbra/backup/ng/
dump_blob(O) Boolean true|false false
date(O) Date dd/mm/yyyy hh:mm:ss|all last
(M) == mandatory parameter, (O) == optional parameter
Usage example:
zxsuite backup getitem a7300a00-56ec-46c3-9773-c6ef7c4f3636 1
Shows item with id = 1 belonging to account a7300a00-56ec-46c3-9773-c6ef7c4f3636
Let’s say a user moves one item to the trash:
2021-07-18 15:22:01,495 INFO [btpool0-4361://localhost/service/soap/MsgActionRequest [[email protected];mid=2538;oip=258.236.789.647;ua=zclient/7.2.4_GA_2900;] mailop - moving Message (id=339) to Folder Trash (id=3)
and then empties the trash.
2021-07-18 15:25:08,962 INFO [btpool0-4364://localhost/service/soap/FolderActionRequest] [[email protected];mid=2538;oip=258.236.789.647;ua=zclient/7.2.4_GA_2900;] mailbox - Emptying 9 items from /Trash, removeSubfolders=true.
She then calls the Administrator to restore the deleted item.
Knowing the itemID and the email address, the Administrator runs the following as the zimbra user to restore the missing item:
zxsuite backup doItemRestore [email protected] 339
The "Raw Restore" operation is a DR-type restore operation compatible with both standard and blobless backup. In contrast to similar restore modes such as the External Restore, Raw Restore operates at a lower level to restore all item metadata, thus maintaining the original IDs for all objects restored.
The Raw Restore restores the source server’s Centralized Storage configuration. This step ensures that any data stored inside of a Centralized Storage is immediately available. If you are using local or independent third-party volumes, it is easy to move the item BLOBs from the primary storage or to restore those from a backup using the Blob Restore operation.
| External Restore | Raw Restore |
|---|---|
Useable on any Zimbra version regardless of the source |
Must match the very same Zimbra version and patch level as those on the source server |
Does not restore any setting |
Restores Centralized Storage settings |
Does not support blobless Backup Paths |
Is designed for blobless Backup Paths and compatible with standard Backup Paths |
Does restore item BLOBs |
Does not restore item BLOBs |
Restored objects get created anew |
Restored objects maintain their original ID |
-
Centralized Storage configuration and settings
-
Domains
-
Classes of Service
-
Distribution lists
-
Mailboxes
-
Mailbox preferences
-
Item metadata
The Raw Restore is only available through the zxsuite CLI tool:
[zimbra@mail ~]$ zxsuite backup doRawRestore
Perform a disaster recovery
Syntax:
zxsuite backup doRawRestore {source_path} [attr1 value1 [attr2 value2...]]
PARAMETER LIST
NAME TYPE EXPECTED VALUES DEFAULT
source_path(M) String
notifications(O) Email Address[,..]
skipProvisioning(O) Boolean true|false false
deleteWhenConflict(O) Boolean true|false false
(M) == mandatory parameter, (O) == optional parameter
Usage example:
zxsuite backup doRawRestore /my/backup/path notifications [email protected],[email protected] skipProvisioning false deleteWhenConflict false
Performs a Raw Restore without restoring provisioning or deleting a mailbox when ids are conflicting, and sends notifications to [email protected] and [email protected]
The disaster recovery operation does not perform blob restore, use doRestoreBlobs when needed.
Restore of a single-server infrastructure
-
Set up a new server (install Zimbra, configure Global and Server settings).
-
Manually create any local or independent 3rd-party volume as it was on the original server.
-
Start a Raw Restore using to restore domains, CoS mailboxes, and item metadata (mailboxes won’t be accessible until this step completes).
-
If the source backup was not running in Blobless Mode, run zxsuite backup doRestoreBlobs for all volumes to restore item BLOBS.
Loss of a single mailbox node in a multiserver infrastructure
-
Add a new mailbox node to the infrastructure.
-
Manually create any local or independent 3rd-party volume as it was on the original server.
-
Start a Raw Restore using the
skipProvisioning trueparameter to restore item metadata (mailboxes won’t be accessible until this step completes). -
If the source backup was not running in Blobless Mode, run zxsuite backup doRestoreBlobs for all volumes to restore item BLOBS.
Loss of multiple mailbox servers in an infrastructure
-
Setup a new empty infrastructure (all servers and roles, setting up Global and Server configuration).
-
Delete default
admin,gal,ham, andspamaccounts. -
On all mailbox servers, manually create any local or independent 3rd-party volume as it was on the original server.
-
On the first mailbox server, start a Raw Restore using to restore domains, CoS mailboxes, and item metadata (mailboxes won’t be accessible until this step completes).
-
On all other mailbox servers, start a Raw Restore using the
skipProvisioning trueparameter to restore item metadata. -
Once steps 3 and 4 complete, If the source backup was not running in Blobless Mode, run
zxsuite backup doRestoreBlobsfor all volumes on all mailbox servers to restore item BLOBS.
Any of these occurrences serve to classify a problem as a Disaster:
-
Hardware failure of one or more vital filesystems (such as / or /opt/zimbra/)
-
Contents of a vital filesystem made unusable by internal or external factors (like a careless rm * or an external intrusion)
-
Hardware failure of the physical machine hosting the Zimbra service or of the related virtualization infrastructure
-
A critical failure on a software or OS update/upgrade
Some suggestions to minimize the chances of a disaster:
-
Always keep vital filesystems on different drives (namely /, /opt/zimbra/ and your Backup NG path)
-
Use a monitoring/alerting tool for your server to become aware of problems as soon as they appear
-
Carefully plan your updates and migrations
Consider the recovery of a system divided into 2 steps:
-
Base system recovery (OS installation and configuration, Zimbra installation and base configuration)
-
Data recovery (reimporting the last available data to the Zimbra server, including domain and user configurations, COS data and mailbox contents)
The Import Backup feature of Backup NG provides an easy and safe way to perform step 2 of recovery.
Using the old server’s backup path as the import path allows you to restore a basic installation of Zimbra to the last valid moment of your old server.
Here we’ve seen just one possible Disaster Recovery scenario: more advanced scenarios and techniques appear in the Zimbra Wiki.
-
Install Zimbra on a new server and configure the Server and Global settings.
-
Install Network NG modules on the new server.
-
Mount the backup folder of the old server onto the new one. If this is not available, use the last external backup available or the latest copy of either.
-
Begin an External Restore on the new server using the following CLI command:
zxsuite backup doExternalRestore /path/to/the/old/store
-
The External Restore operation creates the domains, accounts and distribution lists, so as soon as the first part of the Restore completes (check your Network NG Modules Notifications), the system is ready for your users. Emails and other mailbox items restore afterward.
Server and Global settings are backed up but not restored automatically. Backup NG’s high-level integration with Zimbra allows you to restore your data to a server with a different OS/Zimbra Release/Networking/Storage setup without any constraints other than the minimum Zimbra version required to run Network NG Modules.
Whether you wish to create a perfect copy of the old server or just take a cue from the old server’s settings to adapt those to a new environment, Backup NG comes with a very handy CLI command:
getServerConfig.
zimbra@test:~$ zxsuite backup getServerConfig
command getServerConfig requires more parameters
Syntax:
zxsuite backup getServerConfig {standard|customizations} [attr1 value1 [attr2 value2...
PARAMETER LIST
NAME TYPE EXPECTED VALUES DEFAULT
type(M) Multiple choice standard|customizations
date(O) String `dd/MM/yyyy HH:mm:ss`|"last"|"all"
backup_path(O) Path /opt/zimbra/backup/ng/
file(O) String Path to backup file
query(O) String section/id/key
verbose(O) String false
colors(O) String false
(M) == mandatory parameter, (O) == optional parameter
Usage example:
zxsuite backup getserverconfig standard date last
Display the latest backup data for Server and Global configuration.
zxsuite backup getserverconfig standard file /path/to/backup/file
Display the contents of a backup file instead of the current server backup.
zxsuite backup getserverconfig standard date last query zimlets/com_zimbra_ymemoticons colors true verbose true
Displays all settings for the com_zimbra_ymemoticons zimlet, using colored output and high verbosity.
Specifically, this will display the latest backed up configurations:
zxsuite backup getServerConfig standard backup_path /your/backup/path/ date last query / | less
You can change the query argument to display specific settings, e.g.
zimbra@test:~$ zxsuite backup getServerConfig standard date last backup_path /opt/zimbra/backup/ng/ query serverConfig/zimbraMailMode/test.domain.com config date_______________________________________________________________________________________________28/02/2021 04:01:14 CET test.domain.com____________________________________________________________________________________________________________both
The {zimbrahome}/conf/ and {zimbrahome}/postfix/conf/ directories are backed up as well:
zimbra@test:~$ zxsuite backup getServerConfig customizations date last verbose true
ATTENTION: These files contain the directories {zimbraHome}/conf/ and {zimbraHome}/postfix/conf/ compressed into a single archive.
Restore can only be performed manually. Do it only if you know what you're doing.
archives
filename customizations_28_02_14#04_01_14.tar.gz
path /opt/zimbra/backup/ng/server/
modify date 28/02/2021 04:01:14 CET
Thanks to the advent of highly evolved virtualization solutions in the past years, virtual machines are now the most common way to deploy server solutions such as Zimbra Collaboration Suite.
Most hypervisors feature customizable snapshot capabilities and snapshot-based VM backup systems.
In case of a disaster, it’s always possible to roll back to the latest snapshot and import the missing data using the External Restore feature of Backup NG - using the server’s backup path as the import path.
Snapshot-based backup systems allow you to keep a frozen copy of a VM in a valid state and rollback to it at will.
To 100% ensure data consistency, it’s better to take snapshot copies of switched off VMs, but this is not mandatory.
When using these kinds of systems, it’s vital to make sure that the Backup Path isn’t either part of the snapshot (e.g., by setting the vdisk to `Independent Persistent in VMWare ESX/i) or altered in any way when rolling back, so the missing data is available for import.
To perform a disaster recovery from a previous machine state with Backup NG, you need to:
-
Restore the last valid backup into a separate (clone) VM in an isolated network, making sure that users can’t access it and that both incoming and outgoing emails are not delivered.
-
Switch on the clone and wait for Zimbra to start.
-
Disable Backup NG’s RealTime Scanner.
-
Connect the Virtual Disk containing the untampered Backup Path to the clone and mount it (on a different path).
-
Start an External Restore using the Backup Path as the Import Path.
Doing so parses all items in the Backup Path, and import the missing ones, speeding up the disaster recovery. These steps can be repeated as many times as needed as long as you suppress user access and mail traffic.
After the restore completes, make sure that everything is functional and restore user access and mail traffic.
It’s very easy.
Check the appropriate Operation Completed notification you received as soon as the restore operation finished.
The notification is shown in the Notifications section of the Administration Zimlet and emailed to the Notification E-Mail recipient address you specified in the Core section of the Administration Zimlet.
The skipped items section contains a per-account list of unrestored items:
[...] - stats - Restored Items: 15233 Skipped Items: 125 Unrestored Items: 10 - unrestored items - account: [email protected] unrestored items: 1255,1369 account: [email protected] unrestored items: 49965 account: [email protected] unrestored items: 856,13339,45200, 45655 [...]
There are different possible causes, the most common of which are:
-
Read Error: Either the raw item or the metadata file is not readable due to an I/O exception or a permission issue.
-
Broken item: Both the raw item and the metadata file are readable by Backup NG, but their content is broken/corrupted.
-
Invalid item: Both the raw item and the metadata file are readable, and the content is correct, but Zimbra refuses to inject the item.
There are two ways to do so: via the CLI to search for the item within the backup/import path or via the {product-short} {web-client} to view the items in the source server.
The getItem CLI command can display an item and the related metadata, extracting all information from a backup path/external backup.
The syntax of the command is:
zxsuite backup getItem {account} {item} [attr1 value1 [attr2 value2...
PARAMETER LIST
NAME TYPE EXPECTED VALUES DEFAULT
account(M) Account Name/ID
item(M) Integer
backup_path(O) Path /opt/zimbra/backup/ng/
dump_blob(O) Boolean true|false false
date(O) Date dd/mm/yyyy hh:mm:ss|all last
(M) == mandatory parameter, (O) == optional parameter
To extract the raw data and metadata information of the item whose itemID is 49965 belonging to [email protected], also including the full dump of the item’s BLOB, the command would be:
zxsuite backup getItem [email protected] 49965 dump_blob true
The comma-separated list of unrestored items displayed in the Operation Complete notification can serve as a search argument in the {product-short} {web-client} to perform an item search.
To do so:
-
Log into the Zimbra Administration Console in the source server.
-
Use the
View Mailfeature to access the account containing the unrestored items. -
In the search box, enter item: followed by the comma-separated list of itemIDs.
e.g.
item: 856,13339,45200,45655
|
Warning
|
Remember that any search executes only within its tab, so if you are running the search from the Email tab and get no results try to run the same search in the Address Book, Calendar, Tasks and Briefcase tabs.
|
An item not being restored is a clear sign of an issue, either with the item itself or with your current Zimbra setup. In some cases, there are good chances of being able to restore an item through subsequent attempts.
The following paragraphs contain a collection of tips and tricks that can be helpful when dealing with different kinds of unrestorable items.
Carefully distinguish the read errors that can cause items not to restore:
-
hard errors: Hardware failures and all other
destructiveerrors that cause an unrecoverable data loss. -
soft errors:
non-destructiveerrors such as wrong permissions, filesystem errors, RAID issues (e.g., broken RAID1 mirroring).
While there is nothing much to do about hard errors, you can prevent or mitigate soft errors by following these guidelines:
-
Run a filesystem check.
-
If using a RAID disk setup, check the array for possible issues (depending on RAID level).
-
Make sure that the 'zimbra' user has r/w access to the backup/import path, all its subfolders, and all thereby contained files.
-
Carefully check the link quality of network-shared filesystems. If link quality is poor, consider transferring the data with rsync.
-
If using SSHfs to remotely mount the backup/import path, make sure to run the mount command as root using the
-o allow_otheroption.
Unfortunately, this is the worst category of unrestored items in terms of salvageability.
Based on the degree of corruption of the item, it might be possible to recover either a previous state or the raw object (this is only valid for emails). To identify the degree of corruption, use the getItem CLI command:
zxsuite backup getItem {account} {item} [attr1 value1 [attr2 value2...
PARAMETER LIST
NAME TYPE EXPECTED VALUES DEFAULT
account(M) Account Name/ID
item(M) Integer
backup_path(O) Path /opt/zimbra/backup/ng/
dump_blob(O) Boolean true|false false
date(O) Date dd/mm/yyyy hh:mm:ss|all last
(M) == mandatory parameter, (O) == optional parameter
Searching for the broken item, setting the backup_path parameter to the import path, and the date parameter to all, displays all valid states for the item.
zimbra@test:~$ zxsuite backup getItem [email protected] 24700 backup_path /mnt/import/ date all itemStates start_date 12/07/2021 16:35:44 type message deleted true blob path /mnt/import/items/c0/c0,gUlvzQfE21z6YRXJnNkKL85PrRHw0KMQUqo,pMmQ= start_date 12/07/2021 17:04:33 type message deleted true blob path /mnt/import/items/c0/c0,gUlvzQfE21z6YRXJnNkKL85PrRHw0KMQUqo,pMmQ= start_date 15/07/2021 10:03:26 type message deleted true blob path /mnt/import/items/c0/c0,gUlvzQfE21z6YRXJnNkKL85PrRHw0KMQUqo,pMmQ=
If the item is an email, you are able to recover a standard .eml file through the following steps:
-
Identify the latest valid state
/mnt/import/items/c0/c0,gUlvzQfE21z6YRXJnNkKL85PrRHw0KMQUqo,pMmQ= start_date 15/07/2021 10:03:26 type message deleted true blob path /mnt/import/items/c0/c0,gUlvzQfE21z6YRXJnNkKL85PrRHw0KMQUqo,pMmQ=
-
Identify the
blob path
blob path /mnt/import/items/c0/c0,gUlvzQfE21z6YRXJnNkKL85PrRHw0KMQUqo,pMmQ=
-
Use gzip to uncompress the BLOB file into an
.emlfile
zimbra@test:~$ gunzip -c /mnt/import/items/c0/c0,gUlvzQfE21z6YRXJnNkKL85PrRHw0KMQUqo,pMmQ= > /tmp/restored.eml zimbra@test:~$ cat /tmp/restored.eml Return-Path: [email protected] Received: from test.example.com (LHLO test.example.com) (192.168.1.123) by test.example.com with LMTP; Fri, 12 Jul 2021 16:35:43 +0200 (CEST) Received: by test.example.com (Postfix, from userid 1001) id 4F34A120CC4; Fri, 12 Jul 2021 16:35:43 +0200 (CEST) To: [email protected] From: [email protected] Subject: Service mailboxd started on test.example.com Message-Id: <[email protected]> Date: Fri, 12 Jul 2021 16:35:43 +0200 (CEST) Jul 12 16:35:42 test zmconfigd[14198]: Service status change: test.example.com mailboxd changed from stopped to running
-
Done! You can now import the
.emlfile into the appropriate mailbox using your favorite client.
An item is identified as Invalid when, albeit being formally correct, it is discarded by Zimbra’s LMTP Validator upon injection.
This behavior is common when importing items created on an older version of Zimbra to a newer one; Validation rules update very often, so some messages considered valid by a certain Zimbra version may not be considered valid by a newer version.
If you experience a lot of unrestored items during an import, momentarily disable the LMTP validator and repeat the import:
-
To disable Zimbra’s LMTP Validator, run the following command as the Zimbra user:
zmlocalconfig -e zimbra_lmtp_validate_messages=false
-
Once the import completes, you can enable the LMTP validator running
zmlocalconfig -e zimbra_lmtp_validate_messages=true
|
Warning
|
This is a dirty workaround, as items deemed invalid by the LMTP validator might cause display or mobile synchronization errors.
Use it at your own risk.
|
The Coherency Check performs a deeper check of a Backup Path than the one done by the SmartScan.
While the SmartScan works incrementally by only checking items that changed since the last SmartScan, the Coherency Check performs a thorough check of all metadata and BLOBs in the backup path.
The objective is to detect corrupted metadata and BLOBs.
The Coherency Check verifies the integrity of all metadata in the backup path and the related BLOBs.
Should any errors be found, try running the check with the fixBackup option to move any orphaned or corrupted metadata/BLOB to a dedicated directory within the backup path.
-
At interval periods to make sure that everything is ok (e.g. every 3 or 6 months).
-
After a system crash.
-
After the filesystem or storage device containing the backup path experiences any issue.
Should the SmartScan detect a possible item corruption, a Coherency Check starts automatically.
|
Warning
|
The Coherency Check is highly I/O consuming, so make sure to run it only during off-peak periods |
The Coherency Check is not available via the Administration Zimlet.
To start a Coherency Check via the CLI, use the doCoherencyCheck command:
Syntax:
zxsuite backup doCoherencyCheck {backup_path} [attr1 value1 [attr2 value2...
PARAMETER LIST
NAME TYPE EXPECTED VALUES DEFAULT
backup_path(M) Path
accounts(O) Account Name/ID[,..] all
checkZimbra(O) Boolean true|false false
fixBackup(O) Boolean true|false false
notifications(O) Email Address[,..]
(M) == mandatory parameter, (O) == optional parameter
Usage example:
zxsuite backup docoherencycheck /opt/zimbra/backup/ng/ accounts [email protected],[email protected]
Performs a coherency check on /opt/zimbra/backup/ng/ for Jack's and John's accounts
zxsuite backup docoherencycheck /opt/zimbra/backup/ng/ fixBackup true
Performs a coherency check on /opt/zimbra/backup/ng/ and moves corrupted backup files and blob files not referenced by any metadata out of backup
To check the status of a running scan via the CLI, use the monitor command:
Syntax:
zxsuite backup monitor {operation_uuid} [attr1 value1 [attr2 value2...
PARAMETER LIST
NAME TYPE
operation_uuid(M) Uiid
operation_host(O) String
(M) == mandatory parameter, (O) == optional parameter
Having backup systems is a great safety measure against data loss.
Still, each backup system must be part of a broader backup strategy to ensure the highest possible level of reliability.
The lack of a proper backup strategy gives a false sense of security while turning even the best backup systems in the world into yet another breaking point.
Devising a backup strategy is no easy matter, and at some point, you will most likely face the following question: What if I lose the data I backed up?. The chances of this happening ultimately only depend on how you make and manage your backups. You are more likely lose all of your backed up data if you store both your data and your backups in a single SATAII disk than if you store your backed up data on a dedicated SAN using a RAID 1+0 setup.
Here are some suggestions and best practices to improve your backup strategy by making a backup of the Backup NG’s datastore and storing it offsite.
-
Atomicity: Any transaction is committed and written to the disk only when completed.
-
Consistency: Any committed transaction is valid, and no invalid transaction is committed and written to the disk.
-
Isolation: All transactions execute sequentially so that no more than 1 transaction can affect the same item at once.
-
Durability: A committed transaction remains so even in case of a crash (e.g., power loss or hardware failure).
Due to this, it’s very easy to make a backup.
The best (and easiest) way to do so is by using rsync.
Specific options and parameters depend on many factors, such as the amount of data to sync and the storage in use, while connecting to an rsync daemon instead of using a remote shell as a mode of transport is usually much faster in transferring the data.
You can leave both Zimbra and the Real-Time Scanner running, yet make an additional backup of Backup NG’s datastore using rsync, and you are always able to stop the sync at any time and reprise it afterward if needed.
As seen in the previous section, making a backup of Backup NG’s Datastore is very easy, and the use of rsync makes it just as easy to store your backup in a remote location.
We recommend the following best practices to optimize your backup strategy when dealing with this kind of setup:
-
If you schedule your rsync backups, make sure that you leave enough time between an rsync instance and the next one for the transfer to complete.
-
Use the
--deleteoptions, so that deleted files in the source server are deleted in the destination server to avoid inconsistencies.-
If you notice that using the
--deleteoption takes too much time, schedule two different rsync instances: one with--deleteto run after the weekly purge and one without this option.
-
-
Make sure you transfer the whole folder tree recursively starting from Backup NG’s Backup Path, and include server config backups and mapfiles.
-
Make sure the destination filesystem is case sensitive (just as Backup NG’s Backup Path must be).
-
If you plan to restore directly from the remote location, make sure that the zimbra user on your server has read and write permissions on the transferred data.
-
Expect to experience slowness if your transfer speed is much higher than your storage throughput (or vice versa).
For many reasons:
-
The
Export Backupfeature is designed to perform migrations. It exports asnapshotthat is an end in itself with no capacity for incremental management. Each Export Backup run time remains more-or-less constant while using rsync is much more time-efficient. -
Being a Backup NG operation, any other operation started while the Export Backup is running is queued until the Export Backup completes.
-
An
Export Backupoperation has a higher impact on system resources than an rsync. -
Should you need to stop an Export Backup operation, you won’t be able to reprise it, and you’ll need to start from scratch.
Yes. If your Backup Path is still available, it’s better to use that, as it restores all items and settings to the last valid state. However, should your Backup Path be lost, you’ll be able to use your additional/offsite backup.
Yes, but not through the External Restore operation, since item and folder IDs are the same.
The most appropriate steps to restore data from a copy of the backup path to the very same server are as follows:
-
Stop the RealTime Scanner.
-
Change the Backup Path to the copy you wish to restore your data from.
-
Run either
Restore on New Accountor aRestore Deleted Account. -
Once the restore is over, change the backup path to the original one.
-
Start the RealTime Scanner. A SmartScan triggers to update the backup data.
No, because the External Restore operation does not perform any deletions.
By running several External Restores, you’ll end up filling up your mailboxes with unwanted content, since items deleted from the original mailbox persist on the standby server.
The External Restore operation’s design ensures that accounts are available for use as soon as the operation starts, so your users are able to send and receive emails even if the restore is running.
The new Network Administration Zimlet makes the management of multiple servers very easy. You can select a server from the Backup NG tab and perform all backup operations on that server, even when logged into the Zimbra Administration Console of another server.
Specific differences between SingleStore and MultiStore environments are:
-
In a Multistore environment,
Restore on New Accountoperations ALWAYS create the new account in the Source account’s mailbox server. -
All operations are logged on the target server, not in the server that launched the operation.
-
If a target server for an operation is inappropriate, Zimbra automatically proxies the operation request to the correct server.
Backup and Restore in a Multistore environment works exactly like in a SingleStore environment.
The different servers are configured and managed separately via the Administration Zimlet, but certain operations like Live Full Scan and Stop All Operations can be 'broadcast' to all the mailstores via the zxsuite_ CLI using the --hostname all_servers option.
Backup NG settings support this, too.
(See the CLI wiki page for more details.)
Backup and Restore operations behave as follows:
-
Smartscans can be executed on single servers via the Administration Zimlet or on multiple servers via the CLI.
-
Restores can start from the
Accountstab in the Zimbra Admin Console, from each server tab in the Backup NG menu of the Administration Zimlet and via the CLI. The differences between these methods are:
| Operation started from: | Options |
|---|---|
|
The selected account’s restore is automatically started in the proper server. |
|
Any accounts eligible for a restore on the selected server can serve as the restore 'source'. |
|
Any account on any server can restored, but there is no automatic server selection. |
Export and Import functions are those that differ the most when performed on a Multistore environment.
Here are the basic scenarios.
Importing multiple accounts of a single domain to a different store breaks the consistency of ALL items shared from/to a mailbox on a different server.
A command in the CLI is available to fix the shares for accounts imported on different servers.
Two different scenarios apply here:
-
Mirrorimport: Same number of source and destination mailstores. Each source mailstore import occurs on a different server. This import breaks the consistency of ALL items shared from/to a mailbox on a different server. ThedoCheckSharesanddoFixSharesCLI commands are available to check and fix share consistency (see below). -
Compositeimport: Same or different number of source and destination servers. Domains or accounts get manually imported into different servers. This import breaks the consistency of ALL items shared from/to a mailbox on a different server. ThedoCheckSharesanddoFixSharesCLI commands are available to check and fix share consistency (see below)
The doCheckShares command parses all share information in local accounts and report any error:
zimbra@test:~$ zxsuite help backup doCheckShares Syntax: zxsuite backup doCheckShares Usage example: zxsuite backup doCheckShares Check all shares on local accounts
The doFixShares fixes all share inconsistencies using a migration.
zimbra@test:~$ zxsuite help backup doFixShares
Syntax:
zxsuite backup doFixShares {import_idmap_file}
PARAMETER LIST
NAME TYPE
import_idmap_file(M) String
(M) == mandatory parameter, (O) == optional parameter
Usage example:
zxsuite backup doFixShares idmap_file
Fixes the shares' consistency after an import according to the
mapping contained in the /opt/zimbra/backup/ng/idmap_file
Every time a Backup NG operation starts, either manually or through scheduling, it queues in a dedicated, unprioritized FIFO queue. Each operation executes as soon as any preceding operation is dequeued (either because it completes or terminates).
The queue system affects the following operations:
-
External backup
-
All restore operations
-
Smartscan
Changes to Backup NG’s configuration are not enqueued and are applied immediately.
To view the operation queue, access the Notifications tab in the Administration Zimlet and click the Operation Queue button.
|
Warning
|
The Administration Zimlet displays operations queued both by Backup NG and HSM NG in a single view. No dependency should be inferred by that view, as the two queues are completely separate, in that one Backup NG operation and one HSM NG operation can run at the same time. |
To view Backup NG’s operation queue, use the getAllOperations command:
zimbra@server:~$ zxsuite help backup getAllOperations Syntax: zxsuite backup getAllOperations [attr1 value1 [attr2 value2... PARAMETER LIST NAME TYPE EXPECTED VALUES DEFAULT verbose(O) Boolean true|false false (M) == mandatory parameter, (O) == optional parameter Usage example: zxsuite backup getAllOperations Shows all running and queued operations
To stop the current operation and empty Backup NG’s operation queue, use the doStopAllOperations command:
zimbra@mail:~$ zxsuite help backup doStopAllOperations Syntax: zxsuite backup doStopAllOperations Usage example: zxsuite backup doStopAllOperations Stops all running operations
To stop the current operation or to remove a specific operation from the queue, use the doStopOperation command:
zimbra@mail:~$ zxsuite help backup doStopOperation
Syntax:
zxsuite backup doStopOperation {operation_uuid}
PARAMETER LIST
NAME TYPE
operation_uuid(M) Uiid
(M) == mandatory parameter, (O) == optional parameter
Usage example:
zxsuite backup doStopOperation 30ed9eb9-eb28-4ca6-b65e-9940654b8601
Stops operation with id = 30ed9eb9-eb28-4ca6-b65e-9940654b8601
COS-level Backup Management allows the administrator to disable ALL Backup NG functions for a whole Class of Service to lower storage usage.
-
The Real-Time Scanner ignores all accounts in the COS.
-
The Export Backup function DOES NOT EXPORT accounts in the COS.
-
The backup system treats accounts in the COS as
Deleted. After the data retention period expires, all data for such accounts gets purged from the backup store. Re-enabling the backup for a Class of Service resets this.
Disabling the backup for a Class of Service adds the following marker to the Class of Service’s Notes field: ${ZxBackup_Disabled}
While the Notes field remains fully editable and usable, changing or deleting this marker re-enables the backup for the COS.
-
This guide describes how to perform an Incremental Migration using Backup NG.
-
Incremental Migration is specifically designed for the migration of a production environment, minimizing the downtime and aiming to be transparent for the users.
-
If correctly planned and executed, your mail system won’t suffer any downtime, and the impact on the users is close to zero.
|
Note
|
All the CLI commands in this guide must be executed as the zimbra user unless otherwise specified.
|
-
Emails and email folders
-
Contacts and address books
-
Appointments and calendars
-
Tasks and task lists
-
Files and briefcases
-
Share information
-
User preferences
-
User settings
-
Class of Service settings
-
Domain settings
-
Server settings (migrated for reference but not restored)
-
Global settings (migrated for reference but not restored)
-
Customizations (e.g., Postfix, Jetty.)
-
Items moved or deleted during the process are not moved or deleted on the destination server.
-
Preferences (e.g., passwords) changed during the process are reset upon each import
|
Warning
|
Avoid using incremental migration to set up a server-to-server mirroring. Using multiple imports to create a mirrored copy of the source server won’t create a mirrored copy at all, since the import process performs no deletions. |
-
Source Server: Any Zimbra server can be the source of your migration, provided that it’s running Backup NG or Zimbra Suite Plus.
-
Destination Server: Any Zimbra server can be the destination of your migration, provided that it’s running Backup NG.
-
On the Source server: Before enabling Backup NG on the source server, make sure you have an amount of free disk space comparable to the size of the
/opt/zimbra/store/folder. Compressing the exported data using the gzip algorithm and deduplicating all Zimbra items typically reduces the exported size to 70% of the original size. -
On the Destination server: Make sure you free space greater than the size of the
/opt/zimbra/store/and of theexportfolders on the source server combined.
While you can choose to transfer the data in any other way, rsync is our method of choice because it’s a good compromise between speed and convenience.
The main data transfer executes, while the source server is still active and functional. Since the transfer is via the network, carefully plan your transfer so that you’ll transfer all of your data before migrating.
Anything from a remote mount to a physical drive move is ok as long as it suits your needs.
Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.
Computer Networks. New Jersey: Prentice-Hall. p. 83. ISBN 0-13-349945-6
Set the TTL value of your MX record to 300 on your real DNS to allow a fast switch between source and destination servers.
To avoid any possible data-related issues, run the following checks on the source server:
-
zxsuite hsm doCheckBlobschecks the consistency between Zimbra’s metadata and BLOBs. -
zmdbintegrityreportchecks the integrity of the Zimbra database.
Repair any error found.
Running a reindex of all mailboxes is also suggested.
Disable the Real-Time Scanner on both servers:
zxsuite backup setProperty ZxBackup_RealTimeScanner false
|
Warning
|
We strongly recommend a dedicated device for data export for the best performance and least impact on the running system. |
Mount any such device on the /opt/zimbra/backup/ path, and the ensure the zimbra user has r/w permissions for it.
Run a SmartScan on the source server:
zxsuite backup doSmartScan
All your data is exported to the default backup path (/opt/zimbra/backup/ng/).
You can also choose to only migrate one or more domains instead of all of them. To do so, run the following command instead of the SmartScan:
zxsuite backup doExport /path/to/export/folder/ domains yourdomain.com,yourdomain2.com[..]
Mind that if you start with the SmartScan method, you’ll have to carry on the migration with this method.
If you start with the Single Domains method, you’ll have to carry on the migration with this method.
Do not mix the two methods.
|
Warning
|
If Backup NG is used or planned for use on the destination server, ensure the destination folder is not in Backup NG’s backup path there, to avoid unnecessary backup activity. |
(You can skip this step if you choose to transfer your data by other means than rsync.)
Using rsync, copy the data contained in the
/opt/zimbra/backup/ng/ onto a directory in the destination server
(make sure the Zimbra user has r/w permissions on the folder). Use a
terminal multiplexer like screen or tmux.
This process might need considerable time depending on network speed and amount of data involved.
[run this command as Root] rsync -avH /opt/zimbra/backup/ng/ root@desinationserver:/path/for/the/data/
While the suggested method is great for high-bandwidth situations, the first synchronization can involve large amounts of data. If the rsync method is too slow, you might consider a physical move of the device (or the proper disk file if running on a virtual environment).
After moving the disk, you can remotely mount it back to the source server (e.g., via SSHFS), as the additional synchronizations needed for
the migration involves substantially less data.
In this case, be sure to remount the device on the source server as /opt/zimbra/backup/ng/ with all due permissions.
Import all previously exported data to the destination server.
zxsuite backup doExternalRestore /path/for/the/data/
Network NG imports your data onto the destination server.
|
Warning
|
Do not edit or delete the backup path after this step. |
If you are planning to migrate a very large infrastructure where an export/import lasts for hours or even days, there is an alternative way to handle the migration from this point forward.
Instead of importing all of your data to the destination server, you can run a Provisioning Only import that only creates Domains, classes of service, and accounts on the destination server, skipping all mailbox contents.
zxsuite backup doExternalRestore /path/for/the/data/ provisioning_only TRUE
After doing this, switch the mail flow to the new server.
When the switch completes, start the real import.
zxsuite backup doExternalRestore /path/for/the/data/
Your users may now connect to the new server where new emails are delivered while restoring old emails.
This approach has pros and cons.
Pros
-
Since items are only imported once and never modified or deleted afterward, using this method results in fewer discrepancies than the
standardincremental migration. -
This is the option that has less impact on the source server (e.g. good if you are in a hurry to decommission it).
Cons
-
Items are restored to users' mailboxes while they work on it. Depending on the scheduling of the operation, this method has a higher impact on your users.
-
Since the import uses compute resources on a running system, you might notice some slowdowns.
Now the vast majority of the data has already been imported to the destination server. The source server is still active and functional, and you are ready to perform the actual migration.
Before switching the mail flow, ALWAYS make sure that the new server is ready to become active (check things like your firewall, your DNS settings, and your security systems.)
At the end of this step, the destination server is active and functional.
-
Repeat step 3, step 4, and step 5 (only new data is exported and synchronized).
-
Switch the mail flow to the new server.
-
Once NO MORE EMAILS arrive at the source server, repeat step 3, step 4 and step 5.
The Destination server is now active and functional.
Run the following command to check for inconsistencies with shares:
zxsuite backup doCheckShares
Should this command report any inconsistency, this command parses the import mapfile used as the first argument and fix any broken share:
zxsuite backup doFixShares
Mapfiles reside in the Backup Path of the destination server as
map_[source_serverID].
Delete any imported GalSync accounts from the Zimbra Administration Console. Then, if needed, create new GalSync accounts on all the imported domains and resync all the GalSync accounts with the following command:
zmgsautil forceSync -a [email protected] -n [resourcename]
Running a Volume Deduplication using the HSM NG module is highly suggested after a migration.
Yes. It can be either a trial license or a purchased one.
Everything except the server configuration is migrated, including:
-
User data
-
User preferences
-
Classes of Service configurations
-
Domain configurations
Again, anything that suits your needs is ok. You just need to be very sure about what your needs are.
Do you need to move the data very fast? Physically moving a USB disk between your servers might not be a good idea.
Do you need to move the data in a very reliable way? Mounting the export folder via SSHFS to the destination server might not be a good idea if your internet connection is sloppy.