OpenEdge Disaster Recovery: Backups, Replication, RTO and RPO

OpenEdge disaster recovery works best as three layers: tested backups with after-imaging so you can restore to a point in time, OpenEdge Replication for a hot standby that can take over quickly, and written RTO and RPO targets that decide how much of the first two you actually need. Progress's own documentation says after-imaging is the only way to recover a database to the present time after a media failure, and that OpenEdge Replication requires it. So the practical plan starts with after-imaging, adds replication when your recovery time target demands it, and is proven by regular restore drills.

This guide is for IT managers, ERP owners and operations leads who run a business application on a Progress OpenEdge database and need a plan that holds up on a bad day. It draws on Progress's OpenEdge database management documentation, the OpenEdge Replication documentation and the AWS Well-Architected Reliability Pillar for the RTO and RPO definitions. Commands and property names change between OpenEdge versions, so treat this as a planning map and check the details against your version's documentation.

What do RTO and RPO mean for an OpenEdge system?

Two numbers drive every disaster recovery decision, and you should set them before you pick any tool.

• Recovery Time Objective (RTO) is the maximum acceptable delay between the interruption of service and its restoration. In plain terms: how long can the business run without this system?
• Recovery Point Objective (RPO) is the maximum acceptable amount of time since the last recovery point. In plain terms: how much recent data can you afford to lose or re-enter?

Those definitions come from AWS's Reliability Pillar, which also advises setting them per workload, from business impact, with the business and technical teams together. For an OpenEdge-based ERP, ask the finance, warehouse and customer service leads two questions: "If this is down, what stops?" and "If we lose the last hour of transactions, what do we do?" Their answers become your targets. If you want a deeper walkthrough of that conversation, our guide to setting RTO and RPO first covers it step by step.

What recovery tools does OpenEdge give you?

Progress describes three recovery mechanisms in the OpenEdge RDBMS, and it helps to know which one handles which failure.

• Crash recovery uses the before-image (BI) log to recover from system failures such as a server restart. It happens automatically without anyone running commands.
• Roll-forward recovery uses a backup plus after-image (AI) data to recover from media failures such as a lost disk.
• Two-phase commit keeps transactions consistent across multiple databases. Progress says that if you use it, you should also use after-imaging.

Disaster recovery sits on top of these. A server crash is handled by crash recovery. A destroyed disk, a ransomware event or a lost data centre needs a backup, the AI files and somewhere to restore them, and that is where your plan comes in.

How should you back up an OpenEdge database?

PROBKUP is the OpenEdge backup utility. It backs up the database, the before-image files and transaction log extents, and it supports online backups (while users work), incremental backups and compression. A few details matter for disaster recovery:

• If after-imaging is enabled, PROBKUP switches to a new AI file before the backup starts. That switch creates the reference point from which roll-forward recovery begins. Progress also notes the next AI file must be empty, or the backup aborts, so AI file management is part of the backup routine rather than a separate chore.
• An online backup is not possible on a database started in single-user mode, with no shared memory, or with no crash protection.
• A backup can only be restored to a database with the same physical structure, so keep your structure files (.st) with the backups.

Progress's community guidance on restoring a mix of full backups, incrementals and AI files is to keep at least the last three full backups with their associated incremental and AI files, so you can fall back if the newest full backup will not restore. Store at least one copy off the server and ideally off the site, because a backup that lives on the failed machine is not a disaster recovery plan.

Why is after-imaging the foundation?

Progress states that after-imaging enables recovery to the last transaction or to a point in time after media loss, and that it should be part of every high-availability environment. Its documentation gives a useful example of why it matters beyond hardware failure: if a program accidentally overwrites every customer name, disk mirroring just gives you two copies of the bad data, while after-imaging lets you restore last night's backup and roll forward today's AI files to just before the mistake.

The recovery sequence looks like this at a high level:

1. Restore the last full backup with PROREST, then any incremental backups in order.
2. Apply the AI files with rfutil <db> -C roll forward, optionally stopping at a chosen time with endtime or a transaction number with endtrans.
3. Re-enable after-imaging afterwards, because roll forward disables it and you must start it again with rfutil <db> -C aimage begin.

Two rules from the documentation catch people out. AI files must be applied in the sequence they were generated, with none skipped, and you must apply all of them before the database is usable. That means a missing or corrupt AI file stops your recovery at that point, so archive AI files reliably and monitor the job that does it.

When do you need OpenEdge Replication?

Restore and roll forward is dependable, but it takes time: restore the data, apply the AI files, bring up the application. If your RTO is shorter than that process can deliver, you need a standby that is already running. OpenEdge Replication is Progress's feature for that. It automatically replicates a source database to one or two target databases in real time, for failover or disaster recovery, and includes failback so you can return to the original server later.

Points to plan around:

• After-imaging is required on the source database. For Replication Sets (a source plus two targets that know about each other), after-imaging must also run on both targets so one of them can become the new source.
• Replication is asynchronous. Current Progress documentation says OpenEdge databases support only the asynchronous model, and describes it as store-and-forward: the change can be replicated seconds, minutes or longer after the transaction, depending on your setup. Earlier versions, before OpenEdge 12.0, could also use synchronous replication, but Progress recommended asynchronous for speed. The consequence is simple: do not assume an RPO of zero. Measure your replication lag and set the RPO from the measurement.
• Transition can be manual or automatic. Recent versions include online manual recovery transition, which keeps target database brokers running during the switch and reduces downtime. The target must have after-imaging enabled to become the new source, either beforehand or through properties such as auto-begin-ai, auto-add-ai-areas and an ai-structure-file.
• Replication does not replace backups. A standby faithfully copies a bad update or a deleted table. Keep backups and AI files for point-in-time recovery as well.

