This chapter provides an overview of Zextras Backup, the element of the Zextras Suite in charge of data backup. A summary of the most frequent job is provided at the beginning of the chapter, along with connections to more technical sources.

The design of Zextras Backup is then explained, along with some crucial previous knowledge that will be expanded upon later in the chapter.

The choices for regularly storing and checking the backed-up data are then offered. The relevant Command Line Reference is provided for each section.

Common Zextras Backup Tasks

In addition to connections to technical resources, this section includes instructions for the most often job requested by users.

Activating Zextras Backup

A few additional steps are required once your servers are set up before you can configure the Backup module and have all of your data automatically backed up.

• Install a storage device where you want it. In this step, the default path is /opt/zimbra/backup/zextras; make sure to change it to the one you choose.
• Set the backup path’s correct permissions: /opt/zimbra/backup/zextras chown zimbra:zimbra

The backup route must be initialised once you have defined it, which may be done through the admin panel or the command line. In the first scenario, press the Initialise NOW! button in Fig. 6’s upper right corner. Initialization is carried out through the CLI by simply launching SmartScan for the first time: backup by zxsuite start doSmartScan

The design of Zextras Backup

The key ideas necessary to comprehend Zextras Backup’s design are introduced in this part, along with an overview of how they relate to one another. Each idea is then further explored in its own area.

RPO and RTO are two broad techniques that are taken into consideration when developing a backup plan, which we will discuss before moving on to the architecture of Zextras Backup.

The Recovery Time Objective (RTO) is the maximum length of time a stakeholder is willing to wait to recover its data, whereas the Recovery Point Objective (RPO) is the maximum quantity of data that a stakeholder is willing to lose in the event of a disaster.

These definitions state that the ideal acceptable value is zero, although practical values typically fall within a range of zero, depending on the amount of the data. Real Time Scan and SmartScan work together in Zextras to ensure that both RTO and RPO numbers are very low: While the SmartScan replicates all objects that have been updated, the Real Time Scanner guarantees that all metadata changes are recorded as soon as they occur. As a result, the potential loss of data is minimal and often restricted to those items that have changed between two consecutive runs on the SmartScan.

The notion of ITEM serves as the foundation for Zextras Backup’s whole architecture: The smallest thing that may be kept in the backup is called an item. For instance:

• email communication
• a person or a group of people
• a binder
• an arrangement
• a task
• a document on Drive
• a user account and its settings
• a list of recipients
• an area
• a category of services

As a result, they will never be checked for changes by the Real Time Scan or included in a restore. Examples of such objects include the following:

• Server configuration, or the parameters for each server
• Global Zextras product settings
• Any modifications (Postfix, Jetty, etc.) added to the programme

Every change in the accompanying information for each item handled by Zextras Suite is tracked and preserved, enabling its restoration at a later time. In other words, if one of an item’s associated information changes, a transaction-based “photograph” of the entire thing is taken and saved with a timestamp. Metadata that describes an item includes, for instance:

• when an email was opened, read, deleted, and transferred to a folder.
• a change to a contact’s name, address, or employment
• the removal of a file from a folder or its insertion
• the modification of an item’s status (such as an account).

Technically, all modifications made to an object over its lifespan are kept in the form of a JSON Array. Read more about this in the section on item structure.

An object that has been designated for deletion is known as a deleted item.

A transaction is a change in the state of an object. Change of status refers to when a user modifies one of the item’s related metadata. As a result, a Transaction may be thought of as a snapshot of the metadata taken at a certain point in time. A Transaction ID serves as a unique identifier for every transaction. An item can be returned to any previous transaction. Zextras Backup Restore Strategies has further information.

Real-Time Scan and SmartScan

The actual content of a mailbox is read and utilised to create the backup as part of the Initial Scan, which is carried out by the SmartScan. If the Scan Operation Scheduling is activated in the Administration Zimlet, the SmartScan is then run daily and at each module start.

The main function of SmartScan is to look for objects that have changed since its last run and to update the database with any new data.

Every action that occurs on the system is recorded in real time by the Real Time Scan, enabling recovery with split-second accuracy. Since nothing in the backup is overwritten by the Real Time Scanner, each object has its own entire history. Additionally, it has the capacity to recognise other modifications pertaining to the same item at the same time and record them all as a single metadata change.

Real Time Scan and SmartScan are both by default enabled. While each one can be stopped (on their own), it is advised to leave them both running because they are meant to work best together.