Business Recovery, Step 5: File Level Recovery

In my previous article I talked about the recovery of critical files, the recovery point objectives (RPOs) for them, and how file versioning helps meet the customer need to recover files that simply don’t change very often.

But most files don’t fall into the “this is critical, but it doesn’t change much” category; I think you’ll agree that most fall into the “I created this once and never touched it again” category. So are these files important and, if so, what services should you provide around file level recovery?

Let’s first put some context around which files we’re not talking about.

If you’ve followed the steps in this blog series, you’ve already discussed recovery objectives – most likely at an application level – with your customer. So you’ve decided, for example, you need to recover Exchange within an hour and have the data recovered to within 4 hours. If you’re using the right backup solution, you shouldn’t be concerned about which files are involved for this kind of recovery; it should be a simple checkbox of a server with some kind of context around Exchange, and the solution does all the work. So this kind of data set isn’t a candidate for file level recovery.

What, then, is a file level recovery data set?

Think about all of the files stored on file servers – those stored in folders accessed by a user, a team, or a department. Files that, while aren’t absolutely critical to the business, make up the sum total of years of work done outside an enterprise application – and are important to an individual or team using them. Those are the files we want to ensure are recoverable. Without them, individual contributors and teams may be set back in their workload for days, weeks or months.

Since this data set represents a ton of “one-off” work, is there a proper way to plan to recover these files?

File Level Recovery

Before backups got smart, file level backup and recovery was all there was. So, remember, the focus here is more how you approach the backup and recovery of files, more so than the backup and recovery itself.

The success of file level recovery lies in determining, with your customer, exactly how critical the files are. If you are specifically performing incremental backups across the board, you probably won’t be able to recover an entire set of files easily nor quickly, because each file changes so infrequently and because the files were created over such a long period of time. This means you will need to look at files more closely than as just a single set.

For an effective file level recovery strategy, you should look at breaking up the files into subsets based on who uses it, how critical are the files at a department level, etc. (similar to how you look at data on a per-application basis), and determine what is the RTO and RPO for each subset of data. Now, you could just back it all up and restore it at once, and that very well may work for smaller sets of files. But when you have years of data to be recovered, there will be some priority as to which data is recovered first.

What’s required?

There are two basic steps:

1. Establish File Subsets – separate out user profile data, from home folders, from departmental data, etc. Each has a different value to the business and may fit at different points into the overall recovery process should a disaster strike.
2. Define Recovery Objectives – This will define exactly where in the recovery process they fit. In a true “we lost our building” disaster, user profiles (which can take up GBs of space each) may be less critical than data shared within a department.

What’s the benefit?

File level recovery has been around as long as backups have been, so there’s no big unveiling here. The important benefit is you have put guidelines around what is and isn’t important at a file level, as well as define where each of these files fit in the bigger recovery picture.

Once you have this, as you plan for various levels of disaster (loss of servers, locations, etc.), you can quickly see whether files will or won’t be included in a given recovery.

In my next article, I’ll switch back to looking at Virtualization as part of your recovery offering, specifically addressing when V2V is a viable (and profitable) choice.