SQL Server Backup and Restore - Simple Talk

Chapter 7: Differential Backup and Restore
differential restore on the target server, which also takes only 10–15 minutes to complete,
and we are back online and running.
We have successfully completed the migration, and the down-time has decreased from a
miserable 12 hours to a scant 30 minutes. There is a bit more preparation work to be done
using this method, but the results are the same and the uptime of the application doesn't
need to take a significant hit.
Possible issues with differential backups
In most cases in my experience, the potential issues or downsides regarding differential
backups are just minor inconveniences, rather than deal breakers, and usually do not
outweigh the savings in disk space usage and backup time, especially for larger databases.
Invalid base backup
The biggest risk with differential backups is that we come to perform a restore, and find
ourselves in a situation where our differential backup file doesn't match up to the base
backup file we have ready (we'll see this in action later). This happens when a full backup
is taken of which we are unaware. Full database backups are taken for many reasons
outside of your nightly backup jobs. If, for example, someone takes a full backup in order
to restore it to another system, and then deletes that file after they are done, our next
differential is not going to be of much use, since it is using that deleted file as its base.
The way to avoid this situation is to ensure that any database backups that are taken
for purposes other than disaster recovery are copy-only backups. In terms of the data it
contains and the manner in which it is restored, a copy-only backup is just like a normal
full backup. However, the big difference is that, unlike a regular full backup, with a
copy-only backup, SQL Server's internal mechanism for tracking data pages changed
since the last full backup is left untouched and so the core backup strategy is unaffected.
212