How to Back Up a WordPress Site, and What Breaks on Cheap Hosting

Nobody thinks about backups until the afternoon a plugin update takes the whole site down, or a host support ticket comes back with "the last snapshot we have is from three weeks ago." That is the moment a backup is worth something, and it is exactly the moment most people discover theirs was never really there.

This guide covers every practical way to back up WordPress, what each one is good and bad at, and the four things that quietly break backups even when the plugin says "success." If you only remember one thing: a backup you have never restored is not a backup, it is a hope.

What a WordPress backup actually has to contain

A WordPress site is two things living together, and a real backup needs both:

• The files. WordPress core, your themes, your plugins, and everything in wp-content/uploads (images, PDFs, anything you or your users uploaded).
• The database. Every post, page, product, order, user, comment, and setting. This is the part people forget, and it is the part that matters most. You can reinstall a theme in two minutes. You cannot reinstall 4,000 WooCommerce orders.

A backup that has the files but not the database gives you an empty shell. A backup that has the database but not the uploads gives you a site full of broken images. You need both, captured at close to the same moment, or the two halves disagree about what the site looked like.

The three ways to back up WordPress

1. Host backups

Most decent hosts take a nightly snapshot of your account. It is the zero-effort option and worth having as a floor.

The catch is that host backups are for the host, not for you. They usually live on the same infrastructure as your site, so a hardware failure or a compromised account can take the backup with it. Restores are often all-or-nothing (the whole account, not one site), retention is short (7 to 30 days), and on cheaper plans "restore" means opening a support ticket and waiting. Treat host backups as a safety net you do not control, not as your backup strategy.

2. Manual backups (phpMyAdmin + FTP)

The old-school way: export the database from phpMyAdmin as a .sql file, and download wp-content (or the whole site) over SFTP.

It is free and it teaches you what a site is actually made of. But it is slow, it is easy to get wrong (forget the database and you have backed up nothing that matters), phpMyAdmin exports time out on large databases, and nobody keeps doing it by hand every week. Manual backups are fine for a one-off snapshot before a risky change. They are not a schedule you will actually keep.

3. A backup plugin

This is what most sites should use, because it solves the two things manual backups cannot: it runs on a schedule without you, and it sends the backup somewhere off your server automatically.

A good backup plugin handles the files and the database together, pushes them to storage you own, keeps a sensible number of restore points, and, crucially, can put the site back with one click. This is where the real differences between tools show up, and where the four things below start to matter.

The four things people get wrong

Picking a method is the easy part. These are the details that decide whether your backup is real.

Off-site storage is not optional

A backup that lives on the same server as your site is not a backup. If the disk dies, the account gets hacked, or the host suspends you, the backup dies with the site. The whole point is a copy that survives the thing you are protecting against.

That means the backup has to leave the server: Amazon S3, Google Drive, Dropbox, Backblaze B2, your own SFTP box, somewhere else entirely. Ideally storage you own, so nobody can meter it, lock you out, or delete it on their schedule. If your backup plugin only stores locally, or only to a vault the vendor controls, you are one bad day away from having nothing.

Incremental beats full-every-time

Most backup plugins re-package the entire site on every run. On a small blog that is fine. On a 20 GB media library or a busy store, it means every backup re-reads gigabytes that have not changed since yesterday, which is why so many backups crawl or time out on shared hosting.

Incremental backups only capture what actually changed since the last run. The first backup is full; after that, each one is small and fast. This is the difference between a backup that finishes in seconds and one you start and hope completes before the PHP process gets killed. If you have a real site, incremental is not a luxury, it is what makes a daily schedule survivable.

What actually happens on cheap hosting

Everything above is the standard advice, and you can find it on a dozen sites. Here is the part that usually is not measured.

We run Backup Arena, a public benchmark that puts eight WordPress backup plugins through the same runs: the same site snapshots, the same data, a discarded warm-up followed by three measured iterations, and the site reset to a verified snapshot between every single run. We build SafeGuard, which competes on it, and we say so on the site.

The part worth your attention is the hosting tiers. Every plugin runs on six of them, defined by hard container limits rather than adjectives:

On the constrained tiers, backup plugins do not get slow. They stop. Of the tier wins SafeGuard has recorded, 44 were decided by the other plugin failing to complete a backup or a restore at all on that tier, not by finishing sooner. That is the single most useful thing the benchmark has taught us, and it is invisible in every feature comparison table on the internet, because a plugin that dies at 70 percent still ticks the "backup" box on the marketing page.

