WordPress Backup: the 3-2-1 Strategy and How to Set It Up

WordPress backup requires three steps: regular database backup (daily), wp-content/ file backup (weekly), and storing at least one copy offsite - away from the server your site runs on. The industry standard is the 3-2-1 strategy: three copies of data on two different media, with one copy offsite. A backup stored only on the same server as your site is useless if that server fails. For a complete guide to WordPress site management including updates, monitoring and security, see WordPress Site Management in 2026.

Why WordPress backup is not optional

Every site will eventually face a situation where restoring from backup is the only way forward. Causes include hardware failure, ransomware or security incidents, a broken plugin update, human error when editing the database, or accidentally deleting content. The question is not whether this will happen, but when - and whether you have a backup that gets you back online within an hour.

The security context is relevant: in 2025, a record 11,334 new vulnerabilities were discovered in the WordPress ecosystem, and the median time from disclosure to first active attack dropped to five hours - see WordPress Security in 2026: 10-Point Checklist for a detailed breakdown. A backup is the last safety net when all other security layers fail.

A common misconception: "my web host backs up automatically." Hosting backups are infrastructure backups - retention periods, granularity, and restore availability vary widely between providers, and getting a restore can take hours or days. Your own offsite backup is the answer.

What to back up: a complete WordPress inventory

A complete WordPress backup consists of two independent parts: the database and the files. Restoration only works when you have both. Losing one without the other leaves you with an incomplete site or a broken installation.

MySQL database

The database contains all your site's content and settings: posts, pages, comments, plugin settings, user accounts and passwords, widgets, WooCommerce orders, products and customers. It is the dynamic part of your site - it changes with every new post, order or registration. Back it up most frequently.

Site files

• wp-content/ - the directory containing your themes, plugins, uploaded media (images, documents, videos) and mu-plugins. The core of your installation. Without this directory you lose your visual design, functionality and all media.
• wp-config.php - the configuration file with database credentials, security keys and the table prefix setting. Without it, WordPress cannot connect to the database.
• .htaccess (on Apache servers) or the equivalent nginx configuration - contains redirect rules, security headers and permalink structure.

What you do not need to back up: WordPress core files (wp-admin/, wp-includes/, index.php, wp-login.php and so on) can be downloaded from wordpress.org and reinstalled at any time. Backing up core files just makes archives larger without adding value.

WordPress backup: the 3-2-1 strategy in practice

The 3-2-1 strategy is the industry standard for WordPress just as it is for any critical business data. Its strength lies in its simplicity: even if one protection layer fails, two others remain.

• 3 copies of data - the live site (original) plus two separate backups. One backup is not enough - a backup can be corrupted or contain the same problem as the original (for example, if the backup ran after a malware infection).
• 2 different media or locations - all backups on the same server are effectively one backup, not two. Combine a server backup with a cloud storage backup.
• 1 copy offsite - this is the safety net for server hardware failure or data center outages. Cloud storage, a remote FTP server, or another cloud solution outside your hosting provider.

Where to store offsite backups

Three common categories of external backup storage for WordPress sites:

• Cloud object storage (e.g. Amazon S3, Backblaze B2, Cloudflare R2) - inexpensive, reliable, well-suited to automated backups. A backup plugin sends zip files directly to a bucket. Prices are typically cents per GB per month.
• Cloud sync storage (Google Drive, Dropbox) - easier to set up; most WordPress backup plugins support them out of the box. Free plans have limited space; longer retention requires a paid tier.
• Remote FTP/SFTP server - your own server in a different location or with a different provider. Higher maintenance overhead but full storage control.

Practical recommendation: start with cloud sync storage for the first layer of offsite backup. It is quick to configure and most backup plugins support it without additional setup. When your backups grow (large stores, many media files), switch to cloud object storage, where pricing is more cost-effective at scale.

Backup frequency by WordPress site type

Not all sites need the same backup frequency - it depends on how quickly data grows and how much you would need to reconstruct after a loss.

Site type	Database backup	File backup	Recommended retention
Business site with static content	Daily	Weekly	30 days
Blog with regular publishing	Daily	Weekly	30 days
E-commerce with active orders	Every 4 - 6 hours	Daily	60 days
Site with registrations and forms	Daily	Weekly	30 days
Before any major update	Immediate manual backup	Immediate manual backup	In addition to regular schedule

For e-commerce sites, database backup frequency is critical: every order, every payment, every customer account lives exclusively in the database. A daily backup means losing all transactions since the last backup in a failure. For active stores this can be dozens of orders. That is why we set database backups to run multiple times per day for e-commerce.

