Dealing with anything related to Disaster Recovery (DR) carries a certain amount of stress with it, frankly the name says it all. There’s nothing good about a disaster of any kind. The word is reserved for the worst case scenarios and recovery or getting back to normal after a disaster conjures up a feeling of the utmost urgency, maybe even a little panic. After a disaster questions from nearly every corner of the organization start pouring in. “What were we backing up? “What is our recovery point?” “How long until we can get back to operational status?” “Can we prioritize certain applications for recovery?”
"After a disaster, questions from nearly every corner of the organization start pouring in"
Most of the time, it’s on the administrator to pay close attention to DR preparedness and backups. Nobody else notices the mornings when last night’s backups completed with a 99% success rate. Yet when a single file is unable to be restored for someone on the executive team, the entire infrastructure is put into question and the next thing you know, members from audit and legal get involved. For the IT team, it may feel worse than the original disaster.So how do you make common scenarios like this less stressful and more efficient? How do you reduce the time it takes to search and find files and more importantly restore full confidence in the DR infrastructure? It all starts with reporting…
"For the IT team, it may feel worse than the original disaster"
Know your audience
Everybody wants something different. Managers, directors and legal should all care about the same outcome in the end, but may ask for different data sets in order to reach the same conclusion. For example, a director may want to know that their money was well spent and that the new technology is really providing the service as expected with a measurable ROI. While an Oracle Database or Exchange Administrator may have questions on how quickly and accurately the financial data was backed up, whether or not the subnet or backup network is being utilized across all clients, and how much compression the deduplication technology provides.
“Do we have a backup, and how can we be sure?”
And legal? Now that’s different still. Often times legal will want to know one, critical piece of information - “Do we have a backup, and how can we be sure?” Sometimes this may require an extra step beyond the usual “successful backup” notification. Accurate, repeatable reports can answer a number of key questions regarding data handling, environmental changes over time, and tracking changes across systems. And the best part – these backup reports can be translated into plain English!
Changes over time
Here’s a scenario for you: Let’s say your retention for backups company-wide is at most 60 days. Your IT department becomes involved in an audit, and is requested to produce evidence of successful backups for the past 2 years. Without proper preparation it’s impossible to provide the required information. That is unless reports were taken ahead of time to document success rates, technology changes, and/or other proof that the environment was functioning as expected. Being able to document the evolution of the environment over time can be invaluable when attempting to prove the high availability of the infrastructure as a whole.
Administrative concerns
Judging the success of a backup can be difficult considering the variety of technologies administrators have at their disposal. Take the common scenario of utilizing RMAN for Oracle with a deduplication technology on the backend storage. If you’ve correctly set ‘filesperset’ to 1, then you will have a large number of streams that may be backing up numerous databases. What constitutes a “successful backup,” and how can you verify this? Can you even report on individual databases? Knowing exactly what technologies are in play, and how they can alter your reporting landscape can mean the difference between catching possible breaches and missing them. We see this all the time.
While companies may house a large number of databases and applications, many are not used on a day-to-day basis. Backup reports can be a useful tool in identifying issues and problems to prevent data breaches before they impact the business. In fact, proper reporting can act as an overall IT health check. At a biotech research facility we noticed a single machine was backing up an unexpectedly large amount of data. In troubleshooting the problem further we discovered a security issue with the mounts on their NAS filer. By utilizing the proper reports we were able to avoid potential data breach numbering in petabytes of information, as well as improve organizational trust of the DR infrastructure. For databases, applications, and storage repositories that are not used daily, reporting can be an invaluable tool in identifying pain points and weak sports before they become an issue.
"Proper reporting can act as an overall IT health check"
Takeaway
The last line of defense for many large corporations is their backup and DR infrastructure, and the foundation of disaster recovery is being able to re-create the past. Disasters are inevitable, and therefore it’s the business’ job to prepare as much as reasonably possible, and the first step is reporting. Whether that means collecting the correct information, reducing the number of variables, or parsing through massive amounts of data to identify key points, it’s the job of the DR administrator to be able to capture each of these.
The scenarios I discussed in this blog are common. Backup reporting will make them less stressful in the short term, more efficient in the long term, and provide better service and information to the business. In the end, the will help instill more confidence in both the infrastructure and IT’s ability to handle a disaster.
About the Author