Articles & perspectives
Having Backups Is Not the Same as Being Resilient
By Leetroy Fraser, Founder, Bitralynx Solutions
Originally published August 20, 2026
A successful backup report answers an important question: did the backup job complete? It does not tell you whether staff can return to work after a disruption.
That second question follows a longer path. Staff need a working device, a valid sign in, a usable network, an available application, and the right data. A break anywhere along that path can leave the service unavailable even when the backup is intact.
For nonprofit and human services leaders, the useful unit of recovery is the service staff need to use.
Recover the service, not just the file
A recovery check is complete only when the agreed staff task can be performed.
Identity
The right person can sign in.
Connection
The device can reach the service.
Application
The application and dependencies work.
Data
The required information can be restored.
Staff task
Someone completes the agreed workflow.
Follow the whole path
Choose one important activity. Ask the team to explain what must work for a staff member to complete it.
The dependencies may include an identity provider, internet service, an application vendor, a local device, and a particular permission. Some will be controlled by your agency. Others will sit with providers.
Write down who is responsible for each part and how they are reached during a disruption. If a recovery plan simply says to contact the vendor, it still needs the vendor contact, contract coverage, escalation path, and a way to check the result.
This mapping often reveals why a file restore is only one step. It also makes the limits visible before leadership relies on a recovery promise.
Separate time from data loss
Two targets help frame the discussion:
- Recovery time objective (RTO): the target time for restoring the required service after an interruption.
- Recovery point objective (RPO): the target limit on how much recent data could be lost, expressed as time.
An hourly recovery point does not promise an hour long recovery. It concerns the available data, while restoring a usable service has other steps and dependencies.
Leadership and operations staff need to explain the impact of each target. Losing an hour of changes and losing access for a day create different problems. The technical team can then assess the setup, cost, and testing needed to support the chosen targets.
A target is a planning requirement. Tests provide evidence about whether the current arrangement can meet it.
Ask what the cloud arrangement actually covers
An online application can still have recovery limits. Ask which information is covered, how far back recovery can go, who can initiate it, and what access is needed if the normal administrator account is unavailable.
Also distinguish the provider's service availability from your ability to restore the specific information or configuration you need. The contract and configured service matter more than the word cloud.
Independent backup may be part of the answer. It still needs a defined scope, retention, protection, and a tested recovery process. Adding another product without those details leaves the same questions open.
Federal ransomware guidance recommends maintaining backups, protecting them from the incident, and periodically testing restoration. It also places backup within a wider contingency plan rather than treating it as the whole plan. HHS ransomware fact sheet.
Test a task staff can recognize
A useful recovery test identifies the service, conditions, authorized participants, and expected result before it begins. It protects live operations and uses appropriate test data.
After the technical restore, ask the responsible staff to validate an agreed task. Could the intended person sign in? Could they reach the restored information? Did the result match the stated recovery point? What was missing?
Record the actual steps and timing, not just a pass label. If the test depends on a person or credential that would be unavailable in the real scenario, that is a finding worth addressing.
Keep the result useful
The runbook should explain the recovery order, contacts, access requirements, validation steps, and known limits. Review it when systems or responsibilities change, and repeat the agreed tests.
Our Backup & Disaster Recovery Planning Guide helps leadership frame these questions. Bitralynx Solutions supports the technology and recovery work; your agency directs its service operations and remains responsible for its official records.