When you hear remote backup and disaster recovery, you might be surprised to know that the two are not synonymous. Many companies make the mistake of believing that simply backing up their data remotely will be enough in the event of a disaster. To clear up any confusion, we wanted to shed more light on the differences and how we handle a potential disaster.
This is the process of duplicating your primary application and it’s containing data to a second data storage, located in a second (i.e. remote) data centre. Since the data changes continuously, this service involves a recurring re-backup of most recent version of the data and application. This recurrence can be nightly, hourly, even more frequently.
This is the process of restoring your application back to normal operations, after a disaster has occurred.
We define a disaster as an incident causing the primary instance of the application to completely fail, or be inaccessible, without any clear prognosis on how or when it can be restored in-place. It is important to know that the likelihood of a disaster of this magnitude is very small. An incident that is of known origin with a clear resolution time if often not considered a disaster, as there is typically no data loss involved.
Disaster Recovery requires that a remote backup service is in place.
There are two types of disaster recovery:
1. Manual Recovery by Rebuild: our team is notified of the need to restore the primary service (we will already know that it is down). We will then use the last remotely backed up data and application code to rebuild the application in a secondary, unaffected data centre. The turn-around can be 24 hours, depending on the extend of the disaster. This is a cost-effective solution for systems that can afford longer downtime for a low-likelihood event such as a disaster. Typically the cost to backup data only is small, and the one-time effort of rebuilding the system is small and only needed in the actual case of a disaster.
2. Automatic Failover: this means that after a certain downtime of the primary service or other monitor-able indicators, the application is automatically made available from the secondary data centre. This requires a replica of the primary system to be created at the secondary location and kept in “standby” mode during regular operation. While not as costly as hosting the primary system, this service and the data replication between the two systems can incur some significant cost. A rule of thumb is to double the hosting cost of a typical, single-instance hosted system.
While it is important to have a backup of your data in order to execute your disaster recovery plan, a remote backup will not be enough in the event of a disaster.