Operational data recovery is often overlooked for disaster recovery, but it's probably more important. If your organization's approach to everyday data recovery is "wing it," you're doing it wrong.
It's easy for IT staffers to get bogged down in the daily business of making backups or in the long-term concerns for disaster planning while overlooking the more likely issues surrounding ordinary recovery. Whether it's a whole server, a virtual machine, a program, or a single file, companies need well-defined procedures for data recovery—winging it is a sure-fire way to have something go wrong, and the more important the data, the less you can afford to take that chance.
SEE: Resource and Data Recovery Policy (Tech Pro Research)
Experts' tips and advice on enterprise data recovery
ISACA (the International Systems Audit and Control Association) published advice for safe, policy-driven data recovery earlier in 2018. The best tips are:
- identify and rank critical applications;
- create a recovery team with roles and responsibilities; and
- provide for regular and effective testing of the plan.
A conversation with Commvault's Deepak Verma, director of product management, applications, and file systems, revealed a variety of useful advice on the subject. Data recovery plans are best when they give you confidence—but not so much confidence that you can get burned. "It's the confidence that the backups that you've been making all along, all the time and money and the infrastructure, are going to work when you need them to—[but] how do I know they're working?" Verma said. The simplest way is spot-checking, where you recover random backups. Testing everything would take too long, he noted.
Many, but not all, modern backup applications perform bit-by-bit checks to ensure the data being read from primary storage does in fact match the data being written to backup storage. Add that to your backup software shopping list, Verma advised.
"The other thing I've noticed the industry's heading over to in the last couple of years is away from this notion of always having to do a full restore," Verma said. For example, you could restore a single virtual machine or an individual database table, rather than a whole server or the entire database itself.
That's easy to forget when under pressure from angry users who want their data back immediately. "The days of doing a full recovery are gone, if you will. It's get me to what I need as quickly as possible," Verma said. "I would say that's the state of the industry."
A virtual machine can actually be booted directly from its backup disk, which is useful for checking to see if the necessary data is there but not very realistic for a large-scale recovery, Verma added.
SEE: Disaster recovery: Tech tips and leadership advice (TechRepublic on Flipboard)
Common mistakes and challenges with enterprise data recovery
Verma said he sees various common mistakes during recovery processes. Three mistakes are notorious:
- not knowing the location of the right backups on tape, cloud, or elsewhere;
- not knowing which timeframe of backups to recover from when you find them; and
- not understanding that system recovery to regain one file also means you're losing other data that was created or changed since then.
An additional challenge is the need to explain to end users, especially to non-technical ones, that enterprise data recovery isn't like retrieving your photos from iCloud—it's rarely simple, fast, or perfect the first time. Unfortunately, "That's the expectation that a lot of the management, director-level and above, care about when they're talking about recovery," Verma observed.
Some mistakes aren't recoverable at all, but operational data recovery would be well-served if industry organizations would codify processes and standards, he added.