Retiring mount paths/DDb implications

Last post 10-18-2019, 4:54 AM by mynameisNeil. 4 replies.
Sort Posts: Previous Next
  • Retiring mount paths/DDb implications
    Posted: 08-19-2019, 7:46 AM

    Hi,

    I wonder if someone could help me with a scenario, please.

    I am planning to retire some mount paths from a disk library. They are on old legacy hardware that is liable to fail. I have V11SP12.

    On these mount paths I want to retire there is a mix of both long and short term data.

    Short term data I will let age out once the mountpaths are disabled.

    Long term data will have a new selective copy created and I will force this to go to new mount paths so in theory I will not need the selective copies on the disabled mount paths anymore. The new selective will have a new DDB (DDBSel2) configuring so in theory all selective copies will be protected now on a new DDB and on new mount paths.

    The original selective copy (on the disabled mountpaths) was from a remote site and uses the same DDB (DDBPri/Sel)  as the primary short term copies on this site, so that DDB is used by two copies. This means I need to keep this DDB active once the long term data has been dealt with so that the primary copies still have their existing DDB.

    My concern is that there will be data on the disabled mountpaths that is referenced by the DDB (DDBPri/Sel) that I need to leave active. I don't know the best process to follow to ensure all references for the primary copy will be on the active mountpaths.

    Should I go through and force deletion of all jobs on the disabled mountpaths? Short term should be gone anyway and long term copied so in theory I'm covered? Must I remove the mount paths from the library?

    Has anyone any experience in this, please? Have I explained it well enough? I don't know if there are things I am not considering.

    Thanks very much,

    Neil.

  • Re: Retiring mount paths/DDb implications
    Posted: 08-19-2019, 8:26 AM

    Hi neil

    From SP14 onwards Commvault has introduced a feature on the Mount Path (after selecting "Disable new Mount Path for writes") an additional Check box "Prevent data block references for new backups"

    The purpose is to allow end-user to eventually decommission these Mount Path, once all association is gone

    https://documentation.commvault.com/commvault/v11/article?p=9203.htm

    Regards

    Winston

  • Re: Retiring mount paths/DDb implications
    Posted: 10-17-2019, 4:02 AM

    Hi Winston, thanks for the reply and sorry for the delay. We didn't have that option before but now have upgraded to SP15 so that is the method I am using.

    I'll let you know how I get on.

    Is there a way to check that the DDB references are being updated ahead of finally removing the mount path from the library?

    Thanks again,

    Neil.

  • Re: Retiring mount paths/DDb implications
    Posted: 10-17-2019, 8:10 PM

    Hi Neil

    Once all the Jobs are disassocaited from the Mount Path, you will see the following 

    At this point you will still need to engage support to provide a script to safely decommission the Mount Path

    Keep me posted on how you go

    Kind regards

    Winston 

  • Re: Retiring mount paths/DDb implications
    Posted: 10-18-2019, 4:54 AM

    Great, thank you for that. I shall indeed post an update.

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.
Close
Copyright © 2019 Commvault | All Rights Reserved. | Legal | Privacy Policy