By Axcient Guest Blog 2

backuploss

Data loss is absolutely avoidable, yet an astonishing 66 percent of businesses don’t have a business continuity or disaster recovery strategy. (See “The VAR’s Path to Managed Services” for other interesting statistics about data loss and the cost of downtime.) But protection isn’t solely about running backups. A backup is really just a means to an end for ensuring the uptime of business-critical systems. It’s a mechanism that only partially answers the question, “Am I protected?” So, what else should a VAR be discussing with its customers?

A Matter of Tolerance

While a recovery point objective (RPO) articulates a desired frequency of restore intervals, it’s important to understand one’s tolerance for being outside the objective. For example, if a nightly backup of business records misses a day, is that acceptable? How about two days? Or a week?

The answer depends on your customer’s needs and the criticality of the data in question. Encouraging your customer to consciously define what they will tolerate in a backup system and what is out of bounds will help them to  establish thresholds and more easily determine when corrective action must be taken.

Management by Exception

A good way to stay informed when backups go out of bounds is to set up an alerting structure using the most appropriate mechanisms for a particular customer’s IT operation. There are several very effective techniques:

Trust, but Verify

Backups are running within spec, and monitoring is set up for management by exception. Good. But are you certain that critical data can be restored when needed?

It’s wise to verify periodically that backups are behaving as expected through restoration testing. Think of it as a disaster preparedness drill. Periodic verification uncovers issues caused by changes in the IT environment, such as movement of critical data to a new volume. At least spot-checking for expected data within backups also reveals common problems, including improper configuration of network shares or file exclusion filters.

Additionally, testing server image failovers saves time when the call comes for a real failover. Keep in mind that simply booting to the login screen doesn’t guarantee a server image is healthy, since critical application data could be missing or damaged.

A Happy Story

This article opened with a sad story. Let’s close with a happy one — one very real for those who are protected by the Axcient cloud platform: Important data was backed up within tolerances and without longstanding neglected issues. Critical server images and data were routinely verified to be in working order. Then a tragic event struck. It was a drive crash on a critical server, or a lost laptop, or accidentally deleted files. Data was quickly restored and the affected business was up and running in no time.

Which story do you prefer?

Todd Scallan is VP of Products at Axient. Monthly guest blogs such as this one are part of The VAR Guy’s annual platinum sponsorship. Read all of Axient’s guest blogs here.