Planning your backups
Some thoughts on choosing a backup plan when considering offline storage constraints.
The key to the well regarded 3–2–1 backup strategy is the diversity of backup media and location.
- 3 copies of your data
- 2 local copies on different storage types
- 1 backup off-site
We have written in general about this here.
Typically, you will choose to transmit your backup files to offline / cloud storage over a network. However, even though a decent uplink bandwidth is available at a much more reasonable cost than a few years ago, it is still usually low enough that transmitting a full image backup can take a significant time. Also, WAN connections are often asymmetric with the uplink being up to an order of magnitude lower than the download. One hybrid option to overcome this is to send the full by post and only transmit the delta (inc/diff) backups via the network (see https://aws.amazon.com/snowball/ for a commercial example).
Commercial offsite / cloud storage solutions typically carry a storage size per month charge. This can be considerable for multi-GB image backups.
Reflect offers several predefined backup templates. They have different characteristics that make each most suitable to different overall backup strategies.
Each file contains the entire backup. Each backup point is time-consuming to generate and takes a lot of storage.
Use only if you require each backup file to be self-contained. This might be appropriate for tape archives or write once media.
It is inappropriate when using a remote network sync unless you are not limited by your uplink bandwidth and your offsite storage quota.
Incremental / Incrementals forever
A full is required to seed the backup chain, but all subsequent backups just contain changes since the last incremental. This is the most efficient plan in terms of backup speed and storage space.
However, backups in a chain can only be deleted backwards in time from the most recent. To enable only the most recent backups to be retained, instead of just deleting the unwanted older incremental files, the data from the incremental backups to be discarded are consolidated into the oldest incremental to be retained.
If the Create synthetic full option is set, the behaviour changes; the data from the discarded inc. backups are merged into the full backup.
Read more about the impact the two options on synchronisation here.
The Synthetic full option is inappropriate when using a remote network sync unless you are not limited by your uplink bandwidth as you will need to upload the new synthetic full after each backup point.
Incremental backups may not be appropriate for tape archives or write-once media.
If the backup files are spread across multiple tapes / disks then a restore may be difficult as all the backup files in the chain will need to be located.
If consolidation is invoked, the files that have been updated/merged will need updating on the archive media.
A full is required to seed the backup chain, but subsequent backups contain all the changes since the full backup. The differential backup size will typically increase in time.
The payback for the slowly increasing size of the differential backup files is each backup point is represented entirely by a single differential and its parent full backup.
This backup scheme lends itself well to a remote network sync (especially if bandwidth is low and posting the full is an option). As the size of the differential backups will increase over time, there is a point where it is more efficient to create and upload a full backup.
Grandfather, Father, Son
This is a hybrid of the above schemes with scheduled full, differential and incremental backups (once a month, week and day respectively by default).
If the parameters are chosen well, it will work well for offsite synchronisation. As you have 3 concurrent backup chains, you can choose to store just the full (and diff) backups on tape media for archival purposes.
Incremental backup files are typically small. However, a defrag may result in a large incremental if the volume had been significantly fragmented.
Syncing consolidated incremental files (and a synthetic full if enabled) over the network can be achieved efficiently using a protocol such as rsync that only copies changes.
Reflect uses a mechanism that ensures that during a consolidation any interruption in the process will not result in a corrupt backup chain. However, this cannot be guaranteed during a remote sync.
You can read more about Creating and Editing a Backup Plan here.