One of the most important things that you can do as a DBA, or really as any sort of system administrator, is back up your system.Ensuring that you have have backups, and of course, that you can restore them, is the number one priority for sysadmins. Everything else that you need to do is second to backups. After all, backups ensure you still have a system after a disaster. If you can’t do that, then security, performance, features, none of that matters.
I have worked in large and small environments, and in all cases, I’ve assumed that as the DBA, I need to be checking that backups are occurring, and that I can restore them in case of any issues. Often this has meant I need to work more closely with others that have the actual responsibility for performing backups. This week, I’m wondering how many of you work in similar situations.
Who is responsible for backups in your company?
Is it the sysadmin of each particular application? Does the DBA ensure database backups while the Exchange administrator handles mail backups? Do you have a centralized system for backups? If backups fail, who’s going to get yelled at? Or perhaps more importantly, who will notice that backups have failed?
There are any number of ways to handle backups, and honestly, the best way I’ve seen had a centralized person responsible for running backups every day and checking on automated tasks, but the individual system owners (DBAs, Exchange admins, application managers) checking that backups had been made. These individuals also test restores periodically. In this way there was always someone to double check the person responsible.
Let us know this week how things work in your environment.
Steve Jones
The Voice of the DBA Podcast
Listen to the MP3 Audio ( 2.2MB) podcast or subscribe to the feed at iTunes and LibSyn. 
The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.
Voice of the DBA 
My current employer I made the fatal mistake the system/network managers knew what they were doing when it came to managing database backups. That didn’t last long when the head of our department had requested a restore of one of the production databases only to find out that no one ever saw the backup/recovery through to the end.
I stepped in and did several things. First I made sure all of the database servers were properly managing backups. This went as far as insuring backups were actually being run. Next I developed an archiving process to retain 7 days of backups and transaction logs.
Working with the system/network guys we devised a means of archiving of the nightly backups and transaction logs to another file server then to tape.
Shortly we had everything in place we had a minor disaster to a database that was only a few days from going live. I was asked to restore the database to a point in time to see if I could identify the cause of the disaster. The recovery took only minutes and within the hour we had our answer. (Turned out there was a hidden “feature” in the UI the vendor never told us about causing the problem).
Backup/recovery procedures are not complicated. The most important thing is to have a process in place that not only backups database but restores the databases within a reasonable about of time with minimal loss of work productivity and data loss.
Many shops I’ve been in the D/R plan really does not get fully tested. I have found that policy is one thing but to have a fully tested and documented plan is most important.
Kurt
LikeLike