Process workflow of application-aware backups on VMware virtual machines



Druva interacts with VMware components to back up applications running inside a virtual machine. The following steps describe how Druva backs up Microsoft SQL Server databases inside a VM. Druva utilizes Microsoft VSS and SQL Writer service to back up SQL Server databases inside a virtual machine. Druva requires virtual machine credentials to perform application-aware backups.
Ensure that you provide the VM credentials to Druva when you configure application-aware backups on virtual machines.
SQL Server aware backup workflow on VMware virtual machines
Step | Operation | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Step 1 |
Virtual machine backup request is initiated based on,
Druva forwards the backup request to the backup proxy pool.
|
||||||||||||
Step 2 |
|
||||||||||||
Step 3 |
If the SQL aware backup is enabled for the virtual machine, Druva performs the following steps:
|
||||||||||||
Step 4 |
Backup proxy establishes a VDDK connection to the VM recovery point using a transport mode to read the VM data. Reading encrypted VMDK through the NBD mode is not supported. The backup proxy can read encrypted VMDK disks either using NBDSSL or HotAdd. Here are the supported transport modes:
|
||||||||||||
Step 5 |
Backup proxy starts reading the virtual machine recovery point.
|
||||||||||||
Step 6 |
The backup proxy reads the virtual machine recovery point and prepares to send the backup data to CloudCache (if configured) or Druva Cloud. |
||||||||||||
Step 7 |
Backup proxy transfers the backup data in a continuous stream to the Druva Cloud. Before transferring the data to the Druva Cloud, the backup proxy performs the de-duplication. After the transfer completes, the backup proxy deletes the recovery point stored on the local datastore. |
||||||||||||
Step 8 |
After the backup proxy uploads the virtual machine backup to the Druva Cloud, it performs the following steps:
|
Transaction log backup workflow on VMware virtual machines with SQL Server aware backups enabled
In addition to the full SQL Server database backup, Druva supports transaction log backup of the databases to provide a tighter recovery point objective (RPO). The following workflow describes how Druva backs up transaction logs of the SQL Server databases on the virtual machines for which the backup proxy runs SQL Server aware backups.
Transaction log backup requires successful SQL Server aware virtual machine backups.
Step | Operation |
---|---|
Step 1 |
The backup policy initiates a transaction log backup request. Druva forwards the backup request to the backup proxy pool.
|
Step 2 |
|
Step 3 |
|
Step 4 | The guest OS process (guestossvc) uploads logs to the Druva Cloud through the backup proxy. |
Step 5 |
After the backup proxy uploads the transaction logs to the Druva Cloud, it performs the following steps:
|
The Druva backup proxy starts from step 1 when the next log backup schedule kicks in. For example, you specified an interval of 30 minutes. If the full virtual machine SQL Server aware backup got completed at 12:00 PM, the first log backup happens at 12:00 PM. If the first log backup completes at 12:20 PM, the next log backup starts according to the schedule at 12:30 PM. If the first log backup runs until 12:45 PM, the next log backup starts immediately as soon as the current log backup ends. The Druva backup proxy continues backing up transaction logs until the next full SQL Server aware VM backup runs.
To know more about virtual machine backup, see Backup and Restore VMware Virtual Machines.
If you observe the below error in your Windows event logs, contact Druva Support:
Event ID: 57 NTFS Warning The system failed to flush data to the transaction log. Corruption may occur. Event ID: 137 NTFS Error The default transaction resource manager on volume \\?\Volume{806289e8-6088-11e0-a168-005056ae003d} encountered a non-retryable error and could not start. The data contains the error code. Event ID: 140 NTFS Warning The system failed to flush data to the transaction log. Corruption may occur in VolumeId:<> DeviceName: \Device\HarddiskVolume<>.(A device which does not exist was specified.).Few databases might not be recoverable since the VSS service failed to keep the SQL VSS recovery point persistent on the source VM. Druva is working closely with VMware support to address the above problem.