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 9: File <strong>and</strong> Filegroup <strong>Backup</strong> <strong>and</strong> <strong>Restore</strong><br />

We can see that the first three RESTORE comm<strong>and</strong>s executed successfully but the fourth<br />

failed, with a message stating that the LSN contained in the backup was too recent to<br />

apply. Whenever you see this sort of message, it means that a file is missing from your<br />

restore script. In this case, we forgot to apply the differential file backup for the secondary<br />

data file; <strong>SQL</strong> <strong>Server</strong> detects the gap in the LSN chain <strong>and</strong> aborts the RESTORE comm<strong>and</strong>,<br />

leaving the database in a restoring state.<br />

The course of action depends on the exact situation. If the differential backup file<br />

is available <strong>and</strong> you simply forgot to include it, then restore this differential backup,<br />

followed by TLOG2, to recover the database. If the differential file backup really is missing<br />

or corrupted, then you'll need to process all transaction log backups taken after the full<br />

file backup was created. In our simple example this just means TLOG <strong>and</strong> TLOG2, but in a<br />

real-world scenario this could be quite a lot of log backups.<br />

Again, hopefully this hammers home the point that it is a good idea to have more than<br />

one set of files on h<strong>and</strong>, or available from offsite storage, which could be used to bring<br />

your database back online in the event of a disaster. You never want to be in the situation<br />

where you have to lose more data than is necessary, or are not be able to restore at all.<br />

Summary<br />

In my experience, the need for file backup <strong>and</strong> restore has tended to be relatively rare,<br />

among the databases that I manage. The flipside to that is that the databases that do need<br />

them tend to be VLDBs supporting high visibility projects, <strong>and</strong> all DBAs need to make<br />

sure that they are well-versed in taking, as well as restoring databases from, the variety of<br />

file backups.<br />

File backup <strong>and</strong> restore adds considerable complexity to our disaster recovery strategy, in<br />

terms of both the number <strong>and</strong> the type of backup file that must be managed. To gain full<br />

benefit from file backup <strong>and</strong> restores, the DBA needs to give considerable thought to the<br />

file <strong>and</strong> filegroup architecture for that database, <strong>and</strong> plan the backup <strong>and</strong> restore process<br />

346

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

Saved successfully!

Ooh no, something went wrong!