Carbonio Email Service provider

Logo
Menu
Have a Question?

This section introduces a number of possibilities to recover a single lost item and other advanced backup management options before moving on to a disaster recovery scenario and the solutions to it.

Emergency Recovery

One or more of the following events must take place for a situation to be labelled as a disaster:

  • One or more critical discs or filesystems (such as / or /opt/zextras/) experiencing hardware failure
  • Due to internal or external circumstances (such as a thoughtless rm *, an incursion from the outside, an incorrect file being replaced, or other), the content of a crucial disc became inaccessible.
  • issues with the hosting environment for Carbonio, such as faulty hardware or a failed hypervisor that affects snapshots.
  • a serious flaw in a piece of third-party software or an OS update or upgrade, like a corrupt kernel.

In a catastrophe situation, you would experience a data loss and would either need to replace a hardware part or make repairs to the virtualization infrastructure, as well as repair or reinstall the system.

Reduce the Chances

Because one of the failures stated in the preceding section is unpredictable and might occur at any time, preventing a disaster scenario may not be a simple undertaking.

However, there are a number of solid practises we may recommend to reduce the likelihood of a tragedy, including the following:

  • Always retain important filesystems on separate discs, such as your Carbonio backup path or /opt/zextras.
  • For your server, use a monitoring and alerting solution to spot issues as soon as they arise.
  • Plan your upgrades and migrations thoroughly.
  • To duplicate the services offered by Carbonio, think about using redundancy.
  • Keep numerous backup copies on hand: Please see section Making Additional and Offsite Backups of Carbonio Backup’s Volume for additional details.
The Rehabilitation Process

If, despite your best efforts, a disaster still occurs, you can follow these procedures to restore the system:

  1. Installing the operating system is the first step in setting up the foundational system.
  2. Carbonio’s setup and bootstrapping are discussed in section Node Installation.
  3. Recovering data entails re-importing the most recent data onto the Carbonio server, which may include user and domain configurations, COS data, and mailbox contents.
  4. Recovery of Configurations and Settings

The third point can benefit from Carbonio Backup’s Import Backup option, which offers a quick and secure means of recovering from a catastrophic situation.

In fact, you may use the previous server’s backup path as the import path. allows you to roll back a Carbonio installation to its most recent working state on your previous server.

To recover Carbonio to a certain condition recorded in a backup, there are two equal methods:

  1. a universal one that may be utilised
  2. a virtual machine that use the snapshot function of the hypervisor
Data restoration

These steps must be followed in order to complete the recovery process. It is difficult to estimate in advance how long it will take to properly finish the recovery given the amount and kind of objects involved.

  • Install Carbonio on a fresh server, then set the global and server settings.
  • Mount the old server’s backup folder on the new one. Use the most recent version of either of the two external backups if this is not an option.
  • Use the following CLI command to launch an External Restore on the new server:

The system will be available for your users as soon as the External Restore procedure is finished (see your Carbonio Notifications), since it will immediately generate the domains, accounts, and mailing lists. Emails and other mailbox contents will thereafter be recovered.

Configurations and Setting

Although server and global settings are backed up, they are not immediately restored. With the exception of the minimal Carbonio version necessary, you may restore your data to a server with a different OS, Carbonio Release, networking configuration, and storage arrangement thanks to the high-level connection between Carbonio Backup and Carbonio.

Carbonio Backup has a very useful CLI command that can be used to make an exact duplicate of the previous server or to simply modify its settings to a new environment.

Repair from snapshots and virtual machines

These days, hypervisors’ customizable snapshot capabilities and snapshot-based VM backup solutions are among their most valuable features. Using Carbonio Backup’s External Restore function and the server’s backup path as the import path, it is always feasible to roll back to the most recent snapshot in the event of a disaster and recover the lost data.

You can preserve a frozen duplicate of a virtual machine in a usable condition and roll back to it whenever you want with snapshot-based backup methods. It is preferable to make snapshot copies of powered-off VMs to maintain complete data consistency, although this is not required.

Using Carbonio Backup, you may execute a disaster recovery from a prior VM state if you do the following:
  • Make sure that no users can access it and that neither incoming nor outgoing emails are sent before you restore the last reliable backup onto a different (clone) VM in a separate network.
  • Wait for Carbonio to start before switching to the clone.
  • Disable the RealTime Scanner in Carbonio Backup.
  • Connect and mount (on a separate path) the virtual disc holding the unaltered backup path to the clone.
Launch an external restore while utilising the import path for the backup.
This process analyses every item in the Backup Path and imports the ones that are missing, hastening catastrophe recovery. Furthermore, as long as user access and mail traffic are restricted, these processes can be done as often as necessary.

Verify that everything is operational when the restoration is finished, then restart user access and mail traffic.
The Consequences
Simply initialise a new Backup Path and store the old one in case you need to recover any stuff from before the disaster.

Items are referred to be unrestorable when an automated restoration during the recovery process was not feasible. The most frequent causes of this might be many, but they include:
Search for irrepairable items
Following the completion of the recovery procedure, the administrators will receive a thorough message of Operation Completed that includes a list of missed items for each account, as demonstrated by the following excerpt:
In the passage above, we indicate:

omitted elements
Everything that had previously been restored, either during this restoration or a prior one. Consequently, this communication serves just as information.

