Druva Phoenix now provides an ability to track the credit consumption of each of your organizations. On the Credit Limits page, simply set a limit to the credits that your organizations can consume. Phoenix starts notifying you when the consumption reaches 80% and exceeds the set credit consumption limit.

For more information, see Credit limits.

Customer action required: No action required.

For security reasons, by default, the administrators are automatically logged out of their sessions on the Druva product consoles if there is no activity for 30 minutes.

However, if you want to avoid undesired inactive session terminations and facilitate administrators with the required operational ease, you now have an option to extend the idle session duration up to 6 hours.

For more information, see Configure Idle Session Timeout.

Configure multiple SAML enabled accounts for your organization with separate SAML identities through the ‘Custom Entity ID’ feature.

The custom entity ID feature allows you to configure each SAML enabled account with a unique entity ID. Thus providing centralized control over user authentication to each of your SSO accounts.

For more information, see Set Up Single Sign-On (SSO).

The upcoming Phoenix release planned for January 6, 2020, will bring an enhanced version of the NAS agent. We have added new, client-side architectural changes that significantly improve the backup and restore throughput.

Customer actions required:

The following table lists the versions of the agents released:

We have further enhanced the Druva Phoenix support for protecting AWS resources. The Protect > AWS Resources menu option will seamlessly navigate the users to Druva CloudRanger Dashboard (console.cloudranger.com). With this change, you will get a wide range of CloudRanger capabilities to protect the AWS resources.

To know more about Druva CloudRanger, see https://help.druva.com/en/collections/6156129-aws-workloads.

Druva now allows you to back up data to the Paris region. However, Druva does not support the following features in this region:

Customer action required: No action required.

The following table lists the versions of the agents released:

We have further enhanced the Druva Phoenix support for protecting AWS resources. Starting in the week of December 2, 2019, the Protect > AWS Resources menu option will seamlessly navigate the users to Druva CloudRanger Dashboard (console.cloudranger.com). With this change, you will get a wide range of CloudRanger capabilities to protect the AWS resources.

To know more about Druva CloudRanger, see https://help.druva.com/en/collections/6156129-aws-workloads.

Druva Phoenix now extends the capability of determining the storage expenditures of the resources in their organizations.​​​​​ Earlier, the customers could charge their internal departments for the credits consumed by the servers that were associated with the organizations and administrative groups. With this release, customers can now associate cost codes to the backup sets and determine the storage expenditures of the resources in their departments.​​​​​

The Cost Allocation Report now provides a granular view of the credits consumed by the backup sets along with the backup set type and organizations.

Note: The Cost Allocation Report generated for November 2019 will include new columns, such as backup set name, backup set type, and organization. However, any reports generated before November will display the cost allocation details in the earlier format.

For more information, see:

Customer action required: No action required.

The following table lists the versions of the agents released:

This cloud update has minor bug fixes.

The following table lists the versions of the agents released:

Starting today, if you enable application-aware processing for a virtual machine (VM), Phoenix has the ability to detect if a SQL Server is running inside a VM. And, it can use the Microsoft VSS framework and the virtual device interface to back up databases and its transaction logs. You can then restore the entire database, a point-in-time copy, or perform a marked transaction restore to VMs that have application-aware processing enabled.

At the moment, Phoenix still has to restore a virtual machine and then restore databases to it. Yet, here's something that's in the works and coming soon: we're constantly working towards building the ability in Phoenix so that you can restore databases directly to the VM that hosts the SQL Server.

To learn more about how we are doing it, and what you need to do, see:

Customer action required: Upgrade the Phoenix Backup Proxies to the latest version.

To create application-aware backups, Phoenix needs to login to the virtual machines so that it can perform application-aware processing such as quiescing the application and performing log truncation. To do that, administrators should assign the virtual machine with an application service account for successful application-aware processing. So, we built a credential store that you can use to provide Phoenix the credentials of a virtual machine. You can now store credentials with Phoenix, and then assign them to VMs at scale. Otherwise, you'd have to manually enter credentials for each VM when you configure it for backup. All you need to do is assign a label to the credential that you store with Phoenix, and then use the label to identify it and assign it to multiple virtual machines when you configure application-aware backups for them. Based on the requirements, we can extend this to other workloads as well.

