Skip to main content

How can we help you?

Druva Documentation

Key concepts and terms

This article outlines the key concepts and terms used in Druva Phoenix.

Concept/Term Description



The accounts for handling different responsibilities in Druva Phoenix. For example, cloud administrators, organization administrators, and group administrators.

  • Cloud administrators: Perform activities such as configuring, managing, and monitoring the Druva Phoenix setup.
  • Organization administrators: Manage one or more organizations assigned to them by cloud administrator. An organization administrator can create and manage group administrators for organizations assigned to them.
  • Group administrators: Manage administrative group-related activities such as managing servers belonging to the administrative groups.
  • Cloud administrators (View only): Have the read-only access to all configurations within the organizations. They cannot perform any administration action on any entities of the Phoenix Management Console. However, they can change their own profile-related settings, such as the name and time zone, and can view, download, and send reports and audit trails.
  • Organization administrators (View only): Have the read-only access to all configurations within the organization(s) they have access to. They cannot perform any administration action on the entities on the Phoenix Management Console. However, they can change their own profile-related settings, such as name and time zone, and can view, download, and send reports and audit trails.
  • Group administrators (View only): Have the read-only access to the administrative groups that they are associated with. However, they cannot manage any administrative group. They can also view, download, and send reports and audit trails.
  • Data Protection Officer: Performs activities such as configuring the audit trails and reports, enabling and disabling backups, triggering backups, restoring data to the original or alternate location, deleting the restore points, launching failover, and disaster recovery restore.

Administrative groups

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 one administrative group.

An administrative group allows you to organize your servers for better management. You can optionally assign a group administrator to the administrative group to manage servers.

To configure servers for backup, it is mandatory that you create an administrative group and attach servers to it.

Activation token

An activation token is used to activate Phoenix agents and instances of backup proxy for virtual machines. Druva Phoenix generates an activation token when you register a server.

Druva Cloud uses the activation token to perform a one-time authentication of Phoenix agents or backup proxies. After authentication, Phoenix agents or backup proxies establish a persistent connection with Druva Cloud.


  • You can configure a token to activate as many agents or backup proxies as you want. However, we recommend that you use a single token to activate servers or virtual machines that share something in common. For example, you might want to use a token to activate all servers that are geographically co-located. 
  • Activation tokens only perform a one-time authentication of Phoenix agents and backup proxies. Even if you remove tokens after activating Phoenix agents and backup proxies, backups do not stop. 

Availability group

The Always On availability group is a database mirroring technique for MS-SQL server. It supports a replicated environment for availability databases, which are a discrete set of user databases.

An availability group supports one set of primary databases and one to eight sets of secondary databases. With Always On availability group, you can now back up your databases from the secondary node.  For more information about MS-SQL availability group, see Overview of Always On Availability Groups.


The backup is the process of copying and archiving data from servers to the storage designated for this purpose. To enable backup from your servers, you must install and activate Phoenix agents on your servers.

Druva Phoenix supports the following types of backup:

  • Full backup: Full backup is a type of backup where Druva Phoenix backs up all the files that you select. The first backup of your servers is always a full backup.
  • Incremental backup: Incremental backup is the type of backup where Druva Phoenix backs up only the changed data since the last backup. This last backup can be a full backup or an incremental backup. Subsequent backups from your servers are always incremental in nature. On VMware, Druva Phoenix uses Changed Block Tracking (CBT) provided by VMware to look for changes since the last backup. On SQL servers, Druva Phoenix looks for updated files in the database to identify the information that changed in the database. Restore point created after every incremental backup is self-sufficient and can restore the entire server without depending on any other restore point. 
  • Differential backup: Differential backup is a type of backup where Druva Phoenix backs up the data changed since the last full backup. As the name suggests, it is the backup of the difference since the last full backup.
    The advantage of a differential backup is in the quick recovery because a complete restore requires only a full backup and the last differential backup. 
    Note: Druva Phoenix supports differential backups only for SQL servers. 
  • Transaction log backup: Transaction logs in SQL record all the database changes after every transaction. The Transaction Log backup feature backs up the logs that record database changes. Transaction logs for a SQL server handling high traffic are updated every few minutes. To keep the transaction log backup updated, the Transaction Logs option in the backup policy lets you choose time intervals of 5, 10, 15, 30, 45, 60, or 120 minutes. 

    Transaction log backup is triggered after a full backup of the SQL server is executed and a restore point is created. If a restore point of the SQL server is not created, transaction log backup jobs are not triggered. 

    When a point-in-time restore is triggered,

  1. Druva Phoenix picks the restore point created from the last successfully completed full or differential backup job, and

  2. Druva Phoenix uses the backed up transaction log to restore the database up to a transaction that is closest to the date and time you specify. The closest transaction can be the transaction that occurred right before the date and time you specify, or if exists, the transaction that occurred at the specified date and time.

