Data Backup and Recovery

Invalid/Local Drive Snap Manager SQL



I'm trying to do a Snapshot using Snap Manager for SQL on SQL 2005 IA64, we have 7 database spread to multiple disks with its drive letter (16 LUN), all LUNs are on NetAPP LUN (V-3160).

But when I start the snap manager for sql console, it shows that some of my Databases stated (Invalid/Local Drive ....), but all the drives are on NetAPP LUNs, why the snap manager didn't see that the database files are on netapp lun ?

please help.

Thanks in advanced.


Arief Pribadi




Welcome to the forum.

Try running through the SMSQL configuration wizard again and fix any issues it highlights.  ie Move databases to NetApp managed storage

Hope this helps



Dear Brendon,

Thank you for your suggestions, I've tried to re-configured de SMSQL configuration wizard, but when I've finished configured 1st database, the drive letter I've been used no longer appear on th right pane of the console and it cannot be used for my 2nd and 3rd database. (I have 5 databases using the same LUN).

My databases (5 DB) have multiple files across 7 drives (LUNs) and almost all the LUNs used by these 5 databases.

I Think I got stuck of SMSQL filegroups limitations, 2 of my databases have more then 15 filegroups, while SMSQL only allow 10 filegroups, may be this is the issue ?



Did you used snapdrive before to create LUN? because snapmanager only recognize LUNs created by snapdrive.hope this help.


Dear Robert,

Thank you for your response. Previously the data were stored in HDS storage, I've just migrated the data into V-Series, in the migration prosess the LUN are all created from the filler, not from the host (using SD).

Regarding of the LUNs that was not created by SD, I have attached 1 database to the host using some of the LUNs used by my other 5 database (which not recognize by SMSQL), and the database is recognized by SMSQL, and it can be backup/restore using SMSQL, in this sample I believe the problem is not in the LUNs, but in the database configuration, especially in filegroups configuration. I suspect that this is the issue where SMSQL only support max 10 filegroups, while some of my DB use more than 20 file groups. But again there is a doubt also, because from my 5 DB only 2 that have more then 20 filegroups, while the rest of the 3 are only have max 7 filegroups, but these 3 databases also not recognize by SMSQL to be backup/restore.

So temporarly I used SD Snapshot to snapshot all the LUNs after I stop the sql service first, and mounted from  other server to automate flexcone the LUNs so the database can be attached to other host and can be read for MIS process.


Hi Arif,

The reason for this error is that SMSQL does not allow databases to be spread across multiple LUNs that are also shared by other databases. In your case that is the scenario I believe and not the filegroups limitation. The filegroups limitation is a soft limit and not a hard one. Please refer the Installation & Admin Guide for SMSQL for more details.




Dear Sourav,

Thank you for your response.

I have discusss with DBA team, it seems we can do data file migration, and we will redesign the file and disk allocation for the process, and we will see again the SMSQL functions afterwards.

Thank you again for the response.


Arief Pribadi


I am having the same problem.

I think the resolution is adressed in this KB article:

I let you know if this is the case

Notice that i did not do a upgrade, but there might be a database placed in the wrong folder.

It says:

Solution ID: kb38832
Last updated: 31 MAR 2008

SnapManager for SQL reports Invalid Configuration after upgrading to SQL Server 2005

After upgrading to, or installing a new instance of Microsoft SQL Server 2005 on an existing host that is running Microsoft SQL Server 2000, SnapManager for SQL may report an invalid configuration. In addition, the database selection will not be available for backup and the Configuration Wizard will not allow changes.

SnapManager for SQL reports Invalid Configuration after upgrading to SQL Server 2005.

Cause of this problem
Microsoft SQL Server 2005 does not allow databases to reside in the same drive, physical or LUN,  as the SQL Server install files or error logs. While the program files are easy to identify, the error logs are not so obvious and will cause the drive to be marked as 'SQL Root'.