For more information, see Credentials store.

Customer action required: No action required.

Druva now offers SQL APIs that you can use to organically interact with Phoenix for SQL workloads that Phoenix protects. You can integrate tools and applications with Phoenix by using the APIs to have a more customizable experience for reporting, analytics, and performing business functions for SQL servers that Druva Phoenix protects.

For more information, see API reference documentation on the Druva developer portal.

Customer action required: No action required.

We have made it easier for you to identify backup sets in each workload by assigning a unique name to it. This name acts as a unique identifier for the backup set. So, if you want to search for a backup set from a list of hundreds, just use the name as the search term.

When you create a new backup set, a unique name is automatically assigned to it in the servername#bset<number> format. Moreover, you can rename the backup set at any given point in time.

Note: This feature is applicable only to the File Server, NAS, and MS-SQL workloads.

Will I have to update my existing backup sets manually?

Just sit back and relax. We will ensure that all your existing backup sets are labeled with a unique name.

Customer action required: No action required.

With this release, we are excited to announce a significant enhancement in the restoration speed and improved RTO for your snapshots. All your cold snapshots will now move to the warm tier at no additional cost. What this means is that you will now experience faster and more efficient restoration of your data that initially had a higher RTO in the cold storage.

Customer action required: No action required.

We have tested backup and restore of databases on Oracle 18c and 19c with Phoenix, and it works! Now, you can use Phoenix to backup and restore Oracle databases created and managed using Oracle Database 18c and 19c. For more information, see Support Matrix.

Customer action required: No action required.

A few weeks ago when we added the ability to choose databases for backup, we had to take the ability to run a backup from the command line out. We did this because we were changing a couple of things under the hood. Now, that's back and you can run a backup again using the command line, with a slight modification. Because you can now name a backup set, you have to provide the name of the backup set in the command line instruction to run a backup for it. For your existing backup sets, we have already added a name, so that you can use it.

For more information on how to do this, see Trigger a backup using the command line.

Customer action required: Upgrade the Windows Server agent to the latest version.

The following Phoenix update was released on September 16, 2019.

With this release, Druva takes a step forward in enhancing your disaster recovery process. We now bring to you a one-click, automated, failback disaster recovery solution to restore your failed over data. Struck by an unfortunate disaster and now want to restore your local setup? Go ahead and use our bullet-proof failback solution to move the workloads back to your data center in a single click and resume your IT operations. The failback mechanism seamlessly restores your failed over EC2 instances from your AWS account back to your virtualization data center.

To know more about how it works, check out the following articles:

Customer action required: Ready to use our latest DR failback offering? Here’s how you can quickly perform these tiny bits to get started:

The following Phoenix update was released on August 26, 2019.

With this release, you will get an option to choose databases on an instance that you want to back up with Phoenix.

Now: When you configure a SQL Server backup, you can create multiple backup sets per instance in which you can choose which databases you want Phoenix to back up and which databases to exclude from a backup. You can also add new backup sets to the registered instance with different databases selected for backup.
​
​Earlier: When you configured a SQL Server backup, one backup set was created per instance. The backup set would include all the databases in it. For example, if there are two SQL Server instances on the Windows Server host, Phoenix would create two backup sets, one each for an instance. Backup set one for the first instance included the databases on the first instance and backup set two for the second instance included the databases on the second instance for the backup. You only got an option to exclude databases from backup.

For more information, see:

Customer action required: Upgrade the agent to the latest version. The agents released on or after August 26th, 2019 can discover databases on the SQL Server. After you upgrade the agent and the agent discovers the databases on the SQL Server, you can update the older backup set or add new backup sets to choose the databases that you want to back up.

Note: After upgrading your agent, if you add a database to the SQL Server, Phoenix does not automatically add it to a backup set unless you use an inclusion filter in a backup set or manually add it to a backup set. In addition, the command line backup method for SQL Server will not be available after you upgrade the agent.

