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

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Chapter 9: File <strong>and</strong> Filegroup <strong>Backup</strong> <strong>and</strong> <strong>Restore</strong><br />

Notice that the three file backups are taken at different times. In order to restore this<br />

database, using backups shown, we have to restore the FG1_1, FG2_1 <strong>and</strong> FG3_1 file<br />

backups, <strong>and</strong> then the chain of log backups 1–5. Generally speaking, we need the chain<br />

of log files starting directly after the oldest full file backup in the set, <strong>and</strong> finishing with<br />

the one taken directly after the most recent full file backup. Note that even if we are<br />

absolutely certain that in Log5 no further transactions were recorded against any of the<br />

three filegroups, <strong>SQL</strong> <strong>Server</strong> will not trust us on this <strong>and</strong> requires this log backup file to<br />

be processed in order to guarantee that any changes recorded in Log5 that were made to<br />

any of the data files, up to the point the FG3_1 backup completed, are represented in the<br />

restore, <strong>and</strong> so the database has transactional consistency.<br />

We can also perform point-in-time restores, to a point within the log file taken after all of<br />

the current set of file backups; in Figure 9-4, this would be to some point in time within<br />

the Log5 backup. If we wished to restore to a point in time within, say, Log4, we'd need<br />

to restore the backup for filegroup 3 taken before the one shown in Figure 9-4 (let's call it<br />

FG3_0), followed by FG1_1 <strong>and</strong> FG2_1, <strong>and</strong> then the chain of logs, starting with the one<br />

taken straight after FG3_0 <strong>and</strong> ending with Log4.<br />

This also explains why Microsoft recommends taking an initial full database backup <strong>and</strong><br />

starting the log backup chain before taking the first full file backup. If we imagine that<br />

FG1_1, FG2_1 <strong>and</strong> FG3_1 file backups were the first-ever full file backups for this database,<br />

<strong>and</strong> that they were taken on Monday, Wednesday <strong>and</strong> Friday, then we'd have no restore<br />

capability in that first week, till the FG3_1 <strong>and</strong> Log5 backups were completed.<br />

It's possible, in some circumstances, to restore a database by restoring only a single file<br />

backup (plus required log backups), rather than the whole set of files that comprise<br />

the database. This sort of restore is possible as long as you've got a database composed<br />

of several data files or filegroups, regardless of whether you're taking database or file<br />

backups; as long as you've also got the required set of log backups, it's possible to restore a<br />

single file from a database backup.<br />

319

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

Saved successfully!

Ooh no, something went wrong!