A database restore is only one checkpoint. The real target is a working user flow, verified data, and a measured return to service.
Press enter or click to view image in full size
The database is online again. The lesson still will not open. A user can sign in, but their scheduled consultation is missing. A paid account has returned without the access rights attached to it.
This is why a successful backup job tells us less than it appears to. It confirms that a system wrote a copy somewhere. It does not prove that the copy is readable, that every required dependency can be restored, or that the product will return within the time the business expects.
I am Anton Fokin, CEO of Qtim. When we discuss recovery, we start with the user action that must work after an incident. Then we work backwards through the application, data, infrastructure, and access controls required to restore it.
RPO and RTO begin with user actions
Two metrics turn a backup policy into a business decision.
Recovery Point Objective, or RPO, defines how much recent data the company can afford to lose. Recovery Time Objective, or RTO, defines how long a critical function may remain unavailable. AWS Well-Architected recommends validating both through recovery testing: check the age of the restored data for RPO and measure the full route back to an operational workload for RTO.
Press enter or click to view image in full size
The same target should not cover every dataset. A catalog may be rebuilt from another source. A search index can often be generated again. Course progress, payment records, access rights, and scheduled sessions need stricter treatment because reconstructing them may be slow, incomplete, or impossible.
We define recovery targets by process:
Name the critical user action.
Decide how much recent data that action can lose.
Set the maximum time for the action to work again.
Choose a backup and recovery design that can meet both limits.
The storage technology comes after those decisions.
The database is back. The product is not.
A live database does not make a product usable. The service may also depend on the application version, infrastructure configuration, object storage, queues, a search index, encryption keys, DNS, background jobs, and external integrations.
Some components can be rebuilt. Others need their own recovery point. The order matters too. We usually restore infrastructure and key access first, then data stores, the application, background processing, and integrations. The last step is an end-to-end path through the product.
The slowest required dependency sets the real recovery time.
Two Qtim cases show why the target is a workflow
In Studycats, we brought six educational courses into one platform with user accounts, homework, practice tests, and progress statistics. For a product with this contour, a recovery target has to answer concrete questions. How much submitted work, test history, purchase data, or course-access data could the business accept losing? When does the learner regain the ability to sign in, open the right course, submit work, and see the correct result?
The published case describes the product we built, not the client’s internal backup policy. We use the workflow to define what a recovery test must prove.
Ponimayu is a corporate employee-support platform with online consultations from different specialists. Restoring its database would still leave the central question unanswered. Can a user enter through corporate access, see the scheduled session, and join the consultation with the right permissions and data?
These cases have different interfaces, but the recovery logic is the same. A product returns when its critical chain works from the user’s first action to the business record created or retrieved at the end.
A seven-step recovery drill
We treat a backup as usable only after a restore in an isolated environment. AWS calls out a common failure mode: teams restore a resource but never read or validate the data inside it.
Our minimum drill follows seven steps:
Choose one service and record its target RPO and RTO.
Select a recovery point through the same procedure used in production.
Start the clock and build an isolated environment.
Check integrity through checksums, record counts, and business invariants.
Connect the application and complete one critical workflow.
Record the actual data loss and the full time to readiness.
Update the runbook, automation, and ownership after the test.
A business invariant connects records that must remain consistent. In an education platform, payment, course access, submitted work, and test results may need to agree. In a consultation service, corporate access must lead to the correct scheduled session. A successful SELECT query cannot prove either condition.
The runbook should also be tested by someone who did not write it. During an incident, the author may be unavailable. Commands, expected results, and stop conditions need to make sense without a live explanation.
A copy in the same failure domain shares the same risk
PrThe test record expires as the system changes
After each drill, we keep a short record: the service, owner, recovery point, source copy, target and actual RPO/RTO, integrity checks, end-to-end result, constraints found, runbook changes, and next test date.
The date matters because recovery results age quickly. Database growth, a new application version, another region, key rotation, storage migration, or a redesigned payment or authentication flow can invalidate the previous measurement. AWS Prescriptive Guidance recommends aligning disaster-recovery testing with business requirements and repeating it after material application or infrastructure changes.
A six-month-old RTO measurement may describe an architecture that no longer exists.oduction data and backups should not depend on one administrator account, one deletion policy, one writable network location, or one region. CISA recommends keeping critical backups offline and encrypted, then testing their availability and integrity regularly. The agency also warns that ransomware operators look for accessible backups and try to delete or encrypt them alongside production data.
In cloud infrastructure, isolation can include a separate account, immutable storage, different permissions for creating and deleting copies, multi-factor approval for sensitive operations, and independent alerts. The right combination depends on the threat model and the cost of downtime.
Replication solves another problem. It can support a fast failover after a node failure. It can also reproduce an accidental deletion or corruption. Returning to a point before the event still requires an independent recovery copy with the right retention period.
The test record expires as the system changes
After each drill, we keep a short record: the service, owner, recovery point, source copy, target and actual RPO/RTO, integrity checks, end-to-end result, constraints found, runbook changes, and next test date.
The date matters because recovery results age quickly. Database growth, a new application version, another region, key rotation, storage migration, or a redesigned payment or authentication flow can invalidate the previous measurement. AWS Prescriptive Guidance recommends aligning disaster-recovery testing with business requirements and repeating it after material application or infrastructure changes.
A six-month-old RTO measurement may describe an architecture that no longer exists.
Five questions before the next release
Which user actions can the business afford to lose, and for how long?
How quickly must each critical function work again?
Where are the recovery copies, and who can change or delete them?
When did the team last rebuild the service from a saved point?
What actual RPO and RTO did that test produce?
Our decision rule is simple: a backup becomes credible after the team restores it, validates the data, completes an essential workflow, and records the actual RPO and RTO.
At Qtim, backup and recovery sit inside the wider SaaS infrastructure scope alongside observability, service-level commitments, incident response, and operational runbooks. See how we approach SaaS engineering and infrastructure.
Top comments (0)