A WordPress Backup Strategy You Can Actually Restore From

Backups rarely fail on the day they are taken. They fail on the day of the restore: the archive is three weeks old, the database is missing from it, the only copy was on the server that just died, or nobody knows the steps. A WordPress backup strategy is judged by one thing, which is whether you can get the site back, complete and recent, in a time the business can live with.

So start from the restore and work backwards.

Two numbers to agree on before anything else

The first is how much data you can afford to lose, measured in time. If the answer is "a day", a nightly backup is enough. If losing an hour of orders would hurt, nightly is not a strategy.

The second is how long the site can be down while it is restored. A brochure site can usually wait until tomorrow. A store in the middle of a campaign cannot.

Write both numbers down and get the owner of the business to agree to them. Every later choice about frequency, storage and tooling follows from these two, and so does the cost.

What a complete backup contains

A WordPress site is two things, and a backup that holds only one of them cannot rebuild it.

• The database holds posts, pages, users, settings, orders, form entries and whatever tables your plugins created.
• The files are the wp-content folder (uploads, plugins, themes and must-use plugins), wp-config.php, .htaccess and anything else that lives in the site's root.

Uploads cannot be recreated, and neither can custom themes and plugins unless they also live in version control. WordPress core can be downloaded again, though including it makes a restore simpler. Leave out cache folders, logs and other backups, which only make the archive larger and slower to move.

Some things sit outside WordPress and get forgotten: DNS records, the email routing for the domain, scheduled jobs on the server and plugin license keys. Keep a note of them next to the backups.

For the database, take the export in a way that gives a consistent copy while the site is in use. With WP-CLI or directly with mysqldump:

wp db export backup.sql --add-drop-table
mysqldump --single-transaction -u DB_USER -p DB_NAME > backup.sql

The official WordPress backup documentation walks through the manual methods, including phpMyAdmin.

The 3-2-1 rule applied to a WordPress site

The rule is old and still right: keep three copies of your data, on two different kinds of storage, with one of them off-site. For a WordPress site that usually means the live site, a snapshot at the host and a copy in separate cloud storage.

The host's snapshot is the fast way back when an update goes wrong. It does not help if the hosting account is suspended, the provider has an outage or an attacker gets into the account. The off-site copy covers those cases, so it should sit with a different provider under a different login.

Three details make the off-site copy trustworthy:

• Do not leave archives inside the web root. A backup plugin that writes to a folder under wp-content has produced a file containing your database, and anyone who finds its address can download it. Treat that folder as a staging point for the upload, not as the backup.
• Give the site credentials that can add to the storage but cannot delete from it, where the storage service supports that. A compromised site should not be able to erase its own history.
• Encrypt archives that leave the server. They contain customer data and the database password.

How often to back up, by type of site

Site	Database	Files	Why
Brochure site edited now and then	Weekly, and before every update	Weekly	Little changes between edits
Blog or news site with daily posts	Daily	Daily	New posts and images every day
Lead generation site with forms	Daily or more often	Weekly	Form entries may exist only in the database
Store, booking, membership or learning site	Hourly or continuous	Daily	Orders, bookings and progress arrive all day

Files change far less often than the database on most sites, so the two do not need the same schedule. Incremental backups, which copy only what changed since the last run, keep frequent schedules affordable on sites with large media libraries. Whatever the schedule, take a manual backup before any update or migration, and keep it until the change has proved itself.

Retention: keep more history than feels necessary

Seven daily copies sound generous until you discover that malware was planted three weeks ago, or that an import quietly damaged product data last month. Problems like these are often noticed late. If your oldest backup is younger than the problem, every copy you own contains it.

A workable pattern is daily copies for two to four weeks, weekly copies for a few months and monthly copies for a year. Adjust it to your two numbers and your storage budget.

Retention has a privacy side as well. Backups hold personal data, and a customer you deleted from the live site still exists in last month's archive. How long you may keep backups, and how deletion requests apply to them, depends on the law where you and your customers are. That is a question for your own counsel, and the answer belongs in your written policy.

Stores and course sites: the gap between backups

On a transactional site, restoring last night's database erases today's orders, new accounts and lesson progress, while the payments for those orders were still taken. Plan for that gap before you need to.

• Shorten it. Hourly database backups, a real-time backup service or point-in-time recovery from the host reduce the loss from a day to minutes.
• Restore only what broke. If a bad update or infected files are the problem, restore the files and leave the database alone.
• Export before you overwrite. Put the site in maintenance mode and export the current database, even if it is damaged. Orders placed since the backup can be recovered from that export later.
• Reconcile afterwards. Your payment provider's dashboard is an independent record of what was paid. Compare it with the restored orders, then check stock levels and scheduled subscription renewals before reopening.

The store-specific risks around this are covered in our guide to WooCommerce security, and if you need help designing the recovery process for a busy shop, that is part of our WooCommerce development work.

Run a restore drill

1. Pick a backup that is a week or two old, not the newest one.
2. Restore it to a staging site or a password-protected subdomain. Never practice on the live site.
3. Put the files in place first, then import the database, then update the database details in wp-config.php. If the address differs, change it with wp search-replace.
4. Before anyone logs in, stop the copy from sending email or charging renewals. A restored store will otherwise act on real customers.
5. Check it: log in, open a recent post, look at images, submit a form, place a test order with the gateway in test mode.
6. Time the whole thing and write the steps down on one page, with where the credentials are kept.

Drills tend to expose the same faults. Archives are incomplete because the backup timed out on a large site. A table with a different prefix was skipped. The off-site storage login belongs to someone who left. The download alone takes longer than the downtime you agreed to. Each one is easy to fix on a quiet afternoon and very hard to fix during an outage. Repeat the drill twice a year and after any change of hosting.

Running a WordPress backup strategy yourself, or handing it over

For a small site, host snapshots plus one scheduled off-site backup and a drill every six months is a sound setup, and an owner can run it. It becomes a job to hand over when the site is large enough that plugin-based backups time out, when a store needs hourly or point-in-time recovery, when several environments have to stay in step, or when nobody on the team has the time to run the drills. Scheduled backups, restore tests and a written recovery process are a core part of a WordPress maintenance plan, alongside the routine in our pre-update checklist.

Frequently asked questions

Are my hosting company's backups enough?

They are a good first copy and often the fastest to restore. Ask the host how long backups are kept, whether the database is included, where they are stored and how a restore is requested. Then keep a second copy that you control, because a host backup is no use when the problem is the hosting account itself.

Can I use a staging site as a backup?

No. Staging usually lives on the same server, is overwritten whenever someone refreshes it and holds old data in between. It is a place to test changes and practice restores, not a copy you can rely on.

How long does it take to restore a WordPress site?

It depends on the size of the site and the method. A host snapshot can be back in minutes, while downloading and importing a large media library and database can take hours. The only reliable answer for your site is the time you measured in your last restore drill.

Do I need a backup plugin if my host takes snapshots?

You need an off-site copy from somewhere. A plugin that sends scheduled backups to separate storage is the common way to get one, and some hosts offer the same as an option. What matters is that the second copy is with another provider and that you have restored from it at least once.