Ask a small business owner whether their systems are backed up and the answer is almost always yes. Ask how long it would take to be running again if the main database failed at 10 a.m. on a busy Monday, and the room goes quiet.
That gap between having backups and knowing you can recover is where most small and medium businesses sit. It rarely matters, until the day it does. For an SMB, that day tends to arrive at the worst possible moment: month end, a product launch, or the week a large client goes live.
At SoftGEM we design, build and run AWS platforms for SMBs in Nigeria, the United Kingdom and the United States. Here is how we approach disaster recovery, and the mistakes we see most often.
Mistake 1: Nobody has decided what "recovered" means
Recovery starts with two numbers, and most SMBs have never written them down:
- Recovery Time Objective (RTO): how long the business can tolerate the system being down.
- Recovery Point Objective (RPO): how much recent data the business can afford to lose, measured in time.
Without them, "we have backups" can mean anything from five minutes of lost data to a week. And the cost of a recovery design depends almost entirely on these two numbers.
We tier every system during design. The tier sets the targets and the minimum recovery strategy, and we discuss it with the customer with the cost attached, before anything is built. A customer-facing platform holding health, financial or personal data is typically Tier 1, which for us means an RTO of 60 minutes and an RPO of 15 minutes. A reporting system that can wait a day doesn't need to be paid for as if it were Tier 1.
Mistake 2: Treating a backup as a recovery path
A backup is a copy of data. A recovery path is everything needed to turn that copy back into a working service, in a known time:
- where the data is restored to
- how the application reconnects
- who does each step, and in what order
- how you confirm the data is consistent before letting users back in
On AWS we build recovery in layers. For the database we use Amazon RDS Multi-AZ, which keeps a synchronous standby in a second Availability Zone and fails over automatically. Losing a database instance, or a whole Availability Zone, doesn't lose committed data or wait for a person to notice. Behind that sits AWS Backup, with point-in-time recovery, encrypted under the customer's own AWS KMS keys, for the failures a standby can't fix, such as data that has been deleted or corrupted. The application runs on Amazon ECS with AWS Fargate across both Availability Zones, so a failed task is simply replaced.
Every step of the recovery is written into the customer's operations runbook, and the monitoring alarms point to it. Nobody has to improvise under pressure.
Mistake 3: Never testing the recovery
This is the big one. A recovery plan that has never been run is a hypothesis.
Our standard is a full, timed recovery drill within 90 days of a system going live, then on a regular cadence by tier: semi-annually for Tier 1. Backup restores are verified monthly on top of that. Drills run against a separate, isolated restore environment, not against production, and the customer's technical lead attends. The drill report records the actual recovery time and recovery point against the targets, line by line, and any shortfall becomes a tracked action with a named owner.
What a real drill looks like
Choose Life Wellness runs a health risk assessment platform used by individuals and by employers managing workforce health. We modernized it onto AWS, and because it holds personal health information, it is a Tier 1 workload: 60-minute RTO, 15-minute RPO.
In the recovery drill we:
- Captured a healthy baseline, with the database primary in one Availability Zone.
- Forced the primary database instance to fail.
- Watched Multi-AZ failover promote the standby in the second Availability Zone.
- Re-established application connectivity against the promoted database.
- Ran a point-in-time restore from AWS Backup into an isolated environment.
- Confirmed data consistency and application function against the monitoring signals.
Result: recovery in 42 minutes against the 60-minute target, and a recovery point of 10 minutes against the 15-minute target. There were no deviations from the written procedure. The one follow-up action was to mark the measured recovery time on the monitoring dashboard as the reference for future drills.
That number, 42 minutes, is worth more to the business than any statement that "backups are in place". It is what Choose Life can tell an employer client who asks during procurement.
You can read more about the Choose Life platform in our case study.
Mistake 4: Ignoring where your data lives
There is no AWS Region in Nigeria. For Nigerian SMBs, that means the question of where data sits has to be designed and documented rather than assumed. We record the data-residency position for every customer, restrict deployments to the approved Region, and keep the infrastructure templates portable so the workload can move to an eligible Region if requirements change.
Residency can also point the other way. For Trevidia, a UK invoice management business handling UK personal and financial data, we built on AWS in London (eu-west-2) so the data stays in the United Kingdom, and accepted the slightly higher London pricing as the cost of that decision.
Most SMB workloads run in a single Region across two Availability Zones. That protects against the failures that actually happen day to day. Recovering from the loss of an entire Region is done by restore, which is a trade-off we agree with the customer openly rather than leaving unsaid.
Mistake 5: Assuming resilience has to be expensive
Resilience for an SMB is not about buying enterprise architecture. It is about choosing managed services that handle failover for you, automating backups so they happen without anyone remembering, and spending an afternoon proving that recovery works.
The Choose Life platform, with Multi-AZ database failover, automated backups, monitoring and a tested recovery, runs at a steady-state AWS cost of $850.04 per month, priced before the build and agreed with the customer.
A short checklist for your business
If you want to know where you stand, answer these five questions:
- Have we written down an RTO and RPO for each important system?
- Does our database fail over automatically if its server or data centre fails?
- Are backups automated, encrypted, and kept long enough to cover a problem we notice late?
- Is there a written, step-by-step recovery procedure that someone other than the person who built the system could follow?
- When did we last time a real recovery, and did it meet the targets?
If the answer to the last question is "never", that is the place to start.
SoftGEM Global Technologies is an AWS Advanced Tier Partner based in Lagos, Nigeria. We help small and medium businesses migrate to AWS, modernize their platforms, and run them with tested recovery and clear costs. See our AWS cloud consulting services or contact us at support@softgem.org to talk about your recovery plan.