To follow on from the last post around being able to take an application consistent snapshot without the requirement of taking a VMware snapshot which can be found here. The premise of this post is to highlight another cool feature that also came in Veeam Backup & Replication v10 but this time focused on Microsoft SQL and Oracle logfile backups. In previous versions we could take application consistent snapshots and backups with the requirement of taking a VMware snapshot but from a storage snapshot perspective we were able to truncate the database logs after a successful snapshot or we can choose not to truncate the logs. Whereas for many years we have also had the ability to take a backup of the database logs periodically which then also truncates those logs.
The image below shows pre Veeam Backup & Replication v10 when you go to configure your application aware processing.
Now in Veeam Backup & Replication v10 and specifically those orchestrated snapshots only jobs we can be more granular on what we protect as per below.
This option enables you to take a periodic log backup to a Veeam Backup repository, whilst using the storage snapshot as the baseline. This is only applicable to orchestrated storage snapshots (this capability is already there for image based backups) to achieve this in your storage snapshot only job you will walk through the wizard until you get to the guest processing option page and then confirm that you require application-aware processing and then you can select Applications.
Next and this will depend on how many machines you have in your job and the placement of those VMs will depend on if you are wanting to achieve the VMware Snapshot-less approach to getting an application aware and consistent storage snapshot. Select your VM and edit to make the relevant application log file decisions.
For this VM which is a machine with SQL present I can now set the appropriate configuration that I need here.
Oracle would be the same here on the next tab over.
When this job is now scheduled to run if you have adhered to the configuration in the previous blog post around VM, datastore placement and backup job configuration then you can now achieve an application aware storage snapshot, without the requirement of a VMware snapshot whilst also being able to create a periodic log backup and use the storage snapshot as the baseline for any restore functionality.
From a recovery point of view obviously this means we can have a much better RPO for our database recoveries, we have the speed from the storage snapshot baseline and we have the transaction log backups stored on a Veeam repository as a .VLB file or files.
A common question I have been asked about this feature is will this work with secondary snapshots, for example with NetApp ONTAP, HPE Nimble and HPE 3PAR we have the capability of being able to leverage their storage replication to create and send their snapshots to secondary systems. This feature will work in those scenarios also.
Another thing to note here is that with HPE Nimble those VM Disks for snapshot-less processing must reside on the same volume collection.
Ok, so how do we recover this data using our Veeam Explorers for SQL or Oracle.
Firstly, you should select the ribbon at the top and choose Restore, choose Restore from backup as our option.
Next, we want to choose the Application items restore option.
You will then see the list of Veeam Explorer options that we have, for this example we will choose SQL but this is also applicable to Oracle recovery options.
At this point we are then faced with the Veeam Explorer for SQL and you should choose the machine that is relevant for your restore operation, specifically here you will see a list of backup jobs and storage snapshots. We will choose our storage snapshot and our SQL server.
You will then be faced with the available restore points, or you can choose the latest available snapshot with the option at the top of the wizard.
Then choose a location for a temporary VM will be registered but remained powered off, this will be automatically removed after the restore operation is closed.
To finish the wizard, give a reason for the restore for audit purposes and then select finish on the summary screen this will then open the Veeam Explorer for SQL with the mounted databases from the restore point you chose.
Up until this point this is not different you could always do this before but you would have created the snapshot whilst also taking a VMware snapshot and you only have point in time copies of your databases on your storage snapshot. What this new feature in Veeam Backup & Replication v10 enables is the ability to restore to a specific point in time using those transaction log backups that we put on our Veeam repository as the .VLB files on a schedule.
Getting down to the specific transaction can also be achieved by selecting the “perform restore to the specific transaction” at the bottom of the wizard above. You then have the ability to fine tune which transaction you wish to restore back to, this is a lab environment so not much happening, but I created a transaction to show you an example.
The transaction log backup job runs permanently in the background, shipping transaction logs to the backup repository at a specific time interval (by default, every 15 minutes). This process was once only available for backup jobs but now you can achieve this with your storage snapshots also.
The transaction log snapshot /backup session starts and stops in the following way:
- The initial session starts when the parent backup job schedule is enabled. After that, the session starts with every new session of the parent backup job.
- The session ends before the next session of the parent backup job, and/or when this parent backup job is disabled.
- When the session ends, Veeam Backup & Replication stops the runtime process and uninstalls it from the VM guest OS. When a new session starts, the runtime process is deployed again.
Hope that was useful any questions let me know here below or get in touch on twitter @MichaelCade1