Whether you are moderately experienced in the topic of data protection, or new to this critical area of Information Systems, the best place to start is right at the beginning.  In order to ensure we all are working from the same set of assumptions, let's begin by defining what the various backup & recovery terms mean and then build on this foundation.

The most basic concept here is to start with the definition of a backup.  While this may seem overkill, you will see by the definitions we have carefully developed here at BRBP.ORG and suggest as the standard, the meaning is very succinctly stated.

A backup is defined as follows: "A backup is a point-in-time copy of binary data that is stored separately from the original, and can be retrieved at a later date in the event of data loss."

Keeping a copy of a binary record or data is no different from a logistics and process perspective than was used to store copies of legacy paper documents.  The most important point is that you would never store them both at the same location due to risk.  The same goes with binary data.

Remember that with binary copies there is no degeneration of the data in the copied entity (e.g. photocopier pixelation), so each iteration of the data is basically an "identical twin" - other than perhaps some particular metadata related to the backup itself.

There are a myriad of technologies and approaches out there for data protection, but to truly have a backup that you can use in a recovery effort, if must meet - at a minimum - two criteria.

1) It is a copy of data from a particular point in time; and,
2) The copy must be stored in a disparate location separate from the original data.

Some storage technologies leverage local internal methodologies like snapshots to help provide for quick  and easy data recovery, but these snapshots are local to the storage device and can be lost if not replicated to a disparate location.

The next definition to consider is that of a restore.

A restore is defined as follows: "A restore is the recovery of a point-in-time copy of binary data that is used to replace original data that has experienced a data loss event."

Remember, just because you have a successful backup does not mean that the data is recoverable / usable. There are many "gotchas" that can result in the restored data being unusable or that can result in the inability of data from a particular point-in-time backup to be valid. 

The key to having a valid backup is that it must be able to successfully restore the data to a specific “point-in-time” and the data must be consistent if it is structured data (e.g. a database).

Assuming that you have good backups because your backups are running can be a fatal mistake, and has cost many an IT manager and/or backup administrator their job.  Without the appropriate configuration, methodology and processes in place - you might as well just be going through the motions and leaving your fate to chance. 

Mature organizations understand that in order to ensure they can recover data in the event of data loss (i.e. anything from "Joe" in Finance deleting the wrong file to a full fledged declared business disaster), they need to have have oversight and governance in place - as well as regular periodic testing of key data restores.

Changing your focus from backup to recovery introduces a paradigm shift, but when you are ensuring you can restore critical business data within the appropriate RPO (and ultimately the RTO too), you have taken an important step in the maturity of your organization.  In addition, having the right documented processes and procedures in place to support your data protection methodology is equally important.

With today's companies operating in a global environment as the standard "motus operandi", it is important now more than ever to ensure you have documentation and playbooks for every IT service - especially those that are business critical.  Not to mention that you need to have copies of all your DR plans in two places as well. It won't help you to have DR plans if you can't access them during a disaster event, when you need them most.

Yes, this requires an investment for a company to make, but if things go sideways, you better have done your homework up front. One key fact to remember is that 43% of companies that incur a major loss of business data never reopen!

Once you have point-in-time copies of your data, the question becomes, "How far back do I need to go to provide an adequate recovery period for the client subscribing to the service, and how many point-in-time copies do I need to keep?"  Here is where many organizations make some key mis-assumptions and confuse backup retention with data retention.

Backup images and/or physical backup tapes are rotated on a periodic basis typically referred to as the backup retention period or backup rotation schedule. Don't confuse backup retention with record retention or data retention.

Remember that backup retention is not synonymous with record retention (aka data retention).  Keeping too many backup images or tapes for too long results in skyrocketing costs and exposes your company to litigation risk. 

Industry data suggests that for every 1TB of data that must be provided to attorneys during discovery, the associated cost is $18M.  Imagine the cost - at $400 per hour - for lawyers to go over every document, email and other artifact in a 1TB production of evidence related to a litigation.  The goal is to ensure you only have to provide a minimum amount of data, and only data that is relevant to the case.  Too much data could drive your company to the poor house!

Record or data retention is not related to backup image retention.  Data retention has to do with the original copy of the data, and a backup is a copy of that data.  For example, if you have financial records with a 7-year retention requirement and all those records are in an online database, then you are compliant.  The backup of that database has no retention requirements associated with it.  The typical argument is based on the loss of the original data and ensuring there is a copy to recover to maintain a company's compliance.  That in no way means that your backup tapes should be saved for 7-years.  It merely means you must have 7 years worth of records - not 7 years of backups or tapes.

Once you have determined how many backup copies you need to retain and for how long, you can leverage multiple technologies to automate the core management of these tasks.  Point-in-time backups can be taken using a typical daily backup software solution such as Networker®, NetBackup®, and ComVault® to name a few, and/or using disk-to-disk backup methodologies such as snapshots, SnapMirror®, SnapVault®, SRDF® FlexClone®, and others.

This should help provide a good starting reference point to ensure you understand the common terms and misconceptions around data protection.  It is foundational to designing a resilient service that focuses on key business data rather than backing up everything everday and saving it forever.

Return to Home Page