The gaps are not marginal either. On the same site profiles, one widely used plugin averaged 47.1 seconds to restore where another took 3.9. Another averaged 18.7 seconds to back up against 6.7. Same hardware, same data, same day.

Two things follow, and neither is about which plugin you pick:

1. Test your backup on the hosting you actually have, not on your laptop and not on a staging box with four times the memory. A restore that works on a dedicated server and dies on 256 MB of PHP memory is not a working restore, and shared hosting is where most WordPress sites live.
2. Time the restore, not just the backup. The backup runs unattended at 3am and nobody watches it. The restore runs while the site is down and you are watching every second of it. Those are different numbers, and a plugin can be good at one and bad at the other. We are: SafeGuard backs up faster than six of the eight plugins tested and restores faster than five, so we lose some of these runs, and those results are published unchanged.

Every figure above links to the run that produced it, logs included, and the snapshots are downloadable so you can rerun any of it and check us.

The database will betray you on restore, not on backup

Here is the failure almost nobody sees coming, because it happens at restore or migration time, not backup time.

WordPress stores a lot of settings as serialized PHP arrays: theme options, widgets, menus, page-builder layouts, WooCommerce order data. Serialized strings carry a byte-length prefix:

s:23:"https://oldsite.com/foo"

That 23 is the length of the string. The instant you change a URL, a domain, or a table prefix with a naive find-and-replace, the text gets shorter but the 23 does not, PHP's unserialize() gives up, and the setting silently becomes empty. That is the mysterious "critical error" or missing widget people hit after a restore or a host move. A backup tool either understands serialization (unserialize, replace the leaves, re-serialize) or it corrupts your settings the moment you actually need the backup. There is no middle ground.

The other quiet one is character sets. Older sites are often utf8 (3 bytes per character); modern WordPress is utf8mb4 (4 bytes, needed for emoji and many scripts). Restore a utf8 dump into a utf8mb4 database without converting and multi-byte characters get truncated mid-byte. Good tooling detects the mismatch and converts. Most does not.

A backup you have never restored is Schrödinger's backup

This is the one that catches professionals. The plugin says "backup complete" every night for a year. Then the day comes, you click restore, and it fails: the archive is corrupt, the database dump is half-written, the restore runs out of memory at 70 percent, or the serialized data comes back mangled per the point above.

The only way to know a backup works is to restore it. Restore it to a staging site. Do it on purpose, when nothing is on fire, so that when something is on fire you already know it works. A backup strategy that has never been tested is a guess wearing a hard hat.

How often should you back up?

Match the frequency to how much work you would lose:

• Static or rarely-updated site (brochure, portfolio): weekly is plenty.
• Active blog or content site: daily.
• WooCommerce or any store, membership, or forum: real-time or hourly. Every order, signup, and payment between backups is data you cannot recreate. On a store, "we lost a day of orders" is not a footnote, it is money and angry customers. Stores are different enough to have their own backup guide.

The rule of thumb: your backup interval is the maximum amount of work you are willing to redo. Pick accordingly.

What "good" actually looks like

Putting it together, a backup setup you can trust:

1. Captures files and database, together.
2. Runs on a schedule you do not have to remember.
3. Sends every backup to storage you own, off the server.
4. Uses incremental runs so backups stay fast enough to actually finish.
5. Handles serialized data and character sets correctly, so restores and migrations do not corrupt settings.
6. Restores in one click, and you have tested that it does.

Get those six right and you never have to think about the afternoon the site goes down, because getting it back is boring instead of terrifying.

Where SafeGuard fits

We built SafeGuard because the popular plugins get some of that list right and quietly skip the rest, usually incremental backups and the serialization handling, and usually behind a paid add-on.

SafeGuard does the whole list on every plan: files and database, scheduled, incremental, pushed to any of 20+ storage providers you own (S3, Google Drive, Dropbox, Backblaze, SFTP, and more), with serialization-safe and charset-safe restores, one-click restore with an automatic pre-restore snapshot, and staging so you can test a restore without touching production. It is also the top-ranked plugin on Backup Arena, a public benchmark run on identical hardware, at a 76% win rate across more than 130 runs. The specific version rather than the flattering one: against the eight plugins it has been matched with, it backs up faster than six and restores faster than five. BackWPup and All-in-One WP Migration write a backup quicker; UpdraftPlus, WP Staging Pro and All-in-One recover quicker. Every one of those runs is published with its logs.

You do not have to take our word for the speed, the benchmark is public and reproducible. And right now the first 50 customers get a full year free, because we would rather have 50 people running it on real sites than a louder launch. If you have been meaning to fix your backups, that is a good reason to do it this week.