Druva now offers Alerts APIs that you can use to organically interact with Phoenix to fetch backup failure alerts. You can integrate tools and applications with Phoenix by using these APIs to have a more customizable experience for reporting and analytics.

For more information, see API reference documentation on the Druva developer portal.

Customer action required: No action required.

The following Phoenix updates are released on August 5, 2019.

With this release, Druva Phoenix provides enhancements to the failover workflow. During failover, Phoenix DRaaS converts all virtual machines configured in a DR plan in parallel thereby ensuring that virtual machines across multiple steps have the same RTOs. This will ensure that customers are able to meet their RTO requirements irrespective of the number of steps involved within the DR plan.

For more information, see About recovery workflow.

Customer action required: No action required.

On July 1, 2019, we announced that Phoenix can protect your EC2 instances by creating AMIs and using these AMIs to restore the instances. With this release, in addition to creating AMIs, you can now back up the data on your Amazon EBS volumes to Amazon S3 by taking point-in-time snapshots and then restore these snapshots as EC2 instances, specific files, and EBS volumes.

Phoenix provides the agile flexibility to improve the speed and reliability of your backups and restores, and with this added capability, we enhance this in the following ways:

To know more about this enhancement, see Backup and Restore AWS resources.

Customer action required: No action required

Druva now offers APIs that you can use to organically interact with Phoenix for Hyper-V workloads that Phoenix protects. Integrate tools and applications with Phoenix using the APIs to have a more customizable experience for reporting, analytics, and performing business functions for Hyper-V hosts and virtual machines that Druva Phoenix protects.

For more information, see API reference documentation on the Druva developer portal.

Customer action required: No action required

The following issue has been fixed in this release.

The following Phoenix updates are released on July 15, 2019.

We have rolled out an API documentation portal for developers with Druva Phoenix APIs that help you create reports to explore, get insights, or answer important questions about your jobs and data. This API-driven portal provides a developer-friendly view of all the endpoints offered by Druva and features the following:

With this release, we provide you with the following Phoenix APIs:

Experience our API documentation portal for developers at https://developer.druva.com.

Customer action required: If you are using Phoenix and inSync, ensure that your Phoenix and inSync accounts are merged before you use the APIs. For more information, contact Support.

The following Phoenix updates are released on July 1, 2019.

As Druva Phoenix continues its flight higher than ever, hitting the right balance of needs has led it to be used in production by various organizations across the globe who are looking to protect their data in the form of multiple workloads. With our long history in protecting workloads such as files, Oracle databases, NAS shares, Hyper-V virtual machines, MS-SQL databases, and VMware virtual machines, Phoenix can now protect your EC2 instances too.

You now have a single pane of glass view for multiple workloads (including cloud-native workloads) irrespective of their deployment models. Say goodbye to the concerns of buying separate products to protect data on-premise and in the cloud.

For more information, see Backup and Restore AWS resources.

Customer action required: No action required.

The following Phoenix updates are released on June 17, 2019:

Druva provides an optimal way to obtain your organization’s large data stored in the Cloud.​​​ The requested data is shipped to your data center using an AWS Snowball Edge. This service enables you to export data in the following situations:

Druva provides this feature as an add-on service and this service is charged separately. It is not a part of the standard Druva subscription. Contact the Sales team for more details.

Customer action required: No action required.

Druva now provides a prompt that lets you clean up configuration files if you choose to uninstall them using the command line on a Linux server. In addition, if you plan to upgrade the agent, you can choose to retain the configuration files.

Druva Phoenix also provides environment variables in the agent that let you choose whether you want to clean up configuration files or retain them at the time of uninstalling the agent.

If you plan to upgrade the agent, ensure that you do not remove the configuration files.

For more information, see:

Customer action required: Upgrade the agent to the latest version.

The following Phoenix updates are released on June 03, 2019:

With the aim to achieve easier snapshot management and increased storage efficiency, Druva Phoenix introduces modifications in the retention policy behavior, which are as follows:

Customer action required: No action required.

Druva Phoenix introduces the next level of automation for your VMware infrastructure deployment, which now includes auto configuration based on:

