Zextras Backup

Table of Contents

Zextras Backup Common Tasks
- How to Activate Zextras Backup
Architecture of Zextras Backup
SmartScan
Real Time Scan
Backup Purge
Limitations and Corner Cases of the Backup
Backup on a Third Party Store [BETA]
External Backup
Zextras Backup CLI

This chapter describes Zextras Backup, Zextras Suite’s component that is responsible to back up all the data. The chapter is divided into several sections: at the beginning, an overview of the most common task is given along with pointers to more technical references.

Next, the architecture of Zextras Backup is described, which includes also important concepts to know beforehand; the concepts will be detailed in the remainder of the chapter.

Finally, the used to periodically store and check the data backed up are presented. All sections are accompanied with the corresponding Command Line Reference.

Restore Strategies for the Backup and Advanced Backup Techniques, including Disaster Recovery, have now a dedicated chapter.

Zextras Backup Common Tasks

This section containes guidelines for the most common task required by the users; also links to technical resources are also provided.

How to Activate Zextras Backup

Once you have finished your servers setup, you need a few more steps to configure the Backup module and have all your data automatically backed up.

Mount a storage device (like e.g., a NAS) in you desired path. We will use the default /opt/zimbra/backup/zextras throughout this section; remember to replace it with the path you chose.

The size of the device should be at least 80% of primary + secondary volume size.

Set the correct permission on the backup path: chown zimbra:zimbra /opt/zimbra/backup/zextras
Set the full path for backups, either from the admin console (see screenshot of Figure Zextras Backup Admin Console), or the command line:

zxsuite config server set $(zmhostname) attribute ZxBackup_DestPath value /opt/zimbra-backup

Figure 1. Zextras Backup Admin Console

Once you have specified the backup path, it must be initialised, an operation that can be done either from the admin console or the command line. In the first case, click on the Initialize NOW! button on the top right corner of Figure Zextras Backup Admin Console screenshot. From the CLI, initialization is done by simply starting SmartScan for the first time: zxsuite backup doSmartScan start

To avoid a flood of notifications about running operations, it is suggested to lower the default Notification level from Information to one of Warning, Error, or Critical

Figure 2. Zextras Backup Notification Level

Architecture of Zextras Backup

This section introduces the main concepts needed to understand the architecture of Zextras Backup and outlines their interaction; each concept is then detailed in a dedicated section.

Before entering in the architecture of Zextras Backup, we recall two general approaches that are taken into account when defining a backup strategy: RPO and RTO.

The Recovery Point Objective (RPO) is the highest amount of data that a stakeholder is willing to loose in case of a disaster, while the Recovery Time Objective (RTO) is the highest amount of time that a stakeholder is willing to wait to recover its data.

According to these definitions, the ideal acceptable value zero, while the realistic values are usually near zero, depending on the size of the data. In Zextras, the combination of Real Time Scan and SmartScan guarantees that both RTO and RPO values are quite low: The Real Time Scanner ensures that all metadata changes are recorded as soon as they change, while the SmartScan copies all items that have been modified, hence the possible loss of data is minimised and usually limited to those items that have changed between two consecutive run on SmartScan.

Item

The whole architecture of Zextras Backup revolves around the concept of ITEM: An item is the minimum object that is stored in the backup, for example:

an email message
a contact or a group of contacts
a folder
an appointment
a task
a Drive document
an account (including its settings)
a distribution list
a domain
a class of services (COS)

the last three items (distribution lists, domains, classes of services) are subject to the SmartScan only, i.e., the Real Time Scan will not record any change of their state.

There are also objects that are not items, and as such will never be scanned for changes by the Real Time Scan and will never be part of a restore:

Server settings, i.e., the configuration of each server
Global settings of Zextras product
Any customizations made to the software (Postfix, Jetty, etc…)

For every item managed by Zextras Suite, every variation in its associated metadata is recorded and saved, allowing its restore at a given point in time. In other words, whenever one of the metadata associated with an item changes, a "photograph" of the whole item is taken and stored with a timestamp be means of a transaction. Examples of metadata associated to an item include:

when the email was read, deleted, moved to a folder
a change in the name/address/job of a contact
the deletion or addition of a file in a folder
the change of status of an item (e.g, an account)

Technically, an item is stored as a JSON Array containing all changes in the item’s lifetime. More about this in the Structure of an Item section.

A Deleted Item is an item that has been marked for removal.

An element in the thrash bin is not considered as a deleted item: It is a regular item, placed in a folder that is special only to us, from the Zextras Backup’s point of view, the item has only changed its state when moved to the thrash bin.

