Druva is easy to set up. You only need to perform a few, quick steps to get your setup ready. To see the chronology that you must follow, see Druva setup process. For a full set of instructions for setting up Druva for your file servers, see Initial configuration of file servers. To know how you can set up Druva for your MS-SQL server, see Introduction to Druva for SQL servers.

Hybrid Workloads agent is a component of the Druva solution that you can deploy locally. It communicates with Druva Cloud for backing up and restoring data. To enable backup and restore of server data, you must install and activate Hybrid Workloads agents on the servers that you want to back up. You do not require separate agent installers for File servers and MS-SQL server. The Hybrid Workloads agent installers are designed to identify the type of server. That is why you can use the same installer for installations across File servers as well as MS-SQL server.

No, you do not. Hybrid Workloads agents can identify the type of a server at the time of an installation. That is why you do not require separate installers for file servers and MS-SQL server.

Druva Cloud comprises cloud storage to which your server data is saved.

A backup set is a data set that you can configure for backups by defining the backup content and backup policies for files and databases. A backup set provides configuration options to customize the backup content, backup policy, and retention settings. You can configure multiple data sets for backup with their own policies and settings, independent of each other. For example, if you want to back up files and MS-SQL server database on the same server, you can create two backup sets; one for files and another for the MS-SQL server database with their respective policies.

No. Druva allows you to configure different backup sets to back up different data of the same server.

If you have multiple servers with similar workloads, instead of individually configuring the backup content for each backup set, you can create a content rule and apply to all the corresponding workloads. However, for a workload that needs to back up different content than the other backup sets, you can configure a custom content exclusively for such the backup set. Content rule enables you to configure similar backup sets in bulk whereas the custom content provides the flexibility when dealing with exceptions.

Yes, you can disable a backup set of a server for further backup. When you disable the backup set, Druva does not create new recovery points for that backup set, however, retains the existing recovery points.

Yes, Druva allows you to select a different storage when you configure a new backup set for a server.

Yes, you can attach different backup sets of the same server to different CloudCache.

If a server is configured to back up mixed workloads and the server is mapped to CloudCache, after the server is upgraded to Hybrid Workloads agent 4.7, two backup sets are created corresponding to the administrative group and backup policy and these backup sets are mapped to the CloudCache.

No. Druva does not charge anything for creating backup sets. A customer is charged based on the storage usage. For more information about credits, see Druva Credits.

No. The data backed up with the old policy would be maintained. The recovery points would get deleted with respect to the retention defined in the respective policies.

No data is lost in this scenario. The data corresponding to the unmapped backup set, if not already synced to the cloud, will be synced to the cloud depending on the CloudCache schedule. Once it is synced to the cloud, the corresponding disk space occupied on the CloudCache is freed.

At the time of registering servers, Druva generates an activation token. You must use this activation token to activate Hybrid Workloads agents on your servers. You can also use third-party tools such as Microsoft SCCM for mass installation and activation. However, you must have the activation token for activating Hybrid Workloads agents. The order does not matter; you can choose to register servers first and then install Hybrid Workloads agents. Alternatively, you can install Hybrid Workloads agents first, and then register servers. However, to obtain the activation token for activating Hybrid Workloads agents, you must register your File servers or MS-SQL server.

The Hybrid Workloads agent installer is available at http://downloads.druva.com/phoenix/.
Because the Hybrid Workloads agent installer is server-aware, it identifies the type of a server at the time of installation. That is why you need not maintain separate installers for File servers and MS-SQL server.
You can also download the installer from the Management Console at the time of registering servers.

To enable backup and restore of server data, you must install and activate Hybrid Workloads agents on the servers that you want to back up.

You can use a third-party script such as Microsoft System Center Configuration Manager for installing and activating Hybrid Workloads agents. However, we do not provide scripts for configuring the file servers or SQL servers on which Hybrid Workloads agents reside. You must configure each server from the Management Console.

You must ensure that the free space at locations where Hybrid Workloads agent configuration details, logs, and metadata reside is at least 1% of the size of the data that you want to back up. To know where Hybrid Workloads agent logs and configuration details are available, see Hybrid Workloads agent configuration and log files.

