Manage Learn to apply best practices and optimize your operations.

Backups (not so) Anonymous

Data backup and recovery expert W. Curtis Preston discusses the 12 steps you need to know to gain control of your backup system.

Your backup system is unmanageable. Maybe your customer knows it, maybe they don't. But they will know it at some point. If your system doesn't have any failures and can meet your recovery time objectives (RTOs) and recovery point objectives (RPOs), then feel free to stop reading. "Backups (no) Anonymous" isn't for everyone. For the other 99% of you, it's time to admit you have a problem, which is the first step in getting help.

Before I have a little fun with the 12 steps of AA, let me say that I have the most profound respect for AA and its steps, and am amazed that a book originally published in 1935 could help so many people and be applied in so many ways. I'm about to apply it to backup technology. I bet Bill W. never saw that coming!

Step 1: We admitted we were powerless over our backup system - that it had become unmanageable.

If you keep ignoring that your system can't meet the RTOs and RPOs that your business expects, your system will never get better. It's time to admit that it's not working, and to say so publicly in meetings.

Step 2: We came to believe that a system architect greater than ourselves could restore us to sanity.

The person who is responsible for the day-to-day operations of the backup system shouldn't be the person architecting the new backup system. They should absolutely have input to the design, but they should not be the one coming up with it. They have neither the time nor attention that such a design requires. Due to the time and attention they pay to the backup system, their information on new technology will be sketchy and out of date. What's needed is a person who specializes in such things.

Step 3: Made a decision to turn our will and our backup system over to the care of the system architect as we understood them.

Perhaps the architect will be a person in your company whose job it is to do such things. Perhaps your architect is an outside consultant whose single purpose in life is to keep current with the technology that you might need. Regardless of who the architect is, put your trust in them and provide them with all the input they need.

Step 4: Take a fearless inventory of your company.

Look at all the failed restores. Look at the volume of data you have and figure out what kind of throughput you need. What kind of systems and applications do you need to back up? Next, examine how close you are to being able to meet those requirements.

Step 5: We admitted to the system architect, to ourselves and to our customers the exact nature of our mistakes.

You have to come clean. Don't tell your customers or the architect that your data backup system is fine if it's not. Talk openly about the problems you've had in the past or present. You can only move things forward if you're honest.

Step 6: We're entirely ready to have this person remove all these defects.

This is going to be a lot of work. You're going to need to reexamine all of the configuration settings in your current system and possibly conduct some type of RFI and pilot program. Don't think you're just going to install product "ABC" and things will magically get better. There will be bumps in the road and you must be prepared for that.

Step 7: Humbly asked this person to remove our shortcomings.

In this somewhat warped view of the original 12 steps, this one step is where you would actually do the things necessary to affect change. You would ask your architect what you need to do to make things better. You would test and make the appropriate configuration changes; you would install the new software or hardware (if necessary); and you would document all these changes and report on their progress.

Step 8: Made a list of all the people whose files we had failed to restore, and became willing to make amends to them all.

If you've had backup instability for a while, you've likely created some detractors along the way. Make a list of all of these people and the files you failed to restore -- every single one of them.

Step 9: Made direct amends to such people wherever possible, except when to do so would injure them or others.

If there was a failed restore that someone in your company knows about, meet with them just about that restore. Ask them why it failed from their perspective. Was it not fast enough? Was it the wrong version or timeframe? Was the process too difficult? Apologize to them and tell them what you're doing to make things better. Every time you complete a successful restore, you're making amends for the ones that didn't work.

Step 10: Continue to take requirements inventory and when we were wrong promptly admitted it.

If you've made it this far, you've made things better. Your backup system currently meets the RTOs and RPOs specified by your company's business units and all your restores worked. It won't stay that way. You have to continue to meet with your customers on a regular basis and take inventory of what they want. Be prepared to back up the data before they're prepared to give you the data.

Step 11: We sought to improve our conscious contact with the system architect as we understood them, striving only for knowledge of what they want for our backup system and the power to carry that out.

The system architect can only suggest changes to your backup system if they're aware of issues you're having. You should have regular meetings with a person whose job it is to design changes to your backup system and explain to them how things are going. Be open to new ideas and be ready to make changes again as necessary.

Step 12: Having had an incredible increase in backup system performance, manageability and reliability as the result of these steps, we tried to carry this message to other backup administrators, and to practice these principles in all our affairs.

If your backup system works, you should help the rest of the people out there who are floundering! Share your knowledge. Join a mailing list, forum or user group dedicated to the backup software and hardware you're using.

The last thing to do is to be honest and admit when your backup system has shortcomings, find out what they are, get someone to help you make them better, have open and honest meetings with your customers about how things are going, and don't stop talking to the architect after your design changes have been made.

W. Curtis Preston (a.k.a. "Mr. Backup"), Executive Editor and Independent Backup Expert, has been singularly focused on data backup and recovery for more than 15 years. From starting as a backup admin at a $35 billion dollar credit card company to being one of the most sought-after consultants, writers and speakers in this space, it's hard to find someone more focused on recovering lost data. He is the webmaster of BackupCentral.com, the author of hundreds of articles, and the books "Backup and Recovery" and "Using SANs and NAS."

This was last published in September 2008

Dig Deeper on Disk-based backup

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchDisasterRecovery

SearchStorage

SearchConvergedInfrastructure

SearchITChannel

Close