Skip to main content
commvault.com commvault.com
Question

Moving file server from 3x daily backups to 1x daily vastly increased scan time?

  • August 31, 2023
  • 3 replies
  • 96 views
R
Novice
Forum|alt.badge.img+2

A few days ago, I created a new schedule policy for our Linux file server (which has about 377 TB of data), moving it from 3x daily incremental backups to 1x daily. Since then, the incremental backup job for this particular server has been in the “Scan” stage for 19 hours. The job does not appear to be hung, as the Job Update Time is updating regularly. Is switching the schedule associated with a subclient enough to prompt a rescan of everything? Is this normal behavior? Prior to this, the incremental backups would take between 3 and 7 hours.

 

    3 replies

    Rajiv
    Vaulter
    Forum|alt.badge.img+12
    • RajivVaulter
    • Vaulter
    • September 1, 2023

    Hello @rebajs 

    Has the data size changed or is there any change in number of files? How much data and number of files are being backed up after being in scan for 19 hours as compared to the 3 jobs earlier? Is there a difference? 

    Have you tried splitting the data into various subclients? 

    Best,

    Rajiv Singal

    R
    Novice
    Forum|alt.badge.img+2
    • rebajsNovice
    • Author
    • Novice
    • September 1, 2023

    Hi @Rajiv 

    Yes, it’s guaranteed that the data size changed and new files were added. The backup job did end up finishing after 28 hours, which a final application size of 10.21 TB. The previous jobs were much smaller, but we did have a 19.8 TB job finish earlier in the week after 15 hours.

    We have our Linux FS split into two subclients, currently.

    I’m not really sure why this particular incremental took so long (I have ideas) but I guess I’m no longer worried since it did eventually finish.

    Thanks!

     

    SparshGupta
    Vaulter
    Forum|alt.badge.img+10
    • SparshGuptaVaulter
    • Vaulter
    • September 4, 2023

    Hi @rebajs 

     

    Altering the schedule should have no effect on the scan time.

     

    Posting few questions below -

     

     

    #1 - Are the subclients utilizing Filesystem-based backups (recursive / optimized scan) or intellisnap or block level technologies?

     

    #2 - In the case of the incremental job in question being classified as a trueup job or a reconcile backup operation, it's expected for this particular job to take longer due to the additional operations carried out to ensure file synchronization between the index and client.

     

    #3 - Could you please provide the FileScan logs from the client for both of the jobs in question (the one that took 3-7 hours and the one that took 15 hours)? This will allow us to conduct a detailed analysis and draw out a comparison.

     

     

    Moreover, if you have a substantial number of folders, you can consider enabling the "Folder Level Multithreading" property at subclient level to further reduce the scan time.

     

     

    Thanks,

    Sparsh

    Terms & ConditionsCookie settingsAccessibility statement