You can expect to see the application data (the configuration file and the logs) under your primary partition. If you choose to install Hybrid Workloads agent on your primary partition, both the installation directory and the application data will reside on the primary partition.

An activation token is generated at the time of registering servers. It performs a one-time authentication for validating Hybrid Workloads agent connections to Druva Master. You can use an activation token to activate as many Hybrid Workloads agents as you want. We recommend that you generate only those many tokens that you plan to use. We also recommend that you use a single token to activate servers that share something in common. For example, you might want to use a token to activate all servers that are geographically co-located. To better manage activation tokens, delete the tokens that you have not used for activating Hybrid Workloads agents. To know more, see Manage activation tokens.

Yes, Druva stores your activation tokens. Druva lists the activation token under Manage > ActivationTokens. Your token appears as a string of multiple instances of asterisk (*) on the Management Console.

An activation token only performs a one-time authentication of Hybrid Workloads agents. It does not interfere with backups. If you deleted some tokens, backups from your servers will continue as usual.

Yes. It is possible to create different backup sets to back up server data and map these backup sets to different CloudCaches. For example, a Windows File server is configured with two backup sets to back up C:\Folder1 and C:\Folder2, respectively. These backup sets are distinct and can be configured to different or same CloudCache for backup.

File Server backups are useful for restoring files and folders. VM backup is useful for restoring the entire virtual machine. Both file server backups and VM backups serve distinct purposes. File backups provide granular recovery options, allowing users to retrieve specific files or folders, while VM backups offer a more comprehensive recovery solution by capturing the entire virtual machine's state.

Backup policies are rules that define the schedule for automatic backups, the retention period, and other advanced backup settings. You should create backup policies, and attach them to backup sets. This ensures that backups from servers start according to the backup policies. To know more about backup policies, see About File server backup policies.

Yes, we do. For more information, see About File server backup policies. However, for an exact configuration of backup policies that is suitable for your servers, contact the Support.

No, you cannot specify bandwidth as a percentage value. You can only specify bandwidth in Mbps at the time of creating a backup policy.

By default, Druva excludes some system files and folders from backups, for example, the Recycle Bin. This ensures a faster backup experience. To see the list the files that Druva excludes, see Default folder exclusions.

Yes, you can trigger the restore for File server backup set and MS-SQL server backup set simultaneously. However, if you trigger a restore request for a File server backup set while another restore is in progress for the same File server backup set, the triggered restore request is queued.

Yes, you can browse through the folder library to select the folders that you want to back up.

The backup schedule follows the time zone of the Hybrid Workloads agent. For example, if you set the schedule such that backups start at 8 AM, Hybrid Workloads agents located in New York will start the backup at 8 AM EDT and Hybrid Workloads agents located in California will start backups at 8 AM PST, respectively.

An administrative group is a logical categorization of servers that share something in common. For example, servers located in one region can belong to one administrative group. Similarly, servers having the same operating system can belong to another administrative group. To know more about administrative groups, see About administrative groups.

Yes, you can adjust bandwidth at a backup set-level on the Backup Schedule tab.

No, you cannot. However, you can detach a backup policy from a backup set, and attach a new backup policy to the backup set.

Yes, you can. However, we recommend that you use a single token to activate servers that share something in common. For example, you might want to use a token to activate all servers that are geographically co-located.

When you attach a CloudCache to the backup set, Druva backs up the server data as per the policy configuration. If the smart scan feature is enabled for the File server, attaching a CloudCache to the backup set will not affect the smart scan backup of the server. When you detach a CloudCache from the backup set, there is no impact on the backup execution, such as full or smart scan.

Backup policies are rules that define the schedule for automatic backups and the retention period for data backup. You should create backup policies, and attach them to backup sets. This ensures that backups from servers start according to the backup policies. To know more about backup policies, see About MS-SQL server backup policies.

Yes, we do. For more information, see About SQL server backup policies. However, for an exact configuration of backup policies that are suitable for your servers, contact Support.

No, you cannot specify bandwidth as a percentage value. You can only specify bandwidth in Mbps at the time of creating a backup policy.

By default, Druva backs up all instances and the databases within these instances except for tempDB. However, you can exclude the databases that you do not want to back up at the time of creating a backup policy.

No. But it is possible to exclude the same databases on multiple servers. You will have to specify different content rule for each server.

The maximum number of backup sets that you can configure on the MS-SQL server depends on the number of the instances existing on that server. You can create one backup set per instance. For MS_SQL server, you can create backup set either for "All instances" or "individual instances". If you have created a backup set for "All instances", then Druva does not allow you to create a backup set for individual instances. Similarly, if you have created a backup set for individual instances, then Druva does not allow you to create a backup set for All instances. However, if you have created a backup set for All instances and the backup set is disabled, Druva allows you to create a backup set for individual instances.

For MS_SQL server, you can create backup set either for "All instances" or "individual instances". If you have created backup set for "All instances", Druva does not allow you to create backup set for individual instances. Similarly, if you have created backup set for individual instances, Druva does not allow you to create backup set for all instances. However, if you have created backup set for all instances and the backup set is disabled, Druva allows you to create backup set for individual instances.

Yes, you can trigger the restore for File server backup set and MS-SQL server backup set simultaneously. However, if you trigger a restore request for a File server backup set while another restore is in progress for the same File server backup set, the triggered restore request is queued.

The backup schedule follows the time zone of the Hybrid Workloads agent. For example, if you set the schedule such that backups start at 8 AM, Hybrid Workloads agents located in New York will start the backup at 8 AM EDT and Hybrid Workloads agents located in California will start backups at 8 AM PST, respectively.

An administrative group is a logical categorization of servers that share something in common. For example, servers located in one region can belong to one administrative group. Similarly, servers having the same operating system can belong to another administrative group. To know more about server groups, see Administrator groups.

Yes, you can. You can create backup sets for different databases and attach different backup policies to the backup sets.

Yes, you can adjust the bandwidth at the backup set-level on the Backup Schedule tab.

No, you cannot. However, you can detach a backup policy from a backup set, and attach a new backup policy to the backup set. You can also consider modifying the existing policy to include or exclude databases from backup.

Yes, you can. However, we recommend that you use a single token to activate servers that share something in common. For example, you might want to use a token to activate all MS-SQL server that are geographically co-located.

When you attach a CloudCache to the backup set, Druva backs up the server data as per the policy configuration. Attaching or detaching a CloudCache from the backup set does not impact the backup execution.

Backup proxy is a virtual machine that you must deploy and register for backing up and restoring virtual machines in your VMware setup. Backup proxy contains Hybrid Workloads agent, the component that performs backup and restore of virtual machines. To know more, see Deploy Druva backup proxy.

Backup policies are rules that define the schedule for data backup. You should create backup policies, and attach them to server groups. This ensures that backups from servers belonging to the server group starts according to the backup policies. To know more about backup policies, see About VMware backup policies.

Yes, we do. For more information, see Best Practices to create a Backup Policy. However, for an exact configuration of backup policies that is suitable for your virtual machines, contact the Support.

No, you cannot specify bandwidth as a percentage value. You can only specify the bandwidth in Mbps at the time of creating a backup policy.

No, you cannot create backup sets for your virtual machines.

By default, Druva backs up VMDK files and VMX files. However, only VMDK files are available for restore.

The backup schedule follows the time zone of backup proxy. For example, if you set the schedule such that backups start at 8 AM, backup proxy deployed in New York will start backup at 8 AM EDT and backup proxy deployed in California will start backups at 8 AM PST, respectively.

An administrative group is a logical categorization of virtual machines that share something in common. For example, virtual machines located in one region can belong to a group. Similarly, virtual machines having the same guest operating system can belong to one group.

Yes, you can. You can attach a backup policy that defines backup schedules to a virtual machine. All virtual machines are backed up based on the backup policy you attach to a virtual machine. For more information, see Configure virtual machines for backup.

No, you cannot adjust bandwidth at a virtual machine level. However, you can adjust the bandwidth in a backup policy. Virtual machines inherit the bandwidth settings from the backup policy that is attached to it.

No, you cannot. However, you can detach a backup policy from a virtual machine, and attach a new backup policy to the virtual machine.

Yes, you can. However, we recommend that you use a single token to activate servers that share something in common. For example, you might want to use a token to activate all virtual machines that are geographically co-located.

If you want to change the backup policy, you can consider a reconfiguration.