Most companies discover that their WordPress backup strategy does not work at the worst possible moment: the shop hacked on a Friday evening, the update that took the site down, the hosting account that suddenly became unreachable. In the rescue jobs I get called into, there is almost always some kind of backup – and almost never one that survives a real emergency. A backup that has never been restored is not a backup; it is a hope. In this article I will walk you through the strategy I set up for my own clients in Vienna and across the DACH region: what actually needs backing up, how to automate it so nobody has to remember anything, why the restore test is the single most important step – and the classic failure patterns I keep finding in the wild.
How backups fail in real life
Before the right way, here is my personal hit list from years of emergency calls – check how many apply to your site:
- The backup lives on the same server as the website. Server dies or site gets hacked – original and copy disappear together. The most common and most expensive mistake of all.
- Only half the site was saved. Files without the database, or the database without the uploads folder. Either alone is worthless: a website is both.
- The backup job has been silently failing for months. The plugin hits a PHP memory limit or timeout, the error email goes to an inbox nobody reads. The failure is discovered on the day the backup is needed.
- The hack is older than the oldest backup. With seven days of retention and malware that has been in place for three weeks, every copy you own is already compromised.
- Nobody has ever rehearsed a restore. In the emergency it turns out the archive is incomplete, nobody knows the storage password, and nobody knows the actual restore procedure either.
Every one of these is preventable – with a strategy built around three numbers.
The 3-2-1 rule, translated for websites
Borrowed from enterprise IT and proven for decades: keep 3 copies of your data (the original plus two backups), on 2 different types of storage, with 1 copy off-site. Translated to a WordPress site: the live site on your web server is the original. Your host’s automatic backup is copy one. And your own automated backup to external storage – S3-compatible cloud storage, Google Drive, or a server with a completely different provider – is copy two, the one that matters. It is the copy that still works when your host has a full outage, your account gets suspended, or an attacker encrypts the server together with its local backups.
What needs backing up: database plus files
The database – the heart of the site
The database holds every post, page, setting, user and comment – and in a WooCommerce shop, every order and customer record. It changes most frequently, so it gets the highest backup frequency. For a shop, every lost hour of database means lost orders: there I back up the database hourly to daily. For a company site with occasional blog posts, daily to weekly is enough.
One aspect that routinely gets forgotten: shop backups contain personal data – names, addresses, order histories. That means GDPR applies to your backups just as much as to the live site. In practice: choose backup storage located in the EU, encrypt the archives (mandatory for sensitive data, good practice for everything else), and set a deliberate retention period instead of hoarding copies forever. An unencrypted customer-data archive sitting in some cloud folder is not a safety net – it is a second data breach waiting for its moment.
The files – more than just uploads
A complete file backup covers wp-content/uploads (all images and documents – often several gigabytes and impossible to reconstruct from anywhere else), your themes and plugins including every custom modification, plus wp-config.php and .htaccess – the two files that are always missing when a restore goes sideways. Strictly speaking WordPress core does not need backing up, since it can be re-downloaded any time; I include it anyway, because a complete archive turns a restore from hours of assembly work into minutes.
Automation: backups nobody has to remember
Manual backups fail for a simple reason: human nature. After week three, nobody remembers. A working setup runs automatically and – just as important – complains loudly when it fails. Three approaches that have proven themselves:
- A backup plugin with an external destination: tools like UpdraftPlus back up database and files on a schedule straight to S3, Google Drive or Dropbox. The pragmatic choice for most sites – as long as the destination is off-server and failure notifications are switched on and actually monitored.
- Server-side via WP-CLI and cron: my preferred setup for client projects. A small script exports the database with wp db export, archives the files and pushes the encrypted result to external storage. It runs independently of WordPress itself – which means it keeps working even when the site is already down or compromised.
- Host backups as a supplement: your provider’s automatic snapshots are genuinely useful for quick everyday restores – but unsuitable as the only line of defence, more on that below.
On retention: my standard scheme keeps 14 daily, 4 weekly and 3 monthly snapshots. That staggering is what saves you when a problem surfaces late – injected malware being the classic case. Backups are also the safety net under every single update, which is why they are inseparable from ongoing WordPress maintenance – I have written about that side of the story separately.
Host backup, plugin or your own script? A comparison
| Approach | Strengths | Weaknesses |
|---|---|---|
| Your host’s automatic backup | Zero effort, fast full-site restores | Same infrastructure as the site, retention often just 7–14 days, unreachable if the account is locked |
| Backup plugin (e.g. UpdraftPlus) | Quick to set up, external destinations, selective restore of single components | Runs inside WordPress – hits PHP limits on large sites, failures go unnoticed without monitoring |
| Server-side script (WP-CLI + cron) | Independent of WordPress, robust with large data volumes, fully configurable retention | Needs shell access and someone who knows what they are doing to set it up |
| Manual backups “when I think of it” | Better than nothing | Stops happening after week two – not a strategy, a lottery ticket |
The restore test: the drill almost nobody runs
This is the most important section of the article. A backup proves its worth only in the restore – and the restore is exactly what almost nobody rehearses. My routine for managed sites: at least twice a year, a current backup is fully restored to a separate staging environment. Then everything gets checked: homepage, subpages, forms, and for shops the entire checkout. I also time the whole exercise – because in a real emergency the question is not “do we have a backup?” but “how long are we down?”. A rehearsed restore takes 30 to 60 minutes; an unrehearsed one happily eats a full day, split between panic, password hunting and support tickets. If you have never run this test, run it this week. Either it turns your hope into certainty, or it reveals in time that your backup is worthless – both outcomes are a win.
Host backups: good, but never enough
“But my host does backups” is the sentence I hear most often – and yes, good providers do. Just never rely on them alone: the copies sit in the same infrastructure as your website, retention is usually capped at one or two weeks, and if your account is suspended or the provider goes under, you cannot reach any of it. Host backups are an excellent first line of defence for quick everyday restores – they do not replace your own external copy. If you are unsure what your current setup actually covers, a short session of technical consulting settles it: review the backup situation, name the gaps, define the strategy – half a day, done. And if your site has grown into something business-critical, that review belongs into any serious web development handover anyway.
Conclusion
A backup strategy that survives an emergency is not rocket science: back up database and all files, keep at least one copy off-site following the 3-2-1 rule, automate everything with failure alerts, stagger retention across weeks and months – and rehearse a real restore on staging twice a year. Treat your host’s backup as a supplement, never as the foundation. Get these points right, and a potential total loss shrinks to an annoying but controlled one-hour incident.
If you would rather not build and babysit this yourself: external backups with monitoring and regular restore tests are a fixed part of my website care and maintenance plans – you get the certainty without the ongoing effort. Send me a message via the contact form and I will tell you honestly where your current backup setup stands.
