A site disappearing on a Tuesday morning is rarely due to a spectacular attack: it’s usually a deleted folder, an unfiltered SQL query, or a suspended hosting account due to an unpaid bill.
Most leaders we work with believe they are protected because a file is copied somewhere, only to find out at the worst moment that this copy can’t be restored online.
Here, we detail what constitutes a real backup, how a restoration works, and the billing trap that can be very costly for an online store.
Key points
- A backup must be stored separately from the original data, otherwise it doesn’t count.
- Cloud sync also replicates your deletions and corruptions.
- RAID covers disk failure, but never human error.
- Restoring the database can re-bill your WooCommerce subscribers.
- Test the restoration on a test site before the real incident.
- 66% of companies hit by major data loss close within two years.
What is a backup, and what isn’t
A backup is a copy of your data at a specific point in time, stored separately from the original, kept to enable recovery after loss or damage.
The separation criterion is the only decisive factor: a copy placed on the same disk as the live site is not a backup, it’s a duplicate that will die with the rest.
Cloud sync services like Dropbox, Google Drive, or OneDrive faithfully replicate your deletions and corrupted files to the remote copy, disqualifying it as protection.
A snapshot, a pointer to disk blocks frozen by the storage layer, restores quickly but remains tied to the same storage system.
An archive, often write-once, serves compliance and long-term retention, not quick online recovery.
| Mechanism | Protects against | Doesn’t protect against |
|---|---|---|
| Separate backup | Loss, corruption, account suspension | Nothing, if never tested |
| Cloud sync | Local machine failure | Replicated deletion and corruption |
| Snapshot | Quick rollback | Storage system failure |
| RAID | Physical disk failure | Human error, malware, unpaid bills |
| Archive | Conservation requirements | Immediate business recovery |
GitLab experienced a chain of human errors in 2017 with five backup methods in place, all silently broken on the critical day.
Real loss scenarios
There are seven families of loss scenarios, including hardware failure, human error, malicious actors, and software bugs.
Human error is by far the most frequent: accidental folder deletion, UPDATE query without WHERE clause, trash emptied too quickly.
The financial penalty is significant, as 66% of companies hit by major data loss close within two years.
Losing a showcase site means cutting off a commercial channel, a topic we also address when comparing WordPress, headless, and custom AI for choosing a CMS in 2026.
À lire aussi : Sauvegarde et restauration d’un site WordPress en 2026
How a restoration works in practice
Jetpack VaultPress Backup records every site modification and offers a one-click restoration to a previous point.
This feature is reserved for Business and Commerce plans on WordPress.com, with Personal and Premium plans needing an upgrade.
Restoring overwrites the site with the chosen point’s content, and any subsequent changes disappear unless previously copied, selectively restored, or tested on a pre-created site.
The execution time varies from a few minutes to several hours depending on the site’s size, with an email notification upon completion.
For site migration, prefer domain transfer, cloning, or the Migrate to WordPress.com tool, as backup isn’t designed for this purpose.
The WooCommerce subscriptions trap
On a store equipped with WooCommerce Subscriptions, restoring the database can re-bill customers for an already paid period.
The mechanism is simple: the subscription record reverts to its previous state, scheduled via Action Scheduler or post meta, while orders remain up to date.
The recommended sequence involves four steps: notifying customers, pausing automatic renewals, restoring, then checking and canceling duplicate renewal orders.
There’s a safer way out: uncheck the Site database box on the restoration screen to only restore files, leaving subscription records intact.
On an active store, always test the restoration on a test site before touching production.
Retrieving a backup and restoring it elsewhere
Full download is done from Jetpack > Backup, selecting a date, then Download backup and Create downloadable file, with the file arriving directly or via email.
Components are retrieved separately: themes, plugins, WordPress root with wp-config.php, wp-content folder excluding themes, plugins, and media, database, and media files.
Beware of the mandatory pair: to restore media, the database must also be selected.
On a self-hosted or local site, the procedure documented by the official WordPress.com backup download documentation involves extracting the .tar.gz archive, uploading wp-content via FTP, then importing .sql files through phpMyAdmin.
Import the main file first, then the update files, and modify siteurl and home in the wp_options table if the address changes.
Where to start this week
First, check where your copies are stored: if they share the site’s disk, you don’t have a backup.
Next, schedule a dry run restoration on a test site, noting the actual duration and any steps that get stuck.
If your site sells subscriptions, write the procedure for pausing renewals before you need it.
We cover these tooling and method topics in our other analyses, like our comparison of AI plugins for Obsidian in 2026, and we support these projects through our solutions for small businesses.
FAQ
My host makes backups, is that enough?
It depends on their nature and location. A copy stored on the same infrastructure doesn’t protect you from account suspension due to unpaid bills or propagated corruption. Keep at least one set of recoverable files outside the host, and ensure you know how to restore it yourself, without relying on technical support.
How long does a full restoration take?
From a few minutes to several hours depending on the site’s volume, with an email notification once the operation is complete. A light showcase site comes back quickly, while a store with thousands of media and a large database takes significantly longer. Measure this duration on a test site to provide a credible timeframe to your clients on the incident day.
Can I restore without overwriting recent data?
Yes, through selective restoration. Unchecking the Site database box restores only files, themes, and plugins, without affecting content and records saved since the backup. This is the preferred method after a file infection or a failed plugin update when the database remains healthy and up to date.