WordPress Backup Strategy: How to Recover from Any Attack

No security system is perfect. Even with malware scanning, firewalls, and 2FA in place, determined attackers sometimes get through. When that happens, a solid backup strategy is the difference between a 2-hour recovery and a week-long disaster. Having clean backups ready is a critical part of any incident response plan.

The 3-2-1 backup rule

The industry standard for backup strategy is 3-2-1:

• 3 copies of your data
• 2 different storage media or locations
• 1 offsite copy (somewhere completely separate from your server)

For WordPress, this typically means:

• 1 copy on the server (current state)
• 1 copy in cloud storage (Dropbox, Google Drive, AWS S3)
• 1 copy as a local download on your computer or NAS

What a complete WordPress backup includes

A backup that doesn't include everything is worthless for disaster recovery. A complete backup contains:

📦 backup-2025-03-10.zip
├── database.sql          ← All WordPress data
├── wp-config.php         ← Database credentials, secret keys
├── .htaccess             ← Rewrites, security rules
├── wp-content/
│   ├── plugins/          ← All installed plugins
│   ├── themes/           ← All themes
│   └── uploads/          ← All media files
└── manifest.json         ← Backup metadata

Note: WordPress core files (wp-admin/, wp-includes/) are intentionally excluded — they can always be reinstalled fresh from WordPress.org.

WO Security Shield's backup system

WO Security Shield includes a built-in backup manager with:

Scheduled backups: Configure automatic backups daily, weekly, or after significant events. Backups run as background processes and don't slow down your site.

Remote destinations: Upload backups automatically to:

• FTP/SFTP server
• Dropbox
• Google Drive

Retention policy: Keep the last N backups (default: 10). Older backups are deleted automatically to manage storage.

Backup from the dashboard: Trigger a new backup remotely from your WO Security Shield dashboard without logging in to WordPress.

Recovery process

Full site recovery from backup

1. Download the backup ZIP from your storage destination
2. Extract to a clean hosting environment
3. Create a new database and import database.sql
4. Update wp-config.php with new database credentials
5. Upload the file tree to your server
6. Visit your WordPress admin and run the database upgrade if prompted

Database-only recovery

If only your database was compromised (e.g., a SQL injection attack that modified content):

1. Export the malicious wp_options values you want to remove
2. Import a clean database.sql from a known-good backup
3. Re-apply any legitimate changes made since the backup (new posts, orders, etc.)

Testing your backups

A backup you've never tested is a backup that might not work when you need it most. Set a quarterly reminder to:

1. Download your most recent backup
2. Spin up a staging environment (Local by Flywheel, WP Engine staging, etc.)
3. Restore the backup to staging
4. Verify your site loads and functions correctly

This also verifies that your backup process is actually running and producing valid archives.

Don't back up to the same server

Storing backups in /wp-content/uploads/wss-backups/ (the default location) is convenient but risky. If the server is compromised, the attacker can access or delete your backups.

WO Security Shield stores backups locally by default (protected by .htaccess) but strongly recommends configuring a remote destination immediately after enabling backups.

---

For a step-by-step guide on recovering from an attack using your backups, see how to clean a hacked WordPress site. Set up automated backups with remote storage today at wosecurity.com.

The 3-2-1 Backup Rule for WordPress

The gold standard backup strategy follows the 3-2-1 rule:

• 3 copies of your data
• 2 different storage types
• 1 off-site location

For WordPress, this translates to:

Copy	Storage type	Example
Live site	Server SSD	Your hosting provider
Local backup	Server storage	/wp-content/uploads/wss-backups/
Remote backup	Cloud storage	Amazon S3, Google Drive, Dropbox

What Must Be Included in Your Backup

A complete WordPress backup contains two parts:

1. Files:

• /wp-content/ — your themes, plugins, uploads, and custom code
• wp-config.php — your database credentials and security keys
• .htaccess — your rewrite rules and server configuration
• Any custom files outside the standard WordPress structure

2. Database:

• All WordPress tables (wp_posts, wp_options, wp_users, etc.)
• WooCommerce order data (if applicable)
• Custom plugin tables

Missing either part makes your backup useless. A file-only backup without the database loses all your content. A database-only backup without files loses your theme, plugins, and media library.

Backup Frequency Based on Site Type

Site type	Recommended frequency	Why
Static brochure site	Weekly	Content rarely changes
Blog (1-2 posts/week)	Daily	New content needs protection
WooCommerce store	Every 6 hours	Orders and customer data change constantly
Membership site	Every 6 hours	User-generated content and subscriptions
High-traffic news site	Hourly	Content published multiple times per day

Testing Your Backups

A backup you've never tested is not a backup — it's a hope. Test your recovery process:

1. Download a backup to your local machine
2. Set up a local WordPress environment (Local by Flywheel, MAMP, or Docker)
3. Import the database and copy the files
4. Verify the site loads and content is intact
5. Document the process so you (or your team) can do it under pressure during an actual incident

Do this at least once per quarter. The worst time to discover your backup process is broken is during an active compromise.

Disaster Recovery Checklist

When disaster strikes, follow this order:

1. Don't panic — if you have backups, your data isn't lost
2. Document the current state — screenshots, error messages, file timestamps
3. Identify the type of incident — hack, host failure, accidental deletion, or failed update
4. Choose the right recovery point — the most recent backup before the incident
5. Restore to a staging environment first if possible — verify the backup is clean
6. Restore to production once you've confirmed the backup works
7. Run a full security scan after restoration
8. Change all passwords — especially if the incident was a security breach