At 6:40 a.m., an operations team discovers that the application's primary database is corrupted.
The immediate reaction is reassuring: backups run every night.
The latest backup job is marked successful, so the team starts the restore.
Then the real problems appear.
The backup contains the database, but not several files stored separately in object storage. The restoration instructions refer to infrastructure that was replaced nine months ago. Nobody knows which configuration values need to be recreated, and the person who last tested the process has left the company. When the database is finally restored, it becomes clear that the nightly schedule means almost a full business day of transactions is missing.
The organisation had backups.
What it did not have was a recovery capability.
That distinction is fundamental to application maintenance.
A backup is a recoverable copy of data or system state. Disaster recovery is the broader capability to restore an application and its critical business functions after a serious disruption.
Microsoft makes a similar distinction in its reliability guidance: backups create point-in-time copies that can be restored after data loss or corruption, while broader disaster-recovery mechanisms may involve replication, failover and restoration of the workload itself. It also stresses that backups and restore procedures should be tested regularly rather than assumed to work because backup jobs succeeded. Microsoft: Redundancy, Replication and Backup
For Levelworks, backup and disaster recovery primarily strengthen Resilient App Health. They are the mechanisms that help an application return to a usable state when prevention, redundancy or ordinary recovery mechanisms are no longer enough.
The terms are often used together, but treating them as interchangeable causes weak maintenance plans.
A backup answers:
What can we restore?
A disaster-recovery plan answers:
How do we restore enough of the application to resume the business process, how long should that take, and who does what?
Suppose a database is backed up every six hours.
That may protect the data reasonably well, but it tells you nothing about whether the application can be restored quickly.
Recovery could also require:
A perfect database backup does not recreate those automatically.
NIST defines contingency planning more broadly as the coordinated use of plans, procedures and technical measures to recover systems, operations and data after disruption. Its contingency-planning guidance includes recovery strategy, plan development, testing and ongoing plan maintenance—not backup creation alone. NIST: Contingency Planning
An app maintenance plan therefore needs both data protection and recovery planning.
Teams often begin with a technical question:
Should we back up once a day or once an hour?
The business questions should come first.
Two concepts are particularly useful.
RTO is the maximum acceptable time between a disruption and restoration of the service.
If the RTO is four hours, the recovery strategy should be capable of getting the required service back within approximately that window.
RPO describes how much recent data the business can accept losing.
If the RPO is fifteen minutes, a nightly backup is obviously insufficient.
AWS defines RTO as the maximum acceptable delay before service restoration and RPO as the maximum acceptable period between the latest recoverable data point and the disruption. It also emphasizes that these objectives should come from business requirements and then influence the technical recovery strategy. AWS Well-Architected: Define Recovery Objectives
This distinction prevents overengineering as well as underengineering.
Not every application requires near-zero data loss and recovery within minutes.
A low-risk internal reporting tool may tolerate:
A transaction-processing application might require dramatically tighter objectives.
Those requirements should determine whether the application needs ordinary backups, frequent snapshots, replication, standby capacity or another recovery model.
Databases receive most of the attention because they contain obvious business state.
Modern applications frequently depend on other state that is equally important to recovery.
A backup review should ask whether recovery covers:
Imagine restoring a customer database successfully while discovering that every uploaded contract was stored in an unprotected bucket.
Technically, the database recovery succeeded.
From the user's perspective, the application did not recover.
The correct backup scope comes from tracing what the business workflow needs, rather than simply backing up whichever datastore is most visible.
Once the RPO is clear, backup or replication frequency can be designed around it.
If an application can tolerate losing up to twelve hours of recent changes, a backup every few hours may be sufficient.
If losing thirty minutes of transactions would create unacceptable business consequences, the recovery architecture must preserve more recent state.
This sounds obvious, yet organisations sometimes choose backup frequency based on storage cost or platform defaults without connecting the decision to actual business loss.
Google Cloud's disaster-recovery guidance similarly links RPO to the maximum acceptable age of recovered data and notes that this requirement helps determine backup frequency. Google Cloud: What Is Disaster Recovery?
The important maintenance question is therefore not:
Did the backup run last night?
It is:
If the application failed right now, how much work would we lose—and is that acceptable?
A backup provides little protection if the same event can destroy both the production data and its backup.
This is especially important for cyber incidents.
CISA recommends maintaining regularly updated backups and specifically advises organisations to keep backup copies isolated, including offline where appropriate, because ransomware can attempt to locate and destroy accessible backups. It also recommends testing the restoration process rather than relying on the presence of backup files alone. CISA: Ransomware Guide
Isolation can mean different things depending on architecture and risk:
The goal is to avoid a single administrative mistake, compromised account or destructive event gaining the ability to remove both production and recovery data.
Backup architecture should always ask:
What failure are we protecting against, and can that same failure reach the backup?
A green backup status usually proves that the backup system created something.
It does not necessarily prove that the resulting application can be restored.
Common problems include:
Microsoft's reliability guidance is explicit that backup and restore processes need regular testing to verify that the data is complete, restoration works and the recovery time remains consistent with the required RTO.
That leads to one of the most important rules in this article:
Do not test whether you can create a backup. Test whether you can recover the application from it.
A restore exercise provides much stronger evidence than a successful backup notification.
[Internal Link: “What Makes an Application Resilient?”]
Restore testing should not begin during an actual disaster.
Where practical, periodically restore representative backups into an isolated environment.
Verify:
The result may be surprising.
A team may discover that its documented RTO is two hours while the database alone takes three hours to restore.
That is useful information when discovered during an exercise.
It is disastrous information when discovered during the real outage.
Restore testing also validates the people and process around recovery. If only one engineer knows the correct sequence, the technical system may be recoverable while the organisation remains fragile.
Restoring from backup can be slow.
For some failures, redundancy or replication should recover the service before backup restoration becomes necessary.
Microsoft notes that backups typically support recovery objectives measured in hours, while continuous replication can be more appropriate where business-critical systems need faster failover and less potential data loss.
That creates a useful recovery hierarchy.
A failed application instance may be replaced automatically.
A failed availability zone may trigger failover.
A corrupted database might require point-in-time recovery.
A destructive ransomware incident may require restoration from isolated backup copies.
The application maintenance plan should identify which mechanism applies to which class of failure.
Otherwise teams may reach immediately for backup restoration even when a safer or faster recovery path exists.
Complex applications rarely recover correctly if every component is restored simultaneously in arbitrary order.
Consider an application with:
The recovery sequence should reflect dependencies and business criticality.
The team might restore:
data → identity → critical APIs → transactional processing → secondary workflows
before bringing reporting and non-essential background processing online.
This prevents recovered secondary systems from creating load or modifying state before the critical foundations are stable.
A disaster-recovery plan should therefore identify not only what gets restored but in what order.
Infrastructure teams naturally think in components.
The business experiences workflows.
Customers usually do not care whether worker-service-03 is healthy. They care whether they can sign in, submit an order or retrieve a document.
Recovery planning should therefore map infrastructure back to critical workflows.
A practical table might look like this:
Workflow
RTO
RPO
Critical dependencies
Recovery priority
Customer login
1 hour
Minimal data concern
Identity, database
Critical
Checkout
1 hour
5 minutes
Database, payment, inventory
Critical
Email notifications
8 hours
Queue preserved
Queue, email provider
Secondary
Analytics reports
24 hours
24 hours
Warehouse, reporting service
Lower
The values will differ for every application.
The important step is making priorities explicit.
Otherwise everything gets labeled "critical," which makes the label useless.
Applications increasingly run on infrastructure that can be recreated from code.
That can significantly improve disaster recovery—but only if the infrastructure definitions themselves are protected and tested.
Recovery may depend on:
This is where Version Controlled and Well Documented App Health can reinforce Resilient.
The application is easier to recover when teams can reconstruct its operating environment from known, reviewable definitions rather than manually remembering how production was assembled.
Documentation should also identify any part that still cannot be recreated automatically.
Those manual dependencies are worth knowing before a disaster.
A subtle disaster-recovery problem appears when the credentials required for recovery are stored inside the environment being recovered.
Suppose restoring production requires:
If those credentials are lost, encrypted, or inaccessible during the same incident, the backup may exist without a viable path to use it.
Recovery planning should therefore establish how authorised responders obtain necessary emergency access during a severe disruption.
This should be protected carefully, because creating powerful emergency credentials carelessly introduces another security problem.
The goal is controlled availability, not unrestricted backdoor access.
Traditional disaster recovery often assumes infrastructure failed accidentally.
Cyber incidents can be different because the environment itself may no longer be trusted.
If ransomware or an attacker compromised production systems, immediately restoring into the same environment can recreate the conditions that allowed the compromise.
Recovery may need to answer:
This is another reason isolated backups matter.
CISA's ransomware guidance specifically recommends offline, encrypted backups and regular testing as part of preparedness for destructive attacks.
A cybersecurity disaster can therefore require clean recovery, not simply fast recovery.
Technical recovery plans often document commands while overlooking decision-making.
Someone needs authority to decide:
Define recovery roles before the incident.
The maintenance team should know who is responsible for:
This does not require a complicated command structure for every application.
It does require avoiding the situation where five people know how to restore something but nobody knows who is authorised to make the decision.
[Internal Link: “Application Incident Response: What Should Happen When Your App Goes Down?”]
After a major restoration, validate the business state.
Ask:
Suppose the database restores successfully to 10:00 a.m. after a failure at 10:20.
The infrastructure may be operational, but twenty minutes of business activity may need reconciliation.
A mature recovery process includes that work instead of declaring victory when monitoring turns green.
[Internal Link: “How to Design an App That Recovers Gracefully From Failure”]
Backup scope is not permanent.
An application might launch with one database and later add:
If the backup design remains unchanged, recovery coverage gradually becomes incomplete.
Backup and disaster-recovery review should therefore be triggered by meaningful architectural changes.
Ask after significant change:
Did we add new state?
Did we move existing state?
Did recovery dependencies change?
Does the recovery sequence still work?
Can we still meet the stated RTO and RPO?
This is why disaster recovery belongs inside app maintenance rather than being written once as a launch document.
A hundred-page disaster-recovery document can contain everything and still be operationally useless.
Responders need clear information.
A practical recovery runbook should identify:
Supporting architecture documentation can exist elsewhere.
The runbook itself should help somebody make progress during a stressful incident.
A useful test is to give the plan to a competent engineer who did not write it and see whether they can follow the recovery exercise without relying on undocumented tribal knowledge.
An application maintenance plan should be able to answer the following:
Area
Maintenance question
RTO
How long can this workflow be unavailable?
RPO
How much recent data can we accept losing?
Backup scope
Are all important data and state protected?
Frequency
Does backup/replication frequency meet the RPO?
Isolation
Can the same incident destroy production and backup?
Retention
Are enough recovery points retained?
Restore testing
Have backups actually been restored recently?
Recovery sequence
In what order should components return?
Infrastructure
Can the application environment be reconstructed?
Access
Can authorised responders obtain recovery credentials?
Cyber recovery
Can the application be restored into a trusted environment?
Ownership
Who can activate and coordinate the plan?
Validation
How do we know business functionality is truly restored?
Maintenance
Is the plan updated after material architecture changes?
If several answers are uncertain, the organisation may have backups but not yet have dependable disaster recovery.
Backups are comforting because they are easy to count.
Seven daily backups. Four weekly backups. Twelve monthly snapshots.
Those numbers say very little about whether the application can survive a serious disruption.
The meaningful questions are harder:
Is everything important protected?
Can the backup survive the same event that damaged production?
Can we restore within the time the business expects?
How much data would we lose?
Have we proved the process works?
For Levelworks, those questions are part of maintaining Resilient App Health. Tested matters because untested recovery remains an assumption. Well Documented matters because restoration cannot depend entirely on individual memory, while Version Controlled and Seamlessly Updatable can make reconstruction and recovery significantly more predictable.
An application maintenance plan does not need the most expensive disaster-recovery architecture available.
It needs recovery capability that matches the consequences of failure.
The standard is not whether a backup job reports success.
It is whether, when the application and its data are genuinely lost or damaged, the team can bring the service back to a known, correct and usable state within the limits the business has agreed it can tolerate.
