Here it is time for the party of the month for the SQL Server acolytes and I was running a bit behind. Why? Well, that was due in part to me rushing around trying to do some of what this months topic is. Some would call that pretty could timing.
Hemanth.D (blog|twitter) is hosting the T-SQL Tuesday blogging party this month, and he wants all of us to post about Automation. As Hemanth.D put it on his blog in his own words:
You could write about, what options you would consider when automating something? Where do you draw the line? What are our preferred tools for automation? T-SQL, PowerShell, VBScript or Batch files(?) or maybe just share something that you automated in the last couple of years.
You can read the invite he posted here.
History
As Hemanth.D mentioned in his invitation, this is not the first time this topic has come up for TSQLTuesday. As it would happen, I also participated in the first go around with my contribution about sizing databases on limited information. You can read that here.
This time around, I have a little bit of a different topic to approach. I hadn’t considered this until after having read that Wayne Sheffield wrote about his efforts to verify backup files via script (automation). You can read what Wayne wrote at this link.
Having read that, it seemed painfully obvious to me that I should go ahead and write about my efforts to automate backup restores. After all, if you are verifying the backup files existence, you might also want to test the backups to ensure they are good. Besides, we all need to test our backups anyway, right?
Present
I have a few different methods I have used over the years to automate restores. In one iteration, the restore operations were hard coded in a procedure that was scheduled to run on a nightly or weekly basis. It probably was also just hard coded to be specific to a database. That kind of setup is not super useful except for that one database.
With that in mind, I worked on several iterations to help create a script for myself that would automate the restores of any database, with any number of backup files, to a different server, and not have file paths/names/anything hard-coded. Well – there ended up being one thing hard-coded but that can be changed easily enough.
I decided on a script that would read the backup path for the most recent backup file from the msdb database of the server where the database was backed up. I do this via a linked server that can be created/destroyed in the proc or that can reside permanently (I prefer to leave it in place). Take the filepath of that backup file and restore it to the destination server. All of this via tsql.
Now a caveat with this solution is that the backup path works best if it is a UNC path. Even if you are backing up the database to the local server, backing up to UNC means that the restore operation can just grab that path and not encounter errors due to drive mappings (e.g. backed up to D but the D on the restore server is the cd-rom drive).
What if you don’t want to restore the source database with the same name to the new server? Well, that has also been considered and a parameter can be passed to the stored procedure to allow for a new database name. What if the default file paths are different? That consideration has been made too! All of that said, more testing is always welcome.
The script can be evaluated from here.
Next steps:
With the script, the next things to do would be to create SQL Agent jobs to run the script on a routine basis. Test the script and verify it.
User of this script assumes all risk.
