Why DPM 2010 and SQL are Better Together?

Non-Microsoft backup solutions tend to take generic backup functionality and adapt it to support-specific applications. In contrast, Microsoft created DPM 2010 to leverage fully supported Microsoft technologies in order to provide near-continuous data protection including Windows Server hosts running Microsoft SQL Server 2005, 2008 and 2008 R2. This support includes:

SQL Instance-level protection

Data source co-location, which allows a DPM server to protect over 2,000 databases
Database Administrator Self-Service Recovery

Backup for SQL Server high availability database configurations
Data recovery at database level

Better protection for SQL Server with DPM

DPM 2010 is engineered to provide the best possible protection for SQL Server. In fact, the team that built DPM 2010 worked in consultation with the team that built SQL Server to ensure that SQL Server workloads are reliably protected.

DPM 2010 seamlessly interacts in the following ways with the SQL Server VSS writer to capture consistent versions of an SQL deployment without interrupting access databases:

A baseline copy of the SQL Server data can be made using either the DPM block-level synchronization engine or can be done manually.
Express full backups are captured. These backups use the SQL Server VSS writer and DPM agent to identify which blocks have changed in the database and then forward those changed blocks to the DPM server.
Database transaction logs are synchronized with the DPM server as frequently as every 15 minutes between express full backups. DPM synchronizes the log files using a VSS incremental operation.
Best practice is to configure express full backups every evening and more often for transaction log synchronization (between every 15 to 60 minutes).

Best Practices when backup SQL with DPM 2010

Here are some basic best practices for managing data with a DPM 2010 deployment:

With DPM 2010 you need to configure at least one Express Full Backup per day. The Express Full Backup backs up the database and log files and then truncates the log files, while still replicating only the changed blocks from the production server.
When protecting more than one copy of a database (such as when you are protecting mirrored databases) you should configure one node for full backups and the rest as copy backups. Copy backups do not truncate log files.
If the SQL Server node hosting the copy of a highly available database on which the Full Backup is taken goes down temporarily, it is not necessary to perform any steps on the nodes on which copy backups are taken. If it becomes necessary to switch to another node because the failed node will no longer be available, you need to reconfigure DPM to take a full backup of the new target node.