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 . . .  :^)