Answered by:

Restore erro: "SqlException: The operation did not proceed far enough to allow RESTART"

Question

I'm trying to restore a backup that I made on a new server I created to the one I made the back on. I'm getting this error on most of my content databases during the restore:

Object StateService_0e609739aea044189d82651f721ce4fd failed in event OnRestore. For more information, see the spbackup.log or sprestore.log file located in the backup directory.
SqlException: The operation did not proceed far enough to allow RESTART. Reissue the statement without the RESTART qualifier.
RESTORE DATABASE is terminating abnormally.

I've seen another post which discussed that you needed to use all the same service accounts that were in the original system. I have ensured this and I still get the error. Also, just for testing, I have given "Everyone" full access to the backup folder
where I'm trying to restore from.

Answers

I don't have all the details of you failure but I have a theory and a suggestion. My theory is that the credential running SQL is local to the SQL box or one of the
system accounts and thus unable to reach the share, other possibility is network errors. These solutions work for most of the cases though:

Option 1:

1. Copy your backup locally to the SQL Server. Create a share. Make sure the service running SQL is able to access the share. If you have SQL and SharePoint in the
same box (in a standalone installation for example) you won't even need a share. Make sure that you can access the share from the SQL box and from SharePoint box. Run the restore again giving the share as source (or the folder name, eg. C:\backup, if in the
same box). See if it fails. If it fails try option 2.

Option 2:

1. Using SQL Management Studio Restore the database backup (it should be "\\spserver-test\backups\spbr0003\000000A0.bak"
in your case) and call it the same name you used in the other farm (you can choose other name if you want as well)

All replies

I don't have all the details of you failure but I have a theory and a suggestion. My theory is that the credential running SQL is local to the SQL box or one of the
system accounts and thus unable to reach the share, other possibility is network errors. These solutions work for most of the cases though:

Option 1:

1. Copy your backup locally to the SQL Server. Create a share. Make sure the service running SQL is able to access the share. If you have SQL and SharePoint in the
same box (in a standalone installation for example) you won't even need a share. Make sure that you can access the share from the SQL box and from SharePoint box. Run the restore again giving the share as source (or the folder name, eg. C:\backup, if in the
same box). See if it fails. If it fails try option 2.

Option 2:

1. Using SQL Management Studio Restore the database backup (it should be "\\spserver-test\backups\spbr0003\000000A0.bak"
in your case) and call it the same name you used in the other farm (you can choose other name if you want as well)

And of course I didn't update file path from the other server :/, that's why I had SqlException, but still it should be also an ERROR, when the path does not exist the database can't be attached to sqlserver and our beloved SqlException with RESTART and
RESTORE problems happens.

While setting up a VM just to test restore procedures, I could restore all my web apps - but one... obviously the most important one.

Now SharePoint did not really explain this error properly but it turned out that I had insufficient disk space for the content db. Silly, I know, but I am putting this out there if someone else ever runs into it