CSRecoveryAssistant Failure

Last post 03-05-2019, 3:07 PM by bkpadm3000. 4 replies.
Sort Posts: Previous Next
  • CSRecoveryAssistant Failure
    Posted: 02-18-2019, 9:59 PM

    Trying to do a DR recovery of a CommServe and running into an issue when it comes to restoring the DB.  

    I'm seeing reference to NDF files in a location that doesn't exist on the DR server.

    In the E:\Program Files\Commvault\Content Store\CommServeDR\DR\cmdFile.log

    Directory lookup for the file "C:\Program Files\MSSQL2008\MSSQL10.COMMVAULT\Data\Commserve\commserv_1.ndf" failed with the operating system error 3(The system canno find the path specified.).

    This and 4 other NDF files (commserv_2.ndf etc.) exist on the primary CommServe, but they are not part of the DR backup.  I have no idea what they are and why they exist.  Are they something that should be backed up, and how are they included in the DR recovery?  Or how do I skip these as part of the DR recovery?


  • Re: CSRecoveryAssistant Failure
    Posted: 02-18-2019, 10:08 PM

    To add some extra color to this, I've found out by looking at the files in SQL Mgmt Studio, that they belong to the CommServe database.

    They are:

    • cx_archdata1
    • cx_archindex1
    • cx_eventdata1
    • cx_eventindex1
    • cx_index1

    It would appear that all the other DB files are located in C:\Program Files\Commvault\ContentStore\Data\CommServ.

    Assuming at this point I'd have to relocate the files to where everything else is using this link?  Any gotchas?


  • Re: CSRecoveryAssistant Failure
    Posted: 02-19-2019, 10:52 AM


    I am not sure if I understand your problem. You can change the path of the database files in the CSRecoveryAssistent.

  • Re: CSRecoveryAssistant Failure
    Posted: 02-20-2019, 12:05 AM

    Yes, you can specify where the files get recovered to, but the CSRecoveryAssisstant is somehow looking at file locations from the source, and erroring out.  See the attached log to see the errors on the DR server, and then also see the DB file locations on the source CommServe.  Not sure why it cares to be honest with you, but apparently it does. 

    I believe it's because ALL DB files on the source must be in the same location.  I have no idea why they currently aren't.  I assume at some point during v9 to v10 to v11, it didn't move all the files to the correct place.  As can be seen, 2 of 7 NDF files are location in the *correct* location, and the other 5 are in the legacy location.  I don't think it likes them being a mix, even though the DR backup works correctly. 

    I think by manually moving these files on the source to where everything else is, it will be OK.  Then I'll run another DR backup and re-test.  Can't do this for another week though, so won't know for a bit.

    If anyone has any thoughts/solutions in the meantime, I'm all ears.

  • Re: CSRecoveryAssistant Failure
    Posted: 03-05-2019, 3:07 PM

    In the interests of helping someone else on this forum, my theory and solution were correct.

    Some CommServ database files were located in a legacy location, seperate from the main mdf and ldf files on the source CommServ.  No idea why, but there you have it.  Those files ALL need to be in the same location for the CSRecoveryAssistant to work, which makes no sense because you can restore the DB files anywhere technically.

    C:\Program Files\MSSQL2008\MSSQL10.COMMVAULT\Data\Commserve


    C:\Program Files\CommVault\ContentStore\Data\CommServ


    ### Here is the SQL to drop the CommServ database

    USE [master]
    USE [master]
    EXEC master.dbo.sp_detach_db @dbname = N'CommServ', @skipchecks = 'false'

    ### Here is the SQL to re-attach the DB once the files have been moved.
    NOTE:  The user that executes this also needs to have file permissions on the directory/files you moved to otherwise you'll get an "Access Denied" message.

    use [master]

    create database [CommServ] ON
    ( FILENAME = N'C:\Program Files\CommVault\ContentStore\Data\CommServ\cx_data1.mdf' ),
    ( FILENAME = N'C:\Program Files\CommVault\ContentStore\Data\CommServ\commserv_1.ndf' ),
    ( FILENAME = N'C:\Program Files\CommVault\ContentStore\Data\CommServ\commserv_2.ndf' ),
    ( FILENAME = N'C:\Program Files\CommVault\ContentStore\Data\CommServ\commserv_3.ndf' ),
    ( FILENAME = N'C:\Program Files\CommVault\ContentStore\Data\CommServ\commserv_4.ndf' ),
    ( FILENAME = N'C:\Program Files\CommVault\ContentStore\Data\CommServ\commserv_5.ndf' ),
    ( FILENAME = N'C:\Program Files\CommVault\ContentStore\Data\CommServ\cx_log1.ldf' )
    for attach
The content of the forums, threads and posts reflects the thoughts and opinions of each author, and does not represent the thoughts, opinions, plans or strategies of Commvault Systems, Inc. ("Commvault") and Commvault undertakes no obligation to update, correct or modify any statements made in this forum. Any and all third party links, statements, comments, or feedback posted to, or otherwise provided by this forum, thread or post are not affiliated with, nor endorsed by, Commvault.
Commvault, Commvault and logo, the “CV” logo, Commvault Systems, Solving Forward, SIM, Singular Information Management, Simpana, Commvault Galaxy, Unified Data Management, QiNetix, Quick Recovery, QR, CommNet, GridStor, Vault Tracker, InnerVault, QuickSnap, QSnap, Recovery Director, CommServe, CommCell, SnapProtect, ROMS, and CommValue, are trademarks or registered trademarks of Commvault Systems, Inc. All other third party brands, products, service names, trademarks, or registered service marks are the property of and used to identify the products or services of their respective owners. All specifications are subject to change without notice.
Copyright © 2020 Commvault | All Rights Reserved. | Legal | Privacy Policy