How to Craft the Right Backup Policy for Your Business
How often to back up data and how long to retain those backups are questions that we ask of all prospects and customers. Quite often, we get a response that says, “Do whatever is customary.” However, there is no “customary” set of backup policy rules. Requirements vary from business to business depending on a range of operational, business and regulatory needs.
In this post, I’ll walk through the importance of operational backups as part of any IT business continuity plan, as well the considerations you’ll have to make before determining the frequency and retention policies best suited to your organization. Finally, I’ll share how to keep your policy documentation as simple and user-friendly as possible.
Backups Protect Against Operational (Not System-Wide) Disasters
In what context do organizations use backup restores? It’s always good to keep this question in mind when considering the importance of operational backups. Unfortunately, there isn’t a Bureau of Backup Statistics to do root-cause analysis and tell us how often restores occur and why. Anecdotally, however, we know human-caused errors are generally behind the majority restores.
Users can inadvertently delete or otherwise mangle an individual file. Operating system and application upgrades to a server can also go awry and require that a server be “rewound” to just before the upgrade. Then there is the intentional disaster caused by someone vandalizing the server. All of these are common disasters that require restoration from backup. Note that these high-frequency events are not caused by a widespread catastrophe, thus the data center location infrastructure still exists and has remained available.
These pointed disasters that affect only a portion of the larger environment and aren’t something requiring a failover to another geography. Indeed, such failover to another geography can incur additional downtime impacting other systems that weren’t impacted by the initial catastrophe.
In this way, backups are akin to having a spare tire. You have the spare so that you don’t replace the entire car. It is more prudent to replace the flat tire with the spare tire and get things going again than it is to replace the entire vehicle. Similarly, having a backup gives you a rollback point to get things going again rapidly.
IT Operational Backup Policies to Mitigate “OOPSIES”
In absence of business or regulatory backup requirements, IT managers will, at minimum, need to execute and retain backup images of operating systems. It takes less manpower and downtime to restore a server image from a backup than it does to rebuild it from scratch. That part is obvious, but answering how long to retain backups requires more thought. It depends on what type of system you’re managing.
In systems with restricted access so that users are limited in how much damage, one week’s worth of retention might be all that’s required. With good monitoring of the server and operating system, you would know that a corrupted file was causing a server failure and would be able to troubleshoot and restore the corrupted file with relative ease.
On a more open system, such as a file server with nearly unfettered access by users to modify and delete files, the retention period should be longer. If a user deleted or incorrectly updated a file, would they come to you a month after deleting or damaging a file? That’s actually a quite likely scenario.
Backups are even important for systems that rely on ephemeral infrastructure. This relatively recent concept might apply to web servers or application servers that process or render data, but don’t store it. These servers might be arrayed behind load balancers so that one can fail while it’s siblings carry on the work. Leveraging Chef, Puppet, Ansible or similar orchestration utilities makes it so that rather than try to repair the server, you dispose of it and build a new one from a script. The orchestration utility uses an Application Program Interface (API) to issue commands to build the new server. Since there’s no data and the rebuild script can mint out a new server in less time, why back it up at all? Simply put, it would be catastrophic if the orchestration server failed. Without it, there’s no mechanism to build new servers. Don’t forget to back it up, as well.
Business-Driven Backup Policy
In some scenarios, backups are required to meet service level agreements (SLAs) with customers or partners. Typically, there are certain applications that business leadership wants backup protection extended beyond the baseline set forth by IT management. These frequency and retention requirements might stack atop of your operational backup requirements.
Compliance Considerations
Some compliance requirements are rather open-ended, while others will tell you exactly how long to retain records. For example, some state governments require keeping employee records for 7 years. If records are kept within a closed-access database and are not purged until they are 7 years old, the data is always in the database and you’re technically following the rule of the law. Therefore, your normal backup retention policies are more than sufficient.
Again, these compliance requirements might stack atop of operational backup requirements.
Don’t Be a Data Hoarder
While often overlooked, it’s a good question to ask if data should be destroyed when it ceases to be useful. Consider that if you have old data that will never be used by you and aren’t required to keep, but you still must protect it, it might it be better and more cost-efficient to just destroy it. On a personal level, we do this at home already. Why not also consider it in our businesses?
For example, consider the legal component of this question. One might consult with the firm’s attorney to determine how long to keep data and when it is prudent to destroy data after a certain point in time. For example, an attorney may do some discovery work on current statutes of limitations for product liability and find that up to two years is when an action must be brought to suit. Keeping data older than two years could actually be burdensome since it might be required to make it available during discovery. Having a written policy deeming that such information should be destroyed after two years and following through with the destruction could prevent future legal headaches.
Outside of litigation, a lot data also ceases to be worthwhile to keep. Think of your own home records as an example. You might keep tax returns indefinitely, but supporting documentation like W-2s, 1099, receipts might be shredded after 7 years. Bank, credit card statements, pay stubs, etc. might only be kept a year.
Keeping business information requires that you protect data even if it’s no longer useful. If it costs more to keep and you don’t need it then why keep it?
Write Your Backup Policy Down
Like any other written backup policy, having written and published policies regarding backups can go a long way toward documenting, clarifying and serving as a basis. There are a lot of policy templates available, and the policy doesn’t necessitate being wordy or verbose. Rather, a policy can be a page or two long that states the purpose of the policy. The policy itself can be a simple table detailing the types of data, frequency of backup, onsite retention, offsite retention and a comment stating the rationale for the requirements. Take a look at the following example:
The table above isn’t meant to be taken verbatim, but as a model of how simple a written backup policy can be. Such policies are easier to understand by business leaders and can then be re-negotiated should changes be required.
To wrap things up, remember that backups are needed to recover from operational disasters, but certain business, regulatory, or legal requirements may demand that you protect data for even longer periods. Document your standard and extended backup policies and be sure to work with legal professionals to determine when to purge the data.
