When thinking about your strategy around backups, recovery, availability, and business continuity, one part of the plan tends to fall by the wayside: backup retention. We focus so much on things like recovery objectives, SLAs, and tiers of data, that our thinking revolves around the need to potentially recover the backup that we just made a matter of minutes afterwards.
But there are data sets that need to be available weeks, months—even years—after they are made. And, while, your backup certainly doesn’t replace an archive (in the case of email), it does serve as a means to retain easily accessible data for extended periods of time.
Defining you backup retention policies
There are a few initial considerations in the mix when you begin down the path of establishing retention policies.
- The Data
Not all data is “retention worthy.” Take this blog, for instance. It’s not likely that it will be needed five years from now. But much of your corporate data—intellectual property, email/correspondence, financials—may be necessary for tax/legal or even advanced analytics.
- Compliance Mandates
Many mandates establish the need for retention periods for certain kinds of data. For example, the general recommendation for covered entities under HIPAA is to retain healthcare records for 10 years. While most don’t specify certain durations, there are widely accepted timeframes for most mandates.
Some companies only want to retain data for short durations (e.g. 90 days) to maintain an ability to recover, but not longer—as it may increase their liability.
While we live in a world where storage is a cheap commodity, there’s a reason you want to retain data for a long period of time: it’s important. That means you need to carefully consider where the data resides and on what kind of storage system.
The outcome of all these considerations is a list of identified data sets—each with their own retention periods—that now need to be protected.
Implementing your backup retention policies
Most backup solutions have an ability to retain specific backups with the simple check of a box. The challenge here is that you must look at your current backup strategy, identifying whether you need to modify it to align with your retention strategy in two ways:
- Backup Data Sets
Since you only want to retain specific data, you need to see if your backup definitions are much broader (e.g. you may have an entire file server backed up at once, when all that needs to be retained is one folder). You may need to either modify the backup job definition or create an additional job just for retention.
- Backup Type
The current backup may be image based, and you need it to be file based. Additionally, you may perform incremental backups on a regular basis—since five years from now you probably won’t have all of the needed incremental backups around to re-create a complete backup set, you need a separate full backup.
- Backup Frequency
Since the data requiring retention tends to be pretty important, you may have it backed up every hour (or even more frequently). But long-term retention doesn’t require frequent backups. It’s another reason you may need a designated long-term retention backup.
Keep in mind that not all data identified for retention will have the same backup retention policy. Retention duration and backup frequency may differ from set to set. The important work will be done in identifying what’s going to be needed by the organization years from now, and planning your backup strategy to facilitate a smooth and full recovery when the time comes.
Nick Cavalancia has over 20 years of enterprise IT experience and is an accomplished executive, consultant, trainer, speaker, and columnist. He has authored, co-authored and contributed to over a dozen books on Windows, Active Directory, Exchange and other Microsoft technologies. Nick has also held executive positions at ScriptLogic, SpectorSoft and Netwrix and now focuses on the evangelism of technology solutions.