unrestored objects
a thing that wasn’t restored because the restore procedure ran into trouble. If you want to try to reclaim these things, make a note of all their IDs. They will be mentioned in the section’s reminder.
Recognise the unrestored items
There are two methods to achieve this: using the Carbonio Admin Panel and through the CLI. The backup/import path may be searched for the item using the first method, and the Web interface can be used to examine the item using the second method.
Unrestored Item Restoration
It is obvious when an item cannot be restored that there is a problem, either with the item itself or with your present Carbonio configuration. In some circumstances, even if an item cannot be restored on the first try, there are still strong odds that it can be recovered.

You can find a number of useful hints and pointers in the paragraphs that follow for handling various sorts of irreparable objects.
Making Additional and Offsite Backups of the Volume of Carbonio Backup
Having backup systems is a fantastic way to protect against data loss, but in order to guarantee the maximum degree of dependability, each backup system has to be a part of a larger backup plan. Lack of a sound backup plan might make one feel secure while really putting even the strongest backup systems in the world at risk of failing again.
Making a backup plan is not a simple task, and you will eventually have to consider the following scenario: “What if I lose the data I backed up?”. In the end, the likelihood of this occurring only depends on how you create and maintain your backups. For instance, storing both your data and backups on the same SATA-II disc increases the likelihood that you will lose all of your backup data compared to storing your backups on a separate SAN using a RAID 1+0 configuration.

Creating a copy of the copy NG datastore and storing it offsite is one of the greatest ways to improve your backup plan, as are the following recommendations and best practises.
Creating an Additional Backup of the Volume of the Carbonio Backup
A backup can make use of the well-known database qualities known as ACID, which ensure data validity and integrity, to reduce the likelihood of data loss.

It is quite simple to create a backup of the Volume and ensure the authenticity and integrity of the material by adhering to these criteria. Using the rsync programme, which is built around a method that only transmits deltas (i.e., what really changed) instead of the entire data and operates progressively, is the best (and simplest) way to achieve this. A connection to an rsync daemon rather than utilising a remote shell as a transport is often more faster at moving the data than the latter. Specific settings and parameters depend on a variety of circumstances, including the volume of data to be synchronised and the storage being used.
To create an extra backup of the datastore for Carbonio Backup using rsync, you won’t need to stop Carbonio or the Realtime Scanner, and because of the ACID qualities, you can always pause the sync and resume it at a later time.

Keeping more offsite backups
As was seen in the last section, it is quite simple to create a backup of a Carbonio Backup Volume, and using rsync to save your backup remotely is just as simple.

The following best practises are advised when working with this type of configuration to optimise your backup strategy:
  • Make sure to provide enough time between one rsync instance and the following one when scheduling your rsync backups so that the transfer can be finished.
  • To prevent discrepancies, use the –delete options to ensure that files that have been destroyed on the source server are also deleted on the destination server.
  • Schedule two separate rsync instances: one with –delete to be run after the weekly purge and one without this option if you observe that using this option takes a long time.
  • Make sure you start with Carbonio Backup’s Backup Path and transfer the whole folder tree recursively. Backups of the server’s configuration and map files are included.
  • Make that the filesystem at the destination is case-sensitive.
  • Make sure that the zextras user on your server has read and write rights on the transmitted data if you intend to restore directly from the distant location.
  • If your transfer speed is significantly higher than your storage throughput (or vice versa), you should prepare for slowdown.
Additional Offsite Backup FAQs
The Operation Queue and Queue Management of Carbonio Backup
A dedicated, unprioritized FIFO queue is used for each Carbonio Backup operation that is launched, whether manually or automatically. As soon as a previous operation is dequeued (either because it has finished or been terminated), the subsequent operation is carried out.
The subsequent operations are impacted by the queuing system:
external backup si’
  • Every restoration procedure
  • SmartScan
Changes to Carbonio Backup’s setup are implemented right away and are not queued up.
Operating Queue Control
In instances like this, it is beneficial to know whether Carbonio Backup operations are currently in progress and to manage the queue.
  • See the queue
  • Use the command Clear the Queue to see all currently-running and pending activities.
  • Use to empty Carbonio Backup’s operation queue and halt all currently-running operations.
  • Eliminate only one procedure from the waiting list.
Use the doStopOperation command together with the operation’s ID to eliminate a specific operation from the queue. Using the ID 30ed9eb9-eb28-4ca6-b65e-9940654b8601 as an illustration, run
COS-level Backup Management enables the administrator to completely turn off all Carbonio Backup features for a Class of Service. In other words, no COS member will ever be included in a backup, which reduces the need for storage.
Turn off Backup for a COS
The $ZxBackup_Disabled marker will be added to the Class of Service’s Notes field when the backup for that Class of Service is disabled.
The backup for the COS will now again be available if you change or delete this marker, even though the Notes field is still completely editable and useable.
Since this functionality can only be used through the CLI, use the command carbonio backup doEnableDisableCOS to stop the backup for a specific COS. For example, to stop the backup for the COS named EXTERNAL_COLLABORATORS, use
Run the same command, replacing disable with enable to re-enable the backup.
Additionally, you may use the command to view the backup status for all COS.
The following occurs in the COS when Backup is disabled:
  • Every account will be ignored by the RealTime Scanner.
  • The accounts will not be exported via the Export Backup feature.
  • The backup system will regard accounts as having been deleted. This indicates that all data for those accounts will be deleted from the backup repository after the data retention term has passed. Resetting this behaviour to the default state and designating accounts as Active are accomplished by re-enabling backup for a Class of Service.