How to test your backup before it is too late

A backup you have never tried to restore is just a file. A real backup is one you know works - verified by a test restore.

In practice we find that site owners set up backups years ago but never verified that the backups actually ran or that a restore is possible. Common failure scenarios: the backup plugin was deactivated during a plugin cleanup and backups silently stopped; cloud storage hit its limit and new backups were not saved; the backup archive is corrupted due to an interrupted upload.

Test restore procedure (at least once per quarter)

1. Verify that backups are running. Check the date and size of the most recent backup in your cloud storage. A zero-byte file or a stale date are warning signs.
2. Prepare an isolated test environment. A local WordPress installation or a staging subdomain. Never restore directly to production without verification.
3. Import the database backup. Use phpMyAdmin or WP-CLI to import the SQL dump into a clean database on the test environment.
4. Extract and copy files. wp-content/ and wp-config.php from the archive to the test environment. Make sure wp-config.php points to the test database.
5. Verify functionality. Walk through key functions: homepage, navigation, contact form, and for e-commerce the cart and a product page. Confirm that media files display correctly.
6. Record the result. If the restore completes without issues, the backup is functional. If not, fix the backup configuration now - not when a real incident hits.

Common WordPress backup mistakes

Managing sites, we see the same backup mistakes repeatedly. Here are the ones that cause the most damage when things go wrong:

• Backup only on the same server. If the server physically fails or ransomware encrypts it, any backup stored there is inaccessible. External storage offsite is a necessity, not a luxury.
• Database backup without files. A database without wp-content/ means you recover the content but lose the theme, plugins and all uploaded media.
• Forgotten wp-config.php. Many backup solutions do not automatically include wp-config.php. Without it, WordPress cannot connect to the database and the restore stops at an error page.
• Retention period too short. Some threats (e.g. low-and-slow malware injections) surface weeks later. Backups only 7 days old may not contain a clean pre-infection state.
• Backup never tested. Configuring a backup and verifying that a restore works are two different things. Only a test restore reveals whether the backup actually works.
• Backup as a one-time task. Backup configured but never checked - plugin deactivated, cloud storage limit hit, or storage credentials expired. Backup requires regular monitoring, not just one-time setup.

WordPress backup: what we include in managed hosting

For every site we manage, backup is an integrated part of the monthly routine - not an add-on. In practice this means: daily automated database backup written to external cloud storage offsite, weekly wp-content/ and wp-config.php backup, a manual backup before every major update, and a test restore once per quarter on a staging environment.

The result is straightforward: in a failure, we can restore the site in under an hour, not days. And the client receives confirmation that the backup ran - not just a promise that "we do backups." If you want WordPress management at this standard for your site, see Denva support and care.

Custom web applications and e-commerce stores built on a custom codebase or after a migration have stricter backup requirements - for further context see Migration from Elementor to a clean WordPress theme, where pre-migration backup plays a key role.

Conclusion

WordPress backup is not a one-time task - it is an ongoing routine with clear rules: what to back up, where to store it, how often, and how to verify that the backup actually works. The 3-2-1 strategy is a proven framework that covers most real-world failure scenarios. A backup you have never tested is not a backup.

If you want backup and overall WordPress management handled without technical overhead, Denva support and care includes a complete backup plan with test restores included. Or reach out directly - a no-obligation consultation is free.

FAQ

Frequently asked questions.

Is hosting backup sufficient?

Not always. Hosting backups are infrastructure backups - retention period, granularity and restore availability vary between providers, and getting a restore can take hours or days. Your own offsite backup under your control and with verified retention periods is the standard for any business website.

How much storage does a WordPress backup use?

It depends on media size and number of plugins. A typical business site has a database in the tens of MB and wp-content/ in hundreds of MB to a few GB. An e-commerce store with a large product catalog can have wp-content/ exceeding 10 GB. Most backup plugins support compression, which significantly reduces archive size.

What happens if I lose both the backup and the primary server?

That is exactly why the 3-2-1 rule exists: one backup must always be offsite - in cloud storage or on a remote server with a different provider. If you lose the on-server backup and the server itself simultaneously, the offsite copy remains untouched.

How long should I keep backups?

At least 30 days for a typical business site, 60 days for an e-commerce store. A shorter retention period can be problematic with a malware infection that surfaces weeks later - backups from before the infection need to remain available.

Can I set up WordPress backup without technical expertise?

Basic backup via a dedicated WordPress backup plugin is configurable without technical experience. What most site owners struggle with is the ongoing monitoring - verifying that backups are actually running - and performing test restores, which require some familiarity with WordPress administration.