Close menu

External Recovery

External Recovery

External Restore allows you to import backups created on a separate infrastructure, which is beneficial for creating a test environment that is similar to the production environment, as well as for sophisticated operations like account or domain migration or catastrophe recovery. Furthermore, it is the only technique in which the source and destination servers cannot be the same.
 
External Restore is an intriguing and valuable feature in that it restores all of an account’s shares in addition to the data.

Note

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 Backup Advanced Techniques Chapter.

The External Restore reads data, information, and configuration from the source server’s Backup Path and replicates it to a new server. The technique is broken into three phases and comprises of a workflow with a number of steps.
 
A common scenario in which External Restore is useful: you need to relocate a server from your Rome infrastructure to your Milan infrastructure. The fundamental access requirement is that you have access to the Backup Path on the Rome server (the source) from the Milan server (the destination) in order to do the External restoration on your Milan infrastructure.
Skip Domain Provisioning
Ignore Domain Provisioning
Although the External Restore is typically used on the entire infrastructure, it can also be applied to single or multiple accounts; in this case, only the data and metadata that belong to those accounts will be restored, not domain-level customizations (such as COS, GAL, quota, and so on). The skip_domain_provisioning argument may be used for this operation, as shown in the example that follows, which only restores the accounts john and alice in domain example.com:
zextras$ carbonio backup doexternalrestore  /opt/backup/zextras/ accounts john@example.com,alice@example.com domains example.com skip_domain_provisioning true

When utilising the skip_domain_provisioning option, the process that is described below does not apply; just the Restore all Accounts’ Attributes step will be carried out in Phase 1 because no domain configuration will be affected.

Important

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.

  • 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

  • PHASE 1 Feedback Notification

  • Restore all Items

  • Restore all Mountpoints and Datasources

  • Operation Ended notification with complete feedback

Container Restore
Think about creating a folder named Inbox/Zextras(which is also its Backup Path) and subsequently deleting some messages from there that were in a backup. These messages are restored together with any other messages that may already be present in theInbox/Zextras folder when an External Restore is performed. In other words, since the restored folder and an existent folder both share the same Backup Path, the restored messages are saved there.
 
What occurs is as follows in greater detail:
regional file
The backup folder id will be mapped to the existing folder id if a folder with the same path has previously been established by a filter. Additionally, everything that was in the original folder will be returned to its original location.
external mail box
The mountpoint will be restored if a filter had created a folder with that path. The filter also updates the filter to write to the restored mountpoint. All things in the folder that was produced by the filter are also relocated to the target of the mountpoint.
Before You Begin
It is expected that you have already set up a fresh vanilla infrastructure, or, more specifically, a fresh instance of Zextras that has only undergone a regular installation.
 
Determining a Backup Path on the new infrastructure is really the first thing to do, unless you wish to use the default one (/opt/zextras/backup/zextras), then initialising the Backup.
  1. Disable the RealTime Scanner if Carbonio Backup has already been initialised on the destination server to optimise memory utilisation and I/O performance.
  2. Advanced users can modify or deactivate the RedoLog for the duration of the import to decrease I/O overhead and the amount of disc space required for the migration.
  3. It is feasible to enable compression on your current main volume before beginning the import to consume less disc space overall. It is feasible to establish a new, uncompressed primary disc, set it to Current, and convert the previous one to Secondary. if you do not want to utilise a compressed primary drive after migration. The powerstore component is required for this operation.
  4. Check out the section on multithreading to speed up the restore if you want to utilise the CLI.
Making use of an external restore
Use the doExternalRestore <carbonio_backup_doExternalRestore> command to begin an External Restore procedure.
zextras$ carbonio backup doExternalRestore *source_path* [param VALUE[,VALUE]]
Usage example
zextras$ carbonio 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/

Hint

At the end of the operation, you can check that the configuration of the new mailbox is the same by running the command carbonio config dump (See zextras_config_full_cli).

Using multithreading to expedite the restore
You may restore several accounts simultaneously with the concurrent_accounts argument, considerably accelerating the restoration process. This functionality is only accessible through CLI.
Usage example:
zextras$ carbonio 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

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.

After the Restoration Message Deduplication: 

After an External Restore, it is strongly advised to do a volume-wide deduplication using the Zextras Powerstore component because the native deduplication mechanism might not work well while consecutively importing accounts.