Backup and Recovery Strategy: The Website Insurance Policy Nobody Tests

The backup conversation always happens after the incident

Every business website eventually has a bad day. An update conflicts with a plugin and takes the site down. An editor deletes a page tree that took two years to build. A compromised admin account scrambles the database. A hosting provider has an infrastructure failure, or goes out of business overnight. None of these are exotic scenarios; they are the ordinary failure modes of operating software on the internet.

What separates a bad afternoon from a bad quarter is not whether a backup exists — most sites have something called a backup. It is whether the backup covers the right assets, was taken recently enough, is stored somewhere the incident cannot reach, and can actually be restored by someone under pressure. Those are business decisions, not technical chores, and they deserve the same deliberate treatment as the choice of platform itself.

This article lays out a backup and recovery framework that works across the four platforms we build on — WordPress, Joomla, TYPO3 and Shopify — and explains where those platforms differ in ways that change the plan.

Four asset classes, four backup jobs

“Website backup” is a shorthand that hides four different jobs, because a running website is not one thing. It is at least four, and each one fails independently:

Content and data. The database: pages, posts, products, orders, user accounts, configuration stored in tables. This is usually the asset with the most labor invested and the one that changes most often. On WordPress, Joomla and TYPO3 it lives in MySQL or MariaDB. On Shopify it lives in Shopify’s infrastructure, which changes the plan — more on that below.

Files and code. Uploaded media, theme files, plugins or extensions, and any custom code. Media libraries are frequently the largest single asset on a content site, and losing them cannot be repaired from a database backup, because the database only stores references to the files.

Configuration and environment. Server configuration, the wp-config.php file or its Joomla/TYPO3 equivalents, DNS records, TLS certificate setup, cron jobs, environment variables, and the credentials that connect all of it. This layer is rarely backed up anywhere, and it is the layer that makes the difference between a restore that takes an hour and one that takes a weekend of archaeology.

External state. Anything the website depends on that is not inside it: app configurations in a Shopify store, third-party integrations, email service settings, analytics, redirect rules living in a hosting panel rather than in the CMS. A restore that brings back the site but silently drops these leaves you with a website that looks alive and behaves wrong.

A backup plan that covers only the first item — the database — is the most common plan and the most inadequate one. A useful audit exercise is to walk through each of the four classes and ask: if this disappeared tonight, what would I restore it from, and how old would the restored copy be?

Self-hosted platforms: you own the whole stack

WordPress, Joomla and TYPO3 share a structural property: the site owner is responsible for everything. The platform software, the extensions, the media files, the database, the server they run on — the entire stack is yours, which means the entire stack is also yours to lose.

Three practical consequences follow.

Files and database must be backed up as a pair, close in time. A WordPress site, a Joomla site and a TYPO3 site are each a database plus a directory of files, and they only work as a matched set. A database from Tuesday morning restored under a plugin directory from Friday is a corrupted site — plugin versions record schema changes in the database, and mismatches produce errors that look like nothing else. Backups should be taken as a consistent snapshot of both, or at least in the same maintenance window, not on independent schedules that drift apart.

Hosting backups are a floor, not a plan. Nearly every hosting product advertises backups, and nearly every one comes with limitations: short retention windows, throttled restore processes, restores only to servers at the same provider, and fine print excluding responsibility when things go wrong. Provider backups are genuinely valuable — they cover infrastructure failures that your own copies cannot — but a business site needs at least one backup copy stored outside the hosting account entirely, in a location with its own credentials. This matters most in the scenarios nobody schedules for: a compromised admin account that can reach the hosting panel, or a billing failure that suspends the whole account, backups included.

Security incidents change the restore procedure. The day you restore because of a hack rather than a mistake, the backup itself is suspect. Restoring compromised files over a cleaned database — or the reverse — re-infects the site. Recovery from a security incident is a sequenced process: rebuild from a known-clean point, rotate credentials, then reapply content. Our WordPress security hardening guide covers the hardening side; the point here is that the backup policy must assume this day will come and keep enough retention history to reach back to a known-clean point, not just last night.

The same logic applies to routine updates. A staging-first update workflow — the discipline we describe in the WP-CLI safe update guide — is the first line of defense, and the backup is the second. A plan that has both survives a failed update with minutes of downtime; a plan with neither turns a routine Tuesday into a data-loss event.

