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.