Druva has announced a major upgrade to Druva Phoenix, its converged cloud storage platform that it launched on Amazon Web Services (AWS) in 2015. Druva Phoenix currently allows companies to backup both their physical and virtual environments to cloud. Now it is offering the ability to add Disaster Recovery protection as well.
According to Jaspreet Singh, CEO, Druva: “Companies have been forced to juggle multiple hardware and software resources – including on-site tape, secondary disk hardware and backup software – to manage, protect and secure data. This has created organizational silos and significant expense.
“Phoenix has been designed as a one-stop-shop for on-demand, infrastructure data protection services. By adding DR to Phoenix’s existing public cloud backup and archival capabilities, these silos are eliminated, saving enterprises money and resources.”
Druva Phoenix making the jump from backup to DR
Druva Phoenix customers using VMware are the first to benefit from this new functionality. Rather than customers buy into a new cloud-based data centre that will come with costs, Druva Phoenix will enable any virtual machine (VM) backed up through Phoenix to be spun-up in AWS.
The VMs are converted to Amazon Machine Images (AMI) by the Druva Phoenix DR solution as they are stored in the public cloud. This means that in an emergency the DR capability fails over to AWS, starts the AMIs and users should see little to no impact on their work. All of this is handled by a set of policies that monitor availability and automate the process.
Perhaps the biggest issue for many companies will be unplanned for and unexpected costs. They will need to carefully monitor at what point the DR option kicks in and spins-up an AMI. If the threshold is too low and cannot cope with a very short network glitch then there will be a lot of small charges for AMI’s that have been started. However, if the network down setting is too long there will be user complaints.
Moving from backup to archive to a full DR solution is more than just about spinning up some VMs. There has to be a full understanding of the architecture of the underlying systems, something that a lot of companies don’t have. This is why many companies discover that their DR fails when they need it most. DR is often never as easy as just spinning up a copy of a server as applications are rarely that self contained. This means that the DR failover will start multiple AMIs taking us back to the issue of cost.
Other issues include the need for a copy of the user credential server, be that Active Directory or something else, to be always available. How this will be handled is not detailed in the Druva Phoenix documentation and IT departments need to ensure that when the DR kicks in users are still able to be authenticated. There also needs to be a set of processes that deal with data storage, especially where databases are concerned to ensure the integrity of the data.
DR is just one of the new features in the latest release of Druva Phoenix. The press release lists the following additional headline features:
- Unified Backup & Recovery for Physical and Virtual Environments – Removes the need for costly multi-vendor approaches and provides ever-incremental backups for greater storage flexibility and recovery.
- Seamless Archival – Automates storage management and provides infinite retention ensuring data can be held and securely stored for decades.
- Test & Dev – Boots a copy of a virtual image in the cloud, allowing companies to create a replica of the production environment. Tests and validation can be run against a copy of the production data.
- Integrated Analytics – Converging multiple services provides administrators unified visibility to data and usage patterns.
Existing customers of Druva Phoenix backup and archival will have access to the integrated DR option in April. According to the press release it will involve an additional cost but there is no indication yet of what that might be.
Conclusion
This is a sensible move by Druva to move from backup and archive to DR. However we may have to wait 60 days to find out exactly how it will work in practice. At the moment there are a lot of questions, not least how users will be able to seamlessly logon to VM’s spun-up as a result of DR being activated. There are several ways of solving this but at the moment Druva is not saying how it will be done.
