New KB fix: Databases with multiple backslash characters can be protected but fail during restore with DPM 2010 - The Official System Center Data Protection Manager Team Blog - Site Home - TechNet Blogs

New KB fix: Databases with multiple backslash characters can be protected but fail during restore with DPM 2010

New KB fix: Databases with multiple backslash characters can be protected but fail during restore with DPM 2010

  • Comments 1
  • Likes

KBHere’s a new Knowledge Base article we just published this morning about an issue you’ll see if you protect a database with two backslashes in the path:

=====

Symptoms

When you create a new SQL database (or it is created automatically by an application), and there are multiple backslash (\) characters defined in the database data or log file physical path (like C:\\SQL\test.mdf), you will encounter the following error when you protect this database with System Center Data Protection Manager 2010 and try to recover it to an alternate SQL instance. After you start the recovery process you will see an error in DPM console:

The VSS application writer or the VSS provider is in a bad state. Either it was already in a bad state or it entered a bad state during the current operation. (ID 30111)

Also on the target SQL server, where the database cannot be restored a SQLWRITER 24583 error event is logged in the Application log with the following message:

Sqllib error: OLEDB Error encountered calling ICommandText::Execute. hr = 0x80040e14. SQLSTATE: 42000, Native Error: 3013
Error state: 1, Severity: 16
Source: Microsoft SQL Server Native Client 10.0
Error message: RESTORE DATABASE is terminating abnormally.
SQLSTATE: 42000, Native Error: 3119
Error state: 1, Severity: 16
Source: Microsoft SQL Server Native Client 10.0
Error message: Problems were identified while planning for the RESTORE statement. Previous messages provide details.
SQLSTATE: 42000, Native Error: 3156
Error state: 4, Severity: 16
Source: Microsoft SQL Server Native Client 10.0
Error message: File 'DPMBackup_log' cannot be restored to 'C:\\DPMBackup\DPMBackup_log.ldf'. Use WITH MOVE to identify a valid location for the file.
SQLSTATE: 42000, Native Error: 1834
Error state: 1, Severity: 16
Source: Microsoft SQL Server Native Client 10.0
Error message: The file 'C:\\DPMBackup\DPMBackup_log.ldf' cannot be overwritten. It is being used by database 'DPMBackup'.
SQLSTATE: 42000, Native Error: 3156
Error state: 4, Severity: 16
Source: Microsoft SQL Server Native Client 10.0
Error message: File 'DPMBackup' cannot be restored to 'C:\\DPMBackup\DPMBackup.mdf'. Use WITH MOVE to identify a valid location for the file.
SQLSTATE: 42000, Native Error: 1834
Error state: 1, Severity: 16
Source: Microsoft SQL Server Native Client 10.0
Error message: The file 'C:\\DPMBackup\DPMBackup.mdf' cannot be overwritten. It is being used by database 'DPMBackup'.

Note that backup jobs will run without any issues, and when the database is added, SQL server will accept the path with multiple backslash characters and create the database. Later when you check the physical path of the database files in SQL Management Studio, you will see only one backslash character, as the GUI hides the others.

You can check the original physical path of the database files with the following query:

SELECT * FROM Sys.Database_files

As SQL VSS Writer returns with the path visible in the result of the above query, DPM will also use this path for recovery processes.

Resolution

To avoid the above error, always add new databases with single backslash characters in the database file path, and also ensure application-generated databases also use only one backslash character.

The above error does not occur if you try to recover the database to the original SQL instance or to a network folder.

If you already protected a database which contains multiple backslashes in the physical path for the database files, you will need to recover it to the original SQL instance, or if it is not available, then restore to a network folder and then attach the database files to a different SQL instance.

In the case you restore to the original instance, change the physical path for the database files after these are restored to not contain multiple backslash characters and then you will be able to recover further backups to an alternate SQL instance. You can quickly achieve this by detaching the database and attaching it with single backslashes in the path again.

More Information

If Secondary protection is enabled, DPMMetadata.xml will be generated on the Primary DPM server. Here you can also see the path used by DPM for SQL database protection.

=====

The information above was published today in the following Microsoft Knowledge Base article written by Imre Butsy:

KB2550085 - Databases with multiple backslash characters can be protected but fail during restore with DPM 2010

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis
The Service Manager Team blog: http: http://blogs.technet.com/b/servicemanager
The AVIcode Team blog: http: http://blogs.technet.com/b/avicode
The System Center Essentials Team blog: http: http://blogs.technet.com/b/systemcenteressentials
The Server App-V Team blog: http: http://blogs.technet.com/b/serverappv

clip_image001 clip_image002

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Thank you immensely for this post.

    We are using DPM2012 SP1 with rollup 3. Just recently, we ran into this issue while attempting to restore a Production DB to a staging ground. After Google-ing and finding nothing on the subject, we were preparing to switch DR products; unless a fix could be found.

    I was able to reproduce this issue and confirm that the '\\' path inclusion is still affecting new DPM releases. However, I also found that if you restore to a different DB instance but use the exact file system path (minus the \\), the restore succeeds.

    Thanks,

    Don Mohlmaster

    Tervis