Web App Backup Strategy: The 3-2-1 Rule and What to Test

A solid web app backup strategy covers the database, user uploads and the configuration needed to bring the app back, with at least one copy stored with a different provider than your host. The part that matters most is the restore test: a backup only counts once someone has rebuilt the app from it and timed how long that took.

You don't need to be technical to check whether this is in place. Halfway down you'll find seven questions to ask your developer, and the answers show quickly whether your backups would hold up. I sell maintenance work myself, so factor that in.

The short answer: 3-2-1 for a cloud-hosted web app

If you only have copies 1 and 2, you have backups that work right up until your provider has a bad day. Copy 3 is the one that saves you, and only if someone has tested it.

Backups are one of six ongoing jobs I cover in my complete guide to web application maintenance. Here the focus is the step most teams skip: actually restoring one.

What the 3-2-1 rule means when your app lives in the cloud

The 3-2-1 rule predates cloud hosting, and the US Cybersecurity and Infrastructure Security Agency still recommends it: three copies of important data, on two different types of storage, with one copy stored off-site (CISA's backup guidance for businesses). It was written for office hard drives and tapes, so it needs some translation for a web app.

For a web app, "off-site" means a different provider, or at the very least a different account in a different data center. This isn't theoretical. When fire destroyed a data center at OVHcloud's Strasbourg site in March 2021 (OVHcloud's own incident page), some customers lost data because their backups were in the same building as their servers. A French court later ordered OVHcloud to pay damages to two of them (Blocks & Files on the rulings).

"Two types of storage" is about making sure your copies can't disappear for the same reason at the same time. Your server's disk is one type. Object storage (cloud file storage, such as an S3-compatible bucket) at another provider is another.

Ransomware and hijacked accounts have added one more requirement: at least one copy should be offline or immutable, meaning it can't be changed or deleted for a set period, even by someone holding your server credentials. CISA also recommends encrypted, offline copies. For a web app, that usually means separate credentials for the backup storage, plus an object lock or retention period of, say, 30 days.

Two things don't count as copies: your developer's laptop and your Git repository. The first isn't yours, and the second holds your code, not your data.

What a complete web app backup includes

One of the most common gaps is a backup that only covers the database. It's the most important part, but it can't bring the app back on its own. A complete backup has five parts:

• The database. Customers, orders, users and everything else the app stores. It should be taken with a proper dump tool that produces a consistent copy, not by copying database files while the server is running.
• User uploads. Images, PDFs, invoices and documents. If they live in cloud storage, they're not included in your server backup by default, and they're not protected against deletion unless versioning is switched on.
• Configuration and secrets. In Laravel, that's the .env file with API keys and database passwords. It shouldn't sit unencrypted inside a backup archive, but it does need to be recoverable, for example from your company's password manager.
• The code. It normally lives in a repository on GitHub or similar. That's fine, as long as the account belongs to your company.
• The rebuild guide. A short document explaining how to set the app up from scratch: PHP version, background workers, scheduled tasks, DNS and the third-party services to reconnect. Without it, a restore can take days even when every byte of data is intact.

Caches, sessions and search indexes can usually be rebuilt rather than backed up. The rebuild guide should say how.

In Laravel projects, the spatie/laravel-backup package is a popular choice. It zips the database dump and selected folders, can store the archive on several disks at once, cleans up old backups and sends a notification when something fails (the laravel-backup documentation). It doesn't restore anything for you, so the restore still has to be documented and tested.

RPO and RTO: how much can you lose, and for how long?

Two numbers shape every backup setup. The jargon for them is RPO and RTO:

• RPO (recovery point objective): the maximum amount of data you can afford to lose, measured in time. With nightly backups, you can lose up to a day of orders and changes.
• RTO (recovery time objective): the maximum time the app can be down while it's being restored.

The answers come from the business, not the tech. Here's a rough guide:

Point-in-time recovery lets you rewind the database to a specific minute, for example just before a bad migration wiped a column. Many managed databases offer it, but check how many days back your provider's window goes.

Lower numbers cost more. Storage for a daily off-site backup of a small app usually comes in under €15 a month. The real cost is time for setup, alerting and restore tests, and asking for minutes instead of hours changes the architecture.

Backups are not high availability

A restore takes time, even when everything works. If your app has to be back within minutes, you need redundancy: a standby database that's kept in sync, servers in more than one data center and an operations partner with an on-call rotation. I can help build that, but as a solo developer I can't honestly promise 24/7 response. That calls for an agency, a managed hosting partner or your own team.

Seven questions to ask your developer

You don't need to read a backup config to judge it. Ask these questions and notice whether the answers are specific:

1. What exactly gets backed up? A good answer names the database, user uploads and configuration. "The host takes care of it" is not an answer.
2. How often, and how long are copies kept? For example: nightly, kept for 30 days, plus a weekly copy kept for six months.
3. Where do the copies live? At least one should sit with a different provider or account from the server. If you handle personal data, also ask which region it's in and whether there's a data processing agreement.
4. When did you last restore from a backup, and how long did it take? This is the most important question. The answer should be a date and a duration.
5. Who gets alerted if a backup fails? There should be an alert going to a named person, just like the rest of your uptime monitoring setup.
6. Could someone with access to the server also delete the backups? The answer should be no: separate credentials, and ideally a retention lock.
7. If you were ill tomorrow, could another developer restore the app? That requires access in the company's name and a rebuild guide, the same things you need to switch developers mid-project.

Get the answers in writing and add them to your contract. Backups are one of the line items in my checklist for what a software maintenance agreement should cover.

How to run a restore test, step by step

If the answer to question 4 was "never", this is your next move. A restore test rebuilds the app from a backup in a separate environment, while production keeps running:

1. Pick a backup from the off-site copy. Choose one that's a few days old, so you also confirm older copies exist.
2. Restore to a separate environment, never on top of production. Restoring over the live app can wipe today's orders and sign-ups. The same goes for a real incident, where the first step is working out what to do when your site or app is down, not restoring.
3. Start the clock. Measure from the decision to restore until the app is running again. That number is your real-world downtime estimate for a serious outage.
4. Follow the rebuild guide, not memory. If the developer has to improvise or hunt for passwords, that's a finding in itself.
5. Check the data is complete and recent. Log in as a test user, open a recent order, download an uploaded file and compare row counts in the key tables with production.
6. Check what runs in the background. Queues, scheduled tasks and integrations should work, without reaching real customers.
7. Write a short report and fix what broke. Note the date, which backup you used, how long it took and what was missing. Delete the test environment afterwards, because it holds real personal data.

My rule of thumb: test at least twice a year for most web apps, quarterly when the app is business-critical, and always after big changes such as a new host, a new database or a major framework upgrade.

Why backups fail anyway

When backups fail, it's rarely the technology. More often, nobody was looking:

• The backup job stopped and nobody noticed, for example because of a full disk or expired storage credentials.
• Only the database is included. The uploads are missing.
• Every copy sits with the same provider or in the same account.
• The backup is encrypted, but the key only lived on the server that's gone.
• Only the developer who set it up knows how to restore it.
• The restore takes longer than the business can tolerate, and nobody knew until a real incident.

A restore test catches all six, which is the whole point of testing.

Backups, GDPR and where your copies live

If your app processes personal data of people in the EU, backups and restore tests aren't just good practice. GDPR Article 32 requires appropriate security measures and specifically lists the ability to restore the availability of and access to personal data in a timely manner after a physical or technical incident, plus a process for regularly testing those measures. Denmark's data protection authority, Datatilsynet, for example, lists restore testing in its catalog of recommended security measures.

Location matters too. If you've promised customers that their data stays in the EU, your backups have to stay there as well. A backup bucket in a US region quietly turns a simple setup into an international data transfer. Pick an EU region, sign the storage provider's data processing agreement, and protect backups as carefully as production. This isn't legal advice, so check with a privacy professional if you process sensitive data.

Next steps

Start with question 4. If nobody has ever restored a backup, schedule a restore test first, then use the checklist to find the remaining gaps.

You don't need a developer for this if you run on a hosted platform like Shopify, where the vendor backs up the system and your job is to export your own data regularly. And if your hosting partner already runs documented restore tests, use the questions above to check their work instead of paying twice.

If you want help setting up backups or testing the ones you have, see how I approach maintenance and ongoing development for web apps. You deal directly with the developer doing the work.

Frequently asked questions

Are my hosting provider's backups enough?+

Rarely on their own. Host backups usually sit in the same account, and often the same data center, as your server, so they disappear if the account is locked or compromised. Retention is often short, and many hosts can only restore the whole server rather than a single table. Treat them as copy 2 and add an off-site copy alongside.

How long should I keep backups?+

Long enough to catch problems that surface late. CISA recommends being able to roll back at least seven days, and a common pattern is daily copies for a few weeks combined with weekly or monthly copies for longer. If the backups contain personal data, don't keep them longer than you need. Retention should match your data deletion policy.

Can I restore one deleted record without rolling back the whole app?+

Usually, yes. Your developer restores the backup into a separate environment, finds the missing rows and copies them back into production. That way you keep everything that happened since the backup was taken. It takes some manual work, but it's far safer than restoring the full database over the live app.

Do backups have to be stored in the EU?+

Not always, but it's the simplest option if you process personal data of people in the EU. Storing backups outside the EU and EEA counts as a data transfer under GDPR, which needs a transfer mechanism such as an adequacy decision or standard contractual clauses. Most storage providers offer EU regions, so keeping production and backups in the same jurisdiction is usually easy. Check with a privacy professional for your specific case.