Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

The Voice of the DBA

Steve Jones is the editor of SQLServerCentral.com and visits a wide variety of data related topics in his daily editorial. Steve has spent years working as a DBA and general purpose Windows administrator, primarily working with SQL Server since it was ported from Sybase in 1990. You can follow Steve on Twitter at twitter.com/way0utwest

The Problem with Striped Backups

I noticed a post recently from Bru Medishetty on Striped Backups. I commented, but thought I should explain a little more. There is a problem with striped backups in SQL Server.

They work great, they increase the speed at which you can perform a backup (possibly) and they can lower your backup window as well as reduce the load on your database server. Those are the good things.

The bad thing is they are too easy.

Yes, too easy. It sounds silly, but let me show you something. I can open Management Studio and pull up the backup dialog for one of my databases.

stripedbackup_a

Now typically what I want to do is make a new backup. So I click the “Add” button in the lower right, get this dialog.

stripedbackup_b

I type in my filename, and change the path if needed. I now click “OK” (it’s not grayed out when I enter a file) and I go back to the backup dialog. To make it easier to read, I’ve zoomed in at the bottom.

stripedbackup_c

Or more specifically, let me scroll the box and let you see what’s there:

stripedbackup_d

What I’ve actually got here is the last backup I did (a log backup file) listed along with the new one I entered. If I now click “OK” and perform the backup, what happens? Remember these file names weren’t visible from the main dialog without scrolling, and actually when I clicked “OK” from the file name, that line was actually highlighted.

What will happen is that half of my backup will get striped to 20090929.log and half will be striped to 20091216.bak. If I now want to restore the database on a new server, I need both those files.

Think it couldn’t happen? This is exactly when happened to me one time. I was in NY on business and got a call from a consulting client back in CO. They had done this, thinking they made a backup of the database, moved the file to the network and proceeded on with an upgrade. The upgrade crashed, and they couldn’t restore the .bak file. They called me and as I drove in a cab through Manhattan I had to give them the bad news that without the other file, they couldn’t restore the database. They never found that file and lost a few days worth of work.

They also abandoned SQL Server, moving to MySQL, which has simpler file based backups. They went out of business before long (it was a startup), though I don’t think that was related to MySQL.

I’ve seen new DBAs, developers, managers, any number of people have trouble here. The reason is that the GUI saves the last file you used in the dialog and presents it. Adding a new file, and seeing it highlighted, has confused many people into making a striped backup.

They’re just too easy.

Comments

Posted by Glenn Berry on 23 December 2009

The Script button is your friend. I always teach my students to click on the Script button rather than just clicking OK when it comes to any task in SSMS that has a GUI "wizard" in front of it. That way you can see what T-SQL was generated, and do a sanity check first. Plus, you can save the generated T-SQL as a script.  

Posted by Steve Jones on 23 December 2009

That's a great point, but there are so many non-technical people that might use this dialog in an emergency and not realize things. It's too easy to run a striped backup.

Leave a Comment

Please register or log in to leave a comment.