Transaction

A Transaction is a change of state of an item. With change of state we mean that one of the metadata associated with an item is modified by a user. Therefore, a Transaction can be seen as a photography of the metadata in a moment in time. Each transaction is uniquely identified by a Transaction ID. It is possible to restore an item to any past transaction. See more in section Zextras Backup Part 2: Restore Strategies.

SmartScan and Real Time Scan

The initial structure of the backup is built during the Initial Scan, performed by the SmartScan: the actual content of a Mailbox is read and used to populate the backup. The SmartScan is then executed at every start of the module and on a daily basis if the Scan Operation Scheduling is enabled in the Administration Zimlet.

SmartScan runs at a fixed time—that can be configured—on a daily basis and is not deferred. This implies that, if for any reason (like e.g., the server is turned off, or Zextras is not running), SmartScan does not run, it will not run until the next day. You may however configure the Backup to run the SmartScan every time Zextras Suite is restarted (although this is discouraged), or you may manually run SmartScan to compensate for the missing run.

SmartScan’s main purpose is to check for items modified since its previous run and to update the database with any new information.

The Real Time Scan records live every event that takes place on the system, allowing for a possible recovery with a split-second precision. The Real Time Scanner does not overwrite any data in the backup, so every item has an own complete history. Moreover, it has the ability to detect there are more changes that relate to the same item in the same moment and record all them as a single metadata change.

Both SmartScan and Real Time Scan are enabled by default. While both can be (independently) stopped, it is suggested to leave them running, as they are intended to complement each other.

If none of the two Scan Operations is active, no backup is created.

Backups are written on disk, therefore the Scan operations result in I/O disk access. Therefore, there are a number of scenarios in which either of the SmartScan or Real Time Scan might (or should) be disabled, even temporarily. For example:

You have a high number of trasactions every day (or you often work with Drive documents) and notice a high load in the server’s resource consumption. In this case you can temporarily disable the Real Time Scan.
You start a migration: In this case it is suggested to stop the SmartScan, because it would create a lot of I/O operations on disk and even block the server. Indeed, it would treat every migrated or restored item as a new one.
You have a high traffic of incoming and outgoing emails per day. In this case, you should always have the Real Time Scan active, because otherwise all transactions will be backed up only by the SmartScan, which might not be able to complete in a reasonable time, due to the resources required for the I/O operations.

Backup Path

The Backup Path is the place on a filesystem on which all information about the backup and the archives. Each server has exactly one backup path; different servers can not share the same backup path. It is structured as a hierarchy of folders, the topmost of which is by default /opt/zimbra/backup/zextras/. Under this directory, the following important files and directories are present:

