SQL Server Backup and Restore - Simple Talk

Chapter 7: Differential Backup and Restore
Advantages of differential backups
Perhaps the first question to answer is why we would want to capture only the changed
data in a backup; why not just take another full backup? The answer is simple: backup
time and backup file space utilization. A full database backup process, for a large database,
will be a time- and resource-consuming process, and it is usually not feasible to run this
process during normal operational hours, due to the detrimental impact it could have on
the performance of end-user and business processes. In most cases, a differential database
backup will contain much less data, and require much less processing time than a full
database backup. For a large database that is not subject to a huge number of changes, a
differential backup can execute in 10% of the time it would take for a full backup.
For a real-world example, let's consider one of my moderately-sized production databases.
The processing time for a full database backup is usually about 55 minutes. However,
the average differential backup takes only about 4 minutes to complete. This is great,
since I still have a complete set of backups for recovery, but the processing time is greatly
reduced. Remember that the larger a database, the more CPU will be consumed by the
backup operation, the longer the backup operation will take, and the greater the risk will
be of some failure (e.g. network) occurring during that operation.
The other saving that we get with a differential backup, over a full backup, is the space
saving. We are only storing the data pages that have been modified since the last full
backup. This is typically a small fraction of the total size, and that will be reflected in the
size of the differential backup file on disk. As such, a backup strategy that consists of, say,
one daily full backup plus a differential backup, is going to consume less disk space than
an equivalent strategy consisting of two full backups.
207