I need to come clean – let everyone know my dirty little secret . . . I’m a procrastinator. Not just a little one – nope, no-sir-ee . . . I’m the king of procrastinators. Sure, I have plenty of work to do and more than enough to keep me busy – but I have a tendency to just put some things off until the last minute . . .
Well, my latest task that I’ve put off until the last minute has been my presentation for SMBTN (which is where I am composing this post . . . oops). Lucky for me, there was a schedule change, so my presentation was moved from today (Friday) to tomorrow – which has worked out in my benefit – and here’s why:
My planned presentation was on Backup, Restore & Disaster Recovery of Windows Sharepoint Services. Now mind you, I’ve done a decent amount of work with Sharepoint, and I’ve even done a couple of restores, and moved a few sites as well. Now, each of those restores were full-server restores, and the moves were for servers that we swung. Well, I was working through the various options and realized that there was a scenario that I hadn’t personally dealt with previously. I had not been in a situation where I needed to perform a stsadm based restore of a site without restoring the entire server – e.g., restoring a Sharepoint site to a different server using stsadm.
So, I loaded up a couple VPC machines – one SBS Premium & one Windows 2003 Std with WSS installed. Well, I populated a site, took an stsadm backup – no problem. Then I tried a restore of the site on a different machine, and you know what – it failed. Well, that couldn’t be – so I googled stsadm restore, and verified I was following the right steps . . . sure enough, I was – but it still wasn’t working. I was getting errors about the site not existing, or unable to connect to the config database, or that the website was already in use, blah blah blah . . .
So I did some more research, and the short-story I discovered is that in order for an stsadm restore to work, you have to do a full system-state restore and be sure to restore the STS_Config database too. So what is the issue with this? Well – what happens when you have a true disaster such as a fire and your server is toast. Not only that, it’s a few years old and you can’t get an exact hardware replacement? Have you tried doing a System State restore to different hardware?
At this point I had to go for a walk and sort this out. Surely Microsoft couldn’t have painted us back into a corner like this . . .
All I could think about what FrontPage. I have used FrontPage to move entire Sharepoint sites between servers via it’s built-in backup & restore, and it works so slick. The down-side is that you can’t automate FrontPage to use it as a backup tool. I kept thinking that if there was only a way to use the FrontPage backup functionality without FrontPage . . . so I could schedule it, and automate it, and have a solution that I *know* works . . .
Well, you know what? It turns out that you can. There’s this nifty little command-line tool (very similar to STSADM) that gets installed when you install Windows Sharepoint Services. That tool is smigrate.exe, and it lives in the same directory as stsadm (c:\program files\common files\microsoft shared\web server extensions\60\bin by default). And the cool thing about smigrate? It is a command-line version of the backup/restore functionality that we find in FrontPage.
So let’s connect the dots . . . If I schedule a backup of a Sharepoint site using stsadm, then I can restore that site – but only if the destination server has the same system state and STS_Config database as the original server. Not normally gonna happen in a disaster recovery scenario. OR – I could schedule a backup of a Sharepoint site using smigrate, and get a backup set that I can restore to any site on any Sharepoint server at any time, without having to worry about system state or the presence of other databases such as STS_Config. Take a guess what I’m going to be using for my scheduled Sharepoint backups going forward . . . . :^)
Now, I still have some testing to do to make sure permissions and security are restored with smigrate, but even if they aren’t – I’d rather have a backup/restore option where I know I can get all of my content back and *maybe* have to reconfigure permissions versus a scenario that should restore permissions, but that I can’t get to restore anything . . . :^)