Skip to main content

 

Druva Documentation

Key concepts and terms

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

Concept/ Term Description

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. 
  • Phoenix does not store your activation tokens. Phoenix uses a unique string to only identify each activation token.

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 group-related activities, such as editing server groups, detaching and attaching backup policies, and managing servers belonging to their server 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. You can create a backup policy and attach the policy to one or more server groups.

The backup policies are assigned to servers groups and not individual servers or virtual machines, which simplify the data backup process for multiple servers or virtual machines.

After you assign servers to server groups, Phoenix backs up the data from the servers according to the schedule defined in the backup policy.

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.

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

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.

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

Retention policy

A retention policy is a set of rules for retaining your data within the storage. Use retention policies to define the length of the time for which you want to retain your historic data.

The main objective of using a retention policy is to keep important data for future access, depending on how critical it is, and how often it will be required. A retention policy also ensures that the data that is no longer required is cleaned from your storage periodically. 

A data retention policy should consider the value of your data, as well as the legal requirements that you might need to adhere to. This means that different types of data will be retained for different durations. For example, a bank's retention period for customers' financial records and facilities inventory records will be different. 

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

Server group

A server group is a logical categorization of servers that share something in common. For example, servers located in one region can belong to one server group. Similarly, servers having the same operating system can belong to one server group.

At the time of creating a server group, you must associate it with storage, and attach backup policies to the server group. Backup policies define the data for backup, and the backup schedule.

Assigning a server to a server group eliminates the need for configuring backup policies for individual servers, thereby simplifying server management.

For more information about how to create server groups, 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

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.

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.