map_[server_ID] are so-called map files, that show if the Backup has been imported from an external backup and contain in the filename the unique ID of the server.
accounts is a directory under which information of all accounts defined in the Mailbox are present. In particular, the following important files and directories can be found there:
- account_info is a file that stores all metadata of the account, including password, signature, preferences
- account_stat is a file containing various statistics about the account, like for example the ID of the last element stored by SmartScan
- backupstat is a file that maintains generic statistics about the backup, including the timestamp of the first run
- drive_items is a directory containing up to 256 subfolders (whose name is composed of two hexadecimal lowercase letters), under which are stored Drive items, according to the last two letters of their UUID
- items is a directory containing up to 100 subfolders (whose name is composed of two digits, in which items are stored according to their ID’s last two digits
servers is a directory that contains archives of the server configuration and customisations, Zextras configuration and of the chat, one per day up to the configured server retention time.
items is a directory containing up to 4096 additional folders, whose name consists of two hexadecimal (uppercae and lowercase) characters. Items in the Mailbox will be stored in the directory whose name has the last two characters of their ID.

Setting the Backup Path

The Backup Path can be set both via GUI and via CLI:

Via GUI: in the "Backup" section of the Zextras Administration Zimlet, under "Backup Path".
Via CLI: using the config server command to change the ZxBackup_DestPath config key.

Backup paths are unique and not reusable. Copying a Backup Path to a new server and setting it as its current Backup Path will return an error, and forcing this in any way by tampering with the backup file will cause corruption of both old and new backup data.

Retention Policy

The Retention Policy (also retention time) defines after how many days an object marked for deletion is actually removed from the backup. The retention policies in the Backup are:

Data retention policy concerns the single items, defaults to 30 days
Account retention policy refers to the accounts, defaults to 30 days

All retention times can be changed; if set to 0 (zero), archives will be kept forever (infinite retention) and the Backup Purge will not run.

In case an account is deleted and must be restored after the Data retention time has expired, it will be nonetheless possible to recover all items up to the Account retention time, because in that case, even if all the metadata have been purged, the digest can still contain the information required to restore the item.

Backup Purge

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 and Account retention policy.

Coherency Check

The Coherency Check is specifically designed to detect corrupted metadata and BLOBs and performs a deeper check of a Backup Path than SmartScan.

While the SmartScan works incrementally by only checking items modified since the last SmartScan run, the Coherency Check carries out a thorough check of all metadata and BLOBs in the Backup Path.

To start a Coherency Check via the CLI, use the doCoherencyCheck command:

Quick reference

zxsuite backup doCoherencyCheck backup_path [param VALUE[,VALUE]]

A detailed analysis of the Coherency Check is present on the Zextras Community web site at https://community.zextras.com/coherency-check/.

How Zextras Backup Works

Zextras Backup has been designed to store each and every variation of an ITEM. It is not intended as a system or Operating System backup, therefore it can work with different OS architecture and Zimbra versions.

Zextras Backup allows administrators to create an atomic backup of every item in the mailbox account and restore different objects on different accounts or even on different servers.

By default, the default Zextras Backup setting is to save all backup files in the local directory /opt/zimbra/backup/zextras/. In order to be eligible to be used as the Backup Path, a directory must:

Be both readable and writable by the zimbra user.
Use a case sensitive filesystem.

You can modify the default setting by using either technique shown in Setting the Backup Path.

When first started, Zextras Backup launches a SmartScan, to fetch from the mailbox all data and create the initial backup structure, in which every item is saved along with all its metadata as a JSON array on a case sensitive filesystem. After the first start, either the Real Time Scanner, the SmartScan, or both can be employed to keep the backup updated and synchronised with the account.

Structure of an Item

The basic structure of the item is a JSON Array that records all the changes happening during the lifetime of each item, such as information related to emails (e.g., tags, visibility, email moved to a folder), contacts, tasks, single folders, groups, or drive documents, user’s preferences (e.g., hash of the password, general settings).

To improve performance, only the changes that are needed to restore the items are recorded: for example is not useful to store the user’s last login time or the IMAP and Activesync state, because if the account will be restored on a new one, the values of that attributes would be related to the old account.

By collecting the timestamp of the transaction, we are able to restore data at a specific moment of its life.

During the restore, the engine looks at all the transactions valid evaluating the “start-date” and “end-date” attributes.

The same logic is used to retrieve deleted items: when an item is deleted we store the timestamp and so, we are able to restore items that have been deleted within a specific time frame.

Even if the blob associated to the item changes, and consequently its digest changes too (as happens for Drive Document), the metadata records the validity of the old and the new digest.

Backup of Team Database

Zextras Team is an instant messaging platform with a number of features, including file sharing, Web conferencing, and more. Since Team keeps track of everything (uploaded files, chat, and so on), its database can grow quickly to a large size: This slows down any Backup operations and is not usable for a restore operation.

For this reason, the backup of Team’s DB has been disabled by default. An Administrator may enable it, in theory, but only after having contacted beforehand a TSE (Technical Support Engineer).

SmartScan

What is the SmartScan?

The SmartScan operates only on accounts that have been modified since the previous SmartScan, hence it can improve the system’s performances and decrease the scan time exponentially.

By default, a SmartScan is scheduled to be executed each night (if Scan Operation Scheduling is enabled in the Zextras Backup 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 Zextras Backup’s datastore from any deleted item that exceeded the retention period.

How Does it Work?

The Zextras Backup 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.

Then, all configuration metadata in the backup are updated, so that domains, accounts, COSs and server configurations are stored along with a dump of all configuration.

When LDAP is part of the setup, SmartScan will save in the Backup Path a compressed LDAP dump that can also be used standalone to restore a broken LDAP configuration.

In case the LDAP backup can not be executed (e.g., because the access credential are wrong or invalid, SmartScan will simply ignore to back up the LDAP configuration, but will nonetheless save a backup of all the remaining configuration

When the Backup on External Volume functionality is active, SmartScan creates one (daily) archive for each account which include all the account’s metadata and stores it on the external volume. More information in section [backup-on-external-volume].

When is a SmartScan Executed?

When the Zextras Backup module is started.

While it is possible to enable this option, it is suggested to leave it disabled, because in certain situations, running SmartScan at every module restart can become a performance bottleneck, as it has been discussed previously. * 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

Running a SmartScan

Starting the Scan via the Administration Zimlet

To start a SmartScan via the Administration Zimlet,

Open the Administration Zimlet
If a multiserver installation, choose the server on which to run the SmartScan
Click on the Zextras Backup tab
Click on Run Smartscan

Starting the SmartScan via the CLI

To start a SmartScan via the CLI, use the doSmartScan command:

zxsuite backup doSmartScan start [param VALUE[,VALUE]]

Checking the Status of a Running Scan

Before actually carrying out this check, it is suggested to verify how many operations are running, to find the correct id. you can do this by using the getAllOperations command:

zxsuite backup getAllOperations [param VALUE[,VALUE]]

To check the status of a running scan via the CLI, use the monitor command:

zxsuite backup monitor operation_uuid [param VALUE[,VALUE]]

Real Time Scan

What is the Real Time Scanner?

The Real Time Scan is an engine tightly connected to the Mailbox, which intercepts all the transactions that take place on each user’s mailbox and records them with the purpose of maintaining the whole history of an item for its entire lifetime.

Thanks to the Real Time Scan, it is possible to recover any item at any point in time.

How Does it Work?

The Real Time Scanner reads all the events of the mail server almost real-time, 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.

Managing the Real Time Scanner

Enabling the Real Time Scanner

Via the Administration Zimlet

Select the Zextras Backup Tab.
Under Real Time Scanner, press the Enable button.

When the Real Time Scanner is enabled for the first time or re-enabled after a stop, a SmartScan is required. A warning will be displayed after enabling the Real Time Scanner, and you will be prompted to start the SmartScan.

Via the CLI

To enable the Real Time Scanner via the CLI, the ZxBackup_RealTimeScanner property of the Zextras Backup module must be set to true:

zxsuite config server set $(zmhostname) attribute ZxBackup_RealTimeScanner value TRUE

Disabling the Real Time Scanner

Via the Administration Zimlet

Select the Zextras Backup Tab.
Under Real Time Scanner, press the Disable button.

Via the CLI

To disable the Real Time Scanner via the CLI, the ZxBackup_RealTimeScanner property of the Zextras Backup module must be set to false:

zxsuite config server set $(zmhostname) attribute ZxBackup_RealTimeScanner value FALSE

Why Should I Disable the Real Time Scanner?

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.

Limitations and Safety Scan

The main limitation when restoring data acquired via the Real Time Scanner is:

Emptied Folder - when a user uses the Empty Folder button in the right-click context menu

In this case, and any time Zextras Backup 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.

Backup Purge

What is the Backup Purge?

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.

How Does it Work?

The Purge engine scans the metadata of all deleted items, and should it find any item marked for deletion whose last update is higher than the retention time it will erase it from the backup.

Note however, that if an item BLOB is still referenced by one or more valid metadata files, due to Zextras Backup’s built-in deduplication, the BLOB itself will not be deleted.

Customizations backed up by Zextras Backup also follow the Backup Path’s purge policies. This can be changed in the `Zextras Backup section of the Administration Zimlet by unchecking the Purge old customizations checkbox.

When is a Backup Purge Executed?

Weekly, if the Scan Operation Scheduling is enabled in the Administration Zimlet
When manually started either via the Administration Console or the CLI

With infinite retention active (i.e., the Data Retention Policy is set to 0), the Backup Purge will immediately exit since no deleted item will ever exceed the retention time.

Running a Backup Purge

Starting the Backup Purge via the Administration Zimlet

To start a BackupPurge via the Administration Zimlet:

Click the Zextras Backup tab (be sure to have a valid license).
Click the Run Purge button in the top-right part of the UI.

Starting the Backup Purge via the CLI

To start a BackupPurge via the CLI, use the doPurge command:

zxsuite backup doPurge [param VALUE[,VALUE]]

Checking the Status of a Running Backup Purge

To check the status of a running Purge via the CLI, use the monitor command:

zxsuite backup monitor operation_uuid [param VALUE[,VALUE]]

Limitations and Corner Cases of the Backup

There are a few cases in which the backup may seem to not work correctly. We discuss those cases here.

Restore of an active account on a new account should NOT be done using the latest state available. Suppose that a user by mistake deletes all of his emails or that for any reason (like e.g., a server failure) the emails in an account are lost. The user wants them back and asks the admin. If the admin restores the status of the account to the latest state available, the result is that the new account will contain the latest state available, which is an empty account, since in the latest state the email have already been deleted. Therefore, in order to correctly restore the account, it is necessary to restore it at a point in time which is antecedent the emails were deleted.

When using the POP3/POP3S protocol, if the email client is configured to download email messages and delete them immediately from the server, these messages may not be included in the backup. This does not happen if the Zextras Powerstore component is installed.
When sending an email directly through an SMTP connection (e.g., using a multipurpose device or connecting to the STMP server using telnet), then that email will not be part of the backup.
When sending email using an IMAP/SMTP client, the IMAP client must be configured to store the send email in a remote folder (using the IMAP STORE command) after the send operation, otherwise the email may not be included in the backup.

The last two cases do not apply when using a browser to connect to the Mailbox. In this case is it the Mailbox that contacts the SMTP server to send the email and automatically passes the email to mailboxd.

Backup on a Third Party Store [BETA]

This feature is currently in beta, usage in production environment is not endorsed

Zextras Backup also allows to store its data on a third party S3 bucket or on an NFS/Fuse share.

The standard local Backup Path will still be used to store metadata, a copy of which will then be uploaded to S3 every night, while BLOBs will be stored in the bucket straight away.

This allows to effectively split the live data, keeping the metadata on a local disk and the BLOBs on a remote storage. Due to the fact that Metadata usually makes up the 10% of the backup space but the 90% of the total read/write operations, this design ensures a good level of performances (especially on metadata I/O heavy tasks, such as the Purge and the SmartScan) even when the largest part of the data is hosted remotely.

Even when backing up on a Third Party Store, the local Backup Path will still be used for metadata and to cache BLOB writes.

Metadata management

While BLOBs are momentarily cached on the local disk and uploaded to the remote volume as soon as possible, metadata are stored locally in the Backup Path.

An incremental copy of all metadata to the remote volume is performed every time the scheduled SmartScan runs, and every time a SmartScan is manually executed with the deep true option.

It is also possible to force a metadata upload using the remote_metadata_upload option in the following commands:

doSmartScan
doAccountScan
doBackupServerCustomizations
doBackupLDAP
doBackupCluster

Remote metadata can be fetched to perform a Disaster Recovery or to update/fix local metadata with the zxsuite backup retrieveMetadataFromArchive command to download the latest metadata available in the remote storage to the Backup Path.

Data stored in a Third-party storage

Data is stored in third-party storages using a structure very similar to the one of the Backup Path:

|-- accounts
|-- items
|-- server
`-- backupstat

The only difference in how the content is saved is that all metadata for a mailbox are compressed within a single .tar.gz file instead of being stored uncompressed and spread across multiple subfolders.

How to backup on S3

New Zextras Backup users who don’t have an initialized backup just need to run the setBackupVolume_S3 command to set up the S3 backup. Running it without any further argument will display the full usage message:

zxsuite backup setBackupVolume S3 [param VALUE[,VALUE]]

Existing Zextras Backup users, on the other hand, must use the migrateBackupVolume_S3 command to setup the S3 backup and migrate their current data to it.

zxsuite backup migrateBackupVolume S3 [param VALUE[,VALUE]]

In both cases the command will create a bucket if provided with all the required information, or will use an existing bucket if the bucket_configuration_id parameter is used.

The backup migration to a third party store also copies the metadata archives, the server’s configuration, and the map files; unlike what happened in previous releases, SmartScan is not run at the end of the migration, to reduce bandwidth consumption. Moreover, if the server’s logging is set to debug level, a line for each file uploaded will be added to the log file.

While similar in concept, Zextras Backup and Zextras Powerstore buckets are not compatible with each other - if Powerstore data is stored in a bucket it is not possible to store Backup data on the same bucket and vice-versa.

S3 Backup in a multi-mailbox environment

In multi-mailbox environments, it’s not necessary to create multiple buckets: enter the bucket configuration information when enabling the remote backup on the first server and then just use the bucket_configuration_id and prefix parameters to store other server’s data on a separate directory of the same storage.

Example:

On Server 1, set up the S3 backup by creating a new bucket:

zxsuite backup setBackupVolume S3 \
  bucket_name "Backup Bucket"
  access_key a1b2c3e4 \
  secret f5g6h7i8j9k0
  region EuWest \
  url s3api.myvendor.com
  volume_prefix "server1" \

After the backup is created, list all buckets and take note of the bucket_configuration_id of the backup bucket:

zxsuite core listBuckets all

On Server 2, set up the S3 backup using the previously created bucket:

zxsuite backup setBackupVolume S3 bucket_configuration_id vw12xy34z56 volume_prefix "server 2"

How to backup on NFS/Fuse

While at a first glance it might seem that due to the need of a local mountpoint specifically setting up the backup for NFS or FUSE has little utility, the backend differences in metadata handling ensure a greater degree of data safety.

Splitting the high-access metadata from the BLOBs ensures that disk failures, such as when the share becomes briefly available, are better handled thanks to the local cache granting a higher backup resilience.

To backup on "Local" shares such as NFS or Fuse, first mount the share and then use the appropriate command based on your need:

No pre-existing backup: zxsuite backup setBackupVolume Local
Running backup: zxsuite backup migrateBackupVolume Local

Both commands only require a single argument, which is the path to the local mountpoint of the NFS/FUSE share.

External Backup

What is the External Backup?

This functionality allows to define an external volume on which to store the backups, with the purpose to dramatically reduce the amount of local storage that is needed by the backup and tackle some possible issue that may arise over time, like a hardware failure that leads to data corruption of both the working copy and the backup or scalability issues i.e., the growth in size of the Mailbox might require more space than possibly available on the server.

Since it relies on an external volume, the Eternal Backup is also called Backup on external volume.

The introduction of this feature does not impact the other functionalities of the Backup and can possibly remain disabled; it is also not intended as a replacement for High Availability or Replication services.

Goals and benefits of the External Backup include:

The space needed by the backup on the local storage decreases up to 90%
Support for remote mount points, which must be configured in /etc/fstab and S3 object storage.
Efficient Real Time Scan
Backups are accessible to disaster recovery sites

This functionality partially impacts the existing CLI interface: a few new configuration parameters are introduced and some commands are slightly modified or are extended to support external volumes.

How it works

Before enabling this feature, it is necessary to configure the new volumes that will store the External backup, because no existent volume can be reused. Depending on what approach you choose, the steps to carry out are different.

When local Local shares are used, define a mount point in /etc/fstab with the necessary information to access the volume. In case of a multiserver installation, each server must access a different volume. Note that a volume does not coincide with a partition. For example, when using NFS shares, it is possible to expose different shares that are all stored within a same partition. Consider the following scenario as an example: NAS is located on 192.168.72.16 and has a partition mounted on /mount/externalBackup and exposed via NFS in which we want to store our multiserver installation’s backups. To do so, we first create under /mount/externalBackup one directory for each server: mkdir Server1 Server2 Server3, then we mount the three directories separately via NFS on the server, by adding on Zextras installation three entries similar to the following one in /etc/fstab:
```
192.168.72.16:/mount/externalBackup/Server1 /mnt/Server1 nfs rw,hard,intr  0 0
192.168.72.16:/mount/externalBackup/Server2 /mnt/Server2 nfs rw,hard,intr  0 0
192.168.72.16:/mount/externalBackup/Server3 /mnt/Server3 nfs rw,hard,intr  0 0
```
When using buckets, a new S3 bucket must be created for the purpose and will have its own credentials. You can choose to define in this S3 bucket one or more Zextras Buckets, depending on your requirements (e.g., geographic location, throttling, de-centralisation of backups, and so on). Each Zextras Bucket is identified by a prefix, hence you can use the combination of S3 bucket credentials and Zextras bucket prefix to uniquely identify and store multiple Zextras Buckets within a single S3 Bucket.

Once the volume is configured in zextras, it is possible to use it for the backup: the admin can migrate the backup from the current, local storage to the new external volume.

The external volume will then be used as a storage for the $BACKUP_PATH/items only, while the metadata (which are in $BACKUP_PATH/accounts will still use the local volume like a working directory to store the changed metadata. The SmartScan will then upload to the External Volume one tar.gz archive for each account.

Finally, there is a set of dedicated commands to download the metadata from the External Volume and rebuild the structure and the content of the account in case of disaster recovery.

Folder Permissions

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

Preparing the Migration

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 doCheckBlobs utility.

Running an External Backup

Via the Administration Zimlet

To start an External Backup via the Administration Zimlet:

Click the Zextras Backup tab.
Click the Export Backup button under Import/Export to 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.

Via the CLI

To start an External Backup via the CLI, use doExport command:

zxsuite backup doExport destination_path [param VALUE[,VALUE]]

Scheduling Script

The Zextras CLI can be used to schedule External Backup operations. This is handy when you need to keep a daily/weekly/monthly backup for corporate or legal reasons.

Zextras Backup CLI

This section contains the index of all zxsuite backup commands. Full reference can be found in the dedicated section.