If you back up a Microsoft SQL VM, you can specify how Veeam Backup & Replication must process transaction logs on this VM:
- At the Guest Processing step of the wizard, select the Enable application-aware processing check box.
- Click Applications.
- In the displayed list, select the Microsoft SQL Server VM and click Edit.
- In the Transaction logs section, select Process transaction logs with this job.
- In the VM Processing Settings window, click the SQL tab.
- Specify how transaction logs must be processed. You can select one of the following options:
- Select Truncate logs to truncate transaction logs after successful backup. The runtime process running on the VM guest OS will wait for the backup to complete successfully and then truncate transaction logs. If the job does not manage to back up the Microsoft SQL Server VM, the logs will remain untouched on the VM guest OS until the next start of the runtime process.
- Select Do not truncate logs to preserve transaction logs. When the backup job completes, Veeam Backup & Replication will not truncate transaction logs on the Microsoft SQL Server VM.
It is recommended that you enable this option for databases that use the Simple recovery model. If you enable this option for databases that use the Full or Bulk-logged recovery model, transaction logs on the VM guest OS may grow large and consume all disk space. In this case, the database administrator must take care of transaction logs him-/herself.
- Select Backup logs periodically to back up transaction logs with Veeam Backup & Replication. Veeam Backup & Replication will periodically copy transaction logs to the backup repository and store them together with the image-level backup of the Microsoft SQL Server VM. During the backup job session, transaction logs on the VM guest OS will be truncated.
For more information, see Microsoft SQL Server Logs Backup and Restore.
If you have selected to back up transaction logs with Veeam Backup & Replication, you must specify settings for transaction logs backup:
- In the Backup logs every <N> minutes field, specify the frequency for transaction logs backup. By default, transaction logs are backed up every 15 minutes. The maximum log backup interval is 480 minutes.
- In the Retain log backups section, specify retention policy for transaction logs stored on the backup repository.
- Select Until the corresponding image-level backup is deleted to apply the same retention policy for image-level backups and transaction log backups.
- Select Keep only last <N> days of log backups to keep transaction logs for a specific number of days. By default, transaction logs are kept for 15 days. If you select this option, you must make sure that retention for transaction logs is not greater than retention for the image-level backups. For more information, see Retention for Transaction Log Backups.
- In the Log shipping servers section, click Choose to select what log shipping server you want to use to transport transaction logs:
- Select Automatic selection if you want Veeam Backup & Replication to choose an optimal log shipping server automatically. If the optimal shipping server is busy, Veeam Backup & Replication will direct the data flow to another shipping server not to lose data and to comply with RPO. The process of transaction logs shipment does not require a dedicated server — Veeam Backup & Replication can use any Microsoft Windows server added to the backup infrastructure.
- To define a log shipping server explicitly, select Use the specified servers only and select check boxes next to servers that you want to use as log shipping servers. The server list includes all Microsoft Windows servers added to the backup infrastructure.
Make sure that you select a server that is not engaged in other resource-consuming tasks. For example, you may want not to use a server that performs the WAN accelerator role as a log shipping server. For load balance and high availability purposes, it is recommended that you select at least 2 log shipping servers.
Veeam Backup & Replication automatically excludes its configuration database from application-aware processing during backup. Transaction logs for the configuration database are not backed up.