SQL Server Backup and Restore - Simple Talk

Chapter 6: Log Restores
Missing or corrupt full backup
If we find that the latest full backup file, on which we planned to base a RESTORE
operation, is missing or corrupt, then there is still hope that we can perform our point-intime
restore. Full backups do not break the log chain, and each log backup contains all the
log records since the last log backup, so we can restore the previous good full backup and
then restore the full chain of log files extending from this full backup up to the desired
point of recovery.
However, this is not a reason to skip full backups, or to adopt a cavalier attitude towards
full backup failures. When performing a restore operation, the greatest chance of success
comes when that operation involves the smallest number of files possible. The more files
we have to restore, the greater the chance of failure.
Minimally logged operations
In Chapter 5, we discussed briefly the fact that it is not possible to restore a database to a
point in time within a log file that contains minimally logged operations, recorded while
the database was operating in the BULK_LOGGED recovery model. In order to visualize
this, Figure 6-1 depicts an identical backup timeline for two databases, each of which we
wish to restore to the same point in time (represented by the arrow). The green bar represents
a full database backup and the yellow bars represent a series of log backups. The
only difference between the two databases is that the first is operating in FULL recovery
model, and the second in BULK LOGGED.
184