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
--deleteoptions 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
--deleteto 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
zextrasuser 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
Additional F.A.Q. for Offsite Backup
For many reasons:
The Export Backup feature is designed to perform migrations. It exports a snapshot that is not designed to be managed incrementally. Each time an Export Backup is run, it will probably take just as much time as the previous one, while using rsync is much more time-efficient.
Being a Carbonio Backup operation, any other operation started while the Export Backup is running will be queued until the Export Backup is completed
An Export Backup operation has a higher impact on system resources than an rsync
If you need to stop an Export Backup operation, you will not be able to reprise it, and you will need to start from scratch
Yes. Obviously, if your Backup Path is still available. it’s better to use that, as it will restore all items and settings to the last valid state. However, should your Backup Path be lost, you’ll be able to use your additional/offsite backup.
Yes, but not through the External Restore operation, since item and folder IDs are the same.
The most appropriate steps to restore data from a copy of the backup path to the very same server are as follows:
Stop the Realtime Scanner
Change the Backup Path to the copy you wish to restore your data from
Run either
Restore on New Accountor aRestore Deleted Account.Once the restore is over, change the backup path to the original one.
Start the RealTime Scanner. A SmartScan will be triggered to update the backup data.
No, because the External Restore operation does not perform any deletions. By running several External Restores, you’ll end up filling up your mailboxes with unwanted content, since items deleted from the original mailbox will not be deleted on the standby server.
The External Restore operation has been designed so that accounts will be available for use as soon as the operation is started, so your users will be able to send and receive emails even if the restore is running.
There are for sure, and some of them might even be better than the one described here. These are just guidelines that apply to the majority of cases.