30.06.2013 Views

SQL Server Backup and Restore - Simple Talk

SQL Server Backup and Restore - Simple Talk

SQL Server Backup and Restore - Simple Talk

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Chapter 1: Basics of <strong>Backup</strong> <strong>and</strong> <strong>Restore</strong><br />

Therefore, the full transaction "history" can be captured into a backup file by backing up<br />

the transaction log. These log backups can then be used as part of a database RESTORE<br />

operation, in order to roll the database forward to a point in time at, or very close to,<br />

when some "disaster" occurred.<br />

The log chain<br />

For example, consider our previous scenario, where we were simply taking a full database<br />

backup once every 24 hours, <strong>and</strong> so were exposed to up to 24 hours of data loss. It is<br />

possible to perform differential backups in between the full backups, to reduce the risk of<br />

data loss. However both full <strong>and</strong> differential backups are I/O intensive processes <strong>and</strong> are<br />

likely to affect the performance of the database, so they should not be run during times<br />

when users are accessing the database.<br />

If a database holds business-critical data <strong>and</strong> you would prefer your exposure to data<br />

loss to be measured in minutes rather than hours, then you can use a scheme whereby<br />

you take a full database backup, followed by a series of frequent transaction log backups,<br />

followed by another full backup, <strong>and</strong> so on. As part of a database restore operation, we<br />

can then restore the most recent full backup (plus differentials, if taken), followed by the<br />

chain of available log file backups, up to one covering the point in time to which we wish<br />

to restore the database.<br />

In order to restore a database to a point in time, either to the end of a particular log<br />

backup or to a point in time within a particular log backup, there must exist a full,<br />

unbroken chain of log records, from the first log backup taken after a full (or differential<br />

backup), right up to the point to which you wish to recover. This is known as the log<br />

chain. If the log chain is broken (for example, by switching a database to SIMPLE recovery<br />

model, then it will only be possible to recover the database to some point in time before<br />

the event occurred that broke the chain. The chain can be restarted by returning the<br />

database to FULL (or BULK LOGGED) recovery model <strong>and</strong> taking a full backup (or differential<br />

backup, if a full backup was previously taken for that database). See Chapter 5, Log<br />

<strong>Backup</strong>s, for further details.<br />

33

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!