Use these capabilities to automate the configuration of your virtual machines to specific backup policies and hence, save time and increase efficiency and productivity.

Customer action required: Upgrade the Phoenix agent to the latest version. Tag support requires VMware vCenter 6.5.0 or later.

For more information, see the following documentation:

With this release, Druva extends the existing capabilities of the Phoenix CloudCache. The key enhancements include the following:

Customer action required: No action required.

For more information, see the following documentation:

Druva now allows you to back up data from the File servers, NAS shares, SQL instances, and VMware and Hyper-V virtual machines in the Hong Kong region. However, Druva does not support disaster recovery in this region.

The following Phoenix updates are released on May 20, 2019:

With this release, Druva Phoenix introduces an enhanced disaster recovery solution to improve business continuity to provide greater control of the failover process, automated one-click deployment of virtual machines for failover, tighter AWS integration, and simplified orchestration and testing. As applications become more complex, the interdependencies between virtual machines become more sophisticated. For an application-consistent recovery, organizations are looking for automated solutions to bring up their virtual machines with minimal intervention and dependencies.

With the introduction of automated runbook execution and one-click failover, IT can now automate the manual tasks for deploying proxy and creating the required IAM roles and policies using the AWS CloudFormation template. With failover automation, the key tasks performed during failover are automated by providing additional target instance properties, network pre-configurations, virtual machine boot-ordering, and scripting for custom recovery workflows.

Customer action required: To use the latest DR orchestration features, perform the following actions:

For more information, see the following documentation:

With this release, Druva Phoenix starts considering an MS-SQL Server workload independent of a Windows Server so that administrators can leverage role-based access control (RBAC) independently for MS-SQL Servers. Now, to back up an MS-SQL Server database, you can register an MS-SQL Server host from the MS-SQL Server page itself and add MS-SQL Server backup sets to the host. With this feature, separate administrative groups can be created to manage MS-SQL Server database backups and file and folder backups on Windows hosts.

Note: When you add a SQL Server host, it is also registered with Phoenix as a Windows Server and you can access it using the Protect > Windows/Linux Servers option on the top menu if you want to add file backup sets to it. However, to manage SQL Server backup sets on a Windows Server, you have to navigate to the server from the Protect > MS-SQL Servers page of its organization. Similarly, to manage file backup sets, navigate to the server from the Protect > Windows/Linux servers page of the organization.

Customer action required: No action required.

The following Phoenix updates are released on May 6, 2019:

Phoenix now makes it easier for you to search files across snapshots within a backup set that you want to restore. Phoenix introduces a search bar along with advanced filter options on the Restore Data dialog box. This enables you to search for a particular file to restore without having to browse through all of the backed up files or snapshots.

You can perform a full-text search or search for files of a certain type, such as MS Office files, HTML files, audio files, PDF files, and executable files, and restore them.

Note: In the current release, the search feature is limited only to the files and folders backed up from Windows/Linux servers and NAS shares.

For more information on using the search feature and search filters, see the Search for files section.

Action required: No action required.

Phoenix can now back up files and folders on the Resilient File System (ReFS) volumes. Phoenix also allows you to back up and restore data from and to the NTFS and ReFS volumes.

To know more about the ReFS versions that Phoenix supports, see System requirements.

Customer action required: Upgrade the agent to the latest revision.

With this enhancement, Druva Phoenix significantly improves the file scan performance during incremental backups.

After you upgrade the agent, you can expect the first backup to be slightly slower because of the metadata processing. And, thereafter all the incremental scans will be much quicker.

Customer action required: Upgrade the agent to the latest revision.

Phoenix now supports the backup and restore of files and folders, and NAS shares on the following operating systems.

For more information, see Support matrix.

Customer action required: Upgrade the agent to the latest revision.

With this release, Phoenix will no longer use the Overage term to denote the excess amount of credits utilized after consumption of all your purchased credits. The Credit Balance field on the dashboard will now display the excess credits consumed in red preceded by a minus sign as shown in the following screenshot:

For more information, see:

Action required: No action required.

The following Phoenix update is released on April 15, 2019:

With this enhancement, Druva Phoenix significantly improves the file scan performance during incremental backups.

