Tail-log backups, a feature which is available for SQL Server versions 2005 and newer. The tail-log backup captures records on the transaction log that were written since the last transaction log backup. If you’re going to restore a database to the point of failure, then you need to take a tail-log backup before you start the restore operation.
In a simple term, a tail-log backup contains the log records that were not yet backed up (thus the name, tail of the log). Basically, every time you perform a transaction log backup, you are backing up the tail of the transaction log.
This type of backup is done in order to prevent any work loss and helps to keep the log sequence intact. Before you will be able to recover your database to its most recent point, you must have a backup of its transaction log tail.
Situations where a Tail-Log Backup is required
If you’re going to restore to a point in time prior to the last transaction log backup, if you’re moving the database from one server instance to another, or if you’re overwriting the existing database, then you won’t need a tail-log backup.
The complication starts when the database’s data files are no longer available, perhaps due to a media failure. When this occurs, the next logical step is to back up the current transaction log, and apply this backup to the standby database. You can back up the transaction log even though the data files are no longer available, using the NO_TRUNCATE option e.g.
BACKUP LOG MyDatabase TO DISK = 'G:\Backups\MyDatabase_log_tail.bak' WITH NO_TRUNCATE
You can then use the resulting log backup to bring the standby database to the state the database was in before the failure.
This is another good reason to place your transaction log files on different disks from the data files. If they were on the same disks, a disk failure would prevent you from taking a backup of the transaction log.
Another complication is when your database is using the bulk-logged recovery model, and the current transaction log contains minimally logged transactions. In this situation, a transaction log backup needs to store the modified data pages (extents). If the data files are not available, you cannot back up the transaction log, even with the NO_TRUNCATE option.
Lastly, in SQL Server 2005 and above, every time you try to restore a database which already exists, is using the full or bulk-logged recovery models, and the transaction log contains active transactions, an error similar to the following is displayed:
[Server: Msg 3159, Level 16, State 1, Line 1 The tail of the log for the database "MyDatabase" has not been backed up. Use BACKUP LOG WITH NORECOVERY to backup the log if it contains work you do not want to lose. Use the WITH REPLACE or WITH STOPAT clause of the RESTORE statement to just overwrite the contents of the log. Server: Msg 3013, Level 16, State 1, Line 1 RESTORE DATABASE is terminating abnormally.
This is just SQL Server’s way of telling you that there are log records in the transaction log that have not been backed up. If the current transaction log can be discarded, you can use the REPLACE option to tell SQL Server to ignore the current transaction log e.g.
RESTORE DATABASE MyDatabase FROM DISK = 'G:\Backups\MyDatabase_full.bak' WITH REPLACE