Transaction logs in Exchange Server are very important. These are not just logs of what happens, transaction logs act as a buffer between the database and the users. Data is temporary kept in transaction logs before being committed to the database after a successful backup.
If something happens to the transaction logs, the database will not function and fail to mount. It is important to have the right backup solution, which is compatible with the Exchange Server version installed and is application aware. It is suggested that a daily backup is done correctly to ensure the committing of the transaction logs and correct purging of log files.
Why Do We Need to Move the Logs to Another Drive?
Since transaction logs hold temporary data until it is committed, they tend to get big and consume a lot of storage. The continuous usage and volume of traffic on our database (since we are more dependent on email) increase the need for storage. We can create a new drive and move the transaction logs to it.
In addition, we need to also consider the performance. Let’s say that the database and transaction logs are on the same drive. It would make sense to have them separate as this will increase performance.
On the other hand, there could be issues with the drive. In such a case, we need to move the transaction logs to another drive.
Moving the Transaction Logs
We cannot just move the transaction logs as the database will get damaged and not mount, causing data loss and stoppage of services.
So, we need to first get the exact paths of our database logs. We need to use the Get-MailboxDatabase command (as given below) in the Exchange Management Shell (EMS) to identify the location of the database in question.
Get-MailboxDatabase -Identity "" | FL Name, EdbFilePath, LogFolderPath
Since we need to only move the log folder, we can use the following command:
Move-DatabasePath "<database name>" -EdbFilePath "<database full edb path>" -LogFolderPath "<database log folder>"
This will move the log path to the specified location. To complete this, the system will temporary un-mount the database in question. So, expect some downtime. Depending on the size of the database and the quantity of transaction logs, it will take some time. It would be best to plan this well so that the business will not get impacted.
To move a database location or database log path, the database must be mounted and healthy. If this is not the case, the database will not be operational.
Moving the Logs via PowerShell or the Exchange Admin Center
Transport logs can get quite large if the Exchange Server is very busy. If there are a lot of writes on such logs, it would be best to put them in a separate location.
We can do this either via PowerShell or the Exchange Admin Center (EAC).
To move the transport logs using PowerShell, we need to use the Set-TransportService command in the Exchange Management Shell (EMS).
Set-TransportService <server name> -SendProtocolLogPath "<new location path>" -ReceiveProtocolLogPath "<new location path>"
After executing the command, we can see that the location has already been created and started to populate.
To move the logs using the EAC, follow these steps:
- Log into the EAC and click on the Servers tab.
- Find the server and click on the Edit button.
- Click on Transport logs. Here, we can move the Message Tracking Log, Connectivity Log and Protocol Logs.
What if Something Happens?
There are several issues that may arise while running the above commands or during a normal operation. The transaction logs or the actual database may get corrupted or damaged. Or we could run out of disk space on the source or destination during the move, resulting in database corruption. It's very difficult to recover in such cases with no data loss. We need to also factor in the time and resources required to recover from such situations.
In such situations, a third-party Exchange Database Recovery Software, such as Stellar Repair for Exchange, can come in handy. This application can repair corrupt database, even if the log file is not available or corrupt. It can recover user mailboxes, shared mailboxes, disabled mailboxes, user archive and public folders without any data loss.
