The Uptime Shorthand
Software teams often describe resilience with one number: uptime. It is useful, measurable and easy to compare. It is also incomplete.
A service can report excellent uptime while its data is difficult to restore, trapped in a proprietary format, or dependent on one identity provider. An interface can also experience an outage while the organisation remains able to access its records and continue essential work.
Uptime measures whether a service answered. Business continuity asks: if this system fails today, what truth remains available tomorrow?
Continuity of Truth
Enterprise software holds more than rows. It holds relationships between customers and contracts, approvals and payments, cases and evidence.
Resilience depends on three properties together:
- Availability: authorised people can obtain the data.
- Integrity: it remains complete and trustworthy.
- Interpretability: the organisation can use it without the failed system.
A backup that cannot be opened without the original vendor may protect bits without protecting the business.
Copies That Are Actually Usable
The phrase “we have backups” often ends the conversation too early. A resilient copy should be independently retrievable, regularly tested and documented well enough to support recovery.
If production data and backups share the same provider, credentials and administrative boundary, one incident may reach all of them. An untested backup is an assumption. Recovery performed only by one unavailable specialist is another single point of failure.
What to Measure Instead
Uptime should sit beside recovery time, acceptable data loss, export completeness, restoration test results, identity independence and the time required to produce a usable record outside the primary platform.
These measures turn resilience from a vendor promise into an organisational capability.
Turn Recovery Into a Routine Review
Recovery exercises are often postponed because they sound like large disaster simulations. They can begin much smaller. Once a quarter, choose a critical record type, restore a recent copy into an isolated environment and verify it against a known production sample.
Record how long retrieval took, which credentials were required, which fields or files were missing and whether a person unfamiliar with the system could follow the instructions. Assign every gap an owner and a date. Over time, these observations create a more honest resilience measure than a backup-success percentage.
The review should include business owners as well as engineers. They are the people who can say whether restored data is sufficiently complete to invoice a customer, answer a regulator or continue a case.
The Meaning Must Survive the Restore
A database restore can be technically perfect and operationally useless. A table may contain a status code of 4, a reference to an absent file and a user identifier that no longer resolves. The bytes survived, but the meaning did not.
Resilient copies therefore need schema definitions, relationship maps and enough identity context to interpret important events. Attachments should retain their connection to the records they support. Time zones, currencies and units should be explicit. Where business rules derive a visible total or status, the recovery documentation should explain how that value was produced.
This is especially important for evidence. A company answering a complaint needs more than the latest customer record; it may need the sequence of approvals, messages and changes that led to it. Preserving only current state protects operations incompletely and accountability hardly at all.
Resilience Needs a Named Owner
Backups often sit between infrastructure, application and business teams, which makes gaps easy to inherit and hard to own. Assign one person responsibility for the recovery capability—not for performing every task, but for ensuring that tests happen, findings are resolved and documentation remains usable.
The owner should report a small set of honest measures: last successful restore, verified record coverage, unresolved dependencies and the time required to produce a usable business view. Those measures create a conversation about continuity rather than storage volume.
Conclusion
Infrastructure redundancy helps services remain online. Data resilience helps organisations remain themselves. It protects not just files, but the meaning and relationships that allow work to continue.
Uptime tells us whether the door is open. Resilience tells us whether the organisation can still reach, understand and use what is behind it—even after the familiar interface has gone.
A concise way to explain why uptime and resilience are related but not interchangeable. I will borrow this framing for our next risk workshop.
The emphasis on testing the recovered data, not only the backup job, is exactly right. A green dashboard can create a dangerous amount of confidence.
This captures a gap in many continuity plans: the application may return quickly while the trustworthy business state does not. Recovery objectives should measure both.