RDA

Backups, Disaster Recovery & Security – Part III


2019 Government Ransomware Incidents

In this installment we will focus on Disaster Recovery (DR) and RDA.  More and more organizations are moving their mission critical data and processing to the cloud. We believe this is a good first step to minimize the risk of disasters and security breaches. In the last couple of years Disaster Recovery solutions have evolved to further minimize these risks. 

As shared in the first installment – Disaster Recovery (DR) involves a set of policies, tools and procedures to enable the recovery or continuation of vital technology infrastructure and systems following a natural or human-induced disaster or a crippling security breach. 

Last time, we discussed RDA Data Backups.  In short, RDA backs up your RDA data every night and stores the data backup file in a secure data center on the west coast. When needed, a data backup file can be manually restored to your existing cloud server. 

How does Disaster Recovery differ from Data Backups? The focus of RDA Data Backups is on maintaining the integrity of your RDA data.  If your RDA data is deleted or corrupted, a Data Backup File can be manually restored to get you back to normal operations. Disaster Recovery is focused on managing a bigger event. Itโ€™s purpose is to restore an organization to normal operations after a catastrophic infrastructure failure or crippling security breach.

Natural Disasters

There are two important numbers when planning for disaster recovery. 

Recovery Point Objective (RPO) – The amount of RDA work or data you can afford to lose from a disaster or breach. This is measured in time: days, hours, minutes or seconds. With nightly backups, the RPO can be as high as a full day’s work. For example, if a system disaster happens at 4:30 PM, a day’s work is lost. Or, if you wish to limit losses to no more than ยฝ of a day,  backups at noon and midnight are required. How much data or work can you afford to lose? 

Recovery Time Objective (RTO) – When a disaster or breach occurs, RTO is the length of time it takes to return operations to an acceptable level of functionality. Recovering from a disaster or breech includes more than just restoring your RDA data backup. Some of the steps involved are:

  1. Initiating help desk request
  2. Diagnosing & verifying problem
  3. Procuring new server hardware in a different (secure) region
  4. Loading & configuring the server operating system
  5. Loading current RDA programs onto the new server
  6. Loading and Restoring the RDA data backup
  7. DNS Updating (Domain Name Servers (DNS) are the internet’s equivalent of an address book)
  8. After the disaster is over, restoring your RDA system to the original server location (region)

 All of these steps take time. The question for determining the RTO is: How long can you afford for your RDA system to be down?

Once these two Objectives are defined, an appropriate DR plan can be formulated. Much like insurance, a DR plan can be designed to meet all risk levels. 

Disaster Recovery has changed quite a bit over the last few years. Planning ahead ensures that if a disaster or breach does occur, a plan is in place to restore operations in a graceful, coordinated and timely manner. It is best when the outcome is never in doubt. 

If you would like more information on Disaster Recovery Plans, please contact Mimi English (mvenglish@rdasys.com).

Our next installment in this discussion will be an overview of Security and RDA.




Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Other Posts