Additionally, Phoenix now comes with a standalone Scanner CLI utility bundled with the Phoenix agent. This utility runs independently and provides you with all the telemetry information to get insight into the file system and NAS share. For more information, refer to Scanner CLI utility.

After you upgrade the Phoenix agent, you can expect the first backup to be slightly slower because of the metadata processing. And, thereafter all the incremental scans will be much quicker.

Note: Currently, this enhancement is applicable to the NAS Shares (NFS and SMB) and Linux File servers.

Action required: Upgrade the Phoenix agent to the latest version.

Phoenix can back up and restore databases encrypted using Transparent Data Encryption (TDE). However, ensure that the certificate and key used to encrypt the backed up database must be present on the SQL server to which you restore the database.

Note: Phoenix does not back up encryption keys and certificates.

Action required: No action required.

Phoenix certifies backup and restore of files and folders on Red Hat Enterprise Linux (RHEL) (64-bit) 6.9 and 7.4.

Action required: Upgrade the Phoenix agent to the latest version.

The following Phoenix update is released on April 1, 2019:

Action required: Upgrade the Phoenix backup proxy to the latest version.

The following Phoenix update is released for the cloud update on February 18, 2019:

Druva Phoenix utilizes the advanced capabilities of AWS Snowball Edge to facilitate a fast transition of data to the Phoenix Cloud in a bandwidth-compromised environment. After the data is transferred to the Phoenix Cloud, Phoenix makes the restore points available for the mapped backup sets.

With AWS Snowball Edge, Phoenix allows enterprises to freely move data between the on-premise storage and the Phoenix Cloud without the complexity and cost of legacy hardware; thus, enabling them to speed up their backup.

Additional benefits that you can expect from this integration include:

Phoenix provides this feature as an add-on service and this service may be charged separately. Contact the Druva Sales team for more details.

Action required: No action required.

For more information, see the Backup Optimization by using Snowball Edge as seeding device guide.​​​​​​ ​

The following Phoenix update is released for the cloud update on February 4, 2019:

With this release, Phoenix is now an Oracle recognized database backup solution provider. For more information, see Oracle Backup Solutions Program (BSP). Phoenix provides a robust solution that works with {{oracle_rman}} to:

For more information, see Backup and Restore Oracle Databases

The following Phoenix update is released for the cloud update on January 21, 2019:

With this release, Druva Phoenix introduces an enhanced disaster recovery solution to convert the VMware virtual machine backup images to the AWS EC2 instances. This solution replaces the usage of VM Import for conversion. It drastically reduces the time required for the conversion process and provides predictable and improved RPO to our customers resulting in the faster virtual machine data restores.

In addition, administrators can now monitor the state of the failover process on the Phoenix Management Console.

Action required: For customers using a {{drproxy}} version earlier than 4.8.0, install a new {{drproxy}} version 4.8.0 or later. For more information, see Register Phoenix AWS Proxy.

Phoenix now supports the following:

Action required: Upgrade the backup proxy to the latest version.

Phoenix can now back up VMware virtual machines from the vCenter/ESXi hosts with a datastore that uses NFSv4.1 and NFSv4.2.

Action required: Upgrade the backup proxy to the latest version.

With the aim to constantly enhance the user experience, Druva is excited to introduce a refreshed Phoenix Management Console menu bar. A few options on the menu bar are reorganized and a few icons are removed. However, there is no change in the functionality in the product.

Action required: No action required.

The following Phoenix update is released for the cloud update on January 7, 2019:

The Analytics feature gives you an insight into your deployment of various resources with Druva Phoenix especially with respect to credits and storage consumption. Through various forms of graphs and widgets, you can get an in-depth analysis of the total credits and storage, source + changes data, current source data, the projected timeline for exhaustion of the credit balance, source reduction factor, and the change rates. It also enables you to view the events and the audit trails for the same. This feature is enabled by default for all accounts.

As a Cloud administrator, you can use this feature to:

To access the analytics data, on the menu bar, select All Organizations and click Analytics.

For more information, see Analytics.

Action required: No action required.

The following Phoenix update is released for the cloud update on December 3, 2018:

With this cloud push, following enhancements to the MS SQL Server are available:

For more information, see:

Phoenix certifies backup and restore of databases that are created and managed using SQL Server 2017. For more information about the SQL Server 2017 support, see System requirements.

Action required: Upgrade the agent to the latest version.

The following Phoenix update is released for the cloud update on November 5, 2018:

Role Based Access Control (RBAC) enables organizations to limit privileged user access to a predefined set of administrator roles and data assets to create ethical walls and enforce privacy and control. RBAC also enables the implementation of a delegated administration structure to meet customers’ organizational, compliance, and security requirements. Thus, organizations can achieve their goals efficiently with a seamless, granular, extensible administrator role management of their entities.

The enhanced RBAC offers the following capabilities:

Action required: Upgrade the agent to the version 4.7.6 or later.

For more information, see Manage administrator roles.

Phoenix extends support for backup and restore of databases that are created and managed using SQL Server 2017. For more information about the SQL Server 2017 support, see System requirements.

Action required: Upgrade the agent to the version 4.7.6 or later.

Starting October 15, 2018, the agents use TLS 1.2 to interact with Cloud. Here's how it impacts you:

Action required: To use the agent that connects to the Cloud using TLS 1.2, upgrade it to the latest version.

The following Phoenix update is released with the cloud push on October 1, 2018:

With this cloud push, you can re-register a Hyper-V host. You may want to re-register a Hyper-V host if:

When you re-register a Hyper-V host, the snapshot chain of the virtual machines running on the host is not broken.

For more information, see re-register a Hyper-V host.

Action required: Upgrade the {{phoenix_agent}} to the latest available version.

The following Phoenix update is released for the cloud update on September 17, 2018:

With this cloud update, Phoenix extends its restore capabilities for SQL servers by introducing the following restore enhancements:

To restore the databases to an AG, ensure that you run the Phoenix service with the domain account.

For more information, see:

Action required: Upgrade the agent to the version 4.7.6 or later.

The following Phoenix updates are released with the cloud update on September 03, 2018:

With this release, {{phoenix_cloud}} will support TLS 1.2. Now, you will only be able to access the {{console}} using browsers that support TLS 1.2.

Phoenix agents that will support TLS 1.2 are scheduled for the upcoming major releases. Keep a track of the updates on this page to stay informed about the agent versions that will support TLS 1.2.

Action required: Use browsers that support TLS 1.2.

The Phoenix agent released with this cloud push can back up Hyper-V virtual machines hosted on Windows Server 2016 using the Resilient Change Tracking feature. For the Phoenix agent to use the Resilient Change Tracking (RCT) feature:

For more information, see:

Action required: If you are backing up Hyper-V virtual machines for the first time, ensure that you use the latest Phoenix agent. If you want to use RCT for Hyper-V virtual machines hosted on Windows Server 2016, upgrade the Phoenix agent on the host and change the backup method to RCT.

Note: With the introduction of support for Resilient Change Tracking (RCT), the Phoenix agent uses the native Hyper-V technology to back up the virtual machine files in RAW image format. Before the support of RCT, the Phoenix agent backed up the virtual machine files using the Volume Shadow Copy Service (VSS). With VSS, the Phoenix agent backed up the virtual machine files like flat files. With this change, you may not get deduplication savings for the two different file formats and the storage consumption may increase. However, there is no impact on the backup and restore jobs. You can use older snapshots created using VSS to restore virtual machines on the hosts. For more information, contact Support.

You can now back up and restore vApp virtual machines. You can restore a vApp virtual machine using the original location restore. However, restore to an alternate vApp location is not supported.

Action required: Update the Phoenix backup proxy to the latest revision.

The Phoenix agent attempts a secure connection to the MS-SQL servers hosted on Windows servers to back up databases. The secure connection to MS-SQL server happens through one of the following protocols:

If TLS 1.0 is disabled, and you are using TLS 1.1 or TLS 1.2 ensure that SQL Server Native Client driver 11.0 is installed. Since TLS 1.0 and TLS 1.1 protocols are getting deprecated, if the TLS 1.0 protocol is disabled, and you are using TLS 1.1 or TLS 1.2 and the SQL Server Native Client driver is not installed, the backup jobs fail on the Windows server.

