Skip to main content
Documentation

 

Druva Documentation

Process workflow of application-aware backups on VMware virtual machines

  1. Last updated
  2. Save as PDF
Phoenix Editions: File:/tick.png Business File:/cross.png Enterprise File:/tick.png Elite

Phoenix interacts with VMware components to back up applications running inside a virtual machine. The following steps describe how Phoenix backs up Microsoft SQL Server databases inside a VM.  Phoenix utilizes Microsoft VSS and SQL Writer service to back up SQL Server databases inside a virtual machine. Phoenix requires virtual machine credentials to perform application-aware backups.

Ensure that you provide the VM credentials to Phoenix when you configure application-aware backups on virtual machines.

SQL Server aware backup workflow on VMware virtual machines

VM_backup_SQL_Server_aware.png

Step Operation

Step 1

Virtual machine backup request is initiated based on,

  • Schedule defined in the backup policy.
  • Manual backup

Phoenix forwards the backup request to the backup proxy pool.

  • Based on the load balancing algorithm, Phoenix automatically identifies the backup proxy that will run the backup request.
  • If the identified backup proxy is busy, the backup request is queued and initiated when the backup proxy becomes free.

Step 2
  • In an environment where virtual machines are deployed on ESXi hosts managed by vCenter server, backup proxy contacts vCenter Server to locate the virtual machine and obtains its configuration.
  • In an environment where virtual machines are deployed on standalone ESXi hosts, backup proxy contacts ESXi host to obtain the virtual machine configuration.

Step 3

If the SQL aware backup is enabled for the virtual machine, Phoenix performs the following steps:

  1. The backup proxy directly connects to the virtual machine using the network infrastructure. 
  2. The backup proxy injects the executables (guestossvc.exe) and (PhoenixSQLGuestPlugin.exe) into the VM.
  3. The backup proxy uses VMware tools to run (guestossvc) process inside the guest OS that starts an API.
  4. The guestossvc process starts the SQL Server executable (PhoenixSQLGuestPlugin) process. The backup proxy uses the opened port 3542 on the VM for communication with the guest OS process (guestossvc).
  5. The guestossvc process uses port 3545 on the Windows Server VM to communicate with PhoenixSQLGuestPlugin process.
  6. The SQL Server executable process(PhoenixSQLGuestPlugin) creates a persistent VSS snapshot of all the SQL Server instances.
  7. The Phoenix backup proxy performs the following steps:

    • The backup proxy queries the ESXi hypervisor or the vCenter server to create VM snapshots that contain VMDK files and the VMX files of the virtual machines.  Ensure that enough storage is available on the local datastore for the VM snapshot. 

    • The backup proxy uses CBT and Tools Quiescing to create a virtual machine snapshot. For the first automatic backup, the backup proxy creates a snapshot of a full backup. For all subsequent backups, the backup proxy creates snapshots of the incremental backups. 

Step 4

Backup proxy establishes a VDDK connection to the VM snapshot 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:

Backup proxy Virtual Machine Transport mode
Encrypted Encrypted HotAdd
Unencrypted Encrypted NBD-SSL
Encrypted Unencrypted HotAdd

Step 5

Backup proxy starts reading the virtual machine snapshot. 

Note: The backup proxy reads the VM snapshot on the local datastore.

Step 6

The backup proxy reads the virtual machine snapshot and prepares to send the backup data to Phoenix CloudCache (if configured) or Phoenix Cloud.

Step 7

Backup proxy transfers the backup data in a continuous stream to the Phoenix Cloud. Before transferring the data to the Phoenix Cloud, the backup proxy performs the de-duplication.

After the transfer completes, the backup proxy deletes the snapshot stored on the local datastore. 

Step 8

After the backup proxy uploads the virtual machine backup to the Phoenix Cloud, it performs the following steps:

  • Stop the SQL Server executable
  • Remove the SQL Server executable files
  • Stops the guest OS process
  • Removes the guest OS process files and executable
  • Removes the VSS snapshot from the guest OS

Transaction log backup workflow on VMware virtual machines with SQL Server aware backups enabled

In addition to the full SQL Server database backup, Phoenix supports transaction log backup of the databases to provide a tighter recovery point objective (RPO). The following workflow describes how Phoenix backs up transaction logs of the SQL Server databases on the virtual machines for which the backup proxy runs SQL Server aware backups. 

TL_backup_SQL_Server_aware.png

Transaction log backup requires successful SQL Server aware virtual machine backups.

Step Operation

Step 1

The backup policy initiates a transaction log backup request. Phoenix forwards the backup request to the backup proxy pool.

  • Based on the load balancing algorithm, Phoenix automatically identifies the backup proxy that will run the backup request.
  • If the identified backup proxy is busy, the backup request is queued and initiated when the backup proxy becomes free.

Step 2
  • In an environment where virtual machines are deployed on ESXi hosts managed by vCenter server, backup proxy contacts vCenter Server to locate the virtual machine and obtains its configuration.
  • In an environment where virtual machines are deployed on standalone ESXi hosts, backup proxy contacts ESXi host to obtain the virtual machine configuration.

Step 3
  1. The backup proxy directly connects to the virtual machine using the network infrastructure. 
  2. The backup proxy injects the executables (guestossvc.exe) and (PhoenixSQLGuestPlugin.exe) into the VM.
  3. The backup proxy uses VMware tools to run (guestossvc) process inside the guest OS that starts an API.
  4. The guestossvc process starts the SQL Server executable (PhoenixSQLGuestPlugin) process. The backup proxy uses the opened port 3542 on the VM for communication with the guest OS process (guestossvc).
  5. The guestossvc process uses port 3545 on the Windows Server VM to communicate with PhoenixSQLGuestPlugin process.
  6. The SQL Server executable process (PhoenixSQLGuestPlugin) uses the virtual device interface (VDI) to take log backups of the databases on the virtual machines. It copies the transaction logs to this location: %ProgramData%\Phoenix\VMWare\SQL\TlLogs\. In addition, the SQL Server executable process truncates the transaction logs. 

Note: Since the SQL Server executable copies the transaction logs to the <PATH> on the virtual machine, the process can cause storage consumption bloat. 
Step 4 The guest OS process (guestossvc) uploads logs to the Phoenix Cloud through the backup proxy. 
Step 5

After the backup proxy uploads the transaction logs to the Phoenix Cloud, it performs the following steps:

  • Stop the SQL Server executable
  • Remove the SQL Server executable files
  • Stops the guest OS process
  • Removes the guest OS process files and executable
  • Removes the transaction logs on the guest OS

The Phoenix 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 Phoenix 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 snapshot persistent on the source VM. Druva is working closely with VMware support to address the above problem.