Content area
A log backup contains all the transaction logs generated since the previous log backup. [...] it's imperative that the chain isn't broken; otherwise, the restore sequence can't progress past the break in the chain unless a differential backup exists to bridge the gap.
I'm trying to perform a point-in-timc restore, but two of the log backups \verenH taken by the log backup job. Will I be able to use those log backups, and will the log backup chain be broken now?
The good news is that you should be fine. Whenever you want to restore to a particular point in time, you musí be able Io perform a restore sequence starting with your most recent full database backup and ending with a log backup that covers that point in time. (I mentioned a full database backup, but this also applies to restoring a single file group, a single file, or performing a partial restore - see "Advanced BACKUP and RESTORE Options," June 2011, InslanlDoc ID 129834.)
A typical restore sequence will always stari with a full backup and a series of log backups that finishes with the backup that covers the specified point in time. An alternative might be to restore a differential backup to skip a large number of log backups. This will make the restore sequence smaller and taster. If at any point there is a missing or damaged backup, with no alternative backup to restore, the restore sequence can't progress any further.
The term hg backup chain describes an unbroken sequence of transaction log backups, from whenever the chain started (typically with a full database backup) to the most recent log backup performed. A log backup contains all the transaction logs generated since the previous log backup. Therefore, it's imperative that the chain isn't broken; otherwise, the restore sequence can't progress past the break in the chain unless a differential backup exists to bridge the gap.
If a backup from the chain is missing or damaged, then the chain is broken. This is a good reason to keep multiple copies of backups and regularly test them to ensure the backup process is producing valid backups. You can also break the log backup chain by switching to the simple recovery model, in which log backups aren't possible.
In the case of the original question, it doesn't matter how the log backups were taken. As long as the log backups are in sequence and the log backup chain isn't broken, then a point-in-time restore should be possible. SQL Server Books Online has more information about log chains at tinyurl.com/3lnsw5v.
Copyright Penton Business Media, Inc. and Penton Media, Inc. Dec 2011