Backing up and disaster recovery to the cloud has a number of advantages. Choose one of the recommended scenarios early on

Backup and subsequent data recovery or more advanced disaster recovery (DR) scenarios are still an underrated topic in many organizations. Companies that have never lost data often treat backup and recovery tests as a fringe issue.

Statistically speaking, however, it is true that sooner or later, some kind of failure will occurwhether it's caused by HW, human error or a hacker attack. You will have seen reports in the media of ransomware attacks that have encrypted the data of many organisations, who have found that being able to recover data quickly is very important.

So it is not a question of if, but when something will happen in every organisation. How can we prevent it with cloud backup?

First a little theory

Before you start deploying backup or a more complex DR solution in your organization, a planning part must precede it. First, we define basic parameters such as maximum recovery time (hereinafter referred to as RTO) and maximum data loss time (hereinafter referred to as RPO).

In larger organisations, this phase is usually part of business continuity planning (BCP) or business impact analysis (BIA). We define the criticality of the service and know how much it will cost if it fails.

From the above parameters it is defined SLA services. For example, if we have an SLA of 99.9 %, we can afford a maximum of 8 h 45 min 56 s of service outage per year.

However, we must also include activities such as OS updates, service upgrades, migrations, etc. Therefore, we would choose the parameter MTPOD (max. tolerable period of down time) to a maximum of 8 hours and RTO to 4-6 hours. The RPO parameter, i.e. how much time is lost, is based on the BIA definition.

Backup is selected when we have a longer RTO time and we are able to recover the data within a defined time period.

Disaster recovery we use during short RTO (usually units of minutes) and we solve the service restoration by switching to the backup site. The disaster recovery option is more expensive than backup, but covers more scenarios (such as loss of hardware or the entire site).

Example: if the service runs on SQL server and we have set incremental database backup after 15 minutes, then data loss is in the range of 0-15 min and RPO is max 15 min. The RTO depends on how long the database recovery takes.  

On-premise backup

First, let's recap the most common on-premise backup scenarios environment:

• USB drives

We cast data to USB drives, which we continuously rotate. Cheap solution, high RTO and RPO.

• NAS

We cast data to NAS and use native software from NAS or scripts. Cheap solution, medium RTO, higher RPO.

• Backup SW

We have implemented specialized backup software with the possibility of granular data recovery. We also protect important data by off-site backup to another location or server room. Medium cost solution, medium RTO, medium/lower RPO.

• Backup & Disaster recovery scenario

This is an enterpise scenario, which consists of a complex backup solution and a disaster recovery solution with the possibility of rapid data recovery or switching operations to a backup site. It is suitable for large companies running mission-critical workloads or companies subject to audits and regulations. An expensive solution, the RTO is very low and the RPO is low in the case of DR service switching.

Why is cloud backup worth it?

The advantage of using the cloud for backup and disaster recovery is a large amount of free fundsthat we can quickly start using in the event of an emergency.

On the other hand, in an on-premise environment, we need to keep an appropriate amount of HW ready. In the case of DR, we then reserve the entire second site, which is not fully used most of the time, and where in addition to the HW we also deal with connectivity, cooling, network elements, etc. This represents huge extra costs compared to the cloudwhere we only pay for the data stored and only pay for the funds when they are used.

In the cloud, it is generally true that data transmitted inwards is free a data transmitted outside is charged for. This can be used in any off-site backup scenario.

An example is NAS storagethat can now natively connect both Azure Blob Storage, yes AWS S3 Glacier storage and automatically offload data from the NAS to them. Similarly, cloud storage connections are supported by backup software such as Veeam, CommVault, Acronis Also. The advantage is that you can connect via the internet without setting up a VPN.

Long term cloud data storage on storage as Azure Blob storage tier a archive AWS S3 Glacier archives enable long-term data storage at a very good price/performance ratio.

In case of use Azure Backup data transfers are not charged at all. We only pay for the service based on the number of protected VMs in the on-premise environment and the data stored in Azure.

In the framework of AWS Backup we also only pay for the space used. Prices vary slightly according to the type of service as EFS, RDS Database etc. Generally, storing 1 TB of data with AWS Backup costs $1 per month.

Cloud backup options

Each cloud provider has implemented its own backup technologies and third-party solutions. In the case of:

• Azure it is Azure Backup a Azure Site recovery,
• AWS is AWS Backup services a AWS Disaster Recovery,
• third party solutions are Commvault, Veeam, Acronis, Avamar and others.

Azure Backup

This technology enables back up on-premise resourcessuch as physical and virtual servers on Hyper-v and VMware platforms.

Backup is performed via an appliance deployed in a local environment, which stores backups partly locally and then to the cloud. It depends on the backup policy settings and the function instant recoverywhere recovery can take place from the local server without the need to transfer data from Azure.

In addition to supporting on-premise resources, all Azure resources are natively supported such as:

• virtual computers
• managed drives
• SQL Server on VM
• PostgreeSQL
• blob storage

In the case of recovery, we can restore to both on-premise environments and Azure. The scenario of recovering resources to Azure is interesting in case we lost local hardware in some disaster.

