In an increasingly cloudy world, it’s easy to be seduced by the attraction of handing responsibility for IT services to the chosen cloud provider. However, not all cloud services are created equal: while some include back-up (of variable quality), some do not, and many are not compatible with existing on-premise back-up solutions.
As my colleagues and I review back-up and disaster recovery (DR) options for many widely used cloud services for our customers, it’s become clear that it’s a case of ‘buyer beware’ – or as a minimum, ‘buyer prepare’. Organizations should not assume back-up is included with every cloud service, or that a single back-up solution can manage everything in this brave new world.
As their cloud portfolio grows, they are likely to find themselves with multiple different systems, which requires a considerable investment of time, effort and skill to manage. They also need to consider how quickly they could recover if the worst happened, such as a ransomware attack.
Back-up is of course needed to meet legal and compliance requirements, as well as for recovery. However, it’s worth noting that, while having a significant copy of information elsewhere may also be part of the organization’s business continuity (BC) plan, there are different ways of providing BC in the cloud which are not location based.
Don’t assume your cloud service provides back-up
It’s easy to assume that most cloud services, particularly SaaS, include back-up. Some popular services, such as Google and Office 365, retain copies of your files by default, although for a limited period. If the files need recovering, there are no SLAs, and experience has shown that this is a difficult and uncertain process, although improvements are being made all the time. In other words, the backups are not enterprise quality, so your organization will need an alternative.
Services that are based on buying cloud instances will invariably require additional virtual machines to provide a traditional backup solution, and/or require a separate solution. This will increase costs and tie your organization more closely into the cloud vendor.
For example, Microsoft offers long term data retention for an SQL environment, but this means that both primary service and back-up come from the same vendor. Your organization’s existing back-up system can only provide support if it first inserts an agent, and this is not permitted – so vendor dependency increases.
This also applies to serverless instances. Many organizations will assume their existing back-up system can support all their cloud services. It is not a problem for IaaS, as organizations can back up from snapshots, or insert an agent and use their existing system.
However, PaaS and SaaS are not based on virtual machines but use serverless instances. They are significantly cheaper, but it is impossible to insert an agent, so again traditional back-up systems cannot help.
Take Veeam as an example – this can back up SQL held on a virtual machine, but not as a managed instance. Additionally, Veeam has one interface for traditional server back-up and a completely separate interface for Office 365, although the company hopes to integrate them soon.
Both Azure and AWS provide backup services, but apart from storing the backups on themselves, so not delivering separation, they do not have all the agent capabilities of a traditional backup application. Platforms such as Druva, which resolve the backing up across cloud issue, also do not have agent capabilities.
This increases complexity and makes it difficult to have a single cohesive back-up and DR strategy. Instead, organizations find themselves tied into multiple back-up systems, which is expensive, difficult to manage and even more difficult to test. The situation is constantly evolving, but in the interim, organizations need to be aware of these issues and plan accordingly.
Never mind back-up, what about recovery?
Being forced to use multiple backup products has significant consequences for major systems recovery. At the times of most stress, i.e. during a major failure, organizations need simple and consistent recovery methods across all systems, not multiple products with different data images. This process can be merged to ensure continuous recovery, but it requires considerable additional skills and knowledge about how the multiple products interact – thus negating cloud’s promised simplicity.
Take SQL again – with the back end (data), middleware and front end (web portal) now backed up by different products, recovery is clearly not going to be quick. Microsoft are developing tools to allow the full and consistent back-up of SQL components, but, although they aim to simplify the process through the use of a GUI, they are writing them so that changes can only be made using PowerShell scripts and not their portal. If the skills needed to handle backup and recovery become more complex, then cloud’s much-vaunted ease of use no longer applies.
Due diligence is key
Cloud’s aim is to provide flexibility, scalability, pay-as-you-go and above all simplicity. However, backup and recovery, always a Cinderella service, are becoming increasingly complex and time-consuming in a cloudy world. If an organization has multiple separate services to recover, how quickly could it get them back up and running in a crisis?
There is no easy solution to this dilemma. Instead organizations need to carry out due diligence before committing business critical applications to cloud services and ensure that they understand the risks and prepare accordingly. Finally, they should bear in mind that backing up data is always their responsibility.