Support matrix

Hardware requirements for installing Phoenix agent 

Disks, partitions, and files supported for File Level Restore (FLR) on Hyper-V hosts

Item	Certified
Disk Types	Thin Thick
Partition Tables	MBR GPT (Linux)
Partition Types	Primary Extended LDM (Only Simple and Spanned Volumes with MBR) LVM (Simple/Spanned/Mirror/Striped)
File Systems	NTFS  FAT  FAT32   Ext2/3/4  XFS
File Type	Regular Files Sparse Files Hidden Files

Hardware requirements  for NAS shares

The following table describes the hardware specifications that the Phoenix agent requires to run one backup or restore job at a time:

Hardware	Minimum Requirement
CPU	Three Cores or, Three vCPUs if the agent is installed on a virtual machine
RAM	3 GB
Free space	On Windows and Linux servers, 2% of the total source data is utilized for the Phoenix application data. This application data is stored in the following locations: Windows 2012 Server C:\ProgramData\Phoenix Windows 2008 Server C:\ProgramData\Phoenix Linux /var/log/Phoenix /var/Phoenix

 By default, the Phoenix agent is configured to run six backup sets in parallel.

Hardware requirements for VMware  

This table lists the minimum requirements for deploying a backup proxy that is available as a virtual appliance. 

Backup proxy requirements  

Backup proxy is available as a virtual appliance. Deploying backup proxy creates a virtual machine with the configuration that is listed in this table. Ensure that your VMware setup can assign resources to support this requirement. 

Parameter	Default configuration
vCPU	8 vCPU (2 virtual sockets with 4 cores per socket)
RAM	6 GB
Virtual disks	4 virtual disks (40 GB, 30 GB and 2 disks with 1 MB each).

With the above default configuration, you can backup up to three virtual machines in parallel. For more information, see Sizing for backup proxy.

Hardware requirements for the Phoenix Backup Store 

You can set up a Phoenix Backup Store on:

• An Ubuntu server: Deploy the Debian package that Druva provides on an Ubuntu server and use the Ubuntu server as a Phoenix Backup Store.
• A VMware setup: Deploy the Open Virtual Appliance (OVA) package that Druva provides on a supported VMware/ESXi host and start the virtual machine. Use this virtual machine as a Phoenix Backup Store.
• Amazon Web Services (AWS): Deploy the Debian package that Druva provides on an EC2 instance with Ubuntu operating system to use the EC2 instance as a Phoenix Backup Store. 

The following sections provide a recommended configuration of a system that you can use as a Phoenix Backup Store.

Ubuntu server as a Phoenix Backup Store

This table provides a recommended configuration of the Ubuntu server on which you deploy the Debian package to use the server as a Phoenix Backup Store.

Hardware/Software	Specification
Operating system	Ubuntu 18.04 (64-bit)
CPU	8 Cores
RAM	6 GB
Hard disks	At-least 300 GB.
ZFS pool configuration	RAIDZ (Requires at-least three disks) You can create a ZFS pool with less than three disks using RAID0 configuration.
ZFS compression	LZ4
ZFS deduplication	Off
ZFS record size	128 KB

A virtual machine on a VMware vCenter/ESXi as a Phoenix Backup Store

The following table describes the recommended configuration of the virtual machine that you create using the OVA package that Druva provides, and use it as a Phoenix Backup Store. 

Hardware/Software	Specification
vCenter/ESXi versions	6.7/6.5/6.0
vCPU	8 Cores
RAM	8 GB
Virtual disk	The OVA contains 3 virtual disks. Two disks of 100 GB capacity each to create the ZFS pool for backup and the third disk (sdd) of 200 GB capacity for restore.
ZFS pool configuration	RAIDZ (Requires at-least three virtual disks) You can create a ZFS pool with the two attached disks using RAID0 configuration.
ZFS compression	LZ4
ZFS deduplication	Off
ZFS record size	128 KB

An AWS EC2 instance as a Phoenix Backup Store

The following table describes the recommended configuration of the AWS EC2 instance on which you can deploy the Debian package and use it as a Phoenix Backup Store. 

Hardware/Software	Specification
Instance type	c5.4xlarge
Operating system	Ubuntu 18.04 (64-bit)
CPU	16 Cores
RAM	16 GB
EBS Volume	At-least 500 GB on a ThroughPut optimized HDD (ST1).
ZFS pool configuration	RAIDZ (Requires at-least three volumes) You can create a ZFS pool with less than three volumes using RAID0 configuration.
ZFS compression	LZ4
ZFS deduplication	Off
ZFS record size	128 KB

