The Real Time Scanner is the big 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 informations provided by the RedoLog. Then it 'replicates' the same operations on its own data structure, creating items or updating their metadata. No information is ever overwritten in the backup, so every item has its own 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 Live Full Scan is required. A warning will be displayed after enabling the Real Time Scanner, and you will be prompted to start the Full Scan. |
-
Select the Backup NG Tab.
-
Under Real Time Scanner, press the
Disablebutton.
To disable the Real Time Scanner via the CLI, the
ZxBackup_RealTimeScanner property of the Backup NG module must be set
to false:
zxsuite backup setProperty ZxBackup_RealTimeScanner FALSE
The only time you should disable the Real Time Scanner is while performing an External Restore of multiple domains. This is 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.
This fixes any misaligned data and sanitizes the backed up metadata for the mailbox.
The SmartScan is the main 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.
By default, a SmartScan is scheduled to be executed 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
is executed 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, so that domains, accounts, COSs and server configurations are stored along with a dump of all LDAP data and config.
-
When the Backup NG module is started.
-
Daily, if the Scan Operation Scheduling is enabled in the Administration Zimlet.
-
When the Real Time Scanner is re-enabled 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.
If an item BLOB is still referenced by one or more valid metadata files, due to Backup NG’s built-in deduplication, the BLOB itself will not be deleted.
SPostfix customizations backed
up by Backup NG also follow the backup path’s purge policies. This can
be changed 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.
Should the Data Retention Policy be set to 0, meaning infinite
retention, the Backup Purge will immediately exit since no deleted item
will ever exceed the 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 to be used for a migration or for 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 be ran 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 will check 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 to be notified when the restore operation is finished. Please notice that the Admin account and the user who started the restore procedure are notified by default.
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 not changed 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 is created (the
destination account). All the items existing in the source account at
the moment selected are recreated in the destination account, including
the folder structure and all the user’s data. All restored items will be
created in the current primary store unless the Obey HSM Policy box is
checked.
|
Warning
|
When restoring data on a new account, shared items consistency is not preserved. This is because the original share rules refer to the original account’s ID, not to the restored account. |
A Restore on New Account can be 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 be restored (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. When you’re done choosing, 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 to be notified when the restore operation is finished. Pleas notice that the admin account and the user who started the restore procedure are notified by default.
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/2012 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 in a period of time 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
|
To
deal with IMAP-deleted emails in a more comfortable way for the user,
the deleted IMAP flag will now be stripped from any restored item so
that the item itself is visible in the Zimbra Web Client.
|
-
Select `Accounts`in the left pane of the Administration Console to show the Accounts List.
-
Browse the list and click the account to be restored (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 to be notified when the restore operation is finished. Please notice that the admin account and the user who started the restore procedure are notified by default.
-
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/2012 10:15:00` last
Performs an undelete on John's account of all items created between 08/10/2012 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 informations
-
''PHASE1 Feedback'' Notification
PHASE2
-
Restore all Items
PHASE3
-
Restore all Mountpoints and Datasources
-
''Operation Ended'' notification with complete feedback
If Backup NG is already 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 it to Current and switch the old one to Secondary.
All of this can be done 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 will check 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 to be notified when the restore operation is finished. Please notice that the admin account and the user who started the restore procedure are notified by default.
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
|
Albeit resource consumption does not grow linearly with the number of accounts restored at the same time, 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 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, as it was when said mailbox was deleted, into a completely new account.
When a Restore Deleted Account starts, a new account is created (the
Destination Account), and all the items existing in the source account at
the moment of the deletion are recreated in the destination account,
including the folder structure and all the user’s data. All restored
items will be created in the current primary store unless the Obey HSM
Policy box is checked.
|
Warning
|
When restoring data on a new account, shared items consistency is not preserved. This is because the original share rules refer to the original account’s ID, not to the 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 be restored (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. When you’re done choosing, press
Next. -
Verify all your choices in the Operation Summary window. You can also add additional email addresses to be notified when the restore operation is finished. Please notice that the admin account and the user who started the Restore procedure are notified by default.
-
Click
Finishto start the Restore.
A single item is restored from the backup to the owner’s account. Any type of item can be restored 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 one of the metadata of an item consisting in
an univoque code that identifies an item in a mailbox.
Along with all other metadata, it is stored 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 are stored in a plain text file, so tools like grep and find
can be used to search for 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…
2013-07-18 15:22:01,495 INFO [btpool0-4361://localhost/service/soap/MsgActionRequest [name=[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 empties the trash.
2013-07-18 15:25:08,962 INFO [btpool0-4364://localhost/service/soap/FolderActionRequest] [name=[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
To classify a problem as a Disaster, one or more of the following
must happened:
-
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
The recovery of a system is 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 a 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.
This is just one possible Disaster Recovery scenario: more advanced scenarios and technicques are described 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 will immediately create the domains, accounts and distribution lists, so as soon as the first part of the Restore is completed (check your Network NG Modules Notifications), the system will be ready for your users. Emails and other mailbox items will be restored afterwards.
Server and Global settings are backed up but are 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/2014 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/2014 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 in order for the missing data to be 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 will parse all items in the Backup Path and import the missing ones, speeding up the disaster recovery. These steps can be repeated as many time as needed as long as user access and mail traffic is inhibited.
After the restore is completed, 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.
It can be viewed in the Notifications section of the
Administration Zimlet, and it’s also emailed to the address you specified
in the Core section of the Administration Zimlet as the Notification
E-Mail recipient address.
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 the raw item or the metadata file are readable by Backup NG but their content is broken/corrupted.
-
Invalid item: Both the the raw item or 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 and via the Zimbra Web Client. The first way can be used to search for the item within the backup/import path, and the second can be used 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 be used as a search argument in the Zimbra
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 is executed only within the tab it is
executed, 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 even if it was not restored on the first try.
In the following paragraphs, you will find a collections of tips and tricks that can be helpful when dealing with different kinds of unrestorable items.
A dutiful distinction must be done about the read errors that can cause items not to be restored:
-
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), etc.
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, will display 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/2013 16:35:44 type message deleted true blob path /mnt/import/items/c0/c0,gUlvzQfE21z6YRXJnNkKL85PrRHw0KMQUqo,pMmQ= start_date 12/07/2013 17:04:33 type message deleted true blob path /mnt/import/items/c0/c0,gUlvzQfE21z6YRXJnNkKL85PrRHw0KMQUqo,pMmQ= start_date 15/07/2013 10:03:26 type message deleted true blob path /mnt/import/items/c0/c0,gUlvzQfE21z6YRXJnNkKL85PrRHw0KMQUqo,pMmQ=
If the item is an email, you will be 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/2013 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 .eml file
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 2013 16:35:43 +0200 (CEST) Received: by test.example.com (Postfix, from userid 1001) id 4F34A120CC4; Fri, 12 Jul 2013 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 2013 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 .eml file into the appropriate mailbox using your favorite client.
An item is identified as Invalid when, albeit being formally correct,
is discarded by Zimbra’s LMTP Validator upon injection. This is common
when importing items created on an older version of Zimbra to a newer
one, Validation rules are updated very often, so not all messages
considered valid by a certain Zimbra version are still
considered valid by a newer version.
If you experienced a lot of unrestored items during an import, it might be a good idea to 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 is completed, 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
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
have been modified since the last SmartScan, the Coherency Check
performs a thorough check of all metadata and BLOBs in the backup
path.
It’s specifically designed to detect corrupted metadata and BLOBs.
The Coherency Check verifies the integrity of all metadata in the
backup path and of the related BLOBs. Should any errors be found,
running the check with the fixBackup option will 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 will be started 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, but
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 actually 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 be confronted with 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. It’s more likely that you will 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 will be committed and written to the disk.
-
Isolation: All transactions are executed sequentially so that no more than 1 transaction can affect the same item at once.
-
Durability: Once a transaction is committed, it will stay 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 be synced and the storage in use, while connecting to
an rsync daemon instead of using a remote shell as a transport is
usually much faster in transferring the data.
You won’t need to stop Zimbra or the Real Time Scanner to make an additional backup of Backup NG’s datastore using rsync, and you will be always able to stop the sync at any time and reprise it afterwards 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.
To optimize your backup strategy when dealing with this kind of setup, the following best practices are recommended:
-
If you schedule your rsync backups, make sure that you leave enough time between an rsync instance and the next one in order for the transfer to be completed.
-
Use the --delete options so that files that have been deleted 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 be 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. This includes 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).
Why shouldn’t I use the Export Backup feature of Backup NG instead of
rsync?
For many reasons:
-
The
Export Backupfeature is designed to perform migrations. It exports asnapshotthat is an end in itself and was not designed to be managed incrementally. Each time an Export Backup is run, it’ll probably take just as much time as the previous one, while using rsync is much more time-efficient. -
Being a Backup NG operation, any other operation started while the Export Backup is running will be queued until the Export Backup is completed.
-
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.
Can I use this for Disaster Recovery?
Yes. Obviously, if your Backup Path is still available. it’s better to use that, as it will restore 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.
Can I use this to restore data on the server the backup copy belongs to?
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 will trigger to update the backup data.
Can I use this to create an Active/Standby infrastructure?
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 will not be deleted on the standby server.
The External Restore operation has been designed so that accounts will
be available for use as soon as the operation is started, so your
users will be able to send and receive emails even if the restore is
running.
Are there any other ways to do an Additional/Offsite backup of my system?
There are for sure, and some of them might even be better than the one described here. These are just guidelines that apply to the majority of cases.
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 if you are 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 wrong target server for an operation is chosen, Zimbra automatically proxies the operation request to the right server.
Backup and Restore in a Multistore environment will work exactly like in a Singlestore environment.
The different servers will be 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. This
applies also to Backup NG settings (see the CLI wiki page for more
details).
Backup and Restore operations are managed as follows:
-
Smartscans can be executed on single servers via the Administration Zimlet or on multiple servers via the CLI.
-
Restores can be started 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 be chosen 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 will break the consistency of ALL the items that are 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 export is imported on a different server. This will break the consistency of ALL the items that are 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 are manually imported into different servers. This will break the consistency of ALL the items that are shared from/to a mailbox on a different server. ThedoCheckSharesanddoFixSharesCLI commands are available to check and fix share consistency (see below)
The doCheckShares command will parse 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 will fix 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 is started, either manually or through scheduling, it is enqueued in a dedicated, unprioritized FIFO queue. Each operation is executed as soon as any preceding operation is dequeued (either because it has been completed or terminated).
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. This is just a design choice, as the two queues are completely separate, meaning that one Backup NG operation and one HSM NG operation can be running 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 will ignore all accounts in the COS.
-
The Export Backup function WILL NOT EXPORT accounts in the COS.
-
Accounts in the COS will be treated as
Deletedby the backup system. This means that after the data retention period expires, all data for such accounts will be purged from the backup store. Re-enabling the backup for a Class of Service will reset this.
Disabling the backup for a Class of Service will add 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 will re-enable the backup for the COS.
-
This guide describes how to perform an Incremental Migration using Backup NG.
-
It’s 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 will be close to zero.
-
_ 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 informations
-
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 (Postfix, Jetty, etc…)
-
Items moved or deleted during the process will not be moved or deleted on the destination server.
-
Preferences (e.g. passwords) changed during the process will be reset upon each import
|
Warning
|
The incremental migration is not designed 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 no deletions are performed by the import process. |
-
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: If Backup NG is not currently enabled on the source server, make sure you have an amount of free disk space comparable to the size of the
/opt/zimbra/store/folder (the exported data is compressed through the gzip algorithm, and all zimbra items are deduplicated, usually reducing the size of exported to 70% of the original size). -
On the Destination server: Make sure you have an amount of 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 is executed while the source server is still active and functional. However, since the transfer is performed via network, carefully plan your transfer in advance so that you’ll have transferred all of your data before migrating.
Anything spanning from the remote mount to physical move of the drive is ok as long as it suits your needs.
Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway. --Tanenbaum, Andrew S. (1996). 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. This will
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 doCheckBlobs: Checks the consistency between Zimbra’s metadata and BLOBs.
-
zmdbintegrityreport: Checks 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
|
A dedicated device for the data export is strongly recommended in order to improve the export performance and to lower the impact on the performances of the running system. |
Any such device must be mounted on the /opt/zimbra/backup/ path, and the
Zimbra user must have r/w permissions on it.
Run a SmartScan on the source server:
zxsuite backup doSmartScan
All your data will be 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. The
two methods cannot be mixed.
|
Warning
|
When you move the exported data to the destination server, make sure that the destination folder is not Backup NG’s backup path on the destination server to avoid any nuisances if you already use Backup NG or plan to do so on the destination server. |
(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 A LOT of 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 a lot 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 will involve much 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 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 will only create 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 mailflow to the new server. When the
switch is completed, start the real import.
zxsuite backup doExternalRestore /path/for/the/data/
Your users will now connect to the new server where new emails will be delivered while old emails are being restored.
This approach has pros and cons.
Pros
-
Since items are only imported once and never modified or deleted afterwards, using this method will result in less 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
-
Depending on the timing of the operation, this method has a higher impact on your users due to the fact that items are restored WHILE they work on their mailbox.
-
Since the import is done 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 your firewall, your DNS settings, your security systems, etc.)
At the end of this step the destination server will be active and functional.
-
Repeat step 3, step 4 and step 5 (only new data will be exported and synchronized).
-
Switch the mail flow to the new server.
-
Once NO MORE EMAILS arrive to 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 will parse the import mapfile used as the first argument and fix any broken share:
zxsuite backup doFixShares
Mapfiles can be found 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 an 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.