SQL Server Backup and Restore - Simple Talk

Chapter 5: Log Backups
When determining a backup strategy and schedule for a given database, one of the
major considerations is the extent to which potential data loss can be tolerated in the
event of an errant process, or software or hardware failure. If toleration of data loss is,
say, 24 hours, then we need do nothing more than take a nightly full backup. However,
if exposure to the risk of data loss is much lower than this for a given database, then it's
likely that we'll need to operate that database in FULL recovery model, and supplement
those nightly full backups with transaction log backups (and possibly differential database
backups – see Chapter 7).
With a log backup, we capture the details of all the transactions that have been recorded
for that database since the last log backup (or since the last full backup,if this is the firstever
log backup). In this chapter, we'll demonstrate how to capture these log backups
using either the SSMS GUI or T-SQL scripts. However, we'll start by taking a look at how
space is allocated and used within a log file; this is of more than academic interest, since
it helps a DBA understand and troubleshoot certain common issues relating to the transaction
log, such as explosive log growth, or internal log fragmentation.
Capturing an unbroken sequence of log backups means that we will then, in Chapter 6,
be able restore a full backup, then apply this series of log backups to "roll forward" the
database to the state in which it existed at various, successive points in time. This adds
a great deal of flexibility to our restore operations. When capturing only full (and differential)
database backups, all we can do is restore one of those backups, in its entirety.
With log backups, we can restore a database to the state in which it existed when a given
log backup completed, or to the state in which it existed at some point represented within
that log backup.
144