Log Truncation

With NAKIVO Backup & Replication, you can remove (truncate) transaction log files of Microsoft Exchange and Microsoft SQL servers which will allow you to reduce the size of backups and, as a result, to optimize the use of storage space. Log truncation can be enabled on the Options page of backup and replication jobs. 

Microsoft Exchange Log Truncation

Microsoft Exchange is the industry's leading platform for email, calendaring, and messaging services. To protect data from undesired deletion or modification, each change that is made to a Microsoft Exchange server database is recorded in transaction logs. These logs can be replayed to recover data that was removed or changed in the database. While this approach improves data protection, it has a downside. Since the Microsoft Exchange database is constantly changing (as data is written and removed in the database), transaction logs grow over time. If not periodically removed, they will eventually fill up the disk and may crash the entire server.

NAKIVO Backup & Replication can create consistent backups of VMware and Hyper-V VMs as well as remove transaction log files of Microsoft Exchange 2013, 2016, and 2019 servers. After creating a successful backup, NAKIVO Backup & Replication connects to your Microsoft Exchange server, identifies which transaction log files have already been written to the database and removes or truncates those log files.

Stages of Log Truncation

As a result, NAKIVO Backup & Replication creates regular, application-consistent backups of your Microsoft Exchange server and also removes the transaction log files so they don't consume all free disk space on the server.

Microsoft SQL Server Log Truncation

Any Microsoft SQL server tracks all database transactions (modifications) completed by the server and records them to the transaction logs. Transaction log files (identified with the .ldf extension) are very important, as they are used to ensure database integrity and allow restoring data by replaying the changes. However, these files grow over time and can eventually fill all the free space. This may result in the Microsoft SQL Server crash, or loss of valuable data. That is where Transaction Log Truncation might help.

On one hand, you need to keep the transaction logs, so you can recover Microsoft SQL Server data in case any data deletion, undesired modification, or corruption occurs. On the other hand, you need to remove transaction logs to save space, but without any transaction records you will be unable to successfully recover, should any unpredictable situation occur.

The best practice is to first back up the whole VMware or Hyper-V VM running Microsoft SQL Server and all log files stored therein, and then delete or truncate those files on the source VM freeing up the storage space.

NAKIVO Backup & Replication supports transaction log truncation for Microsoft SQL Server 2008 and later. The product follows the best practice of performing the log truncation process while ensuring ease of use and simplicity. NAKIVO Backup & Replication can automatically truncate transaction log files after successful VM backup and replication. All you need to do is just set it and forget it.

To free up the VM storage space, NAKIVO Backup & Replication performs the following operations:

  • Backs up/replicates the entire VMware or Hyper-V VM running Microsoft SQL Server.

  • After completing a successful backup/replication, identifies Microsoft SQL Server transaction log files, which were already committed to the database.

  • Truncates (deletes) the committed transaction log files on the source VM, thus freeing up storage space.

Consequently, you get a VM backup/replica with all transaction log files. Even though the backed up log files can be pretty large, NAKIVO Backup & Replication easily reduces the size of the VM backup by using backup deduplication and compression features. In its turn, the original VM is left logs-free and can be recovered at a certain recovery point using the aforementioned VM backup/replica, should something go wrong.