Three ways to back up WordPress, three real restores: database-only won't bring the site back

On 5 October 2026 we destroyed the same WooCommerce shop three times over, to see which of the three most common backup methods could actually bring it back up. Short answer: one out of three can't, even though it looks like the most convenient option.\n\n## The setup\n\nTest shop: 500 products, 41 attachments, 290 files in the uploads folder, one real order. Stack: WordPress 7.1.2, WooCommerce 11.1.2, PHP 8.3.35, MariaDB 11.8.9. Real-world versions: WordPress 7.1.2 was released on 22 September 2026 as a security release, WooCommerce 11.1.2 on the same day, also with a security fix alongside a couple of bug fixes.\n\nFor each method we took a backup, then tore the setup down as if migrating to a brand-new server: core reinstalled from scratch, wp-content and database lost. Then we restored, then ran eight checks: the homepage, catalogue page and an image must respond and actually be genuine (an HTTP status code alone isn't enough), plus counts of products, attachments, orders, files in uploads, users and options.\n\nThe detail that catches everyone out: a WordPress error page still responds with a 200 status code. A check that only looks at the status code will say "site's up" even when the site is dead. Our checks also look at the content of the response and the type of file returned.\n\n## The results\n\n| Method | Backup time | Size | Restore time | Checks passed |\n|---|---|---|---|---|\n| Database only | 0.3 s | 1 MB | 1.1 s | 4 out of 8 |\n| Database + wp-content | 1.8 s | 34 MB | 1.8 s | 8 out of 8 |\n| Database + full root | 2.9 s | 60 MB | 2.4 s | 8 out of 8 |\n\nWith database-only (mysqldump): homepage broken, catalogue page broken, image lost, 0 out of 290 files recovered. Products, attachments (as records) and orders, on the other hand, all come back, because that data lives in the tables. This is the dangerous part: the database still contains the image file names, so a cursory check suggests "the data's all there". But the physical files in uploads no longer exist, so the site doesn't display properly.\n\nDatabase + wp-content brings everything back: 8 out of 8 checks, at 33 MB and a good second longer than database-only.\n\nDatabase + full root gives the same result (8 out of 8) but is heavier, since it also includes the WordPress core, which gets reinstalled from scratch anyway. It's still needed in other scenarios, though, for wp-config.php and for anything outside wp-content (e.g. webserver configuration files in the root).\n\n## The takeaway\n\nA database-only backup is the worst-case scenario, not because it never works, but because it looks like a proper backup: the file exists, it's small, and it takes a third of a second to create. Anyone who doesn't test the restore only discovers the gap when it really matters. Doing it properly — adding wp-content — costs 33 MB and one extra second of backup time. Not much, compared with a broken site.\n\n## How to test it risk-free\n\nBefore trusting a backup, restore it on a test subdomain (e.g. test.yoursite.com), pointed at a copy of the database with a different name, without touching DNS or the production setup. All you need is a new folder, a wp-config.php with different credentials, and a dump imported separately. The actual restore test takes less than three seconds: anyone who's never done it doesn't know whether they have a backup — they only know they have a file.