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 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
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
, 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
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
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
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 FAQs on Operation Queue and Queue Management and Offsite Backup