Disaster Recovery for the OpenEdge Database (Part 4)

Recovering from a disaster scenario that affects the OpenEdge Database.

As a reminder we will continue talking about Recovery Point Objective (RPO) and Recovery Time Objective (RTO)

Recovery Point Objective (RPO): defines how much data is willing to be lost in a Disaster Recovery Scenario. Lets assume there are daily backups at midnight. If an event occurred that required restoring the database, all the data entered into the database between midnight and the time of the event would be lost. For some environments this may be acceptable, however for most production environments, losing a large amount of data would be unacceptable, especially if the data cannot be reproduced.

Recovery Time Objective (RTO): defines how long it takes to get the environment operational. How long can the system be down during a recovery event? During the time to recover all database operations will be halted. It the database is used as part of a manufacturing process, then the manufacturing itself will be halted until the system is once again operational. Many companies measure downtime in dollars lost by the hour.

We learned that backups and AI files can be used to reduce the RPO, however it increases the RTO as it takes time to restore backups and apply AI files. We also learned that we can restore a database and apply AI files as long as it is on the same machine, however if you wanted to build a Disaster Recovery System that included replacing the production machine, this would require an additional Disaster Recovery (DR) license. In addition to this license there is significant scripting that needs to be involved. Error checking for actions between can be daunting and errors can be hidden and not discovered until a Disaster Recovery Test or a true emergency. Not the best situation.

The OpenEdge team at Progress recognized this challenge and created the OpenEdge Replication product.

OpenEdge Replication (OER)

OpenEdge Replication provides real-time replication between a single production OpenEdge database to one (or two) OpenEdge database specially used for the purpose of Disaster Recovery. This is accomplished with no scripting or error checking. OER is an additional product that needs to be purchased, but it includes a DR license.

OER takes the change notes generated on the production database sends them over the network to a receiving process that then applies those changes to the disaster recovery database similar to using the “roll forward” process used to apply AI files to a restored database.

In the event of a disaster, the RPO is near zero, as during normal operations, OER keeps the DR database in synch. However, for some large batch update operations like an MRP run, the target DR database may lag behind, but typically not more than a few minutes and will catch up quickly once the batch process completes.

RTO time is dramatically reduced as this DR database and environment are ready to be used with little change to the environment, sometimes just a DNS change.

Testing your Disaster Recovery Strategy

We have discussed several disaster recovery strategies, which OmegaServe can help implement, however every implementation needs to be tested periodically to make sure the business can operate once the DR plan has been executed.

OmegaServe recommends the following testing strategy
• Annual test. Once a year, have a person or set of persons do their operations on the DR environment. While this takes effort to reset once the test is complete, experience has shown that even with multiple tests, problems are discovered where items, typically beyond the database, are missing.
• When the environment changes. New systems are brought online, new components are added to the environment (Pro2 for example), application upgrades, etc. This is the time to do a DR test to make sure the system functions and the new components are functional in the DR environment.

Bringing it all together
Statistics have shown 94% of companies faced with a disaster never fully recover.  Don’t be part of this majority. 

OpenEdge System Health Check

Is your Progress OpenEdge database running optimally? Could there be an unknown issue that could potentially damage or bring down your production database?