Disaster Recovery
Don’t get caught with your pants down. Disaster Recovery is designed to get you back on your feet as soon as possible after a catastrophic event. Office burnt down or Server failure?
Mitigate the heartache with a proper Disaster Recovery plan.
Disaster Recovery (DR)
DR comprises of services and solutions that allow a company to maintain business continuity whenever a disaster occurs that affects critical systems. Disasters of such nature can be categorised as hardware/software failure, accidental data loss, virus infection (such as ransomware), and other unexpected catastrophic events.
For example, if a single server fails at a customer’s site, then a different host server located elsewhere can bring the servers backup as virtual servers; this is the same for storage failures in which there are two paths to the storage on each server.
Types of DR at a Glance:
Backup / Backup as a Service (BaaS)
The simplest form of disaster recovery is backups of data off-site or on a removable disk.
Technically speaking this kind of backup contains organisational data, such as virtual servers, but not the network infrastructure. This is not always the case, as the backups we perform are full system backups. This allows for restoration to dissimilar servers as a ‘whole system’, or restoration of data stored within the system that is backed up.
Cold Site
In this scenario, a basic network is set up at a separate site. In the case of disaster, this network and site can be used by employees to work from in the case of a fire or natural disaster. This allows a company to become operational by facilitating business operations to continue. However by itself it does not give data protection/recovery of data, and so implementing this method requires the additional use of other forms of DR.
Hot Site
A hot site is similar to a cold site in that it provides a separate location and network for employees, however data is kept up-to-date at all times. Hot sites are generally more expensive than cold sites as they take a lot longer to set up and there are other implications in terms of data transfer. The main advantage to this type of DR is that it drastically reduces downtime if a disaster occurs.
Data Centre DR
This is relevant to the physical elements of a data centre space (including the Exchequer Dynamics Data Centre space), as they can be protected by backup sources and fire suppression techniques.
Exchequer Dynamics can provide the following solutions for disaster recovery as a service (DRaaS) and/or replication to our off-site data centre:
Disaster Recovery without Continuous Replication
This is a cost-effective option that is designed to run nightly, allowing core virtual servers to be copied to a different host. In the event of an outage of the main host, you can start the virtual server on the other host in our data centre. This provides a data loss timeframe of 24 hours, but the backed-up VM can boot instantly on the backup server. With recovery time being a lot easier to manage, you would simply replicate a copy back to the site when ready to revert.
Disaster Recovery with Continuous Replication
This is the higher cost option and it is designed to continually backup throughout the day. The system automatically recognises any indication of data changes on virtual hard disks, as opposed to copying the whole disk. By monitoring and tweaking, you can optimise the time the replication occurs. This greatly reduces data loss from 24 hours and could be anywhere from 10 minutes upwards. This is the solution that allows for the least data loss and has the fastest Recovery Time Objective (RTO) as the replicated VM in our data centre can then be replicated back for a fast switchover.
Virtualization DR
Another form of DR works by replicating an organisation’s entire server network to an off-site location which would be unaffected by a disaster scenario impacting the original site. This is primarily implemented by creating a complete replication of critical data or servers to off-site virtual machines. For this type of DR to function correctly the data must be uploaded frequently.