Skip to main content

 

Druva Documentation

Key concepts and terms

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

Concept/Term Description

Administrators

 

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

  • Cloud administrators: Perform activities such as configuring, managing, and monitoring the 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.

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. Phoenix generates an activation token when you register a server.

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

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

Phoenix supports the following types of backup:

  • Full backup: Full backup is a type of backup where 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 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, Phoenix uses Changed Block Tracking (CBT) provided by VMware to look for changes since the last backup. On SQL servers, 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 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: 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. Phoenix picks the restore point created from the last successfully completed full or differential backup job, and

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

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

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. 

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

Cloud

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

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

CloudCache

Phoenix CloudCacheis 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 Phoenix Cloud. If you want to ensure faster backups and restores, you can set up CloudCache for your organization.

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

Credits

With credits, you can pre-purchase Phoenix storage and in-effect pay only for the storage that you consume. Phoenix dashboard provides various credits and consumption-related graphs to track the purchased credits and storage consumption on the 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 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. Phoenix performs global deduplication ensuring only unique data blocks from all your servers are backed up. An organization is an access-based control mechanism to configure servers for backup and restore. An organization creates a logical partitioning of the entities, such as servers, backup policies, and so on. You can create a new organization or use the Default Site (organization) provided by Phoenix to register the servers.

Defreeze operation

De-freeze is the process of preparing cold snapshots for restore. During a defreeze operation, Phoenix retrieves cold snapshots from archival storage and makes the data available for restore.

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: Your account in AWS that acts as a secondary site for Phoenix disaster recovery. The account maintains the AMI for the virtual machines. At the time of disaster, you can launch EC2 instance from these AMI, in-turn spinning up to production in minutes.
  • AWS region: The storage region where you want to create AMIs for your virtual machines. The region of the DR plan and region of the storage to which the virtual machine is backing up the data to must be same.
  • AMI update frequency: The frequency at which the AMI is updated. Based on the defined frequency, on each schedule, the existing AMI, if present, is replaced with an AMI 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 Phoenix. The link between 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. 

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 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 Phoenix that you can deploy locally on the servers. The Phoenix agent communicates with Phoenix 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.

Pre and post-script settings

You can configure the File server backup policy with the settings for pre-backup and post-backup scripts to perform customer-driven processing tasks. Pre-backup scripts are executed before backup jobs to perform the specific pre-backup operation. Post-backup scripts are executed after backup jobs to perform the specific post-backup operation.  For more information about pre-backup and post-backup scripts, see Pre-backup and post-backup scripts for File server.

Retention period

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

At the end of this period, Phoenix 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, Phoenix Cloud performs a check to determine if you deleted some portion of this data. At the end of the 15-days period, Phoenix Cloud purges the data that you deleted already. You can define the retention period at the time of configuring Phoenix Cloud.

Restore

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

Phoenix supports the following types of restore:

  • Restore of hot snapshots: If you deployed Phoenix Cloud for your 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 dating back to 90 days in time. 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.
  • Restore of cold snapshots: Restores of cold snapshots are on-request restores of server data dating back to more than 90 days in time. Such data is stored in cold storage and requires a two-step procedure for restoration. 

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

Snapshot

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.

Phoenix supports the following types of snapshots:

  • Hot snapshot:  Phoenix creates hot snapshots if you deploy inSync CloudCache Server for your Phoenix setup. A hot snapshot is a point-in-time image of backup data that is stored on inSync CloudCache Server. inSync CloudCache Server synchronizes the snapshots to the cloud storage by following the pre-defined schedule.
Note: Snapshots that reside on inSync CloudCache Server appear under Hot on the Restore Overview window.
  • Warm snapshot: A warm snapshot is a point-in-time image of the backup data dating back to 90 days in time. Phoenix directly backs up the data from the servers to the warm storage, where it stays for 90 days and is referred to as "warm snapshots".
  • Cold snapshot: A cold snapshot is a point-in-time image of backup data dating back to more than 90 days in time. Phoenix transfers the data from warm storage, which is more than 90 days old to the cold storage. After the data is transferred, it is referred to as "cold snapshot". 
Note: You cannot delete cold snapshots. Cold snapshots get deleted as per the retention period.   

Storage

A storage is a location in the cloud where Phoenix stores data backed up from different servers. A single instance of storage is a combination of warm storage and cold storage.

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

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

Types of Phoenix storage

  • Warm storage: Warm storage is used to hold the server data that is less than 90 days old. Phoenix directly backs up data from servers to warm storage where the data stays for 90 days. Because the warm storage is faster in performance, restoring of the data in warm storage is "on-demand" in nature, and starts immediately. 
  • Cold storage: Cold storage is used to hold server data that is more than 90 days old. The data, which is residing in the warm storage and which is more than 90 days old, is transferred to cold storage. In cold storage, the data stays for the number of days that you specify.
    Cold storage is slower in comparison to warm storage, and that is why restores of data stored in cold storage are "on-request" in nature. Such restores are usually two-step operations, where data is defreezed first, and restored later.
    For information about restoring data from cold storage, see:
  • Restore a virtual machine
  • Restore a File server
  • Restore a MS-SQL server
  • Virtual Machine Restore
  • Restore a NAS Share

For more information about storage, see Storage.

Thawed data

Thawed data is a cold snapshot that has undergone a defreeze operation. This data is available for a specific duration, during which you can initiate a restore operation. However, if you do not initiate a restore during this duration, the thawed data becomes "cold" again. You must defreeze this data again before performing a restore. 

For more information about how to defreeze data, see

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.

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

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.

Workload A workload is the type of server data that you want to backup. For example, files and folders on a server, databases, or virtual machines.