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.
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:
- Installing the operating system is the first step in setting up the foundational system.
- Carbonio’s setup and bootstrapping are discussed in section Node Installation.
- 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.
- 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:
- a universal one that may be utilised
- a virtual machine that use the snapshot function of the hypervisor
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.
- 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.
Search for irrepairable items
Recognise the unrestored items
Unrestored Item Restoration
Making Additional and Offsite Backups of the Volume of Carbonio Backup
Creating an Additional Backup of the Volume of the Carbonio Backup
Keeping more offsite backups
- 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
- Every restoration procedure
Operating Queue Control
- 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.
Turn off Backup for a COS
- 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.