A working backup strategy pairs a full database export with every file WordPress needs, stores at least three copies across two media types with one kept offsite, and gets tested by an actual restore, not just a green tick in a dashboard. Do three things this week: build one labelled backup set, switch on automated offsite copies, and take a manual checkpoint before your next update or plugin change.
TL;DR:
- Restoring both the database and files in the correct order is crucial, with files restored before importing the database to prevent mismatches.
- Maintaining at least three copies across two different media types and with one stored offsite is essential to meet the 3‑2‑1 backup rule.
- Automated backups should be scheduled regularly based on site activity, with manual checkpoints before major updates or migrations.
- Backup credentials must be stored separately from the site and protected with immutability settings to prevent ransomware damage.
- Regular restore drills at least quarterly verify that backups are functional and can quickly recover the site without data loss.
Table of Contents
- What does a complete WordPress backup strategy actually include?
- How does the 3‑2‑1 rule apply to WordPress backups?
- How often should you back up your WordPress site?
- Which backup method suits your skill level?
- What is the correct order for restoring a WordPress backup?
- How do you know your backups will actually work?
- How long should you keep WordPress backups, and what about personal data?
- Your WordPress backup checklist by task frequency
- Why trust this WordPress backup guidance?
- What one bad update taught us about backups
- Let TTOY Digital handle your WordPress backups for you
- Sources
- FAQ
What does a complete WordPress backup strategy actually include?
Most site owners think they’re backed up because a plugin runs nightly. Then disaster strikes, and they discover the plugin only saved the database, or only the files, and half their site is unrecoverable. A genuinely complete backup has two separate components, and skipping either one leaves you with a partial safety net that fails exactly when you need it most, according to the WordPress Advanced Administration Handbook.
The database holds everything dynamic:
- Posts, pages, and revisions
- Users, roles, and passwords (hashed)
- Comments, categories, tags, and internal links
- Site settings and plugin configuration options
The files hold everything static and structural:
- WordPress core files
- The
wp-content/uploadsfolder, where every image and PDF lives - Themes and plugins
wp-config.php(database credentials) and.htaccess(server rules)
Database exports typically come as .sql, .gz, or .bz2 files, compressed because a busy WordPress database can run into hundreds of megabytes once you factor in comments and revision history. Treat the file copy and the database export as one backup set, labelled with a date, never as two loose, unrelated downloads sitting in different folders.
When you restore, order matters. Restore the files first, then import the database last, because the database import effectively replaces your entire current state, including anything created after your files were copied. Get that sequence backwards and you can end up with a live theme that doesn’t match the settings it’s trying to read.
How does the 3‑2‑1 rule apply to WordPress backups?
The 3‑2‑1 rule sounds abstract until you map it onto an actual WordPress setup, and then it becomes a checklist you can tick off in an afternoon.
Three copies. Your live site is copy one. A host‑level snapshot, the kind most managed hosts run automatically, is copy two. An independent cloud or offline copy that lives outside your hosting account entirely is copy three, and that third copy is the one people skip.
Two media types. Don’t let all three copies sit on variations of the same disk array. Pair cloud object storage (Amazon S3, Google Cloud Storage, or similar) with a local or offline disk, so a single storage failure or account compromise can’t wipe out everything at once.
One offsite. At least one copy needs to live somewhere with no shared login, no shared server, and no shared network with your hosting account. This is the copy that survives a hacked admin panel or a host outage.
Where your storage provider offers object lock or immutability settings, switch them on. This prevents a backup file from being altered or deleted for a set retention window, even by someone holding valid credentials, according to CISA’s StopRansomware guide.
Pro Tip: Never store your offsite backup credentials in the same password manager vault or admin account as your WordPress login. If an attacker gets one, they shouldn’t automatically get the other.
How often should you back up your WordPress site?
Frequency isn’t one‑size‑fits‑all. It should track how often your content actually changes and how much data you could stand to lose if something went wrong right now, a concept backup professionals call your recovery point objective.
- Brochure or portfolio sites that rarely change content need a full backup weekly, which matches WordPress’s own guidance on keeping several recent recovery points in rotation, per the Advanced Administration Handbook.
- Content‑driven blogs publishing several times a week should run daily automated backups, so a bad day never costs more than 24 hours of writing.
- High‑traffic commerce or membership sites, where orders and sign‑ups happen hourly, need at least daily backups and ideally more frequent database snapshots, since every missed order is a lost sale.
- Before any update, plugin install, or migration, take a manual checkpoint regardless of your regular schedule. WordPress’s own lesson plan on backups specifically flags this moment as the highest‑risk point in a site’s life cycle.
Retention matters as much as frequency. Keep somewhere between three and five recent backup points so you can roll back a few days if a problem goes unnoticed, and archive a monthly copy further out for longer‑term recovery. Write your retention rule down. “We keep two weeks of daily backups and six months of monthly archives” is a policy; “the plugin handles it” is a hope.
Which backup method suits your skill level?
There’s no single correct method, and most solid strategies actually combine two or three of the following, layered so a failure in one doesn’t take out the others.
- Managed host snapshots. Many hosting providers run automatic daily snapshots as part of their plan, but check the retention window and whether restoring pulls in only the database or the full file set too. Host backups are convenient, but they usually live on the same infrastructure as your live site, which is exactly the single point of failure the 3‑2‑1 rule exists to avoid.
- Backup plugins. A good plugin schedules backups automatically, pushes copies to a remote destination such as cloud storage, encrypts the file in transit, and offers a straightforward one‑click restore. Compare plugins on restore experience and where copies actually land, not just price, since a cheap plugin that only stores backups on your own server barely counts as a backup at all. TTOY Digital has written up what to look for in a backup plugin if you want a fuller comparison.
- Manual exports. phpMyAdmin, your host’s control panel, or a straight
mysqldumpcommand will export the database on demand. Pair that with an SFTP or rsync pull of your files, and you’ve built a backup set by hand, useful as a one‑off checkpoint or a sanity check on your automated system. - WP‑CLI. For anyone comfortable with a command line,
wp db exportpulls credentials straight fromwp-config.phpand can pipe output to STDOUT for scripted pipelines, according to the WP‑CLI documentation. It’s fast and scriptable, but it only handles the database, so it still needs a file copy alongside it.
If you’re migrating to new hosting, remember the fallback steps: recreate the database user, update the credentials in wp-config.php, and check file permissions on the new server. This is where most manual restores actually go wrong, not the transfer itself.
What is the correct order for restoring a WordPress backup?
Recovery under pressure is where good intentions meet bad sequencing. Follow this order and you’ll avoid the two mistakes that cause most botched restores.
- Restore the files first. Upload the WordPress core, themes, plugins, and the
wp-content/uploadsfolder to the server before touching the database. - Import the database second. Use phpMyAdmin, WP‑CLI, or your host’s tools to import the SQL file, remembering that this step replaces the site’s current state entirely, per the database backup guidance in WordPress’s developer resources.
- Update
wp-config.phpif the database name, username, or password has changed on the new server or account. - Verify on staging before going live. Check that uploaded images render, permalinks still resolve, user accounts log in correctly, and, on a store, that recent transactions match your payment processor’s records.
The most common pitfalls are worth naming outright: overwriting newer live data with an older backup because nobody checked the timestamp first, uploads folders that got skipped because they’re large and someone assumed the plugin covered them, table prefix mismatches when moving between hosts, and file permission errors that leave a restored site half‑working.
Pro Tip: Always restore into a staging copy or a temporary subdomain first. A restore that looks fine at a glance can still be missing images or have broken checkout, and you don’t want to discover that on your live domain.
How do you know your backups will actually work?
A backup you’ve never restored is a theory, not a plan. Regular restore drills, ideally quarterly, are the only way to know your files and database actually recombine into a working site, and to measure your real recovery time objective rather than guessing at it.
Ransomware changes the calculation further. Attackers increasingly target the backups themselves before triggering encryption, on the logic that a business with no clean copy is far more likely to pay, which is precisely why CISA’s StopRansomware guide recommends offline copies, delete protection, and immutable or object‑locked storage wherever it’s available.
Build resilience into the process itself:
- Encrypt backup files, both in transit and at rest.
- Use separate login credentials for your backup storage, never the same admin password as your WordPress site.
- Keep at least one copy genuinely offline or on immutable storage that ransomware reaching your server can’t touch.
- Limit who and what has access to backup storage, since a compromised plugin or staff account shouldn’t be able to reach your recovery copies too.
CISA’s own guidance is blunt on this point: convenience is the enemy of resilience, because the accessible backup is the one attackers go for first.
How long should you keep WordPress backups, and what about personal data?
Retention isn’t just a storage question, it’s a data protection one. If your site holds customer names, order histories, or enquiry form submissions, those backups contain personal data too, and the ICO’s guidance on data security expects organisations to handle that deliberately rather than indefinitely.
- Set a written retention period for backups, not an open‑ended “keep everything forever” default.
- If you delete or anonymise a customer’s data from your live site, your backup rotation should eventually age that copy out too, not preserve it forever in an old archive.
- Keep a record of your restore tests and dates. The ICO treats this as evidence that you could actually restore personal data within a reasonable time if asked, which matters if you’re ever assessed.
Your WordPress backup checklist by task frequency
Turning strategy into habit is the part most guides skip. Here’s the cadence that keeps a backup system from quietly failing without anyone noticing.
- Weekly: confirm the last scheduled backup job actually completed, check storage quota isn’t near its limit, and act on any expiry notifications from your cloud provider.
- Before every change: take a manual full checkpoint before updating plugins, themes, or WordPress core itself, or before any migration.
- Quarterly: run a full restore drill onto a staging environment and time how long it takes, per WordPress’s own recommendation to test backups periodically.
- Quarterly: audit who holds backup credentials and update your backup manifest, the simple record of what’s backed up, where, and how often.
Why trust this WordPress backup guidance?
This guide draws on WordPress’s own Advanced Administration Handbook, CISA’s ransomware guidance, and ICO data protection advice, translated into steps a small business can actually schedule. TTOY Digital runs WordPress maintenance for client sites day to day, and has covered related ground on common WordPress security issues and why backups matter elsewhere on the blog.
What one bad update taught us about backups
We once watched a routine plugin update lock a client’s site into a white screen mid‑afternoon. The only reason it wasn’t a crisis was a manual checkpoint taken twenty minutes earlier, restored in under ten minutes with zero data loss. The lesson stuck: always keep one offline copy, and never let your backup credentials live inside the same account as the site they’re protecting.
— Chris
Let TTOY Digital handle your WordPress backups for you
Reading through all of this, you can probably see where the time sink is. Building the backup set is the easy part; remembering to test it, rotate credentials, and take a checkpoint before every single update is where most small business owners quietly fall behind, usually right before something goes wrong. TTOY Digital’s WordPress Maintenance plan runs at a monthly fee per site and covers tasks including scheduled offsite backups, pre‑update checkpoints, quarterly restore drills, and credential management kept separate from your live site login, all handled by a locally based team. If your hosting is due a refresh too, UK Web Hosting plans are available; current prices are detailed on the provider’s website. Get in touch to talk through what your site actually needs, and we’ll set it running properly, then leave it to do its job.
Sources
- Backups, Advanced Administration Handbook
- StopRansomware guide (CISA)
- A guide to data security | ICO
FAQ
What is the best way to back up a WordPress site?
The best approach combines an automated backup covering both files and database with at least one manual checkpoint before major changes, stored following the 3‑2‑1 rule. No single method is sufficient alone; automation handles routine cover, while manual checkpoints catch the moments automation misses.
Why are some businesses moving away from WordPress?
Concerns usually centre on maintenance overhead, plugin conflicts, and update management rather than any core limitation of the platform itself. A disciplined backup and maintenance routine, such as TTOY Digital’s WordPress Maintenance plan, resolves most of these frustrations without switching platforms.
What is the best WordPress backup solution?
There’s no single best solution, since the right combination depends on your site’s traffic and complexity, but a solid setup pairs a scheduled plugin backup to remote storage with periodic manual exports via WP‑CLI or phpMyAdmin. Compare plugins on restore experience and where copies are stored, covered in TTOY Digital’s plugin selection guide, rather than choosing on price alone.
How can I back up my WordPress site for free?
Most hosts include some level of free snapshot backup, and you can supplement that with a manual database export via phpMyAdmin or wp db export through WP‑CLI, paired with an SFTP download of your files. This costs nothing beyond your time, though it lacks the automation and remote redundancy a paid plugin or managed maintenance service provides.
How often should I test my WordPress backup restore?
A quarterly restore drill onto a staging environment is a reasonable baseline for most small business sites. Higher‑traffic or transactional sites benefit from testing more frequently, since the cost of an untested backup failing during a real emergency far outweighs the time a drill takes.
