Incrementals after Synthetic Full taking longer time than the rest

Last post 03-20-2019, 7:56 AM by alligator89. 2 replies.
Sort Posts: Previous Next
  • Incrementals after Synthetic Full taking longer time than the rest
    Posted: 03-13-2019, 9:58 AM

    Where can i read about how the synthetic full backups work?

    Also I had noticed that any incremental backups which are running after a synthetic full runs longer

    For ex: on Friday there was a synthetic full job (Incremental ran before Synth Full) suppose it took 2 hours

    On Mondays incremental backup would take 3+ hours, even if the data backed up (Size of application/ Data written is less compared to other incrementals.) What could be the reason for this.

  • Re: Incrementals after Synthetic Full taking longer time than the rest
    Posted: 03-15-2019, 7:18 PM

    Hi alligator89

    Synthetic Full in the simpliest manner, is a consolidation backup of the previous full and the incremental which has ran after the last full.

    The incremental are still separate to the Synthetic Fulls, and incremental could take longer for various reasons (network, read, write or deduplication/compression). Load could also be an issue. 

    If you want to narrow down the slowness, a review of the CVPerfMgr.log would help in identifying which hop in the Backup process is causing the slowness. 

    Hopfeully that helps 



  • Re: Incrementals after Synthetic Full taking longer time than the rest
    Posted: 03-20-2019, 7:56 AM

    Hello Winston

    Thanks alot for the response.

    We opened a case with support and they did some analysis

    We did an SP upgrade to SP12 recently , post which the incremental started to scan huge number of files. Because of a new feature called true up (Synchronizing Data on the Disk and the Index) (this was introduced in SP10)


    The incremental was taking longer time due to this issue



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