What is causing this error :- Restore-SPSite : <nativehr>0x80070003</nativehr><nativestack></nativestack>

Question

I want to restore a site collection to my staging environment , and when i typed the following power shell command :-

PS H:\> Restore-SPSite http://ggvstg01:12160/discussionforum/GeneralDiscussi
    -Path C:\Users\user\Desktop\Backup\GeneralDiscussion.bak -Force

Confirm
Are you sure you want to perform this action?
Performing operation "Restore-SPSite" on Target
"http://ggvstg01:12160/discussionforum/GeneralDiscussion".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help
(default is "Y"):y

I will get the following error :-

**Restore-SPSite : <nativehr>0x80070003</nativehr><nativestack></nativestack>
At line:1 char:1
+ Restore-SPSite http://ggvstg01:12160/discussionforum/GeneralDiscussion
-Pat ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
    + CategoryInfo          : InvalidData: (Microsoft.Share...dletRestoreSite:
   SPCmdletRestoreSite) [Restore-SPSite], DirectoryNotFoundException
    + FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletRestoreS
   ite**

Answer 1

I got this error when trying to do Restore-SPSite on a SharePoint Farm that did not match the schema version of the backed-up Site Collection.

After installing the correct CU to my target environment the Restore-SPSite worked without issues.

Found this in the ULS log to pinpoint the issue :

Microsoft.SharePoint.SPException: Schema version of backup 15.0.4617.1000 does not match current schema version 15.0.4569.1000 at Microsoft.SharePoint.SPSite.Restore(String filename, Boolean isADMode, Boolean& readOnlyMode, Boolean& hadWriteLock)

Answer 2

Check in the Event Viewer if there are SQL permission error.

1. Open Event Viewer (click start and search it)
2. Expand Windows Logs and than click Application (in the left side)

3. Check if there are critical error like this

   with the following details

   SQL Database DATABASE_NAME on SQL Server instance SQL_INSTANCE not found. Additional error information from SQL Server is included below.

   Cannot open database DATABASE_NAME requested by the login. The login failed.

   Login failed for user USER_NAME.

Answer 3

You may already have restored this site before. In that process you also delete the site first, which you can find running the command...

>Get-SPDeletedSite

You'll see the site (or sites) listed, like this:

WebApplicationId   : 009c1289-392b-43a6-8222-146117074738
DatabaseId         : 88efc46f-5a2b-4171-81cb-7577da65bac3
SiteSubscriptionId : 00000000-0000-0000-0000-000000000000
SiteId             : 86d69f7e-3a9e-4f65-8eba-550d77f93a18
Path               : /sites/collaboration
Scheme             : Http
Url                : http://portal/sites/collaboration
DeletionTime       : 2014-02-21 11:14:18

WebApplicationId   : c73bb367-d329-4ef2-aef7-323ce207d2a9
DatabaseId         : aeb2d6ab-9f9b-493f-aefc-797d4b591f43
SiteSubscriptionId : 00000000-0000-0000-0000-000000000000
SiteId             : 9d0ed313-0353-4cec-817a-a491a8c5fc26
Path               : /
Scheme             : Http
Url                : http://portal/
DeletionTime       : 2014-02-19 15:27:37

Copy the SiteId and run

Remove-SPDeletedSite –Identity 9d0ed313-0353-4cec-817a-a491a8c5fc26

That way you won't have trouble deleting the site upon restore (which is the first thing that happens).

Answer 4

I ran into this error when restoring a site collection from another farm that was an older CU/patch version.

An optional work around if you don't want to upgrade the other farm:

1. Create a test web application in the newer farm
2. From SQL, restore the original db with the site collection you plan to restore.
3. Upgrade-SPContentDatabase -ID <id guid>
4. Backup-SPSite –Identity 'http://contoso-a.com/' -Path E:\contosobackup.bak
5. Restore-SPSite 'http://contoso-b.com/' -Path E:\contosobackup.bak -Force

Answer 5

This issue may have been resolved. But for someone who might end up with a similar issue in the future:

If you have recently installed a PU or a CU (March 2013 PU or April 2013 CU) and did not run the config wizard on all the servers, do so.

It may resolve the error. Ref: http://spreza.blogspot.com.au/2013/05/restore-spsite-force-failed-by.html

Answer 6

Please check your ULS logs and Event Viewer logs to track inner details of this error.

This type of error occurs usually when you have not run the Configuration Wizard after installing CU update. Please ensure you run the Wizard after you have installed the CU update.

This error can also occur if you are using an account to restore SP Site that has insufficient database permission in SQL Server.

Answer 7

We just had a similar problem that was caused by running out of space on the database server.

Answer 8

1. Create an empty DB to old environment.
2. Add the DB to new environment( the DB schema will be updated)
3. Restore you SC to that DB.
4. Optional Move-SPSite to other DB and delete the one you used to restore the SC.

Answer 9

I can confirm that going by restoring the DATABASE instead of the Site Collection using Restore-SPSite, fixes this. I too had the issue with schema version being higher in the destination environment (development in my case) than what is was in the source environment (production in my case). The following message was logged in the ULS:

Could not deserialize site from D:\Backup\From PROD2013\SiteCollectionBackup.spb . Microsoft.SharePoint.SPException: Schema version of backup 15.0.4841.1000 does not match current schema version 15.0.4859.1003.

Using information from the previous answers in this thread, my workaround was as follows:

1. Remove the existing content database on the destination Web Application (using Central Administration)
2. From SQL, restore the original db with the site collection you plan to restore
3. Add the restored database to the destination Web Application (using Central Administration)

This will automatically upgrade the database to the new schema version, and the restored content should be available immediately on the Web Application. If not, try an IISReset, and open the site again.

Answer 10

We were facing the same issue. Before running the command we need to ensure the following:

• Check if the logged in account has dbo.owner permission on the content database.
• Check if the database name and database server name are provided. If they are not provided then the command will select any database at random.

Refer to TechNet article: https://technet.microsoft.com/en-us/library/ee748655(v=office.16).aspx

Answer 11

Possibly I see three reasons for this error.

1. SharePoint Environment and patches "http://centralAdmin:2013/_admin/PatchStatus.aspx"

if the version of the SharePoint is different then it will through the same error code.

2. Check the database versions (schema) and the logged-in user has permission for the database (webapplication content database) you are trying to restore.

3. Check all solutions(wsps) deployed to the webapplication.

When it tries to restore the site it will also check for the features. If any of the feature is missing it will throw the same error.

Hope this helps you

Answer 12

This is not possible out of the box. You would have to create remote event receiver (with custom logic) to trigger when file is shared and update permission on the folder to reflect that.

Alternatively have you tried using document set to meet your requirements?

Answer 13

I had the same issue. After going through the Event Viewer I realize it is causing due to the following issue on the database transaction logs.

Restoring a site has a lot of sql statements running behind the scene and it could create this issue. To resolve that use one or more of following options:

1. Clear the transaction log
2. Increase the size of the transaction log
3. **Not recommended for production or UAT: Update the recovery mode of the database to "Simple". So that it won't record all these SQL statements in log. However, this is only recommended in development environments since it affects database recovery.