So remember how I mentioned that I had just enough knowledge to be really dangerous?
I got bit by that this weekend and wound up causing an outage on one of our production sites. I ran into some behavior with the stsadm restore command that I wasn’t anticipating.
I was migrating a site from one web app to another using backup and restore. Let’s call this site oops.
So I used stsadm –o backup and made a nice little .cmp file like so
stsadm –o backup –url http://oldwebapp/oops –file c:\oops.cmp
Then I created an explicit managed path in my new webapp to house my migrated site collection. So far so good. Here’s the command I ran to do the restore.
stsadm –o restore –url http://newwebapp/oosp –file c:\oops.cmp -overwrite
This is where the pain began. As you can see, I mistyped the last part of the URL. I also (unnecessarily) used the –overwrite flag. I’m sure you can see where this is heading. Since there was no oosp managed path, SharePoint very helpfully overwrote the http://newwebapp/ ROOT site instead! I found out about 1 minute into the restore when our monitoring site sent me an email telling me the site was down.
I then got to bug our DBA on the weekend to ask her to roll back the content database. Then I got some practice using the restore technique outlined at Emad Magdy's blog post. Good times!
The moral of today’s story? Don’t be lazy. Never use the –overwrite flag in your production environment.