You can download the SQL Server Native Client driver for the MS-SQL Server 2012 from the Microsoft Download Center.

The following Phoenix updates are released for the cloud update on August 06, 2018:

Now, when you restore a Hyper-V virtual machine to an alternate location, Phoenix provides you the option to select a network.

Action required: Upgrade the agent to the latest version.

The following Phoenix updates are released for the cloud update on July 16, 2018:

Phoenix can now back up VMware virtual machines hosted on vCenter 6.7 and ESXi 6.7. For more information on the VMware versions that Phoenix now supports, see System requirements.

Action required: Upgrade the backup proxy to the latest version.

You can now exclude virtual disks attached to a virtual machine while configuring it for backup.

For more information, see:

Action required: Upgrade the backup proxy to the latest version.

The following Phoenix updates are released for the cloud update on July 2nd, 2018:

Phoenix announces the general availability of the Druva Cloud Platform Console.

If you want to use the domain account credentials to back up the MS-SQL server databases, you can now provide the credentials at the time of installing the Phoenix agent.

Action required: Upgrade the agent to the latest version.

To use domain account credentials, ensure that you manually upgrade the Phoenix agent. To manually upgrade the Phoenix agent, download and install the latest Phoenix agent on the server, and provide the domain account credentials at the time of installing the Phoenix agent. Enter the domain account username in the format: domain\username.
If you are already using the domain user account credentials, the Phoenix agent loses the credentials if you auto upgrade the Phoenix agent, and the backup jobs fail.

The following Phoenix updates are released for the cloud update on June 04, 2018:

For an enhanced user experience, Druva is excited to announce the following changes:

For more information, see: Organization Dashboard

Customer action required: No action required.

Druva Phoenix now supports wildcard exclusion in File servers and NAS shares. With this feature, the Phoenix administrators can exclude certain files and folders from being backed up. This feature supports exclusions based on file paths, filenames, folder names, and folder paths. The file extension is considered as part of the filename.

The following wildcard support is available in the folder exclusion policy:

For more information, see:

Customer action required: No action required.

With this Cloud update, Phoenix no longer supports agents with version 3.4 and earlier. Ensure that you upgrade the Phoenix agents on your servers to the latest version to continue to back up and restore the servers.

For more information, see Phoenix EOL policy.

For an enhanced user experience, Druva is excited to announce the following changes with the Cloud update scheduled for June 04, 2018:

Customer action required: No action required.

This cloud update has minor backend changes and bug fixes.

This cloud update has minor backend changes and bug fixes.

Before you upgrade Phoenix agent on Windows 2008 server, ensure that Microsoft Visual C++ 2008 Redistributable package is installed.

The following Phoenix updates are released for the cloud update on April 16, 2018:

Druva is excited to announce support for File-level Restore (FLR) for Hyper-V virtual machines. With FLR, Phoenix administrators can recover individual files and folders on a virtual machine guest operating system from a backed up virtual machine. An administrator may need a file-level restore if:

For more information on Hyper-V FLR feature, see File-level restore (FLR) on virtual machines.

Action required: To use all the capabilities of this feature, Phoenix provides an FLR proxy for the Hyper-V virtual machine hosts. Deploy this proxy on the host to restore files from the backed up virtual machines.

Phoenix can now backup and restore virtual machines hosted on Windows Server 2008 R2.

For more information on certified versions, see System Requirements for Hyper-V.

Action required: Update the Phoenix agent to the latest version.

Phoenix now enables its administrators to set the pre-/post-backup script timeout period to a value greater than 2 hours.

The following table lists the issues fixed in this release.

The following Phoenix updates are released for the cloud update on April 02, 2018:

Druva is excited to introduce the following menu items in the Phoenix Management Console:

Audit trails enable organizations to meet data governance and compliance requirements by providing a chronological view of all administrator data activities. With Audit trail, Phoenix maintains the history of all the activities that the Phoenix administrators perform on the Phoenix Management Console. Cloud administrators can track and monitor all the activities ensuring complete transparency, traceability, and accountability of all the administrators and thereby aiding forensics and compliance initiatives.