How do RTO and RPO map to a disaster recovery design?

AWS describes four general disaster recovery strategies, in increasing order of cost and complexity and decreasing order of RTO and RPO. They are a useful frame for OpenEdge whether your servers are on premises, in a colocation facility or in a cloud.

• Backup and restore. AWS characterises this as RPO in hours and RTO of 24 hours or less. For OpenEdge this is the PROBKUP plus AI archive plan, with copies stored at another location and a documented restore procedure.
• Pilot light. RPO in minutes and RTO in tens of minutes: core data is replicated and always on in the recovery site, while application servers are started when needed. For OpenEdge this is a replicated target database with the application tier built from scripts or images on demand.
• Warm standby. RPO in seconds and RTO in minutes: a scaled-down but working copy of the whole workload is always running. For OpenEdge this is a replication target plus a running application tier that can be scaled up and pointed at.
• Active-active. Near-zero RPO and RTO, but with real complexity in keeping data synchronised. For a traditional OpenEdge application this is rarely the right goal.

These ranges are AWS's general characterisation of the patterns, not OpenEdge benchmarks. Your actual numbers depend on database size, change rate, network bandwidth and how well your team has rehearsed the steps. Pick the cheapest pattern that meets the targets the business signed off on.

What goes wrong in OpenEdge disaster recovery plans?

• AI files are not archived or monitored. The plan assumes a point-in-time recovery that is impossible because a file is missing.
• The backup never gets restored. The first restore attempt happens during the real outage, and nobody remembers the structure file or the licence steps.
• The standby is never exercised. Failover works on paper, but the application servers, DNS or connection strings still point at the old database.
• Only the database is covered. The application tier, scheduled jobs, reports, file shares and interfaces to other systems are left out.
• RTO and RPO were never agreed. IT built to a target the business never set, so the plan is either overbuilt or too weak.

How do you test an OpenEdge disaster recovery plan?

A plan that has not been run is a hypothesis. Schedule these drills and record the times:

1. Restore drill. Restore the latest full backup and roll forward AI files into an isolated environment. Record how long it took, which feeds your real RTO. Verify with a simple set of business checks, such as an order count and a customer balance you can reconcile.
2. Point-in-time drill. Roll forward to a chosen time with endtime to prove you can recover to just before a mistake.
3. Failover drill. If you use replication, run a controlled transition to the target, run the business on it briefly, then fail back. Note every manual step that surprised you.
4. Dependency check. Confirm the app servers, integrations and users can reach the recovered database without changing code.

Write each result down, fix the gaps, and repeat on a schedule. Record who is responsible for each step, because a recovery run by one person who is on holiday is not a recovery.

What about everything around the database?

Recovering the database does not restore the business. A typical OpenEdge application feeds and is fed by other systems: a CRM, a web shop, a warehouse tool, EDI, reporting and finance. After a recovery, those connections need to be pointed at the right place and replayed or reconciled, otherwise orders placed during the outage never reach the ERP, or customer data drifts between systems.

That is the part of disaster recovery most plans skip. Design it deliberately: queue incoming data while the ERP is unavailable, use idempotent processing so replays do not create duplicates, and keep an audit trail you can reconcile afterwards. Our guides to connecting legacy on-premises ERPs with cloud CRMs without downtime and making retries safe with idempotency keys explain the patterns.

How does Insyrge help with OpenEdge disaster recovery?

To be clear about scope: Insyrge is not a replacement for your OpenEdge database administrator, and the database-level work above should be owned by someone certified on your version. Where we help is the layer around it. That includes integrations between an OpenEdge-based ERP and your CRM or other systems, queueing and replay so data survives an outage, and the architecture and runbooks that make the surrounding systems recover in the right order. If you need that, see our ERP and CRM integration service and solutions architecture service.

If you would like a second pair of eyes on your recovery plan, contact us or book a free discovery call.

Frequently asked questions about OpenEdge disaster recovery

Is after-imaging required for OpenEdge disaster recovery?

In practice, yes. Progress's documentation says after-imaging is the only way to recover a database to the present time after a media failure, and OpenEdge Replication requires it on the source database. Without it you can only restore to the time of your last backup.

What is the difference between OpenEdge backup and OpenEdge Replication?

A backup is a point-in-time copy you restore when needed, so recovery takes time. Replication keeps a running copy of the database on another machine, which can take over much faster. Replication also copies mistakes, so you still need backups and AI files.

Can OpenEdge Replication give me zero data loss?

Do not assume so. Current OpenEdge documentation describes replication as asynchronous, meaning the copy can lag behind the source. Measure the lag in your environment and set your RPO from it.

How often should I test my OpenEdge disaster recovery plan?

Run a restore drill on a regular schedule, and repeat it after any significant change such as a version upgrade, a storage change or a new server. Run a failover drill if you use replication. The point is to know your real recovery time before an outage.

Can I run OpenEdge disaster recovery in the cloud?

Yes, the same concepts apply. You can keep the recovery site in a cloud environment and use the pilot light or warm standby patterns described by cloud providers. Confirm licensing and supported platforms for your OpenEdge version with Progress before you design it.

How do I choose my RTO and RPO?

Ask the business what stops when the system is down and what it costs to re-enter lost transactions. Set targets per system, write them down, and design the cheapest option that meets them. Review them each year as the business changes.

Does disaster recovery cover my integrations too?

It should. The database is only one part of the chain. Plan how connected systems queue, replay and reconcile data during and after an outage, or you will recover the ERP and still lose orders.