SQL Server Backup and Restore - Simple Talk

Restoring Databases
Chapter 1: Basics of Backup and Restore
Of course, the ultimate goal of our entire SQL Server backup strategy is to prepare
ourselves for the, hopefully rare, cases where we need to respond quickly to an emergency
situation, for example restoring a database over one that has been damaged, or creating
a second copy of a database (see http://msdn.microsoft.com/en-us/library/ms190436.
aspx) in order to retrieve some data that was accidentally lost from that database. In
non-emergency scenarios, we may simply want to restore a copy of a database to a
development or test server.
For a user database operating in FULL recovery model, we have the widest range of
restore options available to us. As noted throughout the chapter, we can take transaction
log backups and use them, in conjunction with full and differential backups, to restore a
database to a specific point within a log file. In fact, the RESTORE LOG command supports
several different ways to do this. We can:
• recover to a specific point in time – we can stop the recovery at a specific point in time
within a log backup file, recovering the database to the point it was in when the last
transaction committed, before the specified STOPAT time
• recover to a marked transaction – if a log backup file contains a marked transaction
(defined using BEGIN TRAN TransactionName WITH MARK 'Description…')
then we can recover the database to the point that this transaction starts (STOPBE-
FOREMARK) or completes (STOPATMARK)
• recover to a Log Sequence Number – stop the recovery at a specific log record,
identified by its LSN (see Chapter 6, Log Restores).
We'll cover several examples of the first option (which is by far the most common) in this
book. In addition, we can perform more "granular" restores. For example, in certain cases,
we can recover a database by restoring only a single data file (plus transaction logs), rather
than the whole database. We'll cover these options in Chapters 9 and 10.
46