The component that is in charge of backing up all the data is Carbonio Backup, which is covered in this chapter. 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 Carbonio Backup is then explained, along with some crucial preparatory knowledge that will be expanded upon in the next sections.
Finally, the options for backing up objects and accounts are described along with the appropriate CLI instructions. Tasks that can be completed using the GUI may be found in the Backup area of the Admin Panel, while those that can be completed using both the CLI and GUI are cross-referenced between the two sections so you can select your preferred method of execution.
As a result, the Backup documentation is divided into four primary sections:
- The current page for backup (of an AppServer) contains information on the architecture of the backup modules, a glossary of terminology that are important, the most frequent backup actions, and how to perform each one using the CLI.
- Restore Techniques for the Backup: CLI-based methods for restoring specific objects, accounts, or whole AppServers
- Advanced Backup Techniques, including Disaster Recovery, a group of last-ditch recovery options in the event of hardware or software issues (unrelated to Carbonio)
- All tasks that can only be completed through the GUI are included in the backup of the Admin Panel.
Common Tasks for Carbonio Backup
In addition to connections to technical resources, this section includes instructions for the most often job requested by users.
How to Run the Carbonio Backup Programme
The Backup component must be configured after you have done setting up your server in order to have all of your data automatically backed up.
- Install a storage device where you want it. In this step, the default path is /opt/zextras/backup/zextras; make sure to change it to the one you selected.
- Set the backup path’s correct permissions: /opt/zextras/backup/zextras chown zextras:zextras
Building Blocks of Carbonio Backup
The key ideas necessary to comprehend the architecture of Carbonio Backup are introduced in this section, 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 Carbonio 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. Realtime Scanner and SmartScan work together in Carbonio 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.
- email communication
- a person or a group of people
- a binder
- an arrangement
- a task
- a file from the Carbonio Files
- a user account and its settings
- an email list
- an area
- a category of services
- Server configuration, or the parameters for each server
- Global Carbonio product settings
- Any modifications (Postfix, Jetty, etc.) added to the programme
- 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).
Realtime Scanner and SmartScan
When to Turn Off Scanning Operations
- You frequently deal with Carbonio Files 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 need always have the Realtime Scanner running because otherwise, the SmartScan would be the only backup for all transactions, and because I/O operations demand 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 AppServer’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.
- The directory drive_items has up to 256 subfolders, each of which is named with two lowercase hexadecimal letters. These subfolders are where Carbonio Files items are saved, 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 per day up to the chosen server retention duration, containing the server configuration and customizations, the Carbonio configuration, and the chat.
- 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 final two characters of each item’s ID will be used as the name of the directory where it will be kept in the AppServer.
- 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
- 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
How Carbonio Backup Operates
- by the zextras user to be able to read and write to.
- Use a filesystem that recognises case
The Composition of an Item
Block-free Backup Mode
To activate Blobless Backup Mode, there is just one prerequisite.
- There must be no independent third-party volumes: Only local volumes and centralised third-party volumes may be used with Blobless Backup Mode.
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.
- 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 Carbonio Advanced 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.
Use external storage as a backup
- backup carbonio doSmartScan
- backup carbonio doAccountScan
- backup using carbonio, doBackupServerCustomizations
- backup using carbonio doBackupLDAP
- backup carbonio doBackupCluster
Goals 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.
Information Kept in External Storage
External NFS/Fuse Storage
Storage for external objects
- What transpires in this case is regrettable in a number of ways:
- Data stored on the Bucket has already been completely gone.
- The command carbonio core list still displays the remote bucket.All buckets
- Still attempting to utilise that bucket is the backup
- There is no way to get rid of the flawed bucket.
- But there is a very easy way out of this situation, and there are really two options:
- employ the command
- The default, local path will now be used by the backup.
- Another ObjectStorage is already accessible to you: Use the following command to establish a new Backup Volume (we’ll use a new S3 bucket as an example).