Why the backup plugin inside your WordPress dashboard will not save you when the server dies

Log into almost any small-business WordPress site in the UK and you will find a backup plugin sitting in the left-hand menu with a reassuring green tick next to it. Once a week, the plugin zips up the database and the uploads folder and drops the archive into /wp-content/updraft/ or /wp-content/backups/ on the exact same disk as the website itself. That is not a backup. That is a second copy of your files sitting in the same room waiting to burn down in the same fire.

When I move a company site onto my £49 a month website care plan or take over a Linux server, cleaning out thirty gigabytes of old `.zip` archives inside the web root is usually my first job of the morning. Keeping backups inside the website they are meant to protect fails in three ways at once: it fills up your SSD until the database crashes, it leaves your customer data sitting inside a publicly reachable web folder, and it hands any attacker who compromises your admin panel the keys to delete your backups before you even wake up.

If the website can write the backup, the website can delete the backup

Think about how a typical WordPress compromise actually happens. Nobody breaks in through the front door of the Linux kernel. An attacker gets in because an old form plugin had an unpatched vulnerability, or because a staff member’s saved browser password and session cookie were lifted by an infostealer.

Once an automated script has administrator access to `/wp-admin`, or shell access as the `www-data` or `nginx` web user, it owns everything that user has permission to touch. If your backup plugin stores its archives on the local server disk, the script deletes them in half a second. Even if you connected the plugin to a cloud bucket like Dropbox, Google Drive, or Amazon S3 using a read-write API token stored inside the WordPress database, the attacker can click the Delete remote backup button right inside your own plugin dashboard.

Where people keep website backups, and what survives a real incident

Not every backup setup survives the day you actually need to use it:

How the backup is taken	Survives a dead SSD or lost hosting account?	Survives an attacker inside /wp-admin?	Has anyone actually tested restoring it?
Backup plugin saving to /wp-content/	No. Dies with the disk and fills up your storage quota.	No. Deleted in one click from the dashboard.	Almost never until the day the site breaks.
Hosting company’s "free daily snapshot"	No, if your hosting billing fails or the provider locks the account.	Yes, unless the attacker gets into the hosting control panel.	Restores the whole box blindly, overwriting everything.
Plugin pushing to S3/Drive with a full-access key	Yes, stored on a separate cloud network.	No. The stored API key can delete the remote files too.	Rarely tested; large `.zip` imports often time out in PHP.
Server-level off-site pull backup with monthly test restores	Yes. Stored in a separate data centre and provider.	Yes. The web server has zero permission to delete old snapshots.	Yes, restored onto a scratch server to prove it works.

The full-disk crash that happens at three on a Sunday morning

Even if nobody ever attacks your site, running a heavy backup plugin inside PHP is a reliable way to crash a small VPS by accident.

At three on a Sunday morning, the plugin wakes up and tries to compress four gigabytes of product photos and database tables while running inside the web server’s memory limit. Halfway through creating the temporary `.zip` file, the server’s 40GB disk hits 100 per cent full. The moment a Linux server runs out of disk space, MySQL or MariaDB cannot write its transaction logs and stops dead. When your first customer visits on Monday morning, they get “Error establishing a database connection”, caused entirely by the plugin that was supposed to keep the site safe.

Worse, if a poorly written backup plugin drops its temporary archive inside a folder without proper Nginx or `.htaccess` deny rules while the job is running, automated scanners looking for `.sql` and `.zip` files in standard backup paths can download your entire site database, including customer addresses and order history, without logging in at all.

How we back up websites on the £49 a month care plan

A proper backup follows two simple rules: it lives somewhere else, and the machine being backed up is not allowed to erase its own history.

When I look after a site on my £49 a month Website Care Plan, I remove the bloated backup plugins from WordPress altogether. Instead, the backup runs at the operating system level outside the web root, dumps the database cleanly with a single consistent transaction, encrypts the archive before it leaves the machine, and sends it off-site to independent storage in a separate data centre where the web server has no permission to delete past retention points.

More importantly, a backup you have never restored is just a wish. Once a month, I take a real backup from that off-site store and restore it onto a separate scratch environment to prove the database imports cleanly and the pages actually load. If a backup file is corrupt, we find out on a quiet Tuesday morning, not while your checkout page is down.

Common questions

Isn’t my web host’s built-in daily backup enough?
Host-level snapshots are useful when a plugin update goes wrong and you want to roll back twenty minutes. They are not an independent backup. If your hosting provider suffers a storage array failure, or a billing dispute locks your control panel, your live website and your snapshots are trapped behind the same login.

Why do large WordPress backup plugin restores fail so often?
Because restoring a 3GB `.zip` file through a web browser hits PHP execution timeouts (`max_execution_time`) and upload size limits (`upload_max_filesize`) halfway through unpacking. Restoring at the command line over SSH with `wp-cli` or `rsync` and direct MySQL imports takes two minutes and never times out in a browser tab.

How long should a small business keep website backups?
I keep daily backups for two weeks, weekly backups for two months, and monthly archives beyond that. Why so far back? Because if someone quietly injects a spam link into a footer template and nobody notices for three weeks, seven days of rolling daily backups will only give you seven copies of an already-infected site.

If your business website is currently relying on a free plugin dumping zip files onto the same server, have a look at my £49 a month Website Care Plan or my Servers and Infrastructure page, or send me a message and I will check how your backups are actually configured.