Azure Site Recovery (ASR)

This service uses similar components as Azure Backup. But it does not only perform advance according to the relevant policybut continuously replicates data from protected resourcessuch as physical servers or VMs hosted on VM-ware and Hyper-V hypervisors.

Azure resources are supported natively. Here, when ASR is deployed, data is replicated to another region with the option to switch traffic to the replicated site. We wrote about this in detail in the article high availability of services in the cloud.

Another advantage of ASR is the ability to deploy replicated resources on an isolated network (V-net). This can be used to verify the functionality of DR, or for the purpose of a test environment that is 1:1 to the production environment.

AWS Backup

On the side AWS Backup all types of AWS cloud resources are supported, such as:

• Amazon S3
• Amazon EBS
• Amazon RDS including Amazon Aurora
• Amazon DynamoDB
• Amazon Neptune
• Amazon EFS
• Amazon EC2

AWS Backup also allows back up all VMware workloads on-premise and in the VMware cloud. Backup of standard physical servers and other hypervisors is not supported. In the case of physical server protection, we can use AWS Elastic Disaster Recovery.

AWS Elastic Disaster Recovery

This technology enables (as well as Azure Site Recovery) to protect all possible types of resources in on-premise, where RPO is in seconds and RTO is in minutes. The replication agent is at the OS level and can be used on physical and virtual servers.

AWS Elastic Disaster Recovery It also supports scenarios for other cloud providers and replication of their resources. Within AWS, it natively supports replication Failover & Fail back between regions.

Third-party backup solutions

We can use any third-party technology besides native solutions. Mostly it is available in the form of an appliance or some off-the-shelf solution, where you only need to supply your own configurations and license in the BYOL model.

The result is fast deployment and configuration of resources and custom licensing just like in on-prem. Here we have a choice of two scenarios:

1) To the current solution connect cloud storage type Azure Blob Storage or S3 Glacier through the AWS storage gateway and we only use the cloud as off-site storage.

2)    Expand backup infrastructures to the cloud and deploy backup servers and storage.

Recommended cloud backup scenarios

Scenario 1

Long-term data archiving for long term storage as Azure Blob Storage in Archive mode, or AWS S3 Glacier in Archive mode, where prices start at 1-2 EUR per stored TB of data per month.

Transactional operations such as writes and reads, which are negligible for one-time storage, must be added to the price. Archives are not suitable for data that we modify frequently. In the case of Azure, the requirement is to keep data for at least 180 days.

Scenario 2

Off-site backup for NAS storage using cloud storage Azure Blob storage COL and Archive tier or AWS S3 Glacier in Cold and Archive tier.

Here, you need to properly design and configure the replication agent on the NAS so that data destined for long-term archiving is placed on the archive tier and data that is more frequently modified and mirrored 1:1 ends up on the COL or HOT tier.

Scenario 3

Off-site backup using existing backup software and cloud storage connections like Azure Blob storage or AWS S3 Glacier.

This scenario is used most often as it is the cheapest off-site backup option. If we only need to deploy storage on the cloud side, we can connect it over the internet without the need for a VPN.

Scenario 4

Off-site backup + DR using existing backup software and extending the backup infrastructure to the cloud - either by installing it on VMs or deploying the appropriate appliance or platform slave.

Next, it is necessary to have the basic infrastructure ready: networks, VPNs, servers (deallocated) or pipeline and scripts to deploy the necessary storage and increase computing resources for data recovery and creation of DR-Site with the possibility of traffic switching.

In this scenario, the architecture of the entire solution is important because of network readmissions, various traffic redirection, integrations, Firewall settings, DNS, etc.

Scenario 5

Off-site backup + DR using native services such as Azure Backup a AWS Backup.

This scenario requires a basic infrastructure in the cloud such as VPNs, servers (deallocated) and ready deployments of the necessary resources via pipeline and scripts or IaC, which can be used to increase the necessary storage and computing power for data recovery and create a DR-Site with the possibility of traffic failover. RPO and RTO times reach tens of minutes.

Scenario 6

Full DR solution using Azure Site recovery or AWS Elastic Disaster Recovery,

In this scenario, it is possible to achieve minimum RTO and RPO times in the order of units of minutes. It all depends on the architecture of the solution and the components chosen, where all resources are protected by the replication agent.

Finally, on cloud backup

In today's world of digitized processes and ever-increasing enterprise data, there is a growing emphasis on service availability as defined in SLA. From this comes the push for more advanced backup scenarios and BCDR - business continuity & disaster recovery.

As we have shown in this article, many scenarios can be implemented in the cloud - from simple ones where we use only storage, to advanced ones where we use cloud data recovery using native cloud tools or specialized third-party software. To complex Enterprise scenarios providing very low RTOwhere the switchover will automatically deploy all necessary resources and switch over the operation.

From the perspective of running backup or DR in the cloud, we don't have to deal with a large amount of unused hardware, its maintenance, location somewhere in a second datacenter or server room and all the things associated with connection, operation and maintenance. Cloud-based solutions therefore achieve savings in the tens of percentages.