Website backups: the only one that counts is the one you tested

Everyone believes their website has backups. Almost no one has checked one. The story always plays out the same way: on the day a restore is needed, it turns out the host’s copy is three days old, or does not include the database, or is stored on the very server that has just been compromised. This article does not compare plugins: it sets out a backup policy, and above all the one step that validates it, the restore test. If your site has already gone down, start instead with what to do in the first 60 minutes when your website is down.

What a backup must contain

A site is not a folder of files. It is an assembly of four building blocks, and a single one missing is enough for the restore to fail.

• The files. The application core, the theme, the plugins and above all the uploads folder. This is the bulkiest block and the least critical: the core and the plugins can be downloaded again from their official sources, your photos cannot.
• The database. Everything that makes your site a living thing: pages, posts, products, orders, customer accounts, plugin settings. A backup of the files without the database gives you back an empty, unusable site.
• The server configuration. PHP version, memory limits, scheduled tasks, rewrite rules, certificates. Rarely backed up, often rediscovered the hard way.
• What lives off the server. The DNS zone, the email records, the API keys for payment services. Exporting the zone to a text file takes two minutes and saves an evening of piecing it back together.

For the database, the reference command has not changed in twenty years, and two options make all the difference: --single-transaction avoids locking the site during the export, --quick avoids swamping the memory on large tables.

mysqldump --single-transaction --quick --default-character-set=utf8mb4 \
  -u USER -p DATABASE | gzip > db-$(date +%F).sql.gz

On WordPress, the official command line tool does the same thing while taking table prefixes into account:

wp db export - | gzip > db-$(date +%F).sql.gz
tar -czf files-$(date +%F).tar.gz wp-content/uploads wp-content/themes

The 3-2-1 rule, explained without jargon

Three copies of the data, on two different media, one of them away from the main site. This rule, taken up by Cybermalveillance.gouv.fr, the French government’s cybersecurity advice service (the page is in French), translates into three very concrete locations for a website: the live copy on the production server, a copy with the host, and an off-site copy with a provider that has nothing to do with the first.

The third is the only one that truly counts, and it is the one that gets skipped. It alone survives three scenarios the first two do not cover: ransomware that encrypts the server and takes the local backups with it, an account suspended over an unpaid invoice or a dispute, and the failure of the provider itself. A backup stored on the server it is supposed to protect does not count as a copy: it is a convenience archive, handy for undoing an editing mistake, useless on the day of a real disaster.

The off-site copy takes one line to set up, to object storage or a plain remote server:

rsync -az --delete /var/backups/ backup@remote-storage:/backups/mysite/

Two precautions that make the difference, both echoed in the IT hygiene guide from ANSSI, France’s national cybersecurity agency: the account used to deposit the backups must not have the right to delete them, and the encryption key must never sleep next to the archives it protects.

How often, and for how long

The right question is not “how often should I back up” but “how much data can I afford to lose”. A brochure site edited three times a year can lose a day without consequence. A shop that takes forty orders a day cannot lose an hour. That tolerance decides everything else.

Retention is the setting people underestimate most. An infection discovered after three weeks makes backups kept for seven days worthless: every one of them already contains the way in. That is exactly why thirty days of retention is a floor, not a luxury. Plan too for the snapshot taken before every update: it is the most used backup of all, and you will find its logic set out in detail in our guide to securing a WordPress site step by step.

The restore test, the step nobody does

An untested backup is a hypothesis. The test is done on a separate environment, never on production, and always follows the same seven-point route: the home page, a deep page picked at random, a form actually submitted, the checkout funnel through to the payment page, the images displaying, a login to an account, and the dates on the most recent content lining up.

Two technical checks are worth adding before you even restore, because they take ten seconds and spare you hours on the wrong tack:

gunzip -t db-2026-08-06.sql.gz && echo "archive intact"
zcat db-2026-08-06.sql.gz | grep -c "INSERT INTO"

An archive that passes the integrity test but contains not a single insert line is an empty 40-byte file, the classic result of a database credential that expired months ago while nobody read the failure emails.

As for frequency: a test after every structural change, and at least twice a year. The only metric that will matter when the day comes is not the size of your archives, it is the time between the decision to restore and the service coming back. Time it during the test. If it runs past two hours on a brochure site, your procedure needs rethinking.

The five false backups

1. The host’s backup whose terms nobody has read. Often daily, often kept for seven days, sometimes out of scope in the event of a compromise, and frequently charged for at restore time.
2. The plugin that writes into the uploads folder. It puts the archives inside the very perimeter under attack, sometimes publicly reachable by anyone who guesses the address.
3. The manual export from launch day. It freezes a site that no longer exists. Its value shrinks by the week.
4. Folder synchronization. A sync faithfully copies across a deletion or a malicious encryption, usually within minutes. That is not a backup, it is a mirror.
5. The encrypted archive whose key sleeps on the same server. Technically impeccable, operationally worthless.

Backups and migration: the same tool serves twice

A complete, tested backup is not only insurance against disaster, it is the safety net under every risky operation: a change of host, a major version upgrade, a redesign, a takeover by a new supplier. The switchover rule is always the same and fits in one sentence: nothing gets cut until you have checked that the copy works.

In practice, the old environment stays intact and reachable for several weeks after the switchover, read only if need be. That is what lets you recover a forgotten file or compare a behavior without having to restore anything. The same requirement holds for a website redesign and for switching web agency or host without breaking your site: the new site replaces the old one only after validation, never before.

Our position: the value is not the backup, it is the restore

A supplier who sells you “daily backups” is selling you nothing until they have answered five questions: where are they stored, how long are they kept, who tests them and how often, how long does the site take to come back, and who presses the button on a Sunday morning. We answer those five questions in writing before anything is signed, because they are the only ones that count.

For the sites in our care, the policy is this: a daily backup shipped off the production infrastructure, a systematic snapshot before every update, retention managed by the cloud host, a documented restore test twice a year, and a reachable human who does the restoring for you. A one-off intervention goes through a support ticket at €89 (VAT not applicable, article 293 B of the French tax code), and a pack of five tickets at €399 (VAT not applicable, article 293 B of the French tax code) comfortably covers a year of incidents for a brochure site. The details are on our technical support and managed backups page.

One last thing, often forgotten: a code repository is not a backup. It protects the theme and any custom development admirably, but it holds neither the database nor the media. The two arrangements complement each other, as we explain in the article on keeping your website’s history in Git and GitHub.

Tested backups are part of our WordPress maintenance in Pau, in south west France.

Frequently asked questions

My host does backups, is that enough?

Rarely on its own. Check four points in your terms: the actual frequency, the retention period, where the copies are stored and the restore procedure. Many plans keep seven days on the same infrastructure, which protects you neither from an old infection nor from an incident at the host.

Does a backup slow the site down?

If it runs at peak traffic, yes: copying the files and locking the tables eat up disk input and output. Schedule it for the quiet hours and favor a transactional dump, which does not block writes.

How long should you keep backups?

Long enough to cover the time it takes to discover a problem. Thirty days at a minimum for an active site, topped up with a monthly copy kept for a year. Seven days covers no realistic infection scenario.

Can an online shop be backed up continuously?

Yes, by separating the rhythms: the database several times a day, or even as a continuous stream through the binary logs, and the files once a day. The orders are the irreplaceable data, not the theme’s images.

A backup is not judged by its existence but by how fast it gets you back on your feet. Run the test once, on a real site, stopwatch in hand: within an hour you will know exactly what is missing, and you will never again sleep on the same assumption.

Also worth reading: Website maintenance: what happens when you ignore it

Have my backups checkedPut my site under our care