ለኢትዮጵያ የንግድ ሶፍትዌር ከአደጋ ማገገም

DR is the test you hope never to run

Every software vendor's marketing claims robust disaster recovery. The reality varies widely. The test is when something actually goes wrong — a server fails, a data centre has an outage, an attacker encrypts the database, an admin runs a destructive command in production. Vendors who have practiced their DR recover. Vendors who haven't, don't.

This article walks through what real DR looks like for Ethiopian business software customers, what to demand from vendors, and how to verify the claims before you need them.

What DR actually means

Three distinct concepts often bundled together:

1. Backup — copies of your data preserved so you can recover if the primary copy is lost.
2. Disaster recovery (DR) — the process of getting back to operational state after a major disruption.
3. Business continuity (BC) — keeping the business operating during a disruption, possibly with reduced capability.

Backup is necessary but not sufficient. DR is the procedure for using backups (plus other infrastructure) to recover. BC is the broader question of how the business keeps running while DR happens.

The two metrics that matter

Recovery Time Objective (RTO): how long after a disaster before the system is operational again.

Recovery Point Objective (RPO): how much data loss is acceptable, measured in time.

For an Ethiopian ERP:

• RTO of 4 hours means after a disaster you're back online within 4 hours.
• RPO of 1 hour means after a disaster you've lost at most the last hour of data.

These commit in contract or they don't really exist. Ask any vendor what their RTO and RPO commitments are.

Backup patterns that work

Effective backup for Ethiopian business software:

• Daily encrypted backups at minimum.
• Multiple retention tiers — daily for 30 days, weekly for 90 days, monthly for 7 years.
• Off-site storage so a fire or disaster doesn't destroy both primary and backup.
• Encryption with managed keys so backups can't be read by anyone with access to the backup storage.
• Restoration testing quarterly to verify backups are usable, not just present.
• Per-customer isolation in cloud or multi-tenant environments — your backups can't be accessed by another customer's compromised credentials.

Patterns that signal weak backup:

• "We back up regularly" without specifics.
• No documented restore procedure.
• Backups stored on the same infrastructure as production.
• No restoration testing.
• Single retention tier (e.g., 7 days only).

DR scenarios you need answers for

The questions to ask any vendor:

• What happens if your primary data centre has a 24-hour outage?
• What happens if our database is corrupted by a bad data migration?
• What happens if an administrator accidentally deletes production data?
• What happens if an attacker encrypts our data (ransomware)?
• What happens if our internet connectivity fails for a week?

Each scenario has a different DR pattern. Vendors who can't articulate the answer for each are flags.

DR for the three NYLOS deployment models

How DR works in each NYLOS deployment model:

NYLOS Cloud: Multi-region replication for production data. Daily encrypted backups in geographically separate region. Hot standby for fast recovery. RTO 4 hours, RPO 1 hour for typical incidents.

Private cloud (customer's AWS/Azure/GCP): Cloud-native backup services with point-in-time recovery (PITR). Multi-region or cross-account backup options. Customer chooses RTO/RPO based on cloud-provider services and cost trade-offs.

On-premise: Documented backup procedure operated by customer's IT team. Daily encrypted backups to off-site storage. NYLOS engineers help design the DR procedure and verify it during implementation. Customer responsible for ongoing DR testing.

Business continuity for Ethiopian operating reality

Ethiopian operating reality adds connectivity considerations to BC:

• Multi-day internet outages — rare but real. On-premise deployments with offline-tolerant clients keep operations running during outages.
• Power outages — UPS and generator coverage for on-premise; cloud deployments depend on the cloud provider's data centre resilience.
• Currency disruption — Birr depreciation cycles affect software-cost planning over multi-year horizons.

The BC plan should account for these alongside the standard tech-disaster scenarios.

What to verify before signing

A practical verification checklist:

1. Get RTO and RPO commitments in writing.
2. Ask for documentation of the DR procedure.
3. Ask when DR was last tested and what the test showed.
4. Inspect the backup encryption and key-management posture.
5. Verify off-site or cross-region backup placement.
6. Confirm restoration testing cadence.
7. Get the incident-communication procedure in writing.

Vendors who can't satisfy these are not ready for enterprise customers.

What to verify annually

Even with a solid vendor, ongoing verification matters:

1. Annual DR test — request the vendor's annual test result.
2. Backup audit — verify backups are happening as committed.
3. Restore test — for on-premise, perform a real restore at least annually.
4. Incident review — review the year's incidents, post-mortems, and remediation actions.
5. Contract review — confirm DR commitments remain in force; update if your business needs have changed.

Common pitfalls

Five patterns to avoid:

1. Trusting marketing claims without verification.
2. Treating backups as DR. Backups are necessary but DR is the procedure for using them.
3. No restoration testing. Backups that have never been restored may not work.
4. DR plan in someone's head. If it's not documented, it doesn't survive turnover.
5. DR for the platform but not the operations. The platform may be back; the operating team may be unreachable.

How NYLOS handles DR

NYLOS commits RTO and RPO in contracts. DR procedures are documented and tested quarterly. Per-customer monitoring detects incidents before customers do. Incident communication and post-mortem cycle preserve learning. For on-premise customers, NYLOS engineers help design the DR procedure during implementation and provide ongoing review.

Read more

• [NYLOS Cloud ERP](/solutions/cloud-erp)
• [DevOps Maturity for ERP Vendors in Ethiopia](/blog/devops-erp-vendor-ethiopia)
• [Software Vendor Management for Ethiopian Buyers](/blog/software-vendor-management-ethiopia)