SQL Server Backup and Restore - Simple Talk

Chapter 1: Basics of Backup and Restore
transactions. In such circumstances, the log records pertaining to an interrupted transaction,
or one for which the ROLLBACK command is explicitly issued, are read and the
changes rolled back.
In these ways, SQL Server ensures that, either all the actions associated with a transaction
succeed as a unit, or that they all fail, and so guarantees data consistency and integrity
during normal day-to-day operation.
Log backups and point-in-time restore
As we've discussed, each log record contains the details of a specific change that has been
made to the database, allowing that change to be performed again as a part of REDO, or
undone as a part of UNDO, during crash recovery. Once captured in a log backup file, the
log records can be subsequently applied to a full database backup in order to perform a
database restore, and so re-create the database as it existed at a previous point in time, for
example right before a failure. As such, regular backups of your log files are an essential
component of your database backup and restore strategy for any database that requires
point-in-time restore.
The other very important reason to back up the log is to control its size. Since your log
file has a record of all of the changes that have been made against it, it will obviously take
up space. The more transactions that have been run against your database, the larger
this log file will grow. If growth is left uncontrolled, the log file may even expand to the
point where it fills your hard drive and you receive the dreaded "9002 (transaction log
full)" error, and the database will become read-only, which we definitely do not want to
happen. We'll discuss this in more detail in Chapter 5.
27