SQL backups and DDB Verification job

Last post 07-11-2018, 11:48 AM by wsimps01. 3 replies.
Sort Posts: Previous Next
  • SQL backups and DDB Verification job
    Posted: 07-09-2018, 10:44 AM

    Ok so kind of an odd two part question. I'll try to articulate my thoughts.

    1. SQL backups

    We have several SQL servers and currently they are using our default Storage Policy which is

    30 days, Extended Retention monthly for one year.

    The SQL transaction logs backup every 15 minutes

    Differntial backups run weekly

    Full backups run weekly

     

    2. So when our DDB Verification job runs it shows a 1378891539 Total blocks to process. I am assuming because the SQL transaction jobs run every 15 minutes (several SQL servers) that each job contains blocks the DDB verification must process. 

     

    Would altering the frequency of the tlog backup help reduce the block count?

    I am having a meeting with our SQL admin to discuss the required frequency of the backups but I want to ensure I present valid points and not my thoughts.

    Thanks in advance.

  • Re: SQL backups and DDB Verification job
    Posted: 07-10-2018, 3:09 PM
    • efg is not online. Last active: 11-20-2018, 9:09 AM efg
    • Top 10 Contributor
    • Joined on 02-02-2010
    • CommVault Tinton Falls NJ
    • Expert
    • Points 1,568

    I'm more of an applications person (DBs and such) so I'm not sure about the DDB verification... BUT it sounds almost like you have the log backups going to the same storage policy (With DDB enabled) as the database backups.   This is generally not recommended as logs are fairly unique and have very low deduplication ratios.   Most environments I've seen use one policy with deduplication for the database backups, and another non-deduplication policy with compression enabled for the log backups.

    It may be something you might want to consider.

    As far as the frequency of the log backups, that depends on your RPO and SLA requirements.

    There is also an option to back up SQL logs to a local folder first before backing up to Commvault to reduce the number of jobs on the commserve and client.   Here is a link to the documentation on how to configure this feature:

    Backing Up SQL Transaction Logs Without a CommServe Connection

    Let us know if this helps...


    Ernst F. Graeler
    Product Specialist
    Applications and File Systems
  • Re: SQL backups and DDB Verification job
    Posted: 07-11-2018, 11:47 AM

    You are absoluetly correct. Upon spinning up our environment we heard repeatedly that less is best and so we have had the SQL backing up via our 'standard' Policy which does use global dedupes databases, long term retention and an aux copy.

    I am leaning towards a new Storage policy (non Dedupe) for the transaction logs only. Leaving the Differential and Full backups in the current Storage policy. Am I understanding you correctly in that you have just the tlogs in a separate policy?

    Our DBA guy is phenomonial and is easy to work with and understands our concerns so that helps out a lot!

    Thanks for the confirmation and your valued insight. It did help and I'll review the link you provided.

  • Re: SQL backups and DDB Verification job
    Posted: 07-11-2018, 11:48 AM

    You are absoluetly correct. Upon spinning up our environment we heard repeatedly that less is best and so we have had the SQL backing up via our 'standard' Policy which does use global dedupe databases, long term retention and an aux copy.

    I am leaning towards a new Storage policy (non Dedupe) for the transaction logs only. Leaving the Differential and Full backups in the current Storage policy. Am I understanding you correctly in that you have just the tlogs in a separate policy?

    Our DBA guy is phenomonial and is easy to work with and understands our concerns so that helps out a lot!

    Thanks for the confirmation and your valued insight. It did help and I'll review the link you provided.

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