June 16, 2017
Exchange Log Truncation in VM Backups
One of the tremendous benefits to application-aware backups is being able to perform application-aware tasks such as truncating log files. Application-aware backups are able to flush any application specific data out of memory and pending I/O operations to disk so that backups are consistent from an application standpoint. With NAKIVO Backup & Replication, we are not only able to backup applications like Microsoft Exchange Server that are running in a VMware virtual machine, but also truncate the log files as well. Applications like Microsoft Exchange Server allow for log truncation after successful backup processes are run by an application aware backup product. How does log truncation work with Microsoft Exchange Server? How do we setup an application-aware backup job for Microsoft Exchange with NAKIVO Backup & Replication? How do we verify that log truncation is successful?
Microsoft Exchange Server Log Truncation
There are several things at play with Microsoft Exchange Server log truncation. Let’s see what the process looks like when changes are recorded by Microsoft Exchange Server. When we speak of changes, we are talking about any change with email such as sending, receiving, forwarding, deleting, and all the normal functions we think of working with email. Let’s take a walk through how log files are written with Exchange Server. Each database change is first written simultaneously in memory and the transaction log is the first stop along the way. Mere milliseconds later, the database changes that are recorded in the transaction log are moved to the actual database file. The Exchange Server keeps up with the transactions that have and haven’t been written to the database from the transaction logs in a special checkpoint file. The various file types are listed below.
- .chk file – This is the checkpoint file that keeps track of what has and has not been written to the DB.
- .log file – The log file is used for database recovery. Changes in the log file are replayed into the database if the database is shutdown unexpectedly.
- .edb file – This is the Exchange Server database file.
- .jrs file – These are special use files that are used in the event of a disk getting full.
***Note*** – The below screenshot shows all the files in the same directory as it was taken from a lab server. However, Microsoft best practice details that the database files and the log files should live on separate physical drives which not only helps with performance but also helps to mitigate risk.
Let’s take a look at how we would setup a backup job that would properly backup Microsoft Exchange Server via application aware mode and then also setup the log truncation option.
Application Aware Credentials
The first thing we need to configure for application aware backups to work is credentials that are used during the Exchange log truncation process. These credentials are used to authenticate at an application level. To set the credentials, we navigate to the Settings “cog” >> Inventory >> Manage Credentials configuration.
Once there, click the Add Credentials button.
In the dropdown box in Type you have the options for Password or Private keys which are used for Amazon EC2 instances. Below, since we are connecting to an on premise Exchange Server, I am simply using the Password option. The domain username is entered in the format of DOMAIN\username.
You should see the user that you just configured listed under the Manage Credentials box.
Now that we have our user credentials configured, we can create the application aware backup job that will be able to truncate our Exchange logs.
Create an Application-Aware NAKIVO Backup & Replication Job to Truncate Exchange Logs
The backup job creation process is no different than any other job through the first few configuration selections. First, we select the VM we want to backup. Below the VMware virtual machine running Microsoft Exchange, EX10, is selected.
Next, choose the destination for the backup job.
Next, we schedule the job.
Choose your retention settings.
The Options configuration screen is where we want to pay attention to a couple of settings in particular. The first is the app-aware mode which we have set to Enabled (proceed on error). The other options are Enabled (fail on error) or Disabled. The proceed on error setting allows the backup job to finish even if it encounters an error with the application aware portion of the backup. The second option we set is the Truncate Exchange logs. Notice we have it set to On successful VM processing only which is the safest setting. This way if an error is encountered in the application-aware portion of the backup, it will not truncate the Exchange logs. Only if everything is successful, then the log files are truncated. If we click the Settings link next to the Truncate Exchange logs setting, we can here set the credentials we want to be used for the application-aware guest OS authentication.
Once the Exchange Server database is successfully backed up by an application-aware backup, NAKIVO Backup & Replication will issue a command to the volume shadow copy service instructing it that the backup was successful and to proceed with truncating the transaction logs. The Exchange server will at that point begin removing all the Exchange Server transaction logs that have been recorded in the checkpoint file included up to the point when the backup job kicked off.
Application aware backups are a powerful way to maintain transactional consistency with applications. It is also in the case of Microsoft Exchange server, a way to maintain and keep a healthy Exchange Server file system and acceptable level of free disk space on the Logs volume. By setting the application credentials we are able to authenticate to be able to perform the application-aware backup. By checking a few settings on the VMware backup job, we make the job application aware and tell the job that we are dealing with Exchange Server and verify that we want the logs to be truncated. NAKIVO Backup & Replication provides configurable options on how we want to handle errors with the application aware process. If we encounter errors, we can configure the logs to not be truncated which is the safest option. So, be sure on your Exchange Server backups to take advantage of the powerful application-aware process to truncate your Exchange logs and maintain a healthy Exchange Server.