Accidentaly deleted LUN (Mount Path)

Last post 05-24-2019, 11:12 PM by Wwong. 1 replies.
Sort Posts: Previous Next
  • Accidentaly deleted LUN (Mount Path)
    Posted: 05-23-2019, 4:58 AM

    Hello Everybody


    Let's assume a situation when:

    1) Customer created a LUN and configured it as a Mount Path extending current Disk Library with brand new MP

    2) Customer ran only a few backup that went through this Mount Path

    3) Customer accidentaly deleted this LUN from OS side

    4) There are no secondary copies


    What's it's the best way to clear out this situation? Of course assuming that some backups needs to be deleted and due to deduplication nature some jobs that went to affected Mount Path can have shared blocks with other Mount Paths within same Disk Library.

    By default such unpresent Mount Path/LUN will be automatically marked as disabled/offlined in CommCell Console. Manually deleting jobs that went to this MP is possible, but deleting such MP is not allowed as it's used for dedup store previously even if such MP is completely lost and there is no way to take it back to life.

    So... how to clean environment after such disaster without sealing the store? Of course we assume that it will be disruptive and some backups will be definetely lost (not only these logically resided on affected LUN). I cannot find any related documentation/KB.


    Kind regards,


  • Re: Accidentaly deleted LUN (Mount Path)
    Posted: 05-24-2019, 11:12 PM

    Hi eMF

    In V11 SP14, Commvault has introduced a new feature under the Mount Path setting in "Allocation Policy" -> Prevent data block references for new backups

    "When selected, the deduplicated blocks in the mount path will not be referenced when there are multiple mount paths in the library. (Choose this option if you plan to retire the mount path.)"

    Documentation -

    The above purpose also works when you have losted the backend storage of the Mount Path. 

    By selecting the Option, you will inform Commvault to not reference Blocks on the Lost Mount Path, and Commvault will write new reference to other existing Mount Path. 

    Depending on the Scenario:

    • If the Mount Path was lost within 1-2 days, then you would be aware of majority of the impacted Jobs, and can mark them as Bad and let it age out naturally. 
    • If this happened for a very old mount path, then enable this option run DDB Verification and figure out all the impacted Jobs. but moving forward new signature will reference the online Mount Paths.
    By doing the above over time the Deduplication Association will be released from the Mount Path, and then you can gracefully remove it, without needing to seal the DDB and rebaseline. 
    Hopefully that helps 
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