Skip to main content

I'm new to Commvault and SQL and could use some help. 

 

Our organisation is considering making the switch from native SQL server administration tools to CommVault's enterprise backup/recovery solution.

 

I gathered the following information from the change request: 

We use local backup Maintenance plan in SQL server. There is a native daily full backup scheduled at 6 p.m., as well as a transaction log backup scheduled every hour, with a retention of 7 days.  Management is planning on doing SQL backups (daily full + transaction log) using Commvault and will be disabling all native SQL backup jobs once Commvault backups are configured. At any point in time they do not want to overlap the transaction log backup scheduled between the two solution to avoid backup chain breaks. On CommVault side they are planning to do both Agent and VSA Appaware backups. They want to do high transaction db backups using agent and dev SQL DB backup using app aware to save on licensing cost.

 

I have a couple of questions about which I would like to educate myself and would appreciate your assistance in clarifying (request : can you please elaborate a bit) : 

1).Could someone please explain to me how the commvault backup differs from the native SQL backups; both full and transaction log backup?
 

2.) What exactly is a SQL backup chain? Is the log backup always linked to the full backups? is this different in native vs commvault? 

 

3.) How is App aware backup different from Agent based backup?

 

4.) What happens when we continue using native backups while Commvault backs it up?

 

5.) how long do companies typically keep transaction logs ( I was advised that in CV we will be doing daily fulls and will be retaining the data for 7 daily and 4 weekly, if it makes sense) ?

 

6.) Benefits of using commvault over Native backups?

 

Appreciate all your feedback and suggestions in advance.

 

@ShilpaN 

Hello 

See answers inline

 

1).Could someone please explain to me how the commvault backup differs from the native SQL backups; both full and transaction log backup?

-- Really the only main difference is the backup target. The Commvault backup run a backup database query or backup log in a similar fashion to native SQL backups. The only difference in this case since its appaware is the full will leverage the SQL VSS writer to freeze the DB during the full backup.
 

2.) What exactly is a SQL backup chain? Is the log backup always linked to the full backups? is this different in native vs commvault? 

-- Yes the logs are linked to the full and also dependent on the previous for restore. When restoring you must have the entire chain in tact to complete a restore.

 

3.) How is App aware backup different from Agent based backup?

-- Appaware leverage the SQL VSS writer to perform a vss snapshot of the DB to freeze the DB. Once that is complete the vsa job protects the entire VM including that vss snap. On restore it mounts the VM and extracts that vss snap for recovery. Tlog backups are still performed the same for appaware/agent based

 

4.) What happens when we continue using native backups while Commvault backs it up?

-- The log backups will attempted to convert to a full or in this case since its appaware skip the backup of those DBs. You should only run tlog backups in one solution/location

 

5.) how long do companies typically keep transaction logs ( I was advised that in CV we will be doing daily fulls and will be retaining the data for 7 daily and 4 weekly, if it makes sense) ?

-- Its all dependent on the business needs to restore to a point in time. Tlogs are required for point in time recovery. Its not uncommon to see a slightly shorter time for tlog backup then fulls but there are really no rules here.


Thank you @Scott Reynolds. I appreciate your quick response.

 

Sorry to bother you with a few follow-up questions. 

So Commvault uses the same query set to backup (same as native backups). So what makes commvault better than native backup tool?

 

How does agent-based backup work and how does it differ from appaware?
How do we decide which backup type to use -  agent or Appaware? 

 

Would performing more frequent transaction log backups have any effect on the performance of the SQL server or the Commvault components?
If we ask the customer, they will always want the most current backups, so we're trying to understand how we determine the frequency and what questions we ask the customer to determine that. 

 

Is there a tool we can use to forecast/ estimate the backup capacity requirements? 

 

Cheers!

 

 


@ShilpaN 

Commvault allows complete data management. You are not required for space on the server for native dumps, complete control and easy or use for scheduling/management of all SQL servers in the environment, ability to easily make copies, off site backups, aux copies, control retention, quickly restore to alternate servers, out of place, to disk location back into SQL on alternate servers, setup standby servers with live sync, complete dedupe and space savings of all backups across servers, etc just to name a few benefits.

 

Agent based backup performs leverages SQL API to perform a backup for similar to native backup, appaware uses vss on the full backup to perform a snapshot.

 

Generally no many customer run very frequent tlog backups on SQL servers they are generally very small and very quick and should not impact the SQL server. Its not uncommon to run tlog backup every 15min on critical databases. Some every hour or even just once a day on noncritical less active DBs. This depends on recovery time needs and activity of database.

There is no tool to estimate backup capacity. It would all depend on size of the database and change rate for the size of the tlog backups. It should be almost identical as how much space current native backups are using.

 


@Scott Reynolds  thanks heaps for providing this information. I'm more confident now that commvault will improve things.

 

Would I be able to perform all of the tasks below during a restore from both agent-based and Appaware backups?  are they any different to native restores?

  • Restore an entire database from a full database backup (a complete restore).
  • Restore part of a database (a partial restore).
  • Restore specific files or filegroups to a database (a file restore).
  • Restore specific pages to a database (a page restore).
  • Restore a transaction log onto a database (a transaction log restore).
  • Revert a database to the point in time captured by a database snapshot.

If the DBA insists on having a backup locally for some reason ( for quick recovery or better backup control). Would you recommend a file system backup or would a VM image backup suffice? (assuming I can browse and restore it at a file level using this image backup)

 

Excuse my silly questions :)


@ShilpaN  You can perform all of those restores with the exception of page level. There is an alternate option for table level restores that requires another option to be enabled. But unless you have a large database restoring to entire database out of place (example to another server or as a alternate database name to same server) would also be an option.

This is all documented here:

https://documentation.commvault.com/11.24/expert/18233_restore_sql_server_data.html

Table Level

https://documentation.commvault.com/11.24/expert/92238_recovering_sql_tables_from_recovery_point.html

 


Thank you so much, @Scott Reynolds , for your inputs. Helped me learn a lot!

 

I'll be working in the backup team for the next few months, and I'm eager to learn more about Commvault and other backup products we utilize. Have worked on a variety of platforms and have relied heavily on their communities to solve problems, and I'd like to say that this community is extremely active and knowledgeable. 

 

You can expect more questions from me as I progress through the process of learning backup solutions 🙂. Thanks again.
 


@ShilpaN 

Glad we could assist. This communities is a great resource, but also don't forget about official documentation and maintenance website as well for various info.

Best of luck to you!