Note: Transaction log backups are specific to SQL servers.

Backup policy

 Backup policy is set of rules that define the schedule for automatic backups and retaining data within the storage. You can create a backup policy and attach the policy to one or more servers during configuration. Druva Phoenix backs up the data from the servers according to the schedule defined in the backup policy.

Backup policy is a combination of the following components:

For more information about how to create backup policies, see:

Backup proxy

Backup proxy is a virtual machine that you must deploy and register for backing up and restoring virtual machines in your VMware setup. The backup proxy contains Phoenix agent, which performs backup and restore of virtual machines.

Backup proxy pool


The backup proxy pool is a collection of backup proxy servers.

The backup proxy pool eliminates the need to manually map the virtual machines to an individual backup proxy server. All backup requests from the virtual machines are assigned to the backup proxy servers from the mapped backup proxy pool based on the load balancing mechanism.


  • For geographically distributed ESXi servers managed by single vCenter, create one backup proxy pool per geographic organization or remote location. Add the backup proxies deployed locally in that organization or location to the backup proxy pool. Assign the backup proxy pool to virtual machines locally present in that geographic organization.

    For example, an XYZ company has a main organization in Switzerland and three remote locations, one in Singapore, one in Germany, and one in China. At each location, an ESXi host is deployed that manages different virtual machines implemented at that location. A vCenter server is deployed at the main organization at Switzerland, which manages the ESXi host at each remote location.

    Now, to efficiently perform the backup and restore activities, we recommend to deploy backup proxy at each remote location. Create a backup proxy pool at each organization and add the locally deployed backup proxy to the respective backup proxy pool. Finally, assign this backup proxy pool to the virtual machines locally present at each location.
  • For a data center, single backup proxy pool is sufficient. However, you can create multiple backup proxy pools if you want to assign dedicated backup proxy resources to certain virtual machines.

Backup schedule

Backup schedule defines when to automatically backup the server data. Druva Phoenix backs up the data from the servers according to the schedule defined in the backup policy.

A backup schedule comprises of the start time, duration after which you want backup operations to stop, maximum bandwidth that each server can consume, and the days on which you want backups to occur.

For more information about backup schedules, see:

Backup set

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.

A backup set is defined for a server and is a combination of the following components:

A backup set is associated with a backup set type, such as File or MS-SQL. Each File or MS-SQL server can have multiple backup sets attached to it. 

In case of a VMware setup or a Hyper-V host, a backup set is a virtual machine with backup policy attached to it. 

Backup content

Backup content in a backup set specifies what data should be backed up on a server. The backup content is of two types:

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. 

Backup mount A folder in the ZFS pool of the Phoenix Backup Store that is shared through the NFS. Data written to this shared folder is backed up to the Druva Cloud. When you create a Backup Mount on the Phoenix Management Console for a registered Phoenix Backup Store, a shared directory with the Backup Mount name you specify is created on the ZFS pool of the Phoenix Backup Store and shared through the NFS. 

Content rule

When you create a content rule, you choose file types and folders to backup. You can also choose folders and file types to exclude from the backup. By default, Druva Phoenix provides a content rule that already includes certain file types and folders for backup.

For more information about the content rule, see Manage Content rules.


Druva Cloud is a term used to refer to your complete Druva Phoenix setup.

Druva Cloud includes Phoenix agent or backup proxy, and the cloud storage to which your data is saved.


Phoenix CloudCache is a dedicated server in the local environment that locally stores backup and restore data from Phoenix agents.

At periodic intervals, Phoenix CloudCache synchronizes this stored data to Druva Cloud. If you want to ensure faster backups and restores, you can set up CloudCache for your organization.

