Backup and High-Availability Options on AWS

When hosting Data Virtuality Server on AWS, a common question is how to achieve high-availability or prepare for a disaster recovery scenario. This article gives an overview of two possible implementations.

Restoring EBS Snapshots

Your EC2 instance running Data Virtuality Server is using an Elastic Block Store (EBS) acting as the instances' hard disk. Via AWS Backup, regular snapshots can be created, acting as your backup.

The EC2 instance should use an Elastic IP Address. Elastic IP Addresses add an extra layer of abstraction to your EC2 instance by providing a static IP address. This allows you to later assign the Elastic IP Address to a different EC2 instance, without the need of changing the way your data consumers are addressing Data Virtuality Server.

The process in case of a disaster would be as follows:

1. Identifying the latest EBS snapshot and starting a new EC2 instance from it;
2. Assigning the Elastic IP Address to the new EC2 instance.

This approach is relatively easy to set up and involves nearly no additional resources. However, the process of starting up a new instance might take some time.

Warm Standby

If you want to eliminate the need of having to spin up a new EC2 instance, you can have a warm standby instance permanently running. The standby instance regularly will regularly pull the current configuration from the production instance and use it to replace its own configuration. This can be scheduled to run e.g. hourly.

In order for jobs not to run twice on both instances, the standby instance gets put into maintenance mode, so that it will not accept any queries or start any job.

An Elastic IP is also required, leading to the following failover process:

1. Disabling the maintenance mode on the standby instance;
2. Switching the Elastic IP Address to the standby instance.

Compared to the "Restoring EBS Snapshots" method, a warm standby minimizes the amount of time between the occurrence of a disaster and successful recovery. In return, it requires a second running EC2 instance. Please also note, that an additional Data Virtuality Server license is required for this scenario.