Skip to main content
Druva Documentation

Understanding Phoenix workflows

These workflow diagrams explain the backup and restore processes for File servers, MS-SQL servers, NAS, and VMware infrastructure:

Data backup workflow

The following diagram illustrates how data flows within the Phoenix setup at the time of data backup. 

Step Description

Step 1

Phoenix agents installed on servers, back up server data according to the schedule defined in the backup policy. At the scheduled time, Phoenix Cloud initiates backups from servers on which Phoenix agents are installed.

Step 2

Phoenix agents attempt to communicate with Phoenix Cloud following a response-request messaging pattern over WAN.

Step 3

Phoenix Cloud validates agent communication requests. Upon successful validation, Phoenix Cloud assigns agent requests to storage.  

Step 4

Phoenix agents back up data to storage. 

Warm restore workflow 

A warm restore is a restore of data using snapshots that date back to 90 days in time (also referred to as warm snapshots). 

The following diagram illustrates how data flows within the Phoenix setup at the time of warm restore. 

Step Description

Step 1

Phoenix agents installed on servers send restore requests for data dating back to 90 days in time over WAN.

Step 2

Phoenix Cloud validates the requests and assigns them to storage. 

Step 3

Phoenix agents restore data from the storage that Phoenix Cloud assigned.  

Cold restore workflow 

A cold restore is a restore using snapshots that date back to more than 90 days in time (also referred to as cold snapshots). 

The following diagram illustrates how data flows within the Phoenix setup at the time of cold restore. 

Step Description

Step 1

Phoenix agents installed on servers send restore requests for data dating back to more than 90 days in time over WAN.

Step 2

Phoenix Cloud validates the requests and assigns requests to archival storage. The archival storage starts a defreeze operation to prepare data for restore. Phoenix sends an email to administrators to inform about the defreeze operation that is in progress. 

Step 3

The data is thawed and is ready for restore. This data is available in the warm storage that the Phoenix Cloud assigned. 

Step 4 

Phoenix agents restore data from the warm storage that Phoenix Cloud assigned. 

File server backup workflow 

Phoenix Editions: File:/tick.png Business File:/cross.png Enterprise File:/tick.png Elite

This article provides the workflow diagrams and the steps for data backup from the following operating systems:

Note:  If you restart or reboot your servers during backups, the backup operation is aborted. Phoenix agent starts a fresh backup following the backup schedule. Alternatively, you can start a manual backup at any time. 

File servers with Windows operating system

This topic explains how data flow during data backup from the File servers with Windows operating system.

file server backup on windows1.png

Backup workflow

Step Operation

Step 1

A backup request is initiated and forwarded to the Phoenix agent. 

Phoenix checks if Phoenix agent is running. 

  • If the agent is running, Phoenix performs the backup operation.
  • If the agent is not running, Phoenix performs the backup operation based on the type of backup job.
    • For a backup now job, Phoenix fails the backup request.
    • For a scheduled job, Phoenix waits until the expiry window of the backup request, else fails the backup request.

Step 2

Phoenix determines the type of backup.

If you or another administrator initiates the first backup, Phoenix performs a full backup. All subsequent backups triggered by administrators are incremental backups.

Step 3

 

Phoenix agent verifies that the VSS service is running. If the VSS service is not running, Phoenix agent starts the VSS service and instructs VSS to create a snapshot. 

Phoenix agent validates if snapshots are created successfully.

Step 4

Phoenix agent estimates the files and data to back up.

Step 5

 

  1. If snapshots are created successfully, Phoenix agent uses the VSS snapshots as the filesets for data backup to Phoenix Cloud.
  2. If the snapshots are not created successfully, Phoenix agent scans the live files and folders to create filesets for data backup to Phoenix Cloud.

Note: In case of VSS snapshots, Phoenix includes the locked files in the backup. However, in case of live folders and files scan, Phoenix considers locked files as missed files, and attempts to back up such files at the time of the next scheduled backup.

Step 6

After the backup completes, Phoenix agent deletes the created VSS snapshots.

File servers with Linux operating system

This topic explains how data flow during data backup from the File servers with Linux operating system.

file server backup on linux1.png

Backup workflow

Step Operation

Step 1

A backup request is initiated and forwarded to the Phoenix agent.

Phoenix checks if Phoenix agent is running. 

  • If the agent is running, Phoenix performs the backup operation.
  • If the agent is not running, Phoenix performs the backup operation based on the type of backup job.
    • For a backup now job, queues the backup request. The backup request is executed after Phoenix agent starts.
    • For a scheduled job, skips the backup request.

Step 2

Phoenix determines the type of backup.

If you or another administrator initiates the first backup, Phoenix performs a full backup. All subsequent backups triggered by administrators are incremental backups.

Step 3

Phoenix agent performs the full scanning of live files and folders on the File server.

Step 4

Phoenix agent estimates the files and data to back up. 

Step 5

Phoenix agent uses the scanned folders and files as the fileset for data transmission. 

Note: Phoenix considers locked files as missed files, and attempts to back up such files at the time of the next scheduled backup. 

File server restore workflow

Step Operation

Step 1

You or another administrator initiates a restore operation.

You can restore the data at the original location or an alternate location. The alternate location can be the same server and different path or different server and different path.

You can select the destination server where restore can happen for the selected File server restore point. For example, Windows server for Windows restore and Linux server for Linux restore.

Step 2

Phoenix checks if Phoenix agent is running. 

  • If the agent is running, Phoenix performs the restore operation.
  • If the agent is not running, Phoenix queues the restore request and performs the restore operation after Phoenix agent starts.

Step 3

Phoenix validates the restore destination. 

Step 4

Phoenix checks the free space available at the restore destination.

Step 5

Phoenix identifies the file sets for restore.

Step 6

Phoenix starts the restore operation and sequentially downloads the filesets to the restore destination.

 Note: For more information about restoring File servers, see Restore a File server to the same serverRestore the File server to a different server.

NAS Share backup workflow

Phoenix Editions: File:/tick.png Business File:/cross.png Enterprise File:/tick.png Elite

This article provides the workflow diagrams and steps for data backup of NAS shares on Windows and Linux. 

Backup workflow

The following workflow illustrates the data flow during backup of NAS shares on Windows or Linux: 

NASBackupWorkflow.png

 

The following table summarizes the workflow steps. 

Step Operation

Step 1

 A backup request is initiated and forwarded to the NAS proxy. 

Step 2

 

Phoenix checks if the NAS proxy is running. 

  • If the proxy is running, Phoenix performs the backup.
  • If the proxy is down, Phoenix performs the backup based on the type of backup job, as specified below.
    • For a backup now job, Phoenix queues the backup request. Phoenix completes the request after the NAS proxy starts.
    • For a scheduled job, Phoenix skips the backup request.

Step 3

 

Phoenix determines the type of backup.

If it is the first backup from any source, Phoenix performs a full backup. The subsequent backups are incremental backups.

Step 4

Phoenix agent performs a full scan of the files and folders on the NAS share.

Step 5

NAS proxy sends the scanned files and folders for backup to Phoenix Cloud.

Note: If Phoenix is unable to back up  locked files at the first attempt, it checks if the files are unlocked at the end of the backup. If the files are unlocked, they are backed up in the same backup cycle.  Locked files are not backed up.
Step 6 Phoenix Cloud applies deduplication and saves incremental data in snapshots.

 

NAS Share restore workflow

Phoenix Editions: File:/tick.png Business File:/cross.png Enterprise File:/tick.png Elite

Workflow to restore on the source NAS share 

RestoreToSameLocation.png

Workflow to restore on a different NAS share 

RestoreToAlternateLocation.png

Steps to restore a NAS device

Step Operation

Step 1

You initiate a restore operation.

You can select the destination share for the restore of the selected NAS restore point. For example, SMB share for a Windows restore and NFS share for a Linux restore.

Step 2

Phoenix checks if the NAS proxy is running. 

  • If the proxy is running, Phoenix performs the restore operation.
  • If the proxy is not running, Phoenix queues the restore request and performs the restore operation after the NAS proxy starts.

Step 3

Phoenix checks whether the share type of the restore destination is same as the sources and validates the restore request.

Step 4

Phoenix identifies the snapshots to restore.

Step 5

Phoenix starts the restore operation and sequentially downloads the snapshots to the restore destination.

 Note: For more information about restoring a NAS share, see Restore a NAS share.

What you must know about NAS share restore 

This section highlights the important considerations of the NAS share restore:

  • Hot snapshots reside on the Phoenix CloudCache for the period specified in the CloudCache configuration. See Configure Phoenix CloudCacheCloudCache for information on the configuration.
  • If you are a group administrator, you can restore data only to the NAS share that belongs to the administrative group that you manage. Cloud administrators can restore data to shares across all administrative groups.
  • You can restore data only to a share that has the same operating system as the source share. 
  • In the event of a network connection failure during restore, the NAS proxy attempts to connect to the Phoenix Cloud. After the network connection is restored, the NAS proxy restarts the restore from the state where it was interrupted. 
  • If you restart or reboot the NAS device during a restore, the restore operation is aborted. 
  • If you choose to restore data to the same location, the existing data at that location is overwritten unless a different restore setting is configured.
  • The snapshot timestamps are displayed according to the server time zone. For example, for servers located in New York and London, the timestamps are displayed according to EST and UTC time zones, respectively.
  • Restores are not supported to mapped drives.
  • For SMB shares:
    • The following file attributes are supported:
      • Not content-indexed
      • Read-only
    • All the Access Control Lists (ACLs) are restored.
  • For NFS shares,
    • File permissions for file owners, groups, and users are restored.
    • File attributes are not supported.
    • ACL permissions are not supported.
    • The following special permissions for files and folders are not supported:
      • Setgid
      • Sticky bit
      • Setuid
  • Backup and restore can run simultaneously on the same agent.
  • The backup request triggered while a restore is in progress will be queued.
  • Full scan restore will be marked with an  icon.

VMware virtual machine backup workflow 

Phoenix Editions: File:/tick.png Business File:/cross.png Enterprise File:/tick.png Elite

Phoenix performs backup on virtual machines based on the schedule defined in the backup policy, that virtual machine is a part of or an on-demand backup triggered from Phoenix Management Console. This involves interaction of Phoenix components and VMware components.

The following diagram depicts the data flow at the time of backing up virtual machines.

|View larger image|

Virtual machine backup workflow

Step Operation

Step 1

Virtual machine backup request is initiated based on,

  • Schedule defined in the backup policy.
  • Manual backup

Phoenix forwards the backup request to backup proxy pool.

  • Based on the load balancing algorithm, Phoenix automatically identifies the backup proxy that will run the backup request.
  • If the identified backup proxy is busy, the backup request is queued and initiated when the backup proxy becomes free.

Step 2

  • In an environment where virtual machines are deployed on ESXi hosts managed by vCenter server, backup proxy contacts vCenter Server to locate the virtual machine and obtains its configuration.
  • In an environment where virtual machines are deployed on standalone ESXi hosts, backup proxy contacts ESXi host to obtain the virtual machine configuration.

Backup proxy queries the ESXi hypervisor or the vCenter server for the VMDK files, and the VMX files of the virtual machines.  

Step 3

Phoenix determines the type of backup. 

  • If this is the first automatic backup, Phoenix performs a full backup. 
  • For all subsequent backups, Phoenix performs an incremental backup. 

Backup proxy takes a snapshot of the virtual machine and prepares for backup.

Step 4

VDDK connection is established with the virtual machine with SSL transport mode.

Step 5

Backup proxy contacts the virtual machine and establishes a read-only connection to backup virtual machine data.

Step 6

Backup proxy uses the snapshots of the virtual machines to read the VMDK files for the backup. It copies virtual machine data and prepares to send it to Phoenix CloudCache (if configured) or Phoenix Cloud.

Encrypted VMDK backup through the NBD mode is not supported. Encrypted VMDK disks can be backed up either using NBDSSL or HotAdd. Here are the supported transport modes for virtual machine disk backup:

Backup proxy Virtual Machine Transport mode
Encrypted Encrypted HotAdd
Unencrypted Encrypted NBD-SSL
Encrypted Unencrypted HotAdd

Note: The backup proxy creates a snapshot on the local datastore. Ensure that enough storage is available on the datastore for the snapshot. 

Step 7

Backup proxy transfers the snapshot data in a continuous stream to Phoenix Cloud. Before transferring the data to the Phoenix Cloud, backup proxy performs the de-duplication.

After the backup completes, backup proxy deletes the snapshot. 

To know more about virtual machine backup, see Backup and Restore VMware Virtual Machines.

VMWare virtual machine restore workflow

 

 

Step Operations

Step 1

Phoenix administrator initiates virtual machine restore. Phoenix forwards the restore request to the backup proxy pool.

  • Based on the load balancing algorithm, Phoenix automatically identifies the backup proxy that will fulfill the restore request.
  • If the identified backup proxy is busy, the restore request is queued and initiated when the backup proxy becomes free.

Step 2

Phoenix performs a check to ensure that the restore location is not a Network-attached Storage (NAS).

  • In an environment where virtual machines are deployed on ESXi hosts managed by vCenter Server, backup proxy contacts vCenter server to locate the virtual machine.
  • In an environment where virtual machines are deployed on standalone ESXi hosts, backup proxy contacts ESXi host and locate the virtual machine.

Step 3

VDDK connection is established with the virtual machine with SSL transport mode.

Step 4

Backup proxy checks if it is a full virtual machine restore or a VMDK file restore. Backup proxy contacts the virtual machine and establishes a write connection to restore virtual machine data.

  • For a full virtual machine restore, Phoenix creates a new virtual machine with an identical configuration (that is, the configuration of the virtual machine at the time of backup) at the similar location, with the following syntax: 
    <Name of the original virtual machine>_<counter>
  • For a disk restore, Phoenix creates a new virtual machine with minimum configuration (100 MB RAM, 1 CPU, 1 video card, and the disk to be restored) at the location specified, with the following syntax: 
    <Name of the original virtual machine>_<counter>.
Note: For disk restore, create a minimum configuration virtual machine because VMware does not allow to create a disk without creating the virtual machine.

Step 5

Backup proxy obtains the virtual machine data from Phoenix Cloud.

Step 6

Restore operations starts.

Phoenix checks if the restore completes successfully. 

  • If the restore completes successfully, a new virtual machine is available.
  • If the restore fails, Phoenix deletes the newly-created virtual machine.

Hyper-V virtual machine backup workflow

Phoenix Editions: File:/tick.png Business File:/cross.png Enterprise File:/tick.png Elite

Phoenix backs up virtual machines based on the schedule defined in the backup policy, or if a backup is triggered from Phoenix Management Console. The backup workflow is explained below:

hyperV_backup_workflow-4.png

Virtual machine backup workflow

Step Operation

Step 1

Virtual machine backup request is initiated based on:

  • Schedule defined in the backup policy.
  • On-demand backup

Phoenix forwards the backup request to the agent.

Step 2

Phoenix agent verifies that the VSS service is running. The Phoenix agent requests the VSS service to create a snapshot. If the VSS service is not running, Phoenix agent starts the VSS service and instructs VSS to create a snapshot.

Druva recommends that you enable Backup (volume snapshot) under Hyper-V Integration Services. If the Backup (Volume snapshot) is enabled, the VSS service can create a snapshot without interrupting services on the virtual machine. 

Phoenix agent validates if snapshots are created successfully and initiates the backup job.
For  Windows Server 2008 and Windows Server 2008 R2 host:

  • If Phoenix is backing up virtual machines that are stored on a clustered shared volume, then Phoenix can backup only one virtual machine at a time. 
  • A hardware VSS provider is required if  you want Phoenix to create snapshots for multiple virtual machines simultaneously on a single host and run parallel backup jobs. For information on how to configure Phoenix so that it can use third party VSS providers, see How do I configure Phoenix to use third party VSS providers?.
Note: Integration Services are available for virtual machines with Windows guest OS. However, Microsoft provides Integration Services for certain Linux distributions also. For more information, see: If integration services are not available for a virtual machine, Phoenix cannot take a snapshot and backup fails.

Step 3

Phoenix determines the type of backup. 

  • If this is the first automatic backup, Phoenix performs a full backup. 
  • For all subsequent backups, Phoenix performs an incremental backup. 

 

Step 4

Agent estimates the data for backup

Step 5

Agent backs up the data based on the VSS provided snapshot

Next steps

If you want to configure Phoenix for backup and restore, see:

To learn more, see:

Hyper-V virtual machine restore workflow

hyperV_restore_workflow-2.png

Step Operations

Step 1

Phoenix administrator initiates virtual machine restore. Phoenix forwards the restore request to Hyper-V server agent.

You can restore your virtual machine to the original location or an alternate location. Ensure that Phoenix agent is activated and the destination Hyper-V server is registered with Phoenix as a host. 

Step 2

Phoenix checks if Phoenix agent is running. If the agent is running, Phoenix restores the virtual machine. If the agent is not running, the restore job is queued until the agent is ready for backup and restore. 

Step 3

Phoenix agent checks if the destination Hyper-V server has sufficient storage to restore the virtual machine.

Step 4

Backup proxy checks if it is a full virtual machine restore or a virtual disk restore. Agent contacts the server and establishes a write connection to restore virtual machine data.

  • For a full virtual machine restore, Phoenix creates a new virtual machine with an identical configuration (that is, the configuration of the virtual machine at the time of backup) at the similar location, with the following syntax: 
    For original location restore: <Name of the original virtual machine>_<counter>
    For alternate restore <user provided virtual machine name>_<counter>
  • For a disk restore, Phoenix restores the disk on the location you select. 

Step 5

Phoenix Cloud sends the snapshot to the Hyper-V server agent.

Step 6

Restore operations start.

Phoenix checks if the restore completes successfully. 

  • If the restore completes successfully, a new virtual machine is available.
  • If the restore fails, Phoenix deletes the newly-created virtual machine.

Phoenix disaster recovery workflow 

With Phoenix DRaaS, Amazon Machine Image (AMI) copies are created based on the virtual machine backup and maintained in the AWS account. At the time of disaster, you can launch EC2 instance from the AMIs, in-turn spinning up to production in minutes. Phoenix updates AMI copies with the latest virtual machine backup as per the defined schedule. The following diagram depicts the Phoenix DRaaS workflow:

Disaster Recovery workflow.png

Phoenix AWS proxy setup workflow 

Phoenix Editions: File:/cross.pngBusiness         File:/tick.png Enterprise     File:/tick.pngElite
(Purchase Separately)

Phoenix AWS proxy is an Elastic Compute Cloud (EC2) instance that runs a Phoenix service. It orchestrates copying data from the Phoenix backup storage to your AWS account and creates an AMI copy at a frequency specified in the DR plan. The Phoenix AWS proxy runs in the AWS account. Phoenix launches the proxy in the same AWS region where the backup storage for the virtual machine is located. The AMI instantiated for disaster recovery is created in the same region. 

Phoenix AWS proxy setup workflow

To set up Phoenix AWS proxy, you must first download the .json policies from the Phoenix portal. The policies are used to create IAM policy and VMimport policy on the AWS portal and establish trust relationship for VMimport role. After you create IAM policies and roles, you must retrieve the AMI ID based on the AWS region to launch the proxy. The following diagram depicts the workflow to set up Phoenix AWS proxy and the corresponding portal to perform the setup. 

AWS_Proxy__setup (1).png

The following table summarizes the steps to set up Phoenix AWS proxy.

Step Portal Description
Download Policies Phoenix portal Downloads policies that are used to create IAM Policy, and VMimport Policy, and establish trust relationship for VMimport Role in AWS.
Create IAM Policy and Roles AWS portal Creates IAM Policies and Roles. VMimport Policy defines the trusted permission attributes to import virtual machine images from your virtual environment to Amazon EC2, as AMIs. VMimport Role allows access to Amazon EC2 for creating AMI in your AWS account.  IAM Policies allow you to define permissions for users, groups, roles, and resources. IAM Role provides access capabilities to the AWS users. 
Get AMI ID Phoenix portal Retrieves AMI ID based on your AWS region.
Launch Phoenix AWS proxy AWS portal Launches Phoenix AWS proxy in the AWS region where virtual machines are backed up.
Register Phoenix AWS proxy AWS portal Registers and activates the Phoenix AWS proxy.

Data backup with CloudCache deployment workflow 

Phoenix Editions: File:/cross.png Business File:/cross.png Enterprise File:/tick.png Elite

The following diagram illustrates how data flows during backup in a Phoenix CloudCache deployment.

CloudCache_BackupFlow.png

Step Description

Step 1

 

Phoenix agent backs up the server data according to the schedule defined in the backup policy. At the scheduled time, Phoenix Cloud initiates the backup request and forwards it to Phoenix agent.

Note: Phoenix CloudCache maintains a persistent connection with Phoenix Cloud.

Step 2

 

  1. Phoenix agent backs up the data to Phoenix CloudCache.
  2. Phoenix agent saves the metadata to the storage that Phoenix Cloud assigns for backup.

Step 3

 

As per the predefined schedule, Phoenix CloudCache synchronizes the backup data to the storage that Phoenix Cloud assigns. 

Note: Phoenix CloudCache establishes an on-demand connection with cloud storage. After a synchronization is complete, the connection with Phoenix Cloud storage is terminated. For the next synchronization operation, Phoenix CloudCache establishes a connection with the cloud storage that Phoenix Cloud assigns. 

Note: Administrators must configure the synchronization schedule and a bandwidth that Phoenix CloudCache can consume. For more information, see Configure Phoenix CloudCache.

Data restore with CloudCache deployment workflow

Phoenix Editions: File:/cross.png Business File:/cross.png Enterprise File:/tick.png Elite

The following diagram illustrates how data flows within the Phoenix setup at the time of hot restore.

cloudcache_restore_workflow1.png

Step Description

Step 1

Phoenix Cloud initiates the restore request and forwards it to the Phoenix agent.

Step 2

 

  1. Phoenix agent fetches the metadata from the storage in Phoenix Cloud.
  2. Phoenix agent queries the Phoenix CloudCache to restore the data.

Ports and communication protocols for VMware

Phoenix communicates with your virtual infrastructure to backup and restore virtual machine data. This communication happens via ports and communication protocols that are secure for communication and transition of data.

Phoenix uses combination of Transport Layer Security (TLS) and Secure Socket Layer (SSL) protocols for establishing connection and initiating communication between Phoenix components and your virtual infrastructure components such as vCenter Server, ESXi hosts, and virtual machines.

The following diagram depicts the ports and communication protocols that are used by Phoenix for secure connection and communication during the backup and restore operations.

The following table describes the port and communication protocols used for communication between Phoenix and various VMware components.

Port/Communication Protocol Description

443

Phoenix uses Port 443 to establish secure connection and communication between the following:

  • Backup Proxy to Phoenix Cloud
  • Backup Proxy to Phoenix CloudCache
  • Backup Proxy to vCenter Server
  • Backup Proxy to ESXi host
    Note: Backup proxy establishes connection with ESXi host over Port 443 only if it registered with Phoenix as Standalone ESXi. If the ESXi host is registered with Phoenix through vCenter Server, backup proxy communicates with the ESXi host over Port 902.

902

Phoenix uses Port 902 to establish a connection between the backup proxy and ESXi host registered with Phoenix through vCenter Server.

3389/22

 

During the backup cycle, the backup proxy sends network packets to Windows virtual machines (where VMware tools are installed) on port 3389 to identify if the RDP port is open or not. For Linux virtual machines, the port is 22, which is used for SSH.

This is used for Phoenix DRaaS or DR restores.

123 (UDP) Backup proxy accesses NTP server on Port 123 (UDP) for time synchronization.

TLS

Phoenix uses TLS for a secure connection that happens between the following:

  • Backup proxy and Phoenix Cloud
  • Backup proxy and Phoenix CloudCache
  • Phoenix CloudCache and Phoenix Cloud

SSL

Phoenix uses SSL for a secure connection that happens between the following:

  • Backup proxy and vCenter Server
  • Backup proxy and ESXi hosts

Ports and communication protocols for File server

Phoenix communicates with your File servers to backup and restores the data from your File servers. This communication happens through ports and protocols that are secure for communication and transition of data.

Phoenix uses Transport Layer Security (TLS) protocol for establishing a connection and initiating communication between Phoenix components and your File servers.

The following diagram depicts the ports and communication protocols that are used by Phoenix for secure connection and communication during the backup and restore operations.

port_and_protocol_for_file_server_setup1.png

Ports and communication protocols for Phoenix CloudCache

Phoenix communicates with your virtual infrastructure to backup and restore virtual machine data. This communication happens via ports and communication protocols that are secure for communication and transition of data.

Phoenix uses combination of Transport Layer Security (TLS) and Secure Socket Layer (SSL) protocols for establishing connection and initiating communication between Phoenix components and your virtual infrastructure components such as vCenter Server, ESXi hosts, and virtual machines.

The following diagram depicts the ports and communication protocols that are used by Phoenix for secure connection and communication during the backup and restore operations.

The following table describes the port and communication protocols used for communication between Phoenix and various VMware components.

Port/Communication Protocol Description

443

Phoenix uses Port 443 to establish secure connection and communication between the following:

  • Backup Proxy to Phoenix Cloud
  • Backup Proxy to Phoenix CloudCache
  • Backup Proxy to vCenter Server
  • Backup Proxy to ESXi host
    Note: Backup proxy establishes connection with ESXi host over Port 443 only if it registered with Phoenix as Standalone ESXi. If the ESXi host is registered with Phoenix through vCenter Server, backup proxy communicates with the ESXi host over Port 902.

902

Phoenix uses Port 902 to establish a connection between the backup proxy and ESXi host registered with Phoenix through vCenter Server.

3389/22

 

During the backup cycle, the backup proxy sends network packets to Windows virtual machines (where VMware tools are installed) on port 3389 to identify if the RDP port is open or not. For Linux virtual machines, the port is 22, which is used for SSH.

This is used for Phoenix DRaaS or DR restores.

123 (UDP) Backup proxy accesses NTP server on Port 123 (UDP) for time synchronization.

TLS

Phoenix uses TLS for a secure connection that happens between the following:

  • Backup proxy and Phoenix Cloud
  • Backup proxy and Phoenix CloudCache
  • Phoenix CloudCache and Phoenix Cloud

SSL

Phoenix uses SSL for a secure connection that happens between the following:

  • Backup proxy and vCenter Server
  • Backup proxy and ESXi hosts