Druva performs an Image-level backup for the complete VM that includes GuestOS and Data on the VM. Druva performs agent-less backup with the help of a backup appliance known as backup proxy.

Review the supported versions of VMware ESXi and VMware vCenter Server supported by Druva.

Druva provides you the capability to back up and restore virtual machine images, files and folders, and application data. The following are the key features that Druva provides:

Review the recommended resource requirements for the backup proxy, including CPU, memory, and available free space on the VMware datastore.

To perform VM backups and restores, you must set the required privileges. The user permissions can be viewed on the VMware vSphere Web Client. For more information, see vSphere Permissions and User Management Tasks and Managing Permissions for vCenter Components.

Review the list of ports required for communication between Druva and various VMware components.

Yes. The same Druva Proxy Deployer utility is used for both on-premise and VMC.
For more information, see Deploy the first backup proxy and register the VMware setup.

Yes.
For more information, see Prerequisites to install the backup proxy.

Yes, you can download the OVA, and install the backup proxy manually. For more information, see Manually deploy the OVA template to install the backup proxy.

Technically, you can, but the best way is to deploy additional backup proxies from the Management Console. You can deploy multiple backup proxies in a single workflow.
For more information, see Deploy additional backup proxies.

Ensure the required ports are open. For more port-related information, see link.

Add *.druva.com URL to the allowlist and follow the link to verify connectivity.

It is always advised to deploy the proxy on the same or shared data center and same geographical location as the VM to be backed up. It helps to achieve better performance during jobs. See the link for reference.

You can schedule automatic and manual backups from the console. As an administrator, you can configure virtual machines for:

The type of backup needs to be specified in the backup policy. The default backup policy is configured for non-application-aware backup.

Backup policy defines the rules to back up content with automated backup schedules, and retention period to back up virtual machines. To create and manage backup policy, see Manage backup policy.

To understand the workflow at the time of backup, see VMware virtual machine backup workflow.

To exclude virtual disks, you can either:

The following examples describe how you can use a wildcard character to exclude virtual disks that contain a string:

To get the virtual disk name or path:

📝 Note
​Flash-based vSphere web client may not be available for certain vCenter versions. It is possible that the path to the virtual disk you get from the vSphere web client is different from the path that the Druva backup proxy gets from the hypervisor. In such a case, the virtual disk is not excluded from backup.
​

Druva backs up the VMware vCenter Server Appliance as a normal virtual machine. However, it is recommended to set up a backup schedule for the appliance when no other virtual machine backups are running.

From backup proxy version 4.6.9-27918 and later, the recovery points created by Druva for a canceled or unsuccessful job will be deleted during the subsequent Backup Now or schedule backup job.

If you have configured an application-aware backup of the virtual machine, the backup completes successfully with errors, and the virtual machine is successfully backed up. However, Druva skips the database-level backup. See article.

If the powered-off virtual machine is configured without enabling the application-aware processing setting in the backup policy, Druva performs a successful backup.

No. Druva only supports standalone databases right now. We are looking for more validation on whether customers deploy AAG in their virtualized environment. Based on our research, customers prefer to deploy standalone instances and choose VMware HA & DRS. Please reach out to Support for more details.

No. Druva only supports standalone databases right now. We are looking for more validation on whether customers deploy FCI in their virtualized environment. Based on our research, customers prefer to deploy standalone instances and choose VMware HA & DRS. Please reach out to Support for more details.

Customers can restore one or more databases without restoring the entire VM back to their VMware infrastructure.

Yes. The customers have to disable App-Aware processing in their VMware policy. The goal of the functionality to allow agentless backups without the need to deploy & install the agent. However, the customers can still continue to use the Hybrid Workloads agent for MS-SQL server if they don't wish to protect the entire VM. If the customers are looking to protect the entire VM, we would certainly advise them to use the app-aware processing capabilities to save on administration and get a single view of the virtual machine and the Microsoft SQL Server application inside it.

📝 ​Note

MS SQL backups and VMware backups of the same virtual machine must start at different times to avoid backup errors. Ensure that the backups windows do not overlap.

Druva supports Windows Authentication. We are looking for customer feedback on whether they would prefer using native SQL Authentication as well and we can certainly add the capability.

To learn more about the prerequisites for app-aware processing, see System requirements for agentless application-aware processing on VMware virtual machines.

Yes. We have also released a credential store along with app-aware processing. See the documentation on how to configure VMware virtual machines for backup and the credential store documentation that provides information on how to use it. Administrators can now create a service account and provide those details in the credential store in Druva. Administrators can use these credentials and assign them to virtual machines. Druva will use these credentials and discover the applications running inside the VMs (Microsoft SQL Server for now).

Yes. Administrators can define the frequency of the backup of the transaction logs while enabling the app-aware processing feature. The Transaction logs are backed up to a temporary location in the guest OS inside the VM and then uploaded to the Druva Cloud via the Druva Backup Proxy. Druva will start streaming the transaction logs, removing the need to copy it to a temporary location in the upcoming releases. This will remove the need for any temporary space provisioning requirements. Administrators can then choose to restore the databases to a point in time copy.

