It is two in the morning. Your phone lights up with an alert: the homepage is showing a raw error instead of your site, or worse, searching your own URL now returns a "this site may be hacked" warning from Google. A plugin update might have corrupted the database, an attacker might have gotten into wp-admin and swapped out your content, or a teammate might have deleted the wrong page. Whatever the cause, the question you are asking at that moment is always the same: do I have a copy, a real working copy, that can bring all of this back?
This guide answers that question from two directions: what you actually lose when you do not have a backup, and what a proper backup strategy concretely looks like. Instead of generic advice, it walks through where each common method actually fails and how you confirm a backup is restorable before you ever need it to be.
What you actually lose without a backup
"I never got around to backups" usually comes from underestimating the size of the loss. What disappears is not one file, it is several things stacked on top of each other. First, the content itself: years of blog posts, product descriptions, customer reviews, form submissions. Second, search engine trust; the authority Google has built up for your domain over the years does not reset the moment pages start returning 404s, but it takes a real hit, especially if the site stays down for days. Third, revenue: for an ecommerce store, every hour of downtime is orders you did not take, and for an agency, telling a client "your site is gone and we don't have a copy" can mean losing that client outright.
There is also a cost that gets overlooked: rebuild time. A site without a backup does not get rebuilt from scratch, because thousands of database rows, uploaded images, and plugin configurations cannot realistically be recreated by hand. What actually happens is that most of the site is gone for good, and what is left is whatever fragments someone happens to remember. Set against that scenario, the cost of running a real backup system is almost nothing.
The numbers: this is closer than it feels
It is easy to treat this as an abstract risk, until you look at the numbers. According to Patchstack's State of WordPress Security in 2025 report, roughly 13,000 WordPress sites are hacked every day worldwide, about 4.7 million a year. The same report found that newly disclosed vulnerabilities are now being mass-exploited within a median of just 5 hours, meaning the window between a patch existing and attackers using it against unpatched sites now favors the attacker. That should put to rest the assumption that a small site is not worth targeting: most of this activity is automated scanning that does not care how big your site is.
The second figure is even more directly about backups. Sophos's State of Ransomware 2025 report found that attackers specifically targeted backups in 94% of ransomware attacks, and when those backups were compromised, recovery costs rose sharply. The takeaway is that a backup is not just something you should have, it is one of the first things an attacker goes after, which means a backup sitting behind the same credentials as your main system is not really a backup at all.
What a complete backup should actually cover
A complete backup has two parts: site files and the database. On the file side, this is not just the theme and plugins; the wp-content/uploads folder matters just as much, since years of accumulated images, PDFs, and downloadable files often take up the most space, and many size-limited backup tools quietly skip exactly that folder to save room. wp-config.php and .htaccess are two more files people forget but that matter a great deal; they carry site keys and server-level routing rules, and losing them can leave a site technically intact but behaving in ways that are hard to explain.
On the database side, posts, pages, comments, and user accounts are the obvious ones, but plugin settings tables, order and stock data if you run WooCommerce, and submission records if you run a forms plugin are all part of that same database. Files-only loses your content and settings, database-only loses your uploaded media and plugin files. A real disaster recovery scenario needs both, taken at the same time. Restoring a file backup from one date alongside a database backup from another creates new problems of its own, mismatched IDs and broken media links among them.
Comparing backup methods
Saying "I have backups" does not actually tell you much; the method behind that sentence determines whether that backup will work on the day you need it. The table below compares the four approaches most sites end up using, on the same set of criteria.
| Method | Automatic | Offsite (independent of the server) | Ease of restore |
|---|---|---|---|
| Manual FTP download + phpMyAdmin export | No, done by hand | Only if you move it elsewhere yourself | Hard: files and database must be matched by hand, high margin for error |
| Backup plugin (run from inside WordPress) | Yes, schedulable | Only if you connect external storage, not by default | Moderate: easy if the plugin runs, but useless if the site itself is down |
| Host-level backup (hosting control panel) | Yes | No, usually kept on the same server or account | Easy but host-dependent; if the account is suspended, access goes with it |
| Independent, offsite cloud backup | Yes | Yes, with a separate provider and separate credentials | Easy: reachable even if the site itself is completely inaccessible |
The difference in that table comes down to one question: if your site becomes completely unreachable (account suspended, server compromised, host goes out of business), can you still get to your backup? Only the last row answers that question with a clear yes, because that backup lives in a system whose fate is not tied to the site's.
How often backups should run
Frequency depends on how fast your site changes. A blog publishing several posts a day, or a store taking orders constantly, needs daily or even hourly backups; a brochure site that rarely changes might be fine with weekly. A practical rule: your backup interval should never exceed the time it takes to produce an amount of content or orders you cannot afford to lose. A store taking 50 orders a day running on weekly backups is, in the worst case, accepting the risk of losing a full week of orders.
After frequency comes storage: the 3-2-1 rule
A backup taken at the right frequency but stored in only one place is still fragile. This is where the oldest, most battle-tested rule in backup strategy applies: at least 3 copies, on 2 different types of storage, with 1 completely offsite. Three copies protect against any single file corrupting; two different storage types reduce the risk of one storage technology or provider failing at the same time. But the third condition is the one that matters most: at least one copy has to sit somewhere completely independent of the server.
The reasoning is simple. Keeping backups only on the same server as your site carries almost the same risk as not having a backup at all. If the server is compromised, an attacker with that access can reach the backup files too and delete or encrypt them, which is exactly the scenario behind Sophos's 94% figure. If the server fails at the hardware level, or your host suspends the account for any reason, a backup stored on that same server disappears right along with you. A copy held by a separate provider, under separate credentials, does not disappear in either of those scenarios.
How you actually confirm a backup works
An untested backup is a safety net you think you have but might not. Corrupted compressed files, a half-finished database export, an archive cut short by an interrupted upload, these are all common reasons a backup shows as "completed" while being unrestorable. The worst possible moment to discover that is the exact moment you need the backup to work.
A concrete test procedure looks like this: spin up a fresh, empty WordPress install in a real hosting environment separate from the live site (a local setup works too). Restore your most recent backup into that environment, applying files and database in the order your backup tool recommends. Once the restore finishes, check three things: can you reach the login screen, do a handful of randomly chosen pages and posts appear intact, and do uploaded media files (images, PDFs) open without broken links. If all three hold, the backup genuinely works. Repeating this test monthly is the only real way to know your backup tool has not silently started failing; many backup failures go unnoticed for months, because nobody discovers the problem until they actually try to restore.
What to do, step by step, when your site is hacked or crashes
The first step is taking the site offline or into maintenance mode immediately to stop further damage; if an attacker still has access, every minute the site stays live is another minute they can do more harm. The second step is finding the most recent backup you are confident predates the compromise. Do not rush this part: restoring a backup taken after the hack brings the malicious code right back with it and resets nothing. This is why keeping a dated history of backups, not just the latest one, matters so much; without knowing what changed on which date, finding a clean point to restore to is close to guesswork.
After restoring, do not bring the site back online before finding and closing whatever let the attacker in in the first place. Otherwise you get hit through the same door again within days, because you fixed the symptom and left the cause untouched. That cause is usually an outdated plugin, a weak admin password, or an old, forgotten user account; changing all passwords and checking for plugin and core updates right after a restore is the step that most often gets skipped.
Is manual or automatic backup safer
Manual backups depend on human memory, and they get forgotten exactly when they are needed most, during a busy week or a vacation. Nobody skips a backup out of bad intent, it is just unrealistic to rely on a separate system for remembering to run one. Automatic backups remove that risk completely: they run on schedule in the background without anyone needing to remember, and they can alert you when a run fails. If you manage many sites from one system, automatic backup becomes close to mandatory; tracking dozens of sites by hand means at least one eventually slips through, usually on the day it mattered most.
Sources
- Patchstack, State of WordPress Security in 2025 report, patchstack.com
- Sophos, State of Ransomware 2025 report, sophos.com
Instead of tracking these steps by hand for every site, Watch Your WP handles automatic, offsite backups and restore verification for every site from a single panel.
Erdinç
Building Watch Your WP. Writes from hands-on WordPress maintenance, security, and site management experience.
LinkedIn
