The first three articles in this eight-step “recovery” program for businesses focused a lot on recovery time objectives (RTOs), recovery point objectives (RPOs), per-application definitions of each, and a few virtualization-related recovery service offerings you can provide to meet your customer’s needs.
In this fourth step, I want to take a slight change in course and talk about recovery where having the most up-to-date files isn’t the backup objective.
Most backups are relatively small because they only contain changes made (at a file or, even better, a block level) since the last backup. But while you’re backups are busy grabbing the latest and greatest, some files simply don’t change very often and are, therefore, overlooked. For example, take an organizational chart—it is important, but won’t change daily.
Now add to this the fact that your default retention of backups may only be, say, 30 days, with a few archives at monthly and quarterly intervals. So, those critical files that change infrequently may only have one iteration saved within the 30 -day retention period.
If you think about an RPO for a specific file that changes infrequently, it may be defined not so much in terms of a date or time, but in terms of a version. For example, if the version of the org chart you work with today is missing information, you need to recover to the last version of that file—which may be 35 days old.
So, how can you provide recovery of files that infrequently change with a more frequent retention time?
File Versioning will be the fourth step in the eight-step program. It’s a separate service, provided for critical files, that establishes retention of those specific files for a number of iterations, regardless of the retention period.
File Versioning allows organizations to easily recover files based on not when they were changed, but whether they were changed.
First off, you need a backup solution in place that supports file versioning.
Assuming that to be true, the second step is to identify the files that should be backed up via File Versioning, specify the number of versions to be retained, and begin backing up those files. Don’t gloss over this step as this is where you get to define the important documents—org charts, product requirements, IP documents, etc.—that need to be able to be recovered to an older version.
Keep in mind that you don’t need to only provide this service for, say, the org chart I mentioned. You can offer this service for any kinds of files your customer wants to ensure recoverability of well past the default retention time you offer. Presuming you’ve identified a number of important (and some critical) data sets to version, the benefits are great:
In my next article, I'll be staying on the topic of files and looking at recovery on a per-file basis, rather than the traditional thinking of recovery around applications and systems. There are benefits for your customers and opportunities for you in a single file; and I’ll discuss both.