Basics: Backup Lifecycle

In the various backup/data protection groups I hang around on, I periodically see the “I’m new to backup, what do I have to think about?” style posts. There are a plethora of different ways you can answer the question. (Though I’d like to think the most comprehensive answer is, here, read this.)

One way to help a new backup administrator understand the lifecycle ownership is a diagram like this:

The lifecycle for a backup starts when it’s created — and ideally at the same time a lifecycle for a clone or backup copy should also start shortly thereafter.

The lifecycles may have different times depending on your business requirements, but I’d suggest that ideally, since you should have at least two copies of your backups, for most circumstances their retention should be identical. (In short: if it’s important enough to protect, it’s important enough to have copy redundancy.)

Backups have two potential lifecycle periods, which are operational and compliance (or long-term) retention. Your operational retention focuses on that short-term period after the backup creation – e.g., four weeks, a month, etc. When that short-term retention is over, one of two things should happen, namely:

• The backup should be deleted, or
• The backup should slip into compliance/long-term retention mode

It’s at the long-term retention where it all starts to become a little unknown. If you’re a backup or infrastructure administrator, the backups are definitely your responsibility when they’re in the operational retention window. But, that compliance window might be years. I have customers who keep their long-term retention backups for 20+ years – and have known businesses that’d scoff at such ‘short’ retention periods. (In fact, a colleague recently asked me about one of their customers with a 75-year retention policy.) Depending on your organisation’s requirements, those long-term backups could readily slip into being someone else’s problem.

The reason it’s important to think about this overall lifecycle of backups – particularly when starting out with backup – is twofold:

• It helps you to be mindful of the long-term implications of backup planning and execution, and
• It helps you to remember the redundancy implications of backup planning and execution.

The latter is useful when working on new policies – a quick prompt to remind you to make sure the backups will themselves be protected. The former is a reminder to be kind to your future self or the successor in your role. If you’re keeping backups for an extended period, make sure there has been adequate planning around what to do with them. I can explain this by example:

I remember a customer who had been the NetWorker backup administrator for several years at a company describing a horror time he’d been having trying to recover some (almost) 7-year-old backups. Almost outside the company’s compliance retention period, but not quite, and therefore needed for a court case.

The backups weren’t NetWorker backups, though. They were ArcServe backups. ArcServe hadn’t even been the previous backup product. The company had used ArcServe, switched to BackupExec for a year, then switched to NetWorker and the only backup product he’d had to use since joining the company had been NetWorker.

Suddenly, he had to recover from a product no one at the company knew (including himself) from tapes that couldn’t physically load in the current drives without any procedures, training, or detail.

If you’ve ever been in a position where you have to do something for which there is no training, no procedures and no local mentors to assist you, you’ll understand the situation that poor bugger was in. That’s why when you think about the backup lifecycle, you have to pay it forward by being kind to someone who might take over your role in the future.

And by being kind, I mean:

• Documenting the system in case it gets turned off
• Documenting the processes in case it gets turned off
• Storing the installers, licenses, etc., in case it gets turned off.

While you’re operating a backup environment, the above activities are merely part of the daily grind. But if you’re using backup systems for long-term retention, you should be mindful of the backup lifecycle – because there’s always a chance that some of those backups might become someone else’s problem.

So if you’re new to backup and want a quick list of the things you need to think about, make sure the backup lifecycle is on the list.