Defragging the MA drives

Last post 10-06-2010, 5:52 PM by barry.quiel. 4 replies.
Sort Posts: Previous Next
  • Defragging the MA drives
    Posted: 10-04-2010, 10:38 PM

    Hi All

    Guys whats the recommendation for the timing of an initial defrag of our Media Agent drives?  I just just got Diskeeper on it it and its shown that our LUNs are fragmented to hell (usual for de-duped data apparently), so i need to do an initial defrag on them, afterwhich diskeeper should keep them tidy.  But when to do this initial defrag?

    1) Im thinking of defragging during the day only, for obvious reasons, when backups are not running.

    2) do i need to stop the MA services when defragging these?

    3) is it safe to defrag the disk which has the DDB on it?   or only defrag the disks which have backup data on?



  • Re: Defragging the MA drives
    Posted: 10-05-2010, 9:08 AM
    • mort is not online. Last active: 01-13-2016, 10:37 AM mort
    • Top 50 Contributor
    • Joined on 07-06-2010
    • Patrick
    • Adept
    • Points 209

    Would defragging give any advantage? 

    If it's de-duped data it will be read in a completely random manner regardless of where it is on physical disk, as I think commvault stores the data in 2Gb Files but indexes them as smaller blocks of data so a given backup/restore will be accessing data from multiple chunks.  As always I could be completely wrong and if so would love to know...and start defragging my own de-duped stores

    Are there any benchmarks or statments from commvault regarding this?

  • Re: Defragging the MA drives
    Posted: 10-05-2010, 11:04 AM


    Good Morning SSSSTEW,

    I would recommend to defrag the magnetic library that the deduplication data is writing to especially if you are using aux copies. Deduplication scatters the data throughout the disk and has many references pointing  to previously written data. when an aux copy or restore is performed this data has to be rehydrated before the operation can be completed. If the disk is heavily fragmented then this rehydration process can take a performance hit.

    Defrag the DDB drive.

     I would not recommend performing doing a defrag on the DDB drive its self with the services running. If you going to run a defragmentation utility then make sure the services are stopped and the SIDB or SIDB2 process is not running. This will eliminate any possibility of DDB corruption.




  • Re: Defragging the MA drives
    Posted: 10-05-2010, 6:39 PM

    OK great thanks Aaron.

    Mort - this came about from another thread on here which people had poor performance and found defragging helped.  I also got recommended to defrag by a SE, and i think its somewhere on books online but cannot find the reference now.

  • Re: Defragging the MA drives
    Posted: 10-06-2010, 5:52 PM

    Or you could not use windows as a media agent.  NTFS is one of the worst file systems ever created.  I won't give you all the gory details, but lets just say a windows box with 20GB of RAM ( plenty for FS cache ) on a 2TB empty file system could not even write a 2MB file contiguously.


    We switched from a windows MA to a linux MA ( fedora 12 ) and got a 30% performance increase on the same hardware without doing any file system optimization.  It would also allow you to chose a file system that is designed not to frament in the first place ( most of the newer filesystems have a file pre-allocation setting ).

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