Do not be too far forward.
For as long as there has been data, there has been a need to keep another copy somewhere safe. While the medium has changed greatly from rocks to animal skins to papyrus to paper and eventually on to digital media, the need to place data somewhere safe has remained unchanged. We’ll deal in this article with digital backups, since I have no particular talent with rock-based or animal skin-based backups.
Before jumping fully into what backups are, let’s review what backups AREN’T. I often get asked about mirroring (typically two disks, one disk being used for data, one to be an exact replica of the first one) and RAID (many disks banded together to either provide performance or data integrity). Usually the question goes like this:
“I have mirroring (or RAID) set up, do I really need a backup too?”
The short answer is an emphatic YES. Here’s the longer, slightly more detailed version:
While mirroring and RAID are essential technologies – particularly for servers – they are not a substitute for backups. It is true, it meets the barest definition of a backup. Data exists in more than one place simultaneously but there are no “Point In Time” backup options available. Point In Time (often abbreviated as PIT) backups give you the ability, as the name implies, to restore backward to a point before an issue happened. When Sally in Accounting (or Dave in Engineering for that matter) accidentally deletes the CEO’s entire digital collection of lint photos, this highly important data can be restored to their pre-apocalyptic glory. Not so with mirroring or RAID; by their design, they will immediately copy any changes made to the data structure. Without proper digital backups, the lint photos are GONE.
Mirroring (or RAID) AND backup, not OR.
Still others will ask about Microsoft Windows’ “Previous Versions”. The logically named Previous Versions feature allows you to restore backward through – you guessed it – previous versions of the files. We occasionally quickly restore client data by using this tool but the process does suffer from a few drawbacks:
The backup data resides on the same disk that is being backed up
Typically only backed up once a day on a schedule determined by the system itself
The number of revisions is limited by the amount of disk space that was made available to the Volume Shadow Copy service when it was configured.
What I recommend:
Much has been written over the years about a backup strategy called 3-2-1. This plan improves on the old maxim that states if it doesn’t exist in 3 places (live data and 2 backups), it doesn’t exist. 3-2-1 takes the idea one step further by stating that there should be 3 copies of the data, on 2 different media, and 1 offsite.
The data should exist in 3 locations; the live, working data and two backups. Backup media is just as prone to failure as the disks where the primary data resides. In days past, it was even more susceptible to problems – backup tapes would be unreadable, DVD backups would be scratched. This reliability has improved greatly with disk-based backups, but you should never assume that a single backup is sufficient.
The requirement for 2 different media also hearkens from when backup media was more fragile. In the past, both tape and disk-based backup might be used, or DVD and tape. This would ensure that your two backups were not subject to the same weaknesses. We find that this method is still quite valid, but we recommend approaching it in a slightly different way – first backup is to disk media, second backup is to cloud-based storage. This also satisfies the last requirement:
One of the backups should be offsite to preserve geographical diversity.
In more recent years the ability of backup software to keep PIT backups small has completely changed what is being backed up. Where at one time we would only back up files and possibly server configurations, we are now able to take a “snapshot” – a complete disk image of the server – and store only the parts that have changed since the last snapshot. This has made it possible to create fully bootable image backups. If that wasn’t impressive enough, we’re also able to take these images much more frequently. It’s possible to restore a server to a point in time less than an hour prior to its crash, if need be.
One final point – backups amount to naught unless they are monitored and tested. Often. While this seems like it would take a long time, the time required to test your backups at least semiannually (more frequently is preferable) pales in comparison to the time and effort required to resurrect a server while hoping your data backups held together. We cannot be assured that the lint photos will be there unless we test the backups.
Test. Test often.