No. There is no need for the SQL VM to connect to the Druva Cloud. Druva will orchestrate the backup/restore process.

No. We offer pure agentless backups with our App-Aware processing feature even while backing up the transaction logs. We inject a process and a plugin and remove it once the necessary operations are performed. For more information, see the application-aware backup workflow documentation.

When the disk is attached to Windows client virtual the VSS recovery points might get deleted in some cases. Hence it is not advisable to use Windows Client virtual machine for staging location.

System databases ( master, model, msdb, tempdb, Resource, distribution, reportserver, reportservertempdb ) are not protected as part of VMware application-aware MS SQL backups. Use the Druva MS SQL Server agent to protect MS SQL system databases.

For the App aware backups, the following will be the design of the TLog backups and same will be reflected under the Jobs page:

You can follow the steps mentioned in this article to apply credentials on SQL VMs to protect the SQL DB. However, the admin permission required to protect SQL DB inside the SQL VM would require the permission mentioned in this article.

If you reconfigure an individual virtual machine created in a vCenter folder that already has a configuration rule applied to it, it is added to the exclusion list of the rule.

The VM will be reconfigured if the new tag has a rule applied to it and the storage region is the same.

The VMs which have VMX configuration files in that specific datastore are eligible for auto configuration.

If the object is moved or deleted, the auto configuration rule is considered invalid.

Exclusion patterns let you provide strings that can be a part of the name of the virtual machine. The rule does not auto configure a virtual machine with a name matching that pattern. Patterns that you can provide to exclude virtual machines from getting auto-configuration rule applied:

Druva is not case sensitive for the string you enter for exclusions. For example, you enter test_vm as the exclusion string. In such a case, Druva excludes VMs with names such as Test_VM, test_vm, test_VM, and TEST_vm.

All the virtual machines created under the folder with a rule applied are listed under the Configured VMs section.
​

If you select a new folder when you update your rule,

Druva does not alert or mark your rule as invalid if all backup proxies from one pool are moved to another, and your rule uses the empty backup proxy pool. When your rule, that uses an empty backup proxy pool, tries to automatically configure a virtual machine for backup, it is configured. However, when Druva tries to back up your virtual machine, the backup job fails because there is no proxy to back it up.

In step 7 of the Create an auto-configuration rule procedure, you can see a folder hierarchy. If you apply rule1 to VM_Folder1, and you do not create and apply any rule to VM_Folder1-A, rule1 auto-configures VMs under VM_Folder1 and VM_Folder1-A. If you create a rule2 later and apply it to VM_Folder1-A:

In step 7 of the Create an auto-configuration rule procedure, you can see a folder hierarchy. If you apply rule1 to VM_Folder1 and rule2 to VM_Folder1-A:

If rule2 is created to exclude VMs that are powered off (Powered Off setting is checked) and contains the exclusion pattern VM1, rule2 does not auto configure virtual machines VM1 and VM2.

If you try to reconfigure your virtual machines using rules, reconfiguration fails if the storage specified in the rule is different. For example, you add virtual machines VM1 and VM2 under folder VMFD1 in a vCenter setup. You attach VM1 and VM2 to the storage US-West. Later, you create an auto-configuration rule R1 for folder VMFD1 in which you specify storage as US-East. In the rule R1, you disable Exclude already configured VMs ensuring auto-configuration of all virtual machines in the folder when the rule is applied.
When the rule R1 to folder VMFD1 is applied:

No. You can restore a virtual machine instantly only from a Linux CloudCache.

If you switch to a Windows storage after enabling Instant Restore, the Instant Restore is disabled for the selected VMs.

If you dissociate a VM from CloudCache, all the subsequent backups of the VM will be stored directly on the Druva Cloud, and instant restoration of the VM is not possible.

There is no charge for this feature. However, customers must have Enterprise Workloads's Enterprise or Elite licenses to deploy CloudCache. For more information, see Druva Plans & Pricing.

You must be on the Linux CloudCache to use the VMWare Instant Restore capability. If you are already on Linux CloudCache, you must upgrade your CloudCache instance(s) and backup proxies to the latest version.
If you are using CloudCache on Windows, you can easily deploy a Linux CloudCache instance as a VM, after discussing sizing guidelines with Druva support. For more information, see Enable or disable Instant restore.

You can verify this information by referring to the Progress Logs tab of that backup job. The progress logs displays the transport mode used.

The job displays an appropriate error message for such events. Refer the article for more details.

The jobs are triggered as per the proxy pool time zone.

Yes, latest VMware Tools should be installed on the virtual machine.

Follow the link to check the required ESX or VMware license see, link.

Check for the documentation for best practices see, link.

If you notice any issue related to access issue on VMDK files then follow the steps mentioned in the given link.