SQL Server Backup and Restore - Simple Talk

Chapter 2: Planning, Storage and Documentation
The scheduling of differential backups will vary widely, depending on their role in the
backup strategy. For a VLDB, we may be taking differential backups every night, except
for on the night of the weekly full backup. At other times, we may run differential
backups at random times during the day, for example as a way to safeguard data before
performing a large modification or update.
Transaction log backups are, in general, much less CPU- and I/O-intensive operations
and can be safely run during the day, alongside the normal database workload. In fact,
there isn't much point having a transactional backup of your database if no one is actually
performing any transactions! The scheduling of log backups may be entirely dictated by
the agreed SLA; if no more than five minutes of data can be lost, then take log backups
every five minutes! If there is some flexibility, then try to schedule consecutive backups
close enough so that the log file does not grow too much between backups, but far
enough apart that it does not put undue stress on the server and hardware.
As a general rule, don't take log backup much more frequently than is necessary to satisfy
the SLA. Remember, the more log backups you take, the more chance there is that one
will fail and possibly break your log chain. However, what happens when you have two
databases on a server that both require log backups to be taken, but at different intervals?
For example, Database A requires a 30-minute schedule, and Database B, a 60-minute
schedule. You have two choices:
1. create two separate log backup jobs, one for DB_A running every 30 minutes and one
for DB_B, every 60 minutes; this means multiple SQL Agent / scheduled jobs and
each job brings with it a little more maintenance and management workload
2. take log backups of both databases using a single job that runs every 30 minutes;
you'll have fewer jobs to schedule and run, but more log backup files to manage,
heightening the risk of a file being lost or corrupted.
My advice in this case would be to create one log backup job, taking log backups every
30 minutes; it satisfies the SLA for both databases and is simpler to manage. The slight
downside is that the time between log backups for databases other than the first one in
74