Restoring a Sharepoint Services site from backup
Posted by Nico in Nico, tags: 3.0, services, sharepoint, SP2, Todd Klindt, twitterA while back, a server running Sharepoint Services 3.0 went down. Of course that we had to get it back up and running immediately, so I was tasked with reviving a Sharepoint site and I didn’t know how to do it.
Enter the internet.
Seriously, unless you’re doing something with brand new technology, chances are that someone’s already had the exact same problem that you’re having. And if they take the time to share and document their process, other people can use that to their benefit. This is also why I’m re-telling the story, so that if anyone comes across the problem, hopefully they find this and can use it for an answer to their issue.
After arduous searching and much head-desk contact, I decided that this little post on EggHeadCafe.com would be my main point of reference.
So here’s what I started with:
- A server with a fresh install of Windows 2003 server.
- Installed a clean version of Windows Sharepoint Services (with Service Pack 2)
- A few database files floating around, recovered from a backup that basically just copied everything on the drive to somewhere else. The files were: STS_Config.mdf, STS_Config_log.LDF, STS_controlfreak_1.mdf, STS_controlfreak_1_log.LDF, WSS_AdminContent.mdf and WSS_AdminContent_log.LDF.
- A lot of pressure to get this done quickly, and no idea on how to do it.
I then installed Microsoft SQL Server Management Studio Express. There are ways to do all the work via command line, but since I didn’t really know what was going on, and didn’t have the luxury of time, a visual interface made things much easier for me.
When running the Management Studio, I connected entering for the server name “\\.\pipe\mssql$microsoft##ssee\sql\query”. For Authentication, Windows Authentication did it, because the database was setup like so when I ran the WSS installer.
Once inside, if you right click on “Databases” there’s an option to attach. I attached the STS_controlreak_1.mdf file that I’d recovered, and bam! It was in the database. Ok, that was easy.
Next, I went into WSS Central Administration, which is the localhost and port 36459. From there, there’s a section for Application Management. This is where the magic happened.
Under “Content Databases” you see what databases the Sharepoint sites was using. The top right of the screen shows what Web Application you’re working on, and I could chose from Sharepoint (port 80) or the Central Admin site. Of course I wanted the Sharepoint one on port 80.
It was showing me a Database called “WSS_Content” as listed. I clicked on it, and at the bottom of the page that opens, chose “Remove content database”. Then hit OK, and felt my heart beat rise. Luckily, nothing exploded, and all that happened was that the site was no longer using that database. Turns out that “WSS_Content” is the default site that comes with WSS, so it’s safe to remove. No harm done.
Now, after clicking on “add a content database” all that I had to do was enter the name of the database holding the site. The name had to be like it appears on SQL, which in this case was “STS_controlfreak_1″. The Database Server name I used was “CONTROLFREAK\Microsoft##SSEE” (CONTROLFREAK is the server’s name, to make things even more fun).
Then panic ensued. I got an error message, saying “Attaching this database requires upgrade, which could time out the browser session. You must use the STSADM command ‘addcontentdb’ to attach this database.” This was because the install I was doing was more recent than what was there before. In other words, I had a brand new SP2 install, and the old site apparently wasn’t Service Pack 2.
The visual interface would have worked just fine, but I was going to have to add the database manually so that it could update it at the same time, and so it was time for command line action: Windows Key + R. “cmd”. Enter.
cd c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN
stsadm -help addcontentdb (just to get a clue for what’s up)
stsadm -o addcontentdb -url http://controlfreak -databaseName STS_controlfreak_1″
That took a while to process, but eventually I got a nice message telling me “operation completed successfully”. Apparently this was good. To make sure, wanted to make sure the site was listed, so I ran:
stsadm -o enumsites
Sure enough, my site was listed there. And then, the glory. Browsing http://controlfreak had my old site back, running as if nothing had ever happened! I went all TechnoViking and the problem was gone!
Now, the truth is, I was lucky in resolving this. After many a google search, and many different attempts, I was about ready to give up. As a venting channel, I expressed my frustrations on twitter… and then the real magic happened.
A guy named Todd Klindt replied, saying he could help me. We exchanged a few messages, got on messenger, and he held my hand through the last steps.
Turns out I was close, but I needed some more clear idea on how to add the database to Sharepoint. It it hadn’t been for Todd, who knows how much longer it would have taken me to figure it out.
What I do know is that I was very thankful that Todd found my rants on Twitter, and that he volunteered his time to help me out. He is very knowledgeable on Sharepoint overall, and he runs a site on the thing! I checked it out, and bookmarked for future reference: http://www.toddklindt.com. If I ever have to work with Sharepoint again, I’ll make sure to check there first for guidance, how-to’s and best practices. If I was a super-user of Sharepoint, I’d probably be checking out his podcast too.
Entries (RSS)
[...] Originally posted here: Restoring a Sharepoint Services site from backup [...]