What is the External Restore?

Unlike the other restore strategies presented here, the External Restore is the only strategy for which the source server and the destination server could not be the same; that is, the external restore will recover data on a new server or infrastructure. An interesting and useful functionality of External Restore is that besides the data, it restores also all the shares of an account.

External restore proves useful in case of migration of accounts or of whole domains.

It is possible to run an External Restore with the same infrastructure as destination, but this is a rather advanced technique and will be discussed in the Advanced Techniques Chapter.

How Does it Work?

The External Restore reads from Backup Path on the source server all the data, metadata, and configuration data and copies them on a new server. The procedure consists of a workflow with a number of steps, and is outlined below, divided into three Phases.

Suppose you have to migrate a server from the infrastructure you have in Rome to the one you have in Milan: From the Milan (destination) server you need to have access to the Backup Path on the Rome (source) server in order to copy it on your Milan infrastructure.

Two points of the External Restore must be highlighted:

  1. The External Restore is quite a complex and resource-intensive procedure; to minimise its impact on the current server’s operations, read the Before You Start section below for a few tips.

  2. All commands and operations must be run on the destination server.

PHASE 1

  • '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

PHASE 2

  • Restore all Items

PHASE 3

  • Restore all Mountpoints and Datasources

  • 'Operation Ended' notification with complete feedback

Folder restore

Suppose you have created a folder called Inbox/Zextras(which is also its Backup Path), and later deleted from it some messages, which are in some backup. When an External Restore is carried out, those messages are restored, along with any existent message, in the Inbox/Zextras folder. In other words, since the restored folder shares the same Backup Path with an existing folder, then the restored messages end up there.

In more details, the following happens:

Local folder

If a folder with the same path was already created by a filter, the backup folder id will be mapped to the existing folder id. Moreover, all items that were in the original folder will be restored to the same path.

Remote mailbox

If a folder with that same path was already created by a filter, the mountpoint will be restored. Additionally, all items in the folder (created by the filter) are moved to the mountpoint target; also the filter to write to the restored mountpoint will be updated.

Before You Start

It is assumed that you have already installed a new vanilla infrastructure; that is, a new Zextras instance without having yet done any operation or configuration on it besides a standard installation.

The first task to carry out, indeed, is to define a Backup Path on the new infrastructure, unless you want to use the default one (/opt/zextras/backup/zextras), and initialize Zextras Backup.

Moreover, to reduce the overall overhead and load on the server during the External Restore, you can implement the following suggestions.

  1. If Zextras Backup is already initialized on the destination server, disable the RealTime Scanner to improve both memory usage and I/O performance.

  2. 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.

  3. 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. This operation is possible by using the Zextras Powerstore module.

  4. If you plan to use the CLI, check also section Speeding up the Restore through Multithreading

Running an External Restore

Via the Administration Zimlet

  • Click the Zextras Backup tab.

  • Click on the Import Backup button under Import/Export to 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 note that the admin account and the user who started the restore procedure are notified by default.

Via the CLI

To start an External Restore operation, use the doExternalRestore command:

doExternalRestore

zxsuite backup doExternalRestore source_path [param VALUE[,VALUE]]

PARAMETER LIST

NAME

TYPE

EXPECTED VALUES

DEFAULT

source_path(M)

Path

accounts(O)

Account Name[,..]

all

input_file(O)

String

list of accounts, one per line

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

skip_coses(O)

Boolean

true|false

false

skip_account_provisioning(O)

Boolean

true|false

false

skip_domain_provisioning(O)

Boolean

true|false

false

provisioning_only(O)

Boolean

true|false

false

notifications(O)

Email Address

concurrent_accounts(O)

Integer

max_file_size(O)

Integer

restore_datasource(O)

Boolean

true|false

true

force_as_external_restore(O)

Boolean

true|false

false

blobs_archive(O)

String

(M) == mandatory parameter, (O) == optional parameter

Example:
zxsuite backup doExternalRestore /path/to/data/ accounts john@example.com,jack@example.com domains example.com filter_deleted false skip_system_accounts false

Restores the example.com domain, including all system accounts, and the john@example.com and jack@example.com accounts from a backup located in /path/to/data/

At the end of the operation, you can check that the configuration of the new mailbox is the same by running the command zxsuite config dump (See the full reference of all its sub-commands).

Speeding up the Restore through Multithreading

The concurrent_accounts parameter allows you to restore multiple accounts at the same time, thus greatly speeding up the restore process. This feature is available via CLI only.

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

After the Restore: Message Deduplication

Running a volume-wide deduplication with the Zextras Powerstore module is highly recommended after an External Restore, since the native deduplication system might be ineffective when sequentially importing accounts.