For more information about Phoenix CloudCache and its deployment, see Phoenix CloudCache.


With credits, you can pre-purchase Druva Phoenix storage and in-effect pay only for the storage that you consume. Druva Phoenix dashboard provides various credits and consumption-related graphs to track the purchased credits and storage consumption on the Druva Phoenix Portal. The credit balance and cumulative credits used till date are updated based on the storage consumption at 12:15 AM UTC, every day. For more information about credits and various credit consumption scenarios, see Druva Phoenix Credits.

 Custom content

Custom content is the type of backup content that you can define for the physical servers. You can create a custom content, and save it with a name and use it later in other backup sets that you create. Once a custom content is defined for a server, you cannot reuse it for another server until you save it.

Data deduplication

Deduplication optimizes storage by removing duplicate copies of same data. Druva Phoenix performs global deduplication ensuring only unique data blocks from all your servers are backed up. 

Disaster recovery plan

The disaster recovery (DR) plan is a set of rules for recovering your data in case of emergency or disaster.

A DR plan defines the following:

  • AWS account: The account in AWS that acts as a secondary site for Phoenix DraaS. The account maintains the EBS snapshots for the virtual machines. At the time of disaster, you can launch EC2 instance from these EBS snapshots, in-turn spinning up to production in minutes.
  • AWS region: The storage region where you want to create DR copies for the virtual machines. The region of the DR plan and region of the storage to which the virtual machine is backing the data to must be same.
  • Update frequency: The frequency at which Druva Phoenix updates the DR copy. Based on the defined frequency, on each schedule, the existing DR copy, if present, is replaced with a DR copy based on the latest restore point available for the virtual machine.

Data volume

A data volume is a discrete unit of storage on a tape, disk, or other media that supports data. Data volumes are storage blocks to which data can be saved.

The Phoenix CloudCache license determines the size of Phoenix CloudCache for your setup. A data volume permits you to consume a portion of this storage. You can only consume a portion of the storage that is equivalent to the size of the data volumes that you create. If your setup requires more storage, you can add up to 10 data volumes, and set a size for these data volumes. Because you add multiple data volumes, Phoenix CloudCache can be scaled to match the size requirements of your server data.

Failover Cluster Instance (FCI)

An FCI is a single instance of SQL Server that is installed across Windows Server Failover Clustering (WSFC) nodes and, possibly, across multiple subnets. On the network, an FCI appears to be an instance of SQL Server running on a single computer, but the FCI provides failover from one WSFC node to another if the current node becomes unavailable.

NAS Proxy

It is the Phoenix agent installed on Windows or Linux server and handles the backup and restore requests from NAS Shares. You need to install and activate the NAS Proxy to establish connectivity with Druva Phoenix. The link between Druva Phoenix and a NAS device is established when you map a NAS Proxy to a NAS device. Once mapped, you can attach the proxy to a backup set to perform backup and restore. You can map multiple proxies to a device and can also attach it to multiple backup sets. 



You need to identify the geographical locations of all your resources and based on that decide on the organizations that you need to create. You can also create different organizations for the departments that do not share any data. Similarly, you can create organizations for the entities within a corporation that need complete partitioning of their data and other configuration entities, such as backup policies, but need a common dashboard for storage usage and credit consumption across such entities.

For example, suppose Druva Phoenix customer is a central IT organization, which provides backup and restore to several internal groups. Servers and policies belonging to each internal group are independently managed within an organization. Servers, administrative groups, and policies in one organization cannot be accessed in other organization. Also, an organization administrator can be assigned to each organization who has complete control over that particular organization but not to other organizations.

For information about configuring organizations, see Configure Organizations.

Phoenix agent

Phoenix agent is the client-side component of the Druva Phoenix that you can deploy locally on the servers. The Phoenix agent communicates with Druva Cloud for backing up and restoring the data.

To enable backup and restore of server data, you must install and activate the Phoenix agent on all servers that you want to back up.

Phoenix Backup Store An NFS server with Druva binaries installed on it. The Phoenix Backup Store has a ZFS pool using the disks available on the Phoenix Backup Store, and the Backup Mounts in the ZFS pool are shared through the NFS. Data written to a Backup Mount on the Phoenix Backup Store is converted to a snapshot and backed up to the Druva Cloud. Similarly, data is restored from the Druva Cloud to a Backup Mount on the Phoenix Backup Store. 

