Commvault Library Space issue

Last post 12-07-2017, 6:26 AM by Yemble. 3 replies.
Sort Posts: Previous Next
  • Commvault Library Space issue
    Posted: 12-06-2017, 9:43 AM

    Hello all,

    We have an issue with our library at the moment.

    The library has a total capacity of 72.21 TB.

    We checked the disk usage of the library we get:

    Data Written : 45.52TB

    Free Space : 2.95 TB

    If we sum the data written and the free space we get 48.47 of total space.

    Since our library has 72.21TB we miss around 23TB.

     

    Does anyone know how can i reclaim this space?

    We have already suspend all activity and run data aging without sucess.

    We have already check for Orphaned Jobs and Orphaned Data.

     

    Any ideas on where to look or what we can do?

     

    Regards,

    Stg

  • Re: Commvault Library Space issue
    Posted: 12-06-2017, 12:50 PM

    Have you sealed any dedup databases? That data remains until it ages so that may be where the space is hiding.

  • Re: Commvault Library Space issue
    Posted: 12-06-2017, 1:01 PM

    Hello, 

    Thanks for your awnser Tom.

    We have 2 Dedup databases and none is sealed.

    Any other ideas?

     

    Regards,

    Stg

  • Re: Commvault Library Space issue
    Posted: 12-07-2017, 6:26 AM

    Stg:

    Hello, 

    Thanks for your awnser Tom.

    We have 2 Dedup databases and none is sealed.

    Any other ideas?

     

    Regards,

    Stg

    Yes, I have come across this behaviour loads of times AND I have devised a method to work around it in our environment.

    The issue only seems to affect mainly de-duped database library data and has the effect, over time, of consuming much more physical library space than can be accounted for.  My suspicion is that this is due to the back-end storage device not supporting "hole drilling", which is a process that Simpana attempts to use during DataAging, to release library space.  Hole drilling attempts to release space within chunk files back to the free pool, however, in practice, when Hole Drilling is not supported, ONLY when the deleted data blocks are at the end of the file, will that space be actually released.  If it cannot be released, it is marked for some future deletion when all subsequent blocks within the file have, themselves, been deleted.  In short, this is a fragmentation issue.

    My strategy for reclaiming this lost library space involves:

    1) demoting all associated SP primary copies to secondary

    2) deleting the primary DDB and all associated library data

    3) re-creating the primary DDB from scratch

    4) re-populating the primary DDB from the secondary DDB via AuxCopy

    5) promoting all associated SP secondary copies back to primary

    This can be time consuming depending upon the nature of the data, however, the results can be quite staggering as it often releases many Tb of physical library space back to the pool.  Note that this procedure can only work if all of your SPs have both Primary and Secondary copies targetting different storage appliances.  Both copies need to be in-sync before any demotion/promotion is attempted.

    For me, this is a proven method that I have used on many occassions to recover from imminant library capacity issues.  The only downside is that you lose any DR protection whilst this procedure is in place, but this is a calculated risk.

    I should point out that we run a completely tapeless environment, with our libraries located on very large enterprise NAS appliances.  This procedure may, or may not, work well with tape!

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