When you make a backup, by default the backup makes a copy of the current state of the transaction log, and leaves the transaction log in place. If your database is involved in synchronization or replication, then you may need to access old copies of the transaction log after recovering your database.

In many circumstances, disk space limitations make it impractical to let the transaction log grow indefinitely. To free disk space, you can choose to delete the contents of the transaction log when the backup is complete, freeing the disk space. Do not choose this option if the database is involved in replication because replication requires access to the transaction log.

A full backup, which truncates the log file, is illustrated in the figure below. In an incremental backup, only the transaction log is backed up.

Deleting the transaction log after each incremental backup makes recovery from a media failure on the database file a more complex task. Each transaction log needs to be applied in sequence to bring the database up to date, and there may then be several different transaction logs since the last full backup.

You can use this kind of backup on a database that is operating as a MobiLink consolidated database because MobiLink does not rely on the transaction log. If you are running SQL Remote or the MobiLink dbmlsync.exe application, you must use a scheme suitable for preserving old transaction logs.

See:

• Make a backup and rename the original transaction log
• Rename the backup copy of the transaction log during backup
• Make a backup and delete the original transaction log