I am trying to take a backup and restore a site collection on my SharePoint 2003 Server environment using the STSADM utility. I was able to create a backup of my top level site which contains a document library of 2000 items. The utility completed successively generating a back up file around 2Gigs in size.
When i try to restore the site the utility gives an Operation Aborted message. Is there a log that is generated that gives better insight into why the restore operation failed?
Try the ULS logs as usual in the first instance...
You should monitor your SQL server. When doing backup and restores, TembDB takes a bit of a hammering, as does the database where your site is being restored. Ensure that everything has space to grow sufficiently (this may be more than you think - I've experienced the need for greater than 3 times the source data size).
If things should fail on the SQL end, this should be reflected in Application or SQL error logs on the SQL instance.
Are you renaming the site when you restore? If you are making the site name longer you may be running into limits over path lengths.
Related
I have an automatic backup running each night through the Portal which should back up my Azure database to blob storage as a .bacpac file and up until Friday that had been working successfully.
Each night I get an email error saying:
Automated SQL Export failed for myServer:myDatabase at 5/30/2016 11:35:39 PM. The temporary database copy was made, but this copy could not be exported to the .bacpac file.
Some tutorials suggest logging into the Portal and doing it manually. When I do this it works successfully and I am able to see the file without error. But on the following night, the process fails again (it doesn't recover itself from performing a manual backup). Is there a way to get more information on why it is failing?
In the new Portal, you can find more information via audit log, database level operations will be logged there including import/export.
OK so after further analysis I was able to pinpoint the root cause of my issue to a Stored Procedure.
I had a Stored Proc which was explicitly referencing my database. Whenever the database backup is taken in Azure, it creates a temporary name and at that point, "breaks" the Stored Procedure as it was Self Referencing.
Fixing the Stored Proc has resumed the automatic backups.
An example of a statement the Proc was calling was:
Select Name from MyDatabase.Dbo.MyTable
This should be rewritten as the following to make it exportable:
Select Name from Dbo.MyTable
Note that while I was able to obtain a more meaningful error using a local copy of Sql Server Management Studio, no error was present in the Azure Portal.
Hopefully this will help someone else.
I have a SharePoint 2013 site collection backup and i am trying to restore this back up on another SharePoint 2013 site collection. Both SharePoint sites are on the same domain. But when i try to restore the site collection from backup, i am getting an error as -
Restore-SPSite : <nativehr>0x80070003</nativehr><nativestack></nativestack>
At line:1 char:1
+ Restore-SPSite-Identity http://ksptestinst2:9999 -Path
"E:\SiteBackup\BackupSPS ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
+ CategoryInfo : InvalidData: (Microsoft.Share...dletRestoreSite:
SPCmdletRestoreSite) [Restore-SPSite], DirectoryNotFoundException
+ FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletRestoreS
ite
the command i use to restore site collection backup is -
Restore-SPSite -Identity http://ksptestinst2:9999 -Path "E:\SiteBackup\BackupSPSite.bak" -Force
i tried using
Restore-SPSite -Identity "http://ksptestinst2:9999/" -Path "E:\SiteBackup\BackupSPSite.bak" -Force -DatabaseServer KSQL2012SP\SQL
TESTDB -DatabaseName WSS_Content_KSPTESTINST2_9999
but both commands are giving same error.
Can anyone suggest how do we proceed?
Couple of Approaches that you could try:
1: Run SharePoint Config Wizard on both the servers
There could be server patches installed, SharePoint services installed, SQL patches installed, pending restarts or any other factor that you might want to rule out initially. Then perform a backup and restore operation. This is an easy one to cross off the list (quite often overlooked).
2: Match Environment Patch Levels
The best & recommended fix is to ensure that you match the SharePoint Configuration Database versions and/or Cumulative Updates/Patch levels to match both the environments- the environment from where you took the backup might be at a different patch level than the environment you are going to restore the patch to. (Goto Central Admin –> System Settings –> Manage Servers in this Farm and verify if there is any pending action. Keep not of the version to verify any version mismatches between environments)
In the same page, double check that you do not see any “Upgrade Required” mentioned against any of those servers. If it is mentioned there, please ensure that you run the SP Config Wizard before you proceed.
Once things look good, and you have compared the versions, download the latest KB from Microsoft and install them to match the SharePoint Configuration Database Schema versions. Perform all server remediation & CU (Cumulative Updates) installations. Remember to run the Configuration Wizards for each CU.
3: Using STSADM
This is a pretty interesting workaround. But sometimes I feel “Old is Gold”. Power up your SP Management Console and try to perform the restore operation using the good old STSADM command line. At times, when the new powershell commandlets fails, stsadm has worked for me.
stsadm –o restore –url "site url" -filename "backup filename"
4: Content DB Restore
Try a Content Database Backup and restore. Before doing this you might want to check in Central Admin (View All Site Collections –> Select the Site Collection and check the Content DB on which it is installed on) about which all site collections will get affected if you restore a particular Content DB. You do not want to lose any other Site Collections that shares the same Content DB.
5: Editing Backup File
(Not Recommended - But works like a Charm)
This is one of those quick and untidy fixes you could possibly try. To start, open the backup file (file you got from the Backup-SPSite command) in Notepad++. (or any other text editor; avoid Notepad though). It might look funny with special characters, but ignore all those for now.
If the file size is too large to open in Notepad++ (>100MB), you can use any standard File Splitter Program to split the file into multiple smaller files of say 10 MB. I have had success with FFSJ
When you edit the file (if you have split the files, open the first split file) in Notepad++ and look for version number that looks something like 15.0.XXXX.XXXX. It should appear somewhere in the beginning lines.
DO NOT MODIFY ANYTHING ELSE. Interestingly, this is the version number that the Restore-SPSite Commandlet checks initially. And if it sees the server version different from the backup version, it just throws the error
Now to know which version number to put there, all you have to do is open your ULS logs (15\Logs{latestlogfile}) and search for a text "schema version". You should see a message similar to this:
Could not deserialize site from E:\SiteCollection1.bak .
Microsoft.SharePoint.SPException: Schema version of backup
15.0.YYYY.YYYY does not match current schema version 15.0.XXXX.XXXX at Microsoft.SharePoint.SPSite.Restore(String filename, Boolean
isADMode, Boolean& readOnlyMode, Boolean& hadWriteLock)
If you are unable to find the above message in the logs, then the issue would be probably something else and there is little/no chance to get this option to work
If you succeed in finding the error message, pick the version number it was expecting from the above ULS error message and update the VERSION NUMBER ONLY in the backup file you were editing in Notepad++. Save it. If you had split the files using a file splitter tool, merge the files back into a single backup file.
Now run the restore command with the new backup file and see if it works.
Restore-SPSite -Identity {{SiteCollectionURL}} -Path "E:\SiteCollection1-New.bak" -Force
These are just a few of the options (not an exhaustive list, but hopefully a good start) that you could try.
I have had greater probability of success with option #1 & #5. Option #2 is something that should be done in the long run.
You could read a bit more on this from my post here as well.
While regular publish to Azure with WebDeploy, had checked Execute Code First Migrations, which i did before.
But this time the Use this connection string at runtime, was also checked, and i published without noticing it. as a result the remote azure db was wiped and instead is seeded with what looks like a default database with aspnetmemembership tables and _Migrations table that only has migrations related to identity tables.
The production data w db structures is gone and I did not yet setup backup on azure, doing it now.
Is there way to restore the database from some sort of auto backup on azure, i have web version w 1Gb size selected, I do not see any options
this suggests that web version would not have any daily backup, but also that web version is discountinued as of april, but i still have it. http://msdn.microsoft.com/en-us/library/jj650016.aspx
and another questions, i understand everything that happened? But it seems extremly dangerous that its so easy to wipe out the whole database and VS shows no warning nor publishing to azure notifies of anything. Is there anything that can be done to prevent dumb but yet very costly erros like this ?
TIA
I got a backup of a Sharepoint 2010 site that I created from our client's production server so that I can make some new changes to it on my staging server.
I can restore the site collection from the backup without a problem but when I try to create a backup of the same site on my staging server, I always get the error "Operation is not valid due to the current state of the object".
Before the error is given however, a small part of the backup file is created. If I try to run the Backup-SPSite again, it always fails at the same point and the corrupt backup files are always the same size.
Going through the logs it looks like the problem might be related to user permissions. I wonder if it's possible that the user permissions, user data, etc that came over from the client's production server are somehow screwing the backup process now because the same data cannot be found on my staging server.
The same error is mentioned here http://technet.microsoft.com/en-us/library/ee748617.aspx but UseSqlSnapshot parameter doesn't work anyway in my case.
I've been hitting my head against the wall with this problem and would appreciate if anyone has any advice on what might help! :)
The setup:
Windows Server 2008 R2
Sharepoint 2010 Server (no SP1 because it hasn't been installed on the client's production server)
Microsoft SQL Server Express Edition
Cheers!
The backup process started working after I checked in a file that had been checked out by a user on my client's production server.
I found out what file that was by opening the corrupted backup file and looking at the title of the last entry.
I have 12.0.0.6421 showing in Central Admin, which would seem to indicate that SP2 was installed. However, when I run an STSADM command to backup a site collection, I do not see the message informing me that it's "setting the site collection to be-read only for the duration of the backup" as described here:
http://bobfox.securespsite.com/FoxBlog/Lists/Posts/Post.aspx?ID=121
I simply get the "Operation completed successfully" message I used to get pre-SP2. Does this mean that SP2 wasn't installed correctly?
Anthony,
Showing a build of 6421 does indeed indicate that SP2 is in-place. Just to make sure, I checked my own farm and VMs as well as a reliable external source (an entry from Todd Klindt's blog: http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=154). I didn't doubt the build number, but it never hurts to confirm :-)
At first, I thought I understood where the issue might be, so I ran some tests. First, I ran an STSADM backup in catastrophic mode to backup my entire farm. Since this isn't a site collection backup, no locking should occur:
stsadm -o backup -directory \\ss-nas3\backups\test -backupmethod full
My catastrophic backup ran without issue, and I didn't receive any message about a lock or read-only behavior. I looked at my ULS logs, as well, and confirmed that no lock was being established (searching for "sitelock" and "lock"). This was as I expected, as I was doing a catastrophic backup -- not a site collection backup.
Next, I tried a site collection backup:
stsadm -o backup -url https://www.sculpted-system.com/pictures -filename \\ss-nas3\backups\test\SiteCollectionBackupTest.bak
Strangely enough, I didn't see a locking message here, either. I took a look at the ULS logs, and I saw nothing to indicate that a lock was put in place. Finally, I performed an
stsadm -o getsitelock ...
... while the backup was running and was greeted with this:
<SiteLock Lock="none" />
ARGH! That's not what I wanted (or expected) to see! Clearly, there was a problem ... so, I tried coming at it from a different angle. I took a look at the MSDN documentation for the STSADM -o backup command, and it clearly indicated that a lock should occur by default. It also indicated that the -nositelock switch should work to override the behavior. So, I tried adding -nositelock to my site collection backup command line.
Guess what: it choked on -nositelock with a command line error (invalid parameter).
Doing an STSADM -help backup indicated that -nositelock was not a valid switch for my environment. None of the new switches I expected (e.g., -nositelock and -force) were present. It's as if my production farm was stuck in pre-SP2 with regard to backups.
I decided to check a development VM I had that was also build 6421 (but different image -- amongst other things, Win2K8 instead of Win2K3 R2), I saw that the -nositelock was a valid command line option. So I checked another development VM that was also build 6421 (but Win2K3 R2 like my "regular farm"). -nositelock was a valid option there, too.
I had applied SP2 the same across all three environments when upgrading (WSSv3 SP2 bits, following by MOSS 2007 SP2 bits, followed by a run of the configuration wizard), so I wasn't sure what was going on.
For fun, I ran a site collection backup on each of the VMs that correctly displayed that -nositelock was a valid command line switch for site collection backups, and I was met with the locking message I didn't see earlier (and that you weren't seeing, either). Clearly, the SP2 updates were operating as I expected them to everywhere except my primary (production) farm.
I concluded I must have somehow done something wrong as part of upgrading my farm, so I tried re-running the WSSv3 SP2 update (first) and MOSS 2007 SP2 update (second) on each box. With each update on each box, I was told the that the update had already been applied. So, I dropped back and punted: I re-ran the configuration wizard to see if it would do anything. I then rebooted the two (virtual) boxes in the farm.
No change.
At this point, I can only confirm that you aren't losing your mind. Two of my all-in-one development VMs with SP2 build 6421 operate as expected, but my two-server/VM farm that is build 6421 that should be locking on site collection backup is not.
I think I'll probably follow up with a friend who is a Microsoft TAM. If I learn anything, I'll post it here and probably on my blog. In the meantime, you might want to follow up with Microsoft, as well. Clearly, something isn't working as expected.
For what it's worth!
There is a list of SharePoint Versions maintained by the SharePoint community here:
http://www.sharepointdevwiki.com/display/SharePointAdministrationWiki/SharePoint+Versions
Your version is correct for SP2; I wouldn't worry about the STSADM message appearing; it's a pretty inconsistent tool.