Taking Additional and Offsite backups of ZxBackup's Datastore
From ZeXtras Suite Wiki
|Language:||English • español • português|
|Available since version: 0.87|
|Latest Version: 2.16.1|
|Released on: May 7th, 2019|
- 1 Who watches the watchmen?
- 2 Making an additional backup of ZxBackup's datastore
- 3 Storing your ZxBackup's datastore backup offsite
- 4 Additional/Offsite backup F.A.Q.
- 4.1 Why shouldn't I use the "Export Backup" feature of ZeXtras Backup instead of rsync?
- 4.2 Can I use this for Disaster Recovery?
- 4.3 Can I use this to restore data on the server the backup copy belongs to?
- 4.4 Can I use this to create an Active/Standby infrastructure?
- 4.5 Are there any other ways to do an Additional/Offsite backup of my system?
Who watches the watchmen?
While mailserver backups were never really a concern for Juvenal or Plato, the concept of "who watches the watchmen" can also be applied to this field.
Having backup system is a great safety measure against data loss, but each backup system must be part of a broader "backup strategy" to ensure the highest possible level of reliability. The lack of a proper backup strategy gives a false sense of security, while actually turining even the best backup systems in the world into yet another breaking point.
Devising a backup strategy is no easy matter, and at some point you will most likely be confronted with the following question: "What if I lose the data I backed up?". The chances of this happening ultimately only depend on how you make and manage your backups: it's more likely to lose all of your backed up data if you store both your data and your backups in a single SATAII disk than if you store your backed up data on a dedicated SAN using a RAID 1+0 setup.
In this article you can find some suggestions and best practices in order to improve your backup strategy by making a backup of the ZeXtras Backup's Datastore and storing it offsite.
Making an additional backup of ZxBackup's datastore
ZeXtras Backup's Datastore has the following characteristics:
- Atomicity: any transaction is committed and written to the disk only when completed.
- Consistency: any commited transaction is valid and no invalid transaction will be committed and written to the disk.
- Isolation: all transactions are executed sequentially so that no more than 1 transaction can affect the same item at once.
- Durability: once a transaction is committed, it will stay so even in case of a crash (e.g. power loss or hardware failure).
Due to this, it's very easy to make a backup of it. The best (and easiest) way to do so is by using rsync. Specific options and parameters depend on many factors, such as the amount of data to be synced and the storage in use, while connecting to an rsync daemon instead of using a remote shell as a transport as it's usually much faster in transferring the data.
You won't need to stop neither Zimbra nor the Real Time Scanner in order to make an additional backup of ZxBackup's datastore using rsync, and you will be always able to stop the sync at any time and reprise it afterwards if needed.
Storing your ZxBackup's datastore backup offsite
As seen in the previous paragraph, making a backup of ZxBackup's Datastore is very easy, and the use of rsync makes it just as easy to store your backup in a remote location.
In order to optimize your backup strategy when dealing to this kind of setup, the following best practices might help a lot:
- If you schedule your rsync backups, make sure that you leave enough time between an rsync instance and the next one in order for the transfer to be completed.
- Use the --delete options so that files that have been deleted in the source server are deleted in the destination one to avoid inconsistencies.
- If you notice that using the "--delete" option takes too much time, schedule two different rsync instances: one with the "--delete" to be ran after the weekly Purge and one without such option.
- Make sure you transfer the whole folder tree recursively starting from ZxBackup's Backup Path. This includes Server Config backups and mapfiles.
- Make sure the destination filesystem is case sensitive (just as ZxBackup's Backup Path must be).
- If you plan to restore directly from the remote location, make sure that the zimbra user on your server has read and write permissions on the transferred data.
- Expect to experience slowlynesses if your transfer speed is much higher than your storage throughtput (or vice versa).
Additional/Offsite backup F.A.Q.
Why shouldn't I use the "Export Backup" feature of ZeXtras Backup instead of rsync?
For many reasons:
- The "Export Backup" feature is designed to perform migrations. It exports a "snapshot" which is an end in itself and was not designed to be managed incrementally, meaning that each time an Export Backup is ran it'll probably take just as much time as the previous one, while using rsync is much more time-efficient.
- Being a ZeXtras 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.
- Should you need to stop an Export Backup operation, you won't be able to reprise it and you'll need to start from scratch.
Can I use this for Disaster Recovery?
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, but should your Backup Path be lost you'll be able to use your additional/offsite backup. See the Disaster Recovery Page for more informations.
Can I use this to restore data on the server the backup copy belongs to?
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 the following:
- Stop the RealTime Scanner
- Change the Backup Path to the copy you wish to restore your data from
- Run either a "Restore on New Account" or a "Restore Deleted Account"
- Once the restore is over, change the Backup Path to the original one
- Start the RealTime Scanner. A SmartScan will trigger to update the backup data
Can I use this to create an Active/Standby infrastructure?
No, because the "External Restore" operation does not perform any deletions. In the long run running several External Restores you'll end up filling up your mailboxes with unwanted stuff, 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 that your users will be able to send and receive emails even if the restore is running.
Are there any other ways to do an Additional/Offsite backup of my system?
There are for sure, and some of them might even be better than the one described in this page. This are just guidelines that apply to the vast majority of the cases. Feel free to share your experiences on the ZeXtras Forum!