Data Backup and Recovery

SMSQL 5.2 and SMSP 6.1 Clone Backup DB Error


Hi Community!

I recently finished my 3rd Installation of SMSP 6.1 with SMSQL 5.2 and Snapdrive 6.4.

At all 3 Installations i sporadic get the following Error for the Content Database in the SharePoint 2010 Environments:

Errors: Clone Backup DB Error :WSS_Content_01

Clone Backup DB Error :WSS_Content_02

Clone Backup DB Error :WSS_Content_03

The Problem is that SMSP 6.1 cannot create the Single-Item Index of these Content Databases.

After testing around with SMSQL and SMSP and no success i decided to Downgrade the SMSQL 5.2 to SMSQL 5.1P2 and now the Backups working again.

I think there is a Bug with SMSP 6.1 in combination with SMSQL 5.2 because all other SQL Backup were working perfectly.

Maybe someone of Netapp can confirm my suggestion 😃


Christian Lapacka | HATAHET productivity solutions GmbH




Hi Christian

I have been working through the same issue for the last few months, finally I have been able to perform an item version backup, the resolution was to downgrade SMSQL from 5.2 to 5.1P2, make sure you uninstall 5.2 first and remove the snapinfo folders, then rerun the SMSQL configuration wizard.

Let me know how you get on.



Although I have had a few backups fail with that same error using SMSQL 5.1P2 today


May you have old clones mounted in SQL!

First check this with the Clone Wizard of SMSQL if there are no clones for "Delete Cloned Databases" you can delete it in the SQL Management Studio and then run the Backup again


I actually check this prior to running the backup, since my last post I ran a backup and that was fine. However SMSP seems to leave cloned DB's attached to the verification server, surely this is not normal behaviour?


Since SMSQL 5.1P2 i don´t have this problem! Which Snapdrive Version do you have?


I'm running the same configuration as you now. SMSP 6.1, Snapdrive 6.4 and SMSQL 5.1P2. My only problems now are orphaned clone DB's and the error below:

Configuration Value

Plan Name Full Backup

Plan ID PLAN20120208160858

Backup Level Item Version Level

Backup Type Full Backup

Job ID FB20120217190000

Agent Host S-HO-SP

Media Service S-HO-SP

Email Notification Snap Manager for Sharepoint

Agent Version

Manager Version

Username bloor_homes\smsp

Start Time 2012-02-17 19:00:00

End Time 2012-02-17 19:07:02

Statistical Result 1657 MB data, 1(0) site collections, 25(0) sites, 282(0) lists, 813(0) items. Error:runcommand error


I had the same problem using SMSQL 5.2, SD 6.4 and SMSP 6.1

Reverted to SMSQL 5.1P2 and backups are now completing successfully



Hello customers/partners,

I can tell you now that this is a recently discovered bug, 585632.

Engineering are currently working on this. I can provide you here with the public report, which is not yet showing up on our site (it should soon).

%%% TITLE:

Restore and clone may fail with error Logical file db_data is not part of database db, Use RESTORE FILELISTONLY to list the logical file names.


When doing a database restore or cloning, the operation may fail with the

following error messages in SMSQL report:

Failed to prepare VDI mount snapshot.

Error encountered when executing sql command:

Msg 3234, SevLevel 16, State 2, SQLState 42000

[Microsoft][ODBC SQL Server Driver][SQL Server]Logical file 'db_Data' is not

part of database 'db'. Use RESTORE FILELISTONLY to list the logical file names.

Msg 3013, SevLevel 16, State 1, SQLState 42000

[Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE DATABASE is terminating


Error Code: 0xc00408a0

Unable to get VDI command to perform snapshot creation or LUN restore.

The SQL command executed.

Failed to restore SQL Server database [db] of [inst].

The problem will happen under the following conditions:

1. Multiple databases are sharing same LUN or two LUNs;

2. Among databases sharing LUN(s), there are more than one databases whose

name's first 4 characters are the same, and those databases are belonging

to the same SQL Server instance, or different instances but the first 4

characters of those instances' names are the same.

With such configuration, when those databases are backed up at the same

time, one or more of backup metadata file may be overwritten during

the backup, so the restore or clone will fail.


To prevent this problem from happening again with newly created backup,

use the following workaround:

1. Add the following registry key DWORD (32bit) value named

"SupportLongDbName" under:

HKEY_LOCAL_MACHINE\SOFTWARE\Network Appliance\SnapManager for SQL Server\Server

Set its value to 0.

2. Restart SnapMgrService.

In case a restore is needed for the existing backup, you can manually

mount snapshot which contains the database, copy the database files

from the snapshot LUN manually, then attach the database using the

copied files.

%%% NOTES:

The workaround provided for preventing the issue from happening with

newly created backup does not apply to database with a long name, such

as more than 86 characters. For database with very long name, relocate

such database to separate LUN, so it does not share the same LUN with

other databases.

Daniel Breslauer

NetApp Technical Support Engineer