SQL Backup

Blog Dive: SQL Protection with DPM

by

Background for this post

Since version 2006 DPM has been able to protect SQL databases. Often in environments that are using DPM I still see they are using DPM for backup of all workloads but not using it for SQL backups. There are reasons for this such as a lack of understand of how DPM protects SQL or lack of trust in DPM to protect SQL. The goal of this blog post is to lay out why you would want to use DPM to backup SQL, what SQL versions and functionality (such as AlwaysOn) are supported, what happens under the hood when DPM protects SQL and that you can use DPM as your sole solution for protecting SQL. This is an effort to convince those that don’t use DPM for SQL Backups today to start using it or those that don’t trust DPM for SQL backups that it is a great option to consider. This blog post is targeted directly at DBA’s or DPM admins that need to give information about SQL protection to their DBA’s.

One major challenge I had when I set out to write this blog post is that I am not a DBA or a SQL expert. So I don’t have any SQL “street cred” so I needed to fully understand what a SQL DBA would require to ok DPM being the sole backup solution for SQL in an organization.

I have the fortunate opportunity to work with an awesome SQL MVP named Jes Borland at Concurrency. As a part of my research for this blog post I reached out to Jes Borland to have a discussion around SQL protection. One of the important questions I asked her was “What things do you look for in a SQL backup solution?“. Her response was “What I look for in a backup tool: the ability to do all types of SQL Server backups – full, differential, log, copy-only. Ability to take advantage of built-in backup compression.” as well as “As a DBA, my main question is, “How do I restore?“. This was perfect as they are key things I should look out for to make sure DPM can do.

Now that we covered the background let’s look at what DPM can do when it comes to SQL protection.

Why would you want to use DPM to backup SQL?

  • DPM understands SQL and was designed to protect the advanced configurations of SQL.
  • DPM can protect SQL up to every 15 minutes.
  • Reduce potential conflicts between backup tools and schedules of SQL protection.
  • DPM can protect SQL at the instance level or the database level. When protection at the instance level is turned on DPM will detect new databases on that instance and automatically add them to protection.
  • DPM is an affordable option for protecting SQL. It is a good fit for small SQL shops and can scale for large enterprise SQL shops.
  • DPM has self-service recovery of SQL databases using the Self-Service Recovery Tool (SSRT) that can be extended to DBA’s.

What SQL versions and functionality does DPM support?

Versions:

  • 2005
  • 2008
  • 2008 R2
  • 2012
  • 2014

Functionality:

SQL Clustering

When protecting a SQL cluster DPM is cluster aware. DPM is aware of the clusters identity as well as the nodes in the cluster. In a SQL clustering scenario if the SQL Server is changed to a different node, DPM will continue to protect the clustered SQL without any intervention from backup administrators.

SQL Mirroring

If the SQL you are protecting is mirrored DPM is aware of the mirrored databases and will protect the shared data set properly.

SQL Log shipping

In scenarios when SQL log shipping is being used DPM will automatically discover that log shipping is being used and DPM will auto-configure itself to co-exist ensuring proper SQL protection.

SQL AlwaysOn

When protecting SQL AlwaysON DPM will automatically detect Availability Groups and detects when a failover occurs and will continue protection of the database.

What happens under the hood with SQL protection in DPM?

Protection:

When SQL protection is first setup an express full copy of the database is created and this is the initial backup of the database. Express full backups bring over block level changes of the databases themselves. This would be the entire database on the very first backup.

Express full backups leverage a filter technology. This filter technology is what identifies changed blocks instead of needing to read all of the data or use checksums. This filter technology is known as volume shadow services (VSS). Specifically the SQL Server VSS Writer is used during SQL protection. This does two things: DPM backup of SQL will not impact databases and it will only backup changed blocks after the initial backup of the database reducing the storage footprint. Backing up the block level changes also has a significantly lower impact of the protected server during backup.

After the initial backup of the SQL database DPM will perform subsequent express full backups and synchronizations between the express full backups. Synchronizations copy over SQL Transaction logs. A recovery is possible from both an express full and synchronization backups.

DPM can be set to protect SQL databases as often as every 15 minutes so that you can have frequent protection of SQL throughout a day. As a part of the DPM SQL protection recovery points are created for each incremental synchronization and express full backup. DPM can maintain up to 512 shadow copies of a full SQL Server database(s) by storing only the differences at the block level. In a scenario where you have one express full backup per week, stored as one of 512 shadow copy differentials between one week and the next, plus 7 days x 24 hours x 4 (every fifteen minutes), DPM would have over 344,000 recovery points (what you restore from) of SQL.

The following screenshot is an example of SQL protection in DPM. The top half in red shows an example of auto protection of SQL at the instance level while the lower half in blue is an example of individual database protection.

clip_image001

Truncating SQL logs:

DPM does truncate the SQL transaction logs as a part of the backup process. DPM truncates the logs (creates empty space inside the transaction log) after each synchronization.

Note that if the synchronization is set to a long window of time such as 12 hours the transaction log could grow to large for truncating and will need to be shrunk. So general rule is to keep the synchronization’s closer together.

To shrink the SQL transaction logs this needs to be done manually or using a SQL Maintenance job. This could always be done using a Pre-Backup/Post-Backup script.

Now if “Just before a recovery point” is selected in the protection group then the synchronization (incremental backup) will not be scheduled to run. Configuring this way tells DPM that only express full backups should run. Transaction logs will not be truncated by DPM in this scenario.

Recovery:

A good friend of mine System Center MVP Robert Hedblom always says “backup is about the restore”. I subscribe to the same principle in that “restore should always be the focus of any backup solution”. In a disaster recovery situation DPM can be used to restore from a loss of the database down to within 15 minutes of the failure. DPM can recover the database to original instance, a separate instance to a folder, or even copy to a tape. You can see those options reflected in the following screenshot:

clip_image002

When recovering to original SQL instance or a alternate SQL instance you can specify what state you want to leave the database in. Restoring the database in a non-operational state will allow you the ability to restore transaction logs in addition to the database restore.

clip_image003

You also have the option to specify where you want to place the database files (.MDF) and log files (.LDF) during the restore.

clip_image004

The DPM Self-Service Recovery Tool (SSRT) can be deployed on the client computers of the DBA/s. When recovering a database using the SSRT the experience is much like it is when recovering directly from DPM. When the New Recovery Job button is clicked a Recovery Wizard window will open with the same options as recovering directly from DPM. A screenshot of the SSRT shown below displays the UI with a restore job that has completed.

clip_image005

Details of a recovery job in the SSRT are shown in the following screenshot.

clip_image006

Hopefully this article has shed some light on SQL protection with DPM and will help you consider using DPM to protect your SQL instances/databases. For further information on SQL protection with DPM visit the following links on TechNet:

Read more