Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

News

5/10/2010
02:45 PM
George Crump
George Crump
Commentary
50%
50%

Knowing That Your Data Recovery Will Work

Probably no single process has had more software, hardware and infrastructure thrown at it then the backup process. Despite this continual investment many of the IT managers that I speak with express doubt in their ability to recover the right data in the right amount of time. What do you do to know that your data recovery will work when you need it to?

Probably no single process has had more software, hardware and infrastructure thrown at it then the backup process. Despite this continual investment many of the IT managers that I speak with express doubt in their ability to recover the right data in the right amount of time. What do you do to know that your data recovery will work when you need it to?When there is doubt in the ability to recover data it often leads to an overprotection problem that we have seen for years now and as we first reported in our article "Solving the Data Protection Puzzle". Essentially if you don't have confidence in your current data protection tasks you try to protect the data in as many ways as possible. Similar to driving with two seat belts and a helmet. You are hoping that in the event of a failure one of the data protection tasks will bring you back up. As the book says, hope, especially when it comes to data protection, is not a strategy.

To know you can recover requires focus on two areas. First, make sure you have a workflow that keeps your eye on the right ball at the right time and second, trust your workflow but verify it often. The first area, workflow, is really about creating a data protection management system and ironically isn't as much about recovery as it is backup. While this conflicts with the popular phrase from backup software vendors, "it is not about backups its about recoveries" the truth is if you don't get that backup completed successfully, there is nothing to recover. Clearly both are important but in my mind completing a successful backup comes first.

This first step then, the evolution of data protection from a series of unrelated tasks to a smooth workflow, is critical given today's environment. The IT team has too much data to protect given the current staffing levels. They have to be able to have tools that will give them laser beam focus on the data that really matters. Laser focus on only the critical data sets requires a shift from the conventional thinking that every backup must work every night strategy to only the backups that really matter must work when they need to work. This is not advocating that you stop protecting data every night but that when you are faced with a list of failed backup jobs, along with your normal IT tasks, you need to know what to work on first. From a backup perspective this means knowing what failures put the most business critical data at risk and fixing those first. Essentially the data protection process becomes a way to help you prioritize what to do first each morning.

Developing a process involves knowing what data protection resources you have, what policies are in effect and probably most important establishing realistic service level agreements (SLA) with the owners of data. Once those are known then the focus shifts to managing the SLAs instead of tracking every single backup job. If the management system highlights not every failure but the most critical failures they are putting SLA attainment in jeopardy.

The next step is the verify stage. While there are many ways to verify backup jobs there is only one acid test; recovery of the full system. In our next entry we will talk about verification and how to accomplish full verification with requiring 100 additional IT personnel.

Track us on Twitter: http://twitter.com/storageswiss

Subscribe to our RSS feed.

George Crump is lead analyst of Storage Switzerland, an IT analyst firm focused on the storage and virtualization segments. Find Storage Switzerland's disclosure statement here.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 5/28/2020
Stay-at-Home Orders Coincide With Massive DNS Surge
Robert Lemos, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-11844
PUBLISHED: 2020-05-29
There is an Incorrect Authorization vulnerability in Micro Focus Service Management Automation (SMA) product affecting version 2018.05 to 2020.02. The vulnerability could be exploited to provide unauthorized access to the Container Deployment Foundation.
CVE-2020-6937
PUBLISHED: 2020-05-29
A Denial of Service vulnerability in MuleSoft Mule CE/EE 3.8.x, 3.9.x, and 4.x released before April 7, 2020, could allow remote attackers to submit data which can lead to resource exhaustion.
CVE-2020-7648
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.72.2 are vulnerable to Arbitrary File Read. It allows arbitrary file reads for users who have access to Snyk's internal network by appending the URL with a fragment identifier and a whitelisted path e.g. `#package.json`
CVE-2020-7650
PUBLISHED: 2020-05-29
All versions of snyk-broker after 4.72.0 including and before 4.73.1 are vulnerable to Arbitrary File Read. It allows arbitrary file reads to users with access to Snyk's internal network of any files ending in the following extensions: yaml, yml or json.
CVE-2020-7654
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.73.1 are vulnerable to Information Exposure. It logs private keys if logging level is set to DEBUG.