Home » SharepointRSS

Problems restoring a site-

MOSS 2007 restores have always been a headache for us- neither import/export nor backup/restore work reliably for us- sometimes they work, sometimes they don't. 
I encountered the following issue last week- does anyone know of a hotfix or some other solution for this error:  "The site collection could not be restored. If this problem persists, please make
sure the content databases are available and have sufficient free space."


More info:

I have set up a sharepoint recovery farm and have been backing up the sharepoint content databases and profile databases directly from SQL.  I was able to successfully restore a backup of the content database to the recovery farm.  The site came up fine on the recovery farm and I was able to create a backup of the site I needed via stsadm site backup command, however when trying to restore the site to the live farm (and I have succesfully backed up and restored other sites from recovery to live this way)  I got:

 

The site collection could not be restored. If this problem persists, please make
sure the content databases are available and have sufficient free space.

 

I tried deleting the site and recreating it, which put it on a new content database (sharepoi3 instead of 2) but still got the same error when trying to restore.
I did a databaserepair on all 3 content databases, to check for orphaned objects, but found nothing.
I restarted the windows timer service and did an iisreset on all 4 sharepoint servers. This did not help either.
The only other solution I could find would be to remove and then add the live databases (through stsadm) and since I wasn't feeling lucky and didn’t want to make the other sites unavailable,  I opted to try and find a workaround.
I did an export on the site on the recovery farm, which was successful, but when trying to import it it threw an error-
Start Time: 10/2/2009 6:39:18 PM.
Progress: Initializing Import.
FatalError: Could not find WebTemplate #10799 with LCID 1033.
at Microsoft.SharePoint.Deployment.ImportRequirementsManager.VerifyWebTemplat
e(SPRequirementObject reqObj)
at Microsoft.SharePoint.Deployment.ImportRequirementsManager.Validate(SPRequi
rementObject reqObj)
at Microsoft.SharePoint.Deployment.ImportRequirementsManager.DeserializeAndVa
lidate()
at Microsoft.SharePoint.Deployment.SPImport.VerifyRequirements()
at Microsoft.SharePoint.Deployment.SPImport.Run()
Progress: Import Completed.

Eventually I manually recreated the site in live and restored content from the subsites, (save as template with content) but this of course lost all permissions.

 

5 Answers Found

 

Answer 1

I first would like to verify that your recovery farm is using a different host header than the original farm.  Sometimes having two farms with the same URLs can pose issues.

What I've done to restore content using only database restores is to first back up the data that I need to restore in SQL running a maintenance plan.  Then, I copy that database to the destination SQL server (in a location that can be restored from).  Restore that database on top of the database you want to use for the web application using the SQL DBMS menus. 

Now, you have to run the stsadm -o deletecontentdb command to remove the content DB association with your web application that you want to restore.  After that command completes, run stsadm -o addcontentdb to reattach the same database which will associate your backed up data to the web app.  Now, you should be able to access the content.

Please note that the only exception to this process is Project Server content.  I would refer to KBs and Brian Smith's blog if working with Project Server restores.

Hope this helps.

 

Answer 2

Hi Dan, thanks for your response-

I first would like to verify that your recovery farm is using a different host header than the original farm. 

Yes- recovery farm is on seperate boxes, different IPs and URLs/host headers.  It's a completely seperate farm with its own SQL server and this farm runs parallel to live.

Sometimes having two farms with the same URLs can pose issues.

Not the case here- different URLs.

What I've done to restore content using only database restores is to first back up the data that I need to restore in SQL running a maintenance plan. 

Yes- this is exactly what I am doing.

Then, I copy that database to the destination SQL server (in a location that can be restored from).  Restore that database on top of the database you want to use for the web application using the SQL DBMS menus. 
Now, you have to run the stsadm -o deletecontentdb command to remove the content DB association with your web application that you want to restore.  After that command completes, run stsadm -o addcontentdb to reattach the same database which will associate your backed up data to the web app.  Now, you should be able to access the content.


OK, I did everything exactly as described above with ONE exception- I ran the stasam -o deletecontentdb on the recovery farm BEFORE restoring the SQL database.  Do you think this is what is causing the error when I later attempt to restore the site in live?  The site comes up fine on the recovery farm, it is only when I try to restore it to the live farm that I have an issue.

One other thing to note that may or may not be related- the site I was restoring was one that has previously gotten deleted and restored (yes, we have some issues with user education) and I am wondering if that is part of the problem as well.
 

Answer 3

If the site you are referring to was a subweb to a site collection or a site collection itself and it exists in the backed up DB, this should not be an issue during the restore. 

When you restore the database, you may need to make sure the proper security is added to the database as well.  You may have different service accounts accessing the database between the two farms and that could cause an issue. 

I don't think that running the deletecontentdb before restoring is an issue, but I've never performed the steps in that order so I truly cannot say.

Also when you restore the database, you want to make sure and select "Overwrite the existing database" on the Options pane and "Leave the database ready to use by rolling back uncommitted transactions.  Additional transaction logs cannot be restored. (RESTORE WITH RECOVER)"

Finally, after complete, make sure your database is Online in SQL DBMS.  Sometimes when doing the restore you may have to OFFLINE the old DB prior to the restore.
 

Answer 4

Just an update-
I took the same .bak file I made of the site from the content db restore on my recovery farm, copied it to the filesystem on our pre-production farm, and did stsadm -o restore and it worked perfectly.  This is so frustrating. 

To clarify- restoring the content database from a backup of live to the recovery farm works perfectly.  I only have a problem with restoring the site backup to the live farm. 
 

Answer 5

The issue turned out to be that the site was in a content database that was missing two fields from the dbo.Sites Table (FullUrl and UserAccountsDirectoryPath).  This is why it worked to restore it to my recovery farm- that database had all the fields. 

Eventually I ended up editing the db in SQL (not supported), because without making that change I couldn't apply SP2.  I needed SP2 to move all the sites out of that damaged database, so I added the fields to the damaged database, upgraded to SP2, then created a new content db and moved all the sites to it and deleted the old corrupt content db.

 
 
 

<< Previous      Next >>


Microsoft   |   Windows   |   Visual Studio   |   Follow us on Twitter