Shopify: the platform is backed up, your store is not

Shopify inverts the responsibility split. As a hosted service, Shopify operates the infrastructure — servers, uptime, platform-level disaster recovery — and store owners cannot and should not worry about any of it. That is a genuine, underrated benefit, and it is part of what the subscription fee buys.

But infrastructure availability is not the same thing as a backup of your store. If a staff member deletes a product collection, uninstalls an app that took its settings with it, or overwrites a heavily customized theme, there is no “restore my store to yesterday” button. The data and configuration that make a store yours — products, variants, collections, themes with their customizations, app configurations, metafields — are your responsibility to preserve, and Shopify provides export mechanisms rather than automatic personal backups.

A Shopify recovery plan therefore has three components. Product and customer data can be exported on a schedule and stored outside the platform. Themes — including the customization work, which is often the most expensive asset in a store — can be version-controlled: modern theme development with Shopify CLI keeps the theme in a repository where every change is a commit you can roll back to. And app state deserves an audit, because apps modify themes and hold configuration outside your direct reach — the aftermath of a bad app uninstall is common enough that we maintain a dedicated guide to removing leftover app code. If you are weighing this responsibility against open-source alternatives, our comparison of the WooCommerce and Shopify operating models covers the trade in detail, and the Shopify platform page summarizes where we think the line falls.

Decide how much you can lose before deciding how often to back up

Backup schedules are often set by tools rather than by requirements. The useful discipline is to decide two numbers first:

Recovery point objective (RPO): how much data loss is acceptable? For a brochure site updated weekly, losing a day of changes is trivial, and daily backups are generous. For a store taking orders continuously, losing a day of orders is a commercial event, and database backups need to run far more frequently — or the store needs to treat the order system’s own records as a second source of truth.

Recovery time objective (RTO): how long can the site be down? An hour is survivable for most businesses; a week is not. The RTO is what exposes the difference between having a backup file and having a recovery plan, because restore time depends on where the copy lives, how fast it can be moved, and whether anyone has rehearsed the procedure.

One rule survives every platform and every vendor pitch: a backup that has never been restored is a hypothesis, not a backup. Backup tools fail silently in ways nothing else on a website does — a storage credential expires, a quota fills, a database grows past a timeout — and the failure is discovered at the exact moment the backup is needed. The only reliable test is a periodic practice restore: rebuild the site from backup into a staging location, on a schedule, and record how long it took. Quarterly is a reasonable rhythm for a typical business site. The first practice restore is usually sobering, which is the point of doing it before the incident does it for you.

A policy that fits a business website

The framework above compresses into a policy that fits on one page:

• Match backup frequency to change frequency. Daily backups of the database on actively edited sites and stores; files on a slower cadence with a copy taken before every significant change.
• Keep at least three copies on two media, one off-site — the standard 3-2-1 pattern, applied with the off-site copy stored under credentials that are separate from the website’s own admin accounts.
• Keep retention history measured in weeks or months, not hours. Ransomware, slow-burning hacks and mistaken deletions are often discovered long after they happen; short retention destroys the evidence and the clean restore point together.
• Back up the invisible layer. Configuration files, DNS records, credentials inventory, and a written runbook for the restore itself. The runbook is the difference between the person who knows the procedure and a procedure anyone can follow.
• Test the restore on a schedule, not as a one-time project.

None of this is expensive relative to what it protects. When we walk clients through a website total cost of ownership analysis, the backup line item is consistently one of the smallest on the sheet — a fraction of what a single day of extended downtime or unrecoverable data loss costs. It is the cheapest insurance on the website, and the only kind that pays out in data you actually recognize.

Where this fits in the bigger picture

Backup and recovery is one of three policies that determine whether a website is governable infrastructure or a liability: what runs on it (plugin and extension governance), how it moves (platform migration planning), and how it recovers. A site can survive a weak answer to one of these. It cannot survive weak answers to all three.

If your current site has never had a practice restore, that is the place to start — and if the stack is one you did not build yourself, a professional audit of what is actually being backed up, versus what is assumed to be, is a small project that resolves the question in days. Our maintenance and WordPress development, Joomla development and Shopify development practices all include recovery planning as standard scope, because “we can rebuild it quickly” is the sentence every site owner should be able to say out loud and actually mean.