Audit trail captures activity details, such as the name of the administrator who accessed the entity, the action performed, the resource and the entity on which the activity was performed, the timestamp of the action performed, and the updated values of the entity. After an activity is completed, there is no latency and Phoenix logs the audit details immediately without any interaction with the administrators.

The key features of this update enable cloud administrators to:

For more information, see:

Customer action required: No action required.

Phoenix now supports SQL instances that are configured under AlwaysOn Failover Cluster Instances (FCI) for instance-level high availability.

For more information, see:

Customer action required: No action required.

With Phoenix agent 4.7.1, the default settings to retain snapshots have changed. Earlier, you could use the pre-populated values in the retention settings of the backup policy (number of dailies, weeklies, monthlies, and yearlies). Now, the default values are removed, and Phoenix requires you to explicitly specify the retention values while creating a backup policy. This change does not impact the existing retention policies.

If you are registering a server under the Default Organization, Phoenix provides a default backup policy with the following retention settings:

Customer action required: No action required.

This cloud update had minor backend changes and bug fixes.

Druva is excited to announce the following features with the Cloud update scheduled for April 02, 2018:

With the aim to constantly enhance the user experience, Druva is excited to introduce the following menu items in the Phoenix Management Console:

Audit trails enable organizations to meet data governance and compliance requirements by providing a chronological view of all administrator data activities. With Audit trail, Phoenix maintains the history of all the activities that the Phoenix administrators perform on the Phoenix Management Console. Cloud administrators can track and monitor all the activities ensuring complete transparency, traceability, and accountability of all the administrators and thereby aiding forensics and compliance initiatives.

Audit trail captures activity details, such as the name of the administrator who accessed the entity, the action performed, the resource and the entity on which the activity was performed, the timestamp of the action performed, and the updated values of the entity. After an activity is completed, there is no latency and Phoenix logs the audit details immediately without any interaction with the administrators.

The key features of this update enable cloud administrators to:

Customer action required: No action required.

Phoenix now supports SQL instances that are configured under AlwaysOn Failover Cluster Instances (FCI) for instance-level high availability.

Customer action required: To use all the capabilities of this feature, upgrade to the Phoenix agent version that will be released with this Cloud update.

The following Phoenix update is released for the cloud update on March 5, 2018.

The expiry date information is no longer displayed in the License and Storage section of the Phoenix dashboard as shown in the following screenshots. This is done to align with the non-expiring nature of Phoenix credits.

The following Phoenix updates are released for the cloud update on February 05, 2018.

Druva now supports AlwaysOn Availability Groups for MS-SQL server. You can back up databases that are a part of the AlwaysOn Availability Groups for MS-SQL server.

The key features of this update include:

With this update, Phoenix provides a new menu option, Protect menu, and the Servers menu is moved to the Protect menu. To access the MS-SQL server backup and restore configurations, operations, and other listings, click Protect > MS-SQL Server.

Action required: To use all the new capabilities of this feature, upgrade to the Phoenix agent version 4.7.1.

You can now backup jobs through the command-line interface. The command line utility is supported only for the configured MS-SQL backup sets.

For more information, see Trigger backup using command-line interface.

Action required: To use the new capability of this feature, upgrade to the Phoenix agent version 4.7.1.

With this update, you can start using an AWS account with multiple Phoenix organizations for disaster recovery. Virtual machines from multiple organizations can be replicated to a single AWS virtual private cloud subnet.

For more information, see DRaaS FAQs.

You can select resource pool, folder, and network settings at the time of restoring a virtual machine or disk to an alternate location.

For more information, see:

To use this feature, upgrade to backup proxy version 4.7.1. Since the automatic upgrade to backup proxy version 4.7.1 is not supported, you must deploy the new backup proxy through OVA on the Downloads page.
See, Upgrade backup proxy.

The following issue is fixed with the Phoenix update released on Feb 05, 2018:

The following Phoenix updates are released for the cloud update on January 15, 2018.