Mark a job bad

Last post 06-13-2018, 8:54 AM by ApK1. 5 replies.
Sort Posts: Previous Next
  • Mark a job bad
    Posted: 06-13-2018, 3:56 AM

    Hi all.

     

    Using Dedub in our environment.

     

    At the moment we have a restore test of a server which fails because of a bad chunk, and when making tests on other servers, these servers also fails the restore because of this bad chunk.

    So this chunk has many references to many different backup jobs.

    If I mark the job bad, because of the unreadable chunk, would a new chunk be created with valid data after a new backup has run? Would I then be able to do a successful restore or what would happen if I mark a job bad?

     

    Regards

    -Anders

  • Re: Mark a job bad
    Posted: 06-13-2018, 5:49 AM

    Hi Anders

    When a chunk is impacted due to corruption or other storage related issue, when we run a Data Verification from Commvault, the purpose is to identify all the associated jobs to that chunk and mark those jobs as bad. 

    Ok so the purpose of marking jobs as bad, is so the next Backup it will enjoy try to reference corrupted chunk and write new baseline references. The purpose is to future proof your latest backup without it referencing corrupted data. 

    However that does not ensure that the new data that is written down, will help resolve old backup that is referenced to the old chunk. Note - each job has associated chunks and archive file, new archive file won't be necessarily helpful in resolving your corruption issue. 

    The recommendation for all corruption on Storage level, the root cause needs to be addressed to ensure the integrity of the Backup data. 

    I.e. corruption could be due to application, OS, Network or Storage, so as an additional recommendation it is also good to have secondary copy, so you will have two set of backup rather then just one. 

    Hopefully that helps

    Thank you 

    Winston

  • Re: Mark a job bad
    Posted: 06-13-2018, 8:28 AM

    Hi Anders,

     

    Essentially, what Winston is trying to say is that Commvault has built in mechanisms in place to mark block bad when Data Verification jobs run. This could be a job based on against a storage policy or an entire DDB verification.

     

    Both processes can mark blocks bad when encountered however it will not help existing jobs that already reference this bad block. The Data Verification process will allow future jobs to stop referencing this bad block.

     

    Also underlying environmental issues needs to be identified as to why blocks are becoming bad as not all faulting conditions will trigger Data Verification to mark the block bad.

     

  • Re: Mark a job bad
    Posted: 06-13-2018, 8:38 AM

    Hi Guys.

     

    Thanks for your reply.

     

    So when the block is marked as bad, would it be aged out or would it remain until the ddb is sealed?

     

    Thanks

    -Anders

  • Re: Mark a job bad
    Posted: 06-13-2018, 8:43 AM

    Hi Anders,

     

    The blocks that are marked bad would eventually age out once the jobs referencing it all age. This bad block wouldn't be increasing in references since it's been marked bad so new jobs does not reference against it.

  • Re: Mark a job bad
    Posted: 06-13-2018, 8:54 AM

    Makes sense... :-)

     

    Thanks for clarification.

     

    Regards

    -Anders

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