Planning backups and recovery for a web application is not the same as switching on an automated backup feature and assuming the job is done. The planning process is about deciding what your business cannot afford to lose, how quickly it needs to resume operating, and what steps someone would actually follow to restore service. A backup that has never been tested is an assumption, not a safeguard.
The distinction between backup and recovery matters. Backup is the act of copying data. Recovery is the process of restoring that data and returning the application to a working state. A plan that only addresses the first half leaves the most difficult part unexamined.
Two concepts shape every backup decision. The Recovery Point Objective (RPO) defines the maximum age of data you are prepared to lose. If your RPO is one hour, your backup schedule must capture changes at least that frequently. The Recovery Time Objective (RTO) defines how long you can tolerate the application being unavailable before it is restored. These are business decisions, not technical ones, and they should be set by the people who understand the operational impact of downtime.
For a CRM system, an RPO of 24 hours might mean losing a day of sales notes and pipeline updates. For a SaaS platform processing real-time transactions, even a few minutes of data loss could breach contractual obligations. The planning process starts by establishing these targets for each component of the system, not by choosing a backup tool.
| Recovery decision | Business effect | Evidence to test |
|---|---|---|
| What actually needs backing up | Web applications consist of several distinct layers, and each has different backup requirements. | A database holds structured business data: customer records, orders, configurations. |
| Defining the scope of the plan | Begin by listing every data store and configuration source the application depends on. | For each one, document what it holds, how frequently it changes, and what the consequence would be if it were lost entirely. |
| Where backups are stored | Storing backups in the same environment as the live application protects against hardware failure but not against the environment itself becoming unavailable. | If your application runs on a single cloud provider in a single region, a regional outage could take out both the live system and its backups simultaneously. |
| Encryption and access control | Backups contain the same sensitive data as the live system, and in some cases they retain historical records that have since been deleted from the application. | They must be encrypted at rest, and access to backup storage should be restricted to a small number of named individuals. |
What actually needs backing up
Web applications consist of several distinct layers, and each has different backup requirements. A database holds structured business data: customer records, orders, configurations. File storage holds uploaded documents, images and generated exports. Infrastructure configuration defines how servers, networks and access controls are arranged. Separately, there are secrets and credentials: API keys, database passwords, SSL certificates and integration tokens that are not stored in the database but are essential for the system to function.
A common oversight is backing up the database while neglecting the other layers. Restoring a database onto a freshly provisioned server without the correct environment configuration, without the right file permissions and without valid certificates will not produce a working application. The plan must account for every component the system needs to run.
Defining the scope of the plan
Begin by listing every data store and configuration source the application depends on. For each one, document what it holds, how frequently it changes, and what the consequence would be if it were lost entirely. This inventory drives every subsequent decision.
For a customer portal, the list might include a relational database containing user accounts and support tickets, an object-storage bucket holding uploaded documents, an email service holding message history, and a series of environment variables controlling integrations with an internal CRM. Each of these has a different backup mechanism, a different RPO and a different recovery procedure.
Where backups are stored
Storing backups in the same environment as the live application protects against hardware failure but not against the environment itself becoming unavailable. If your application runs on a single cloud provider in a single region, a regional outage could take out both the live system and its backups simultaneously.
The practical question is how much geographic and provider separation is justified for your specific risk profile. A customer-facing SaaS product with contractual uptime commitments may need backups in a different region or even a different provider. An internal admin panel used by a small team might accept the risk of same-region storage if the cost of cross-region replication is disproportionate to the impact of a prolonged outage.
Encryption and access control
Backups contain the same sensitive data as the live system, and in some cases they retain historical records that have since been deleted from the application. They must be encrypted at rest, and access to backup storage should be restricted to a small number of named individuals. The principle is straightforward: if someone can download a backup, they can extract every piece of data the application has ever held.
Recovery credentials also need careful handling. The account used to initiate a restore must exist independently of the live system. If the only account with restore permissions is tied to an identity provider that is itself unavailable, recovery becomes impossible until that provider is restored.
Third-Party data you do not control
Many web applications rely on external services that hold data you do not directly back up. A payment processor stores transaction records. An email delivery service stores message logs. An analytics platform stores event data. Your backup plan should identify which of these external data sources are operationally critical and whether you need a local copy or a contractual guarantee of data availability from the provider.
Not testing recovery
The single most common mistake is treating backup creation as proof of recoverability. A backup can complete successfully every day for months and still fail to restore correctly because of schema changes, missing dependencies or corrupted incremental chains. The only way to know whether recovery works is to perform it, in an isolated environment, and verify that the application functions as expected afterwards.
Testing does not need to happen daily, but it should happen on a regular schedule and it should be documented. A recovery test that reveals a problem is far more valuable than a backup that has never been challenged.
Ignoring backup retention
Backups consume storage, and storage costs money. Without a retention policy, organisations either keep everything indefinitely, driving up costs, or delete old backups too aggressively, losing the ability to recover from problems that are not detected immediately.
A practical retention policy considers how long it might take to discover a data problem. If a corruption in the database goes unnoticed for two weeks, you need backups going back at least that far. The policy should define how many daily, weekly and monthly backups are retained and when each tier is purged.
Forgetting about application state
Restoring data is not the same as restoring an application. Background jobs may have been in progress. User sessions will be invalidated. Caches will be empty. Integration webhooks may need to be re-registered. A recovery plan that stops at "restore the database" leaves the team to figure out the remaining steps under pressure.
The plan should include a post-restore checklist: verify that scheduled tasks are running, confirm that integrations are receiving data, check that file permissions are correct and ensure that monitoring and alerting are operational again.
Key questions to put to a supplier
- What exactly is being backed up: databases, files, configuration, secrets?
- Where are backups stored, and is that location separate from the live environment?
- Are backups encrypted at rest, and who holds the decryption keys?
- How frequently are recovery tests performed, and are the results documented?
- What is the documented procedure for restoring the full application, not just the data?
- What is the retention policy, and can it be adjusted if our RPO requirements change?
- If the supplier ceases trading, how do we gain access to our backups?
Limitations of backups
Backups protect against data loss, not against all forms of disruption. They do not prevent ransomware from encrypting live data if the attack spreads before detection. They do not help if the backup credentials have been compromised by the same breach that affected the live system. They do not address denial-of-service attacks that make the application unreachable even though the data is intact.
Backups are one component of a broader resilience strategy that includes access controls, network security, monitoring and incident response. Planning them thoroughly means understanding exactly where their protection ends and where other measures need to take over.