Administrators

The accounts for managing Enterprise Workloads resources. For example, cloud administrators, organization administrators, group administrators, and data protection officers. 

• Cloud administrators: Perform activities such as configuring, managing, and monitoring the Enterprise Workloads.
  Cloud administrators can also create custom administrator roles and assign selective access rights to the role based on the organization’s needs. The custom administrator roles are derived from the three base roles, such as the cloud administrator role, the organization administrator role, and the group administrator role. The custom roles impart distinct capabilities to the administrators to help them to manage entities on the Hybrid Workloads Management Console. For example, you can create a custom cloud administrator role to back up and restore devices, and delete snapshots. You can create another custom cloud administrator role only to restore devices.
• Organization administrators: Manage one or more organizations assigned to them by cloud administrators. 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 read-only access to all configurations within the organizations. They cannot perform any administration action on any entities of the Hybrid Workloads 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 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 Hybrid Workloads 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 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 recovery points, launching failover, and disaster recovery restore.

For more information on administrators and roles, see Manage administrator accounts and Manage administrator roles.

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 Hybrid Workloads agents and instances of backup proxy for virtual machines. Druva generates an activation token when you register a server.

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

Note:

• 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 Hybrid Workloads agents and backup proxies. Even if you remove tokens after activating Hybrid Workloads agents and backup proxies, backups do not stop. 

Availability group

Backup

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 Hybrid Workloads agents on your servers.

Druva supports the following types of backup:

• Full backup: Full backup is a type of backup where Druva 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 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 uses Changed Block Tracking (CBT) provided by VMware to look for changes since the last backup. On SQL servers, Druva looks for updated files in the database to identify the information that changed in the database. Recovery point created after every incremental backup is self-sufficient and can restore the entire server without depending on any other recovery point. 
• Differential backup: Differential backup is a type of backup where Druva 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 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 recovery point is created. If a recovery 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 picks the recovery point created from the last successfully completed full or differential backup job, and

2. Druva 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 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:

• Backup policy type
• Backup schedule
• Retention period
• Platform-specific backup settings

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

• Backup Policies for VMware
• Backup Policies for File server
• Backup Policies for Microsoft SQL
• Backup policies for HyperV
• Backup policies for NAS Shares

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 Hybrid Workloads 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.

Tip:

• 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 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 schedule for VMware
• Backup schedule for File server
• Backup schedule for MS-SQL server
• Backup schedule for HyperV
• Backup schedule for NAS Shares

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:

• Backup content, such as content rule or custom content
• Backup policy

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:

• Content rule
• Custom content

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

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 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.

Cloud

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

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

CloudCache

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

At periodic intervals, 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 CloudCache and its deployment, see CloudCache.

Credits

With credits, you can pre-purchase Druva storage and in-effect pay only for the storage that you consume. Druva dashboard provides various credits and consumption-related graphs to track the purchased credits and storage consumption on the Druva 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 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 performs global deduplication ensuring only unique data blocks from all your servers are backed up so a single instance can be restored. 

Data deduplication allows users to reduce redundant data and more effectively manage backup activity, as well as ensuring more effective backups, cost savings, and load balancing benefits.

Let us consider an organization performs full-file incremental backups of files, where only a few bytes have changed, and occasionally performs full backups due to age-old design challenges in backup systems. A 10 TB file server would create 800 TB of backups just from eight weekly fulls, and probably another 8 TB or so of incremental backups over the same amount of time. A good deduplication system can reduce this 808 TB down to less than 100 TB – without lowering restore speed.

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 Disaster Recovery. The account maintains the EBS recovery points for the virtual machines. At the time of disaster, you can launch EC2 instance from these EBS recovery points, 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 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 recovery 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 CloudCache license determines the size of 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, 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 Hybrid Workloads 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. The link between Druva 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. 

Organizations

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 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.

Hybrid Workloads agent

Hybrid Workloads agent is the client-side component of the Druva that you can deploy locally on the servers. The Hybrid Workloads 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 Hybrid Workloads agent on all servers that you want to back up.

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 executes pre-backup scripts before a backup job and a post-backup script after a backup job to perform specific tasks.

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.

Restore

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

Druva supports the following types of restore:

• Restore of hot recovery points: If you deployed CloudCache for your Druva setup, you can restore hot recovery points of your servers. Such restore operations are on-demand in nature. Restores of hot recovery points startrecovery points immediately and continue till your server data is restored to the location that you specified.

Note: To perform a hot restore, you can use recovery points that appear under Hot on the Restore Overview window.

• Restore of warm recovery points: Restores of warm recovery points are on-demand restores of server data. Such data is stored in the warm storage. Restores of warm recovery points start immediately and continue till your server data is restored to the location that you specified.

  For CloudCache deployments, if a few data blocks remain in CloudCache and are not fully transferred to the Cloud, then any attempts to restore from warm snapshots during a CloudCache disconnection, will fail.

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

• Restore Virtual Machines
• Restore a NAS Share

Recovery point

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

Druva supports the following types of recovery points:

• Hot recovery point:  Druva creates hot recovery points if you deploy CloudCache for your Druva setup. A hot recovery point is a point-in-time image of backup data that is stored on CloudCache. CloudCache synchronizes the recovery points to the cloud storage by following the pre-defined schedule.

Note: Recovery points that reside on CloudCache appear under Hot on the Restore Overview window.

• Warm recovery point: A warm recovery point is a point-in-time image of the backup data. Druva directly backs up the data from the servers to the warm storage, where it stays and is referred to as "warm recovery points".
• Cold recovery point: Cold recovery points are point-in-time copies of backup data older than 15 days. These recovery points are stored in the Amazon Glacier Deep Archive. Typically, cold recovery points are maintained for:
  • Long term data which over a period is hardly accessed or restored.
  • Need to store this data for compliance and audit purposes.
  • Cheaper storage and cost savings.

  At the time of restore, data from the cold tier is retrieved, moved temporarily to the warm tier, and then restored.

  Once you click Restore and initiate the restoration process, the data retrieval from cold tier and its restore from the warm tier happen automatically. Warmed up data is deleted from the warm tier after 10 days.  

Storage

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

You can pre-purchase Druva 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 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 Credits.  

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

Warm storage: Warm storage is used to hold the server data. Druva 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 recovery points 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 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 Hybrid Workloads agent to recognize a VSS provider.

VMware transport mode

Druva 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.