A backup is useful only when it can restore the systems and data the business actually needs within an acceptable time. This section helps teams define recovery objectives, choose backup patterns and test the full recovery process.
| Recovery decision | Business effect | Evidence to test |
|---|---|---|
| How to Plan Backups and Recovery | Planning backups starts with knowing exactly what you are protecting and why. | Most businesses skip this step and jump straight to asking a developer to "set up backups," which usually results in something that runs but cannot actually restore the system when needed. |
| Backup Strategies for Web Applications | A web application is not a single file you can copy. | It is a collection of moving parts, and each part needs a different approach to backing up. |
| Disaster Recovery Planning for Business Systems | Backups and disaster recovery are related but distinct. | A backup is a copy of your data. |
| How Often Should You Back Up a Web Application? | The right frequency depends on how much data you are prepared to lose and how often the data changes. | There is no universal answer, but there is a reliable way to work it out. |
How to Plan Backups and Recovery
Planning backups starts with knowing exactly what you are protecting and why. Most businesses skip this step and jump straight to asking a developer to "set up backups," which usually results in something that runs but cannot actually restore the system when needed.
Begin by listing every component your web application depends on: the application code and its configuration, the database or databases, file storage (documents, images, exports), integration credentials and keys, and any third-party services that hold data you do not control. If your CRM stores customer correspondence inside a third-party email provider, that data sits outside your backup scope unless you have a separate arrangement in place.
Next, rank each component by how quickly its loss would stop the business operating. A customer portal that cannot process orders is more urgent than an internal reporting tool used once a week. This ranking determines where you spend time and money on resilience.
Assign ownership clearly. In many organisations, the development team assumes someone in operations is handling backups, while operations assumes the hosting provider takes care of it. The result is a gap that only becomes visible after something fails. Write down who is responsible for configuring backups, who checks they are running, and who would lead a recovery effort.
Finally, document the plan in a form someone unfamiliar with the system could follow. If the only person who knows how the backups work leaves the business, the plan is worthless. Include server locations, access credentials (stored securely), the order in which components must be restored, and who to contact at the hosting provider.
Backup Strategies for Web Applications
A web application is not a single file you can copy. It is a collection of moving parts, and each part needs a different approach to backing up.
Database backups
Databases change constantly and are usually the most valuable component. A file-level copy of a running database is often corrupt because the data is partially written at the moment of capture. Use the database engine's own export or dump tools, which create a consistent snapshot. For systems with high transaction volumes, consider whether the backup tool can create a snapshot without locking the database and blocking users.
Application code and configuration
Application code should live in a version-control repository such as Git. If it does, you already have a reliable backup of the code itself. Configuration files, environment variables and server settings are a separate concern. These change less frequently but are difficult to reconstruct from memory. Ensure they are stored alongside the code or in a separate, versioned location.
File storage
User-uploaded documents, generated reports and media files need regular backup. If these files are stored in an object-storage service, check whether the provider offers built-in versioning or replication. If they sit on a server's file system, they need to be included in the backup schedule explicitly. A common mistake is backing up the database diligently while forgetting that every customer document lives in an unbacked folder.
Full, incremental and differential approaches
A full backup copies everything each time. It is simple to restore but slow and expensive to run at scale. Incremental backups copy only what changed since the last backup of any type, making them fast but requiring every backup in the chain to restore successfully. Differential backups copy what changed since the last full backup, striking a middle ground. For most business web applications, a daily full database backup combined with more frequent incremental or log-based backups provides a practical balance.
Disaster Recovery Planning for Business Systems
Backups and disaster recovery are related but distinct. A backup is a copy of your data. Disaster recovery is the process of getting your entire system running again after a significant failure, whether that is a server failure, a data-centre outage, a ransomware attack or a configuration error that corrupts production data.
Start with a business-impact analysis. For each system, answer two questions: what happens if this is unavailable for one hour, one day and one week? The answers tell you how much to invest in recovery capability. A system that costs the business thousands of pounds per hour of downtime justifies a different level of investment than one that is merely inconvenient.
Define specific recovery scenarios rather than a vague "we will restore from backup." A scenario might be: the primary database server fails and cannot be restarted. Another might be: an administrator accidentally deletes a table of customer records. A third might be: the entire hosting region goes offline. Each scenario has a different recovery path, and planning them separately reveals gaps that a single generic plan would miss.
Agree on communication procedures. When a critical system goes down, people need to know who is working on it, what the expected timeline is and whether they should notify customers or regulators. Without a pre-agreed communication plan, staff waste time asking questions and customers lose confidence.
How Often Should You Back Up a Web Application?
The right frequency depends on how much data you are prepared to lose and how often the data changes. There is no universal answer, but there is a reliable way to work it out.
Ask yourself: if the system failed right now, what is the most recent data we could not afford to recreate? If your team enters fifty customer records per day and each record takes ten minutes to re-enter, losing a full day's work costs roughly eight hours of staff time. That suggests a daily backup is insufficient and you need something more frequent, perhaps hourly or using continuous database log shipping.
For a system that changes rarely, such as an internal knowledge base updated a few times per week, daily backups may be more than adequate. The cost of more frequent backups, in terms of storage and processing overhead, would not be justified by the small amount of data at risk.
Consider the time of day as well. If your application processes a large batch of transactions overnight, a backup that runs at midnight might capture an inconsistent state. Schedule backups to avoid conflicting with heavy processing periods, or use tools that can create consistent snapshots regardless of activity.
Be wary of assuming that because your hosting provider offers "daily backups," your needs are met. Provider backups are often designed for the provider's protection, not yours. They may have short retention periods, slow restore times or limited granularity. Treat provider backups as a safety net, not a strategy.
Testing Your Backup and Recovery Plan
An untested backup is an assumption, not a safeguard. Testing is the step most businesses skip, and it is the step that most often reveals fatal problems.
There are two distinct things to test: whether the backup contains what you expect, and whether you can actually restore from it. Passing the first test does not guarantee passing the second. A backup file might be intact but require software versions, configuration settings or licence keys that no one has documented.
Plan a recovery test on a separate environment, never on production. The goal is to bring the system up from backups and verify that it functions correctly. Check that users can log in, that data is present and consistent, that integrations with other systems still connect and that file uploads are accessible. Simply confirming the database mounts is not enough.
Time the recovery. If your plan assumes you can be back in two hours but the restore actually takes eight, your business-impact assumptions are wrong and you need to adjust either your recovery capability or your expectations.
Test at least quarterly, and test after any significant change to the system architecture, database schema or hosting environment. A change that alters the backup configuration or the restore process can silently break recovery without triggering any error alerts.
Document what went wrong during each test and track whether the issues are fixed before the next one. Common findings include missing configuration files, outdated credentials, backups that were silently failing for weeks and restore procedures that referenced servers that no longer exist.
RPO vs RTO: What Business Owners Need to Understand
These two acronyms are central to any serious backup and recovery discussion, and they are frequently misunderstood.
Recovery Point Objective (RPO) is the maximum amount of data loss you can tolerate, measured in time. If your RPO is one hour, your backups must be frequent enough that you never lose more than an hour's worth of data. RPO is about how far back in time you might have to go.
Recovery Time Objective (RTO) is the maximum time it should take to get the system running again after a failure. If your RTO is four hours, the entire recovery process, from detecting the failure to having users working normally, must complete within that window. RTO is about how long the business is disrupted.
The two are independent. You could have an RPO of five minutes but an RTO of two days, meaning you lose almost no data but the business is offline for a long time while the system is rebuilt. Conversely, you could have an RTO of thirty minutes but an RPO of twenty-four hours, meaning you are back quickly but you have lost a full day of data.
Both have direct cost implications. A shorter RPO requires more frequent backups, more storage and more processing. A shorter RTO requires standby infrastructure, faster networks and more rehearsed procedures. The practical approach is to set RPO and RTO based on actual business impact, not on what sounds reassuring, and then budget accordingly.
When discussing these with a supplier, ask them to state both values for the system they are proposing and to explain what happens when those targets are not met. A contract that specifies an RTO of four hours but has no consequences for missing it provides little practical protection.
Backup Storage and Retention Policies
Where backups are stored matters as much as whether they are taken. A backup stored on the same server as the live data protects against accidental deletion but not against hardware failure. A backup stored in the same data centre protects against server failure but not against a data-centre outage.
For most business systems, a reasonable starting point is to store backups in a different availability zone within the same cloud region, with a second copy in a different region for critical data. Storing backups with a different provider entirely adds another layer of protection but introduces complexity in access and restore procedures.
Retention policy determines how long you keep backups before deleting them. Short retention saves storage costs but limits your ability to recover from problems that go unnoticed for days or weeks. A corruption that replicates to backups will eventually overwrite all clean copies unless you retain older backups for long enough to notice the problem.
Consider compliance obligations as well. UK data-protection law requires that personal data is not kept longer than necessary, and this principle extends to backup copies. A backup containing customer personal data that is retained indefinitely may itself be a compliance issue. Define retention periods based on what you genuinely need for operational recovery and any regulatory requirements, and ensure old backups are actually deleted according to the policy rather than accumulating indefinitely.
Encrypt backups at rest. If backup files are stored unencrypted and someone gains access to the storage location, they have direct access to your customer data, configuration secrets and business records. Encryption adds minimal complexity during backup and restore but significantly reduces the impact of a storage breach.
How to Recover from a Ransomware Attack
Ransomware targeting business systems increasingly aims at backups as well as live data. If the attacker can encrypt or delete your backups before you notice the intrusion, your recovery options narrow dramatically.
The immediate priority is isolation. Disconnect affected systems from the network to prevent the ransomware spreading to connected services and, critically, to backup storage. If your backups are accessible from the compromised environment with the same credentials, assume they are compromised too.
Assess what is affected before taking any recovery action. Ransomware often sits in a system for days or weeks before activating, meaning backups taken during that period may already contain the malicious software. You may need to restore from a point before the initial compromise, which requires knowing when that occurred and having backups old enough to reach it.
Do not pay the ransom without taking specialist advice. Paying does not guarantee data recovery, funds further criminal activity and may have legal and insurance implications. Engage a specialist incident-response firm with experience in the specific type of ransomware involved.
Recovery from a clean backup is the preferred path, but it must be done carefully. Restore to a completely fresh environment, not back into the compromised infrastructure. Change all credentials, including API keys and integration tokens, before reconnecting the restored system to other services. If the ransomware gained access through a known vulnerability, ensure that vulnerability is closed before the system goes live again.
After recovery, conduct a thorough review of how the attack succeeded and what needs to change in your backup architecture, access controls and monitoring to prevent a recurrence. Ransomware recovery is not complete when the system is back online; it is complete when the conditions that allowed the attack have been addressed.
Geographic Redundancy for Business-Critical Systems
Geographic redundancy means running your system, or a ready-to-activate copy of it, in more than one physical location. If one location becomes unavailable, traffic shifts to the other with minimal disruption.
This is not the same as storing backups in another region. A backup in a different region allows you to rebuild the system, which takes time. Geographic redundancy means a working copy already exists elsewhere, reducing recovery time from hours or days to minutes.
The decision to invest in geographic redundancy should follow from your RTO analysis. If your business can tolerate several hours of downtime while a system is restored from backups in another region, geographic redundancy is probably unnecessary. If your RTO is measured in minutes, it becomes difficult to achieve without a redundant copy already running.
Data residency is a particular consideration for UK businesses. If your system processes personal data of UK residents, storing a redundant copy outside the UK may have implications under UK data-protection law. Ensure that any cross-border data storage is covered by an adequate legal mechanism and that your privacy documentation reflects the actual data flows.
Geographic redundancy introduces complexity. Data between regions must be kept in sync, which means deciding between synchronous replication (which keeps the copies identical but adds latency to every write operation) and asynchronous replication (which is faster but means the secondary copy may be slightly behind the primary). The choice affects both user experience and your RPO in a failover scenario.
For most business systems, a pragmatic middle ground is to maintain active backups in a second region with documented procedures for standing up a replacement environment, rather than paying for a fully redundant always-on copy. This approach accepts a longer RTO in exchange for significantly lower cost and complexity. The right balance depends on what downtime actually costs your business, not on what is technically possible.