To resolve this problem, follow these steps:

  1. Create an Error Log folder in the desired new target.

  2. From the startup options for the database instance, locate the error log path and change it to the new location.

  3. Restart the SQL server instance.

  4. Make sure that the SnapManager MMC was closed and reopened to pick up the changes.

Performance and disaster recovery factors should be considered when deciding on the configuration of SQL Server and SnapManager backup/restore strategies.

Or it should be this solution
Solution ID: kb50622
Last updated: 25 AUG 2009

LUNs or databases are listed as local/invalid when configuring SMSQL

LUNs or databases are listed as local/invalid when configuring SMSQL

Cause of this problem
This can occur when a new database is created with files on a LUN that is used by another database in a dissimilar configuration.

This can also occur when database is on a local drive or the database on a LUN has an associated file on a local drive and cannot be backed up by SMSQL.

A single database on a LUN with a log, index file, or other file on a local drive will cause the entire LUN to show as local/invalid because it cannot be properly backed up.

Databases containing multiple .MDB files in different LUNs will cause this error as all files need to be in the same LUN for a consistent backup of the Database.

  1. Confirm all databases in a LUN are using the same configuration.

    Supported configurations:
    SnapManager 2.1 for Microsoft SQL Server
    SnapManager 5.0 for Microsoft SQL Server

  2. Migrate the database to a LUN or migrate the file associated with the database from the local drive to the LUN that contains the database or log files.



we ran into a similar issue.

All our databases on one LUN were reported to be on an invalid LUN.

The root problem was that, due to space limitations on the original drive, we shifted the windows page file to the LUN that held most of our databases.

After changing this, the problem disappeared.


See this:

Bug Detail

Bug ID341035
TitleSnapManager for SQL Server 5.0 does not work on SQL Server 2008 database when full text catalog is enabled
Duplicate of
Bug Severity3 - Serious inconvenience
Bug StatusFixed
Bug TypeSnapManager
 SnapManager for SQL Server 5.0 and 5.0R1 will not be able to configure or
 backup SQL Server 2008 database when the full text catalog is enabled. When
 using Configuration wizard to move a SQL Server 2008 database with full
 text catalog enabled, SnapManager MMC Snap-in will failed with this error:
 "An error occurred while associating the selected SQL object and the LUN. 
 Retry the operation. Details : startIndex cannot be larger than length of
 string. Parameter name: startIndex Stack Trace:mscorlib". The databases with
 full text catalog enabled in the backup view will be shown as "Invalid/Local".
 Use SnapManager for SQL Server 5.0R1P2 or later.
 This issue only applies to SQL Server 2008 database with full text catalog


SnapManager - 5.0R1P2

Date Posted: 24-JUN-2009
SnapManager 5.0R1P2 for Microsoft SQL Server
Based on SnapManager 5.0R1 for Microsoft SQL Server

Bugs fixed in this release:


  366120 – Restore of Single Database on Single LUN fails for
           transactional log backup

  341035 – SMSQL 5.0 does not work with SQL Server 2008 when 
           full text catalog is enabled

  352356 - 5.0 does not set default snapinfo snapshot retention 
           correctly causing volume out of space

  352690 - SMSQL V 5.0 "Unable to get valid backup time from 
           snapinfo snapshot name"

  359236 - Point in time restore puts database in restoring state

  355297 - SMMOSS Restore issue: SMSQL fails to restore data in 
           multiple databases in one LUN in Japanese environment

Release Notes:

  363584 - SMSQL cannot create scheduled jobs on Windows 2008 Japanese OS.

           Customers running SQL Server 2005 version 2005.90.3042
           or below will not be able to create schedule jobs to 
           backup their SQL databases using SMSQL. 

           Customers must upgrade their SQL Server 2005 service pack 
           level to 3 (SQL version 2005.90.4035).

           SQL Server 2005 service pack levels and version information

           SQL Server 2005 RTM 2005.90.1399 
           SQL Server 2005 Service Pack 1 2005.90.2047 
           SQL Server 2005 Service Pack 2 2005.90.3042 
           SQL Server 2005 Service Pack 3 2005.90.4035