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.
When to Turn Off Scanning Operations
- You often work with Drive documents or have a large volume of daily transactions, and you see that the server is using a lot of resources. In this situation, the Real Time Scan can be temporarily disabled.
- You begin a migration: In this situation, it is advised to suspend the SmartScan since it would cause several I/O operations on the disc and maybe even cause the server to become unresponsive. In fact, it would regard each object that was moved or restored as a brand-new one.
- Your daily email volume is heavy, both inbound and outbound. In this situation, you should always keep the Real Time Scan on since otherwise, the SmartScan will be the only backup for all transactions, and because I/O operations need a lot of resources, it might not be able to finish in a timely manner.
- Map files, also known as map_[server_ID] files, are used to indicate if a backup has been imported from an external backup and include the server’s unique ID in the filename.
- All of the accounts defined in the Mailbox’s definitions are listed in the directory called accounts. You may find there, in particular, the following significant files and directories:
- The file account_info contains all of the account’s details, such as the password, signature, and preferences.
- account_stat is a file that contains statistics about the account, such as the ID of the most recent content that SmartScan saved.
- The timestamp of the first run is one of the general data about the backup that are maintained in the file called backupstat.
- Drive items are kept in a directory called drive_items that has up to 256 subfolders, each of which is named using two lowercase hexadecimal letters. Drive items are placed here according to the last two letters of their UUID.
- items is a directory that has up to 100 subfolders. Items are kept in these subfolders according to the last two digits of their IDs.
- servers is a directory that holds archives, one every day up to the chosen server retention duration, of the conversation, Zextras configuration, and server configuration and customizations.
- items is a directory with a name made up of two hexadecimal (uppercase and lowercase) characters that may hold up to 4096 extra folders. The directory whose name contains the final two characters of each item’s ID will hold the items in the Mailbox.
- A map between the original object and the restored item is contained in the user object ID mapping file called id_mapper.log. The file may be found in /backup/zextras/accounts/xxxxx-xxxx-xxxx-xxxxxxxxxx/id_mapper.log. Only in the event of an external restoration is this file present.
Choosing a backup route
- Via GUI: Under “Backup Path” in the “Backup” section of the Zextras Administration Zimlet.
- Using the CLI: changing the ZxBackup_DestPath config key using the zxsuite config server command.
- The default setting for the data retention policy for single items is 30 days.
- The account retention policy relates to the accounts and is set to 30 days by default.
Check for Coherence
The Operation of Zextras Backup
- able to be read and written by users of Zimbra.
- Use a filesystem that recognises case.
The Composition of an Item
Team database backup
What is a SmartScan, exactly?
How does it function?
How Often is a SmartScan Run?
- Upon launching the Zextras Backup module.
- Whenever the Scan Operation Scheduling option in the Administration Zimlet is activated, every day
- after being previously deactivated, when the Real Time Scanner is once again enabled through the Administration Zimlet
Checking the Status of a Running Scan and Running a SmartScan
What exactly is a real-time scanner?
How does it function?
Why Should I Disable the Real Time Scanner? Managing the Real Time Scanner Enabling the Real Time Scanner
Safety Scan and Limitations
- When a user selects the Empty Folder option from the right-click context menu, the folder is empty.
How does it function?
- Weekly if the Administration Zimlet’s Scan Operation Scheduling is activated.
- when manually initiated using the CLI or the Administration Console
Limitations and Unique Situations for the Backup
- In a few instances, the backup does not function properly. Here, we go over such situations.
- The most recent state should NOT be used when restoring an active account to a new account. Imagine if a person accidentally deletes all of his emails or that the emails in a user’s account are lost for any other cause (such, for example, a server failure). The user begs the administrator to give them back. The outcome of restoring the account status to the most recent state accessible is that the new account will include that state, which is an empty account because the emails had already been erased in the most recent state. Therefore, it is important to restore the account to a point in time that is before the emails were erased in order to do so appropriately.
- If an email client is set up to download emails and promptly delete them from the server while utilising the POP3/POP3S protocol, these emails might not be backed up. If the Zextras Powerstore component is installed, this does not take place.
- The backup does not include emails sent directly over an SMTP connection (such as when using a multifunctional device or telnet to connect to the STMP server).
- If an IMAP/SMTP client is used to send email, the IMAP client must be set up to store the email in a remote folder (using the IMAP STORE command) after the send operation in order for the email to be backed up.
Fixing LDAP Backup issues
Amplify Log Verbosity
Root credentials are missing
Use external storage as a backup
- backup zxsuite doSmartScan
- backup zxsuite doAccountScan
- doBackupServerCustomizations in zxsuite backup
- backup with zxsuite doBackupLDAP
- backup using zxsuite doBackupCluster
Objects and advantages
- Only metadata that statistically makes up less than 10% of the overall backup size requires fast IOPS storage.
- The majority of the time, backups are kept outside, away from the local infrastructure, and are therefore reachable from disaster recovery sites.