Pre and post-script settings

You can configure file server and NAS backup policies with pre-backup and post-backup scripts to perform specific tasks before and after a backup job. Druva Phoenix executes pre-backup scripts before a backup job and a post-backup script after a backup job to perform specific tasks.

For more information about pre-backup and post-backup scripts, see Pre-backup and post-backup scripts for File server and Pre-backup and post-backup scripts for NAS.

Retention period

The retention period is the duration for which server data is retained on Druva Cloud.

At the end of this period, Druva Cloud purges the data that you chose to delete.

For example, if you back up data on the first day of a month and set the retention period to 15 days, Druva Cloud performs a check to determine if you deleted some portion of this data. At the end of the 15-days period, Druva Cloud purges the data that you deleted already. You can define the retention period at the time of configuring Druva Cloud.


The restore is the process of retrieving backup data that Druva Phoenix stores. In the event of data loss or corruption, you can restore server data that you previously backed up.

Druva Phoenix supports the following types of restore:

  • Restore of hot snapshots: If you deployed Phoenix CloudCache for your Druva Phoenix setup, you can restore hot snapshots of your servers. Such restore operations are on-demand in nature. Restores of hot snapshots start immediately and continue till your server data is restored to the location that you specified.
Note: To perform a hot restore, you can use snapshots that appear under Hot on the Restore Overview window.
  • Restore of warm snapshots: Restores of warm snapshots are on-demand restores of server data. Such data is stored in the warm storage. Restores of warm snapshots start immediately and continue till your server data is restored to the location that you specified.

For more information about how to restore servers and virtual machines, see 


A snapshot is a point-in-time image of backup data. It indicates the state of the backup data at a particular point-in-time.

Druva Phoenix supports the following types of snapshots:

  • Hot snapshot:  Druva Phoenix creates hot snapshots if you deploy Phoenix CloudCache for your Druva Phoenix setup. A hot snapshot is a point-in-time image of backup data that is stored on Phoenix CloudCache. Phoenix CloudCache synchronizes the snapshots to the cloud storage by following the pre-defined schedule.
Note: Snapshots that reside on Phoenix CloudCache appear under Hot on the Restore Overview window.
  • Warm snapshot: A warm snapshot is a point-in-time image of the backup data. Druva Phoenix directly backs up the data from the servers to the warm storage, where it stays and is referred to as "warm snapshots".


A storage is a location in the cloud where Druva Phoenix stores data backed up from different servers.

You can pre-purchase Druva Phoenix storage using credits depending on your data needs and location preferences, and in-effect pay only for the storage that you consume. The purchased storage is translated into credit allocation. For example, if you have purchased a 10-TB Druva Phoenix storage for a contract term of one year, 120 credits (TB months) are allocated to your account. You can effectively track the purchased credits and storage consumption using Dashboard. For more information about credit usage, see Druva Phoenix Credits.  

Note: If you have a Business license,  you can purchase Druva Phoenix storage only in one AWS region. 

Warm storage: Warm storage is used to hold the server data. Druva Phoenix directly backs up data from servers to warm storage where the data stays. Because the warm storage is fast in performance, restoring of the data in warm storage is "on-demand" in nature, and starts immediately. 

For more information about storage, see Storage.

Volume Shadow Copy Service (VSS)

Volume Shadow Copy Service (VSS) is a Windows service for capturing and creating snapshots that are called as shadow copies. VSS, which operates at the block level of the file system, provides a backup infrastructure for Microsoft operating systems.

Druva Phoenix instructs Microsoft VSS to create shadow copies of data on Windows servers. When shadow copies are created on the same volume they can result in heavy input and output load. Therefore, if VSS is enabled, administrators can configure the operating system to create shadow copies on a separate volume.

Consult your Windows operating system documentation for further information about making this configuration change.

For more information about configuring a VSS provider, see Configure Phoenix agent to recognize a VSS provider.

VMware transport mode

Druva Phoenix backup proxy can access virtual machine data from data stores using three different methods – NBD, HotAdd, NBDSSL. These methods are referred to as VMware Transport modes.

For more information about transport mode, see Transport modes.