Hardware requirements for Phoenix CloudCache

Prerequisite	Minimum Requirement
CPU	64-bit, quad-core processor
RAM	8 GB or greater
Network Traffic rules	Outgoing network traffic: Phoenix CloudCache connects to Phoenix cloud using port 443. Incoming network traffic: Phoenix agents connect to Phoenix CloudCache using port 443.
Firewall	If a firewall is enabled, allow all outgoing TCP/IP traffic to port 443 for "*.druva.com".
Web proxy	Druva supports the following proxy types: HTTP socks4 socks5 For more information see: Configure Web proxy

 Note:  Phoenix does not support 4K native drives in the CloudCache environment. We recommend you to use 512 native drives for backup.    

To use Phoenix CloudCache 3.3-7649 or later, install the following agents on the servers that you want to protect:

• Linux RPM version 4.6.1-7433 or later.
• Windows 64/32 bit agent version 4.6.1-7430 or later.

  If you do not use the recommended agents,  the following errors will be displayed:

• PHOENIX 146 error for agent.
• KeyError 101 error for CloudCache.

Network requirements

Field	Requirement
Network Traffic rules	Phoenix agent: Phoenix agents connect to Phoenix Cloud using port 443. Phoenix CloudCache:   Phoenix CloudCache connects to Phoenix Cloud using port 443. Phoenix agents connect to Phoenix CloudCache using port 443.  Phoenix Backup Store  Phoenix Backup Store connects to the Phoenix Cloud using port 443.
Firewall	For all the agents and CloudCache: If the firewall is enabled, allow all outbound TCP/IP traffic to *.druva.com through port 443.
Web proxy	Druva supports the following proxy types: http socks4 socks5 For more information see: Configure web proxy for Windows Configure web proxy for Linux Configure web proxy for CloudCache Configure web proxy for the Phoenix Backup Store

Supported storage regions of Phoenix

	Storage name	Storage region
North America and Canada	us-east-1	North Virginia
	us-west-2	Oregon
	ca-central-1	Montreal
South America	sa-east-1	Sao Paulo
Europe	eu-west-1	Ireland
	eu-west-2	London
	eu-central-1	Frankfurt
Asia	ap-southeast-1	Singapore
	ap-northeast-1	Tokyo
	ap-south-1	Mumbai
	ap-east-1	Hong Kong
	ap-southeast-2	Sydney

For restores on Windows/Linux servers and NAS shares, the search functionality is not available in the Hong Kong region.

Security considerations

One thing that is often overlooked when deploying a data protection solution is security. While Druva automatically handles the security of information in transit and at rest, there are other security mechanisms that organizations should consider for implementing beyond encryption when it comes to data protection. The following sections discuss the security considerations that organizations should take into account as they implement Phoenix for their data protection solution.

Roles and responsibilities 

To prevent privileged users from making unauthorized changes to resources within their organization, Phoenix supports the Role Based Access Control (RBAC) for separation of duties. This capability allows organizations to limit privileged user access to a predefined set of roles and data assets. This RBAC capability makes it possible to create ethical walls to enforce privacy, as well as implement a delegated administration structure to meet customers’ organizational, compliance, or security requirements. To add RBAC in your Phoenix deployment, see Manage administrators.

Global regulatory compliance 

As part of your data protection strategy, organizations need to take into account where they operate and what requirements they have on security and availability of the data.  With Druva Phoenix, organizations can store data in any of twelve global regions depending on their security, compliance, data access, and availability requirements. While not only a compliance requirement, proximity to data can also help shrink the time it takes to recover in the event of a disaster.

Single sign-on 

Phoenix supports SAML which allows organizations to centralized authentication for the administration of their Phoenix environment. This allows Phoenix administrators to leverage existing centralized authentication mechanisms like Okta, Ping Identity, or Active Directory which are already being used today.  The use of Single sign-on (SSO) helps to guarantee the availability of access to Phoenix and eliminates local authentication stores which cause audit and compliance headaches as well as create a security risk. To integrate Phoenix with your SSO authentication mechanism, see Configure single sign-on for Phoenix.

Testing your recovery 

As part of your data protection strategy, it is important to see if what you are backing up is actually getting backed up, whether part of a normal business continuity and disaster recovery process.

Conclusion 

While protecting data in flight and at rest are important security capabilities of any enterprise-level data protection solution, there are definitely more issues to take into account, and more capabilities to take advantage of when it comes to protecting the overall data attack surface. For identifying and implementing more such security considerations for Phoenix, contact Druva Support.