A single server failure, a botched plugin update, or a malware infection can wipe out years of content in minutes. The only reliable protection against catastrophic data loss is a recent, tested backup stored somewhere separate from the hosting server. WordPress backups are not optional for any site that matters — but the backup system must be correctly configured, regularly verified, and actually tested to confirm restoration works before it is needed in an emergency. We go deeper on the whole subject in our Complete Guide to WordPress How.
WordPress Backups — What Needs Backing Up
A complete WordPress backups set has two components: the database and the files. Missing either component leaves the backup incomplete and potentially unusable for full site restoration.
The WordPress database (typically named something like your_site_db) contains: all post content and revisions, all pages, all user accounts and their metadata, all plugin settings stored in wp_options, all custom field values in wp_postmeta, all comments, all category and tag assignments, and all theme customiser settings. The database is the site’s content — without it, a file restore produces a working WordPress installation with no content. The WordPress files include: wp-config.php (database credentials, security keys, custom constants), the wp-content/ directory (plugins, themes, uploaded media, cache files), and optionally the WordPress core files (though these can be re-downloaded from WordPress.org). The uploaded media files (wp-content/uploads/) are particularly important — they are the only non-reproducible file content. WordPress core and plugin files can always be re-downloaded; uploaded images, videos, and documents cannot be recovered from any source other than a file backup or the original upload source.
What can be excluded from WordPress backups to reduce backup size: wp-content/cache/ (caching plugin data that regenerates automatically after a restore), wp-content/backups/ (avoid backing up backup files within backups), and large log files. WordPress core files (wp-admin/, wp-includes/, and the root PHP files) can be excluded if the backup solution allows downloading fresh core files during restoration — UpdraftPlus and many other backup plugins offer this option. On a typical WordPress site, the full backup including media and excluding cache is 200MB–5GB depending on media volume. According to the WordPress official backup documentation, a complete site restoration requires both the database export (SQL file) and the wp-content directory — either component alone is insufficient for a full restoration.
Setting Up UpdraftPlus for Automated Backups
UpdraftPlus is the most widely used WordPress backups plugin with over 3 million active installations. The free version provides everything most sites need: scheduled automatic backups, remote storage to Google Drive, Dropbox, Amazon S3, or other services, and one-click restoration from within the WordPress admin.
Install UpdraftPlus — the leading WordPress backups plugin → Settings → configure the schedule: set “Files backup schedule” to Daily and “Database backup schedule” to Daily → set “Retain backups” to 7 (keeping one week of daily backups) → choose remote storage. For Google Drive storage: click the Google Drive button → authorise the UpdraftPlus Google Drive access → a folder named “UpdraftPlus” is created in Google Drive and all backups go there automatically. For Dropbox, Amazon S3, or other services, the configuration is similar — each requires credentials or authorisation from the respective service. After configuring remote storage, click “Backup Now” to create the first backup immediately → verify the backup files appear in the remote storage location before relying on the scheduled backups. The backup is only as reliable as the remote storage connection — always confirm the first backup uploads successfully.
Configure UpdraftPlus WordPress backups to exclude unnecessary directories: Settings → Files to exclude → add wp-content/cache, wp-content/backups, and any custom directories that contain generated or temporary files. This reduces backup file size and upload time without losing any essential content. Enable “Database encryption” with a passphrase for sensitive sites — this encrypts the SQL backup file before uploading to remote storage, protecting database contents including user emails, order data, and personal information from exposure if the remote storage account is compromised. Store the encryption passphrase separately from the backup location — in a password manager, not in a note in Google Drive alongside the backup files. Our guide on WordPress GDPR compliance covers the personal data protection requirements that make backup encryption particularly important for sites storing customer or user personal data.
Testing WordPress Backup Restoration
Untested WordPress backups are unreliable — a restore test on staging is essential for restoration is not a backup system — it is a hope. Backup files can be corrupt, remote storage connections can fail silently, database exports can be truncated, and restoration procedures can fail in ways that are only discovered when they are needed in an emergency. Testing restoration on a staging or local environment before a crisis provides the confidence that backup and recovery procedures actually work.
Test WordPress backups restoration with UpdraftPlus: create a fresh WordPress installation on a subdomain or local environment → install UpdraftPlus → Settings → UpdraftPlus → Existing Backups → Connect to your remote storage → find the backup set to restore → click Restore → select which components to restore (database, plugins, themes, uploads) → Restore. A successful restoration confirms the backup files are intact and the restoration procedure works correctly. Test at least quarterly for sites without major content changes, and after every significant change (major WordPress update, new plugin installation, major content import) for active sites. The restoration test also familiarises administrators with the restoration procedure — performing it for the first time during an actual outage under stress produces mistakes that a familiar procedure eliminates.
A post-restoration checklist confirms WordPress backups quality ensures the restored site functions correctly: verify the homepage loads correctly, log into the admin with the restored credentials, check that the most recently published post is present (confirming the backup was current enough), verify all plugins are active and functioning, test the contact form and any checkout flows, and check that the domain’s SSL certificate is still valid (restoration to a different domain requires SSL reconfiguration). For WooCommerce restorations specifically, test a complete checkout with a test order — payment gateway credentials in the database may need to be re-entered if they were stored in an encrypted format that did not survive the restoration. Reviews from UpdraftPlus’s documentation recommend testing restoration at least twice per year and before any major site changes, with the test performed on a separate environment rather than overwriting the production site to confirm restoration functionality.
Backup Strategies for Different Site Types
WordPress backups frequency and retention strategy depends on how often the site’s content changes and how much data loss is acceptable in a worst-case recovery scenario.
Brochure sites: weekly WordPress backups with 4-week retention is adequate with 4-week retention is adequate. The site changes slowly and weekly backups ensure at most one week of updates need to be re-entered after a restore from the most recent backup. Active blogs updating daily: daily database backups with 14-day retention, weekly file backups (files change less frequently than database content). WooCommerce stores processing daily orders: daily or twice-daily database backups with 30-day retention — orders, customer data, and inventory are in the database and losing a day of orders is potentially catastrophic. Membership sites: daily database backups (member accounts, subscription status, access records are all in the database), with the understanding that payment processor subscription records are stored externally and survive WordPress data loss without database backups.
Real-time replication supplements WordPress backups (not replacement) is available through services like BlogVault, JetBackup, and managed host backup systems (Kinsta, WP Engine, Cloudways all include daily automated backups with 14–30 day retention). These managed backup services run at the server level rather than through WordPress, capturing database changes as they occur rather than on a fixed schedule. For high-traffic WooCommerce stores where even 6 hours of order data loss is unacceptable, real-time replication combined with daily UpdraftPlus backups provides both point-in-time recovery (from real-time replication) and off-site archive retention (from UpdraftPlus remote storage). The redundancy between two independent backup systems is worth the modest additional cost for sites where the data is irreplaceable or represents significant revenue.
Manual Backup Methods — phpMyAdmin and FTP
Manual WordPress backups use phpMyAdmin for the database and FTP for the files. Understanding these methods provides both a fallback when plugins are unavailable and a deeper understanding of what backup plugins do automatically.
Manual database backup: cPanel → phpMyAdmin → select the WordPress database → Export → Quick export method → SQL format → Go. The browser downloads a .sql file containing all WordPress database tables and their data. This file can be imported via phpMyAdmin → Import → select the SQL file → Go, on any MySQL server. For large databases (over 512MB), phpMyAdmin’s web-based export may time out — use phpMyAdmin’s “Custom” export method with chunked export, or use mysqldump via SSH: mysqldump -u username -p database_name > backup.sql.
Manual file backup: connect to the server via FTP → navigate to the WordPress root directory → download the wp-content/ folder and wp-config.php to a local computer. The wp-content/ download includes plugins, themes, and uploads. Large media libraries make manual WordPress backups via FTP impractical — create a ZIP archive of wp-content/ on the server (cPanel → File Manager → compress) and download the single ZIP file. After any manual backup, verify the files are accessible and the SQL file is non-empty before deleting the source or relying on the backup for recovery. Manual WordPress backups are reliable when correctly executed but require manual effort each time — automated plugin-based backups with remote storage are more practical for ongoing protection and are strongly preferred over manual methods for routine backup schedules. Our guide on diagnosing WordPress site down events covers the backup restoration as the recovery path for severe site failures where targeted fixes are not viable, making a current, tested backup the most important preparation for any potential site emergency.
Version-controlled WordPress backups for theme and plugin code use Git rather than file-based backup plugins. A Git repository tracking the child theme, custom plugins, and any other custom code provides complete version history with per-commit rollback capability that is more granular than daily backups. Store the repository on GitHub, GitLab, or Bitbucket — all provide free private repositories. The Git backup covers only custom code (not the database, not media files, not WordPress core or third-party plugins) but provides the most detailed and reliable protection for the code assets that represent the most developer effort and that are not stored anywhere else. Combine Git version control for custom code with UpdraftPlus for database and media backup to create a comprehensive backup strategy that protects every type of WordPress site asset with the appropriate backup mechanism for each type.
Backup verification beyond restoration testing includes checking backup file integrity: UpdraftPlus provides an MD5 checksum for each backup file that can be verified to confirm the file was not corrupted during transfer to remote storage. The checksum is shown in the Existing Backups list next to each backup set. Verifying checksums monthly (or after any backup that took significantly longer than usual) catches corrupted backup files before they are the only available restore point after a site failure. A backup file that fails checksum verification is useless for restoration — discovering this during a routine check rather than during an emergency recovery provides time to create a new clean backup without the pressure of a live site outage requiring immediate action. Implement WordPress backups monitoring by setting up email alerts for failed UpdraftPlus backup jobs: UpdraftPlus sends an email notification when a scheduled backup fails, allowing the issue to be investigated and resolved before the next scheduled backup window rather than discovering a weeks-long backup failure during an emergency.
Migrating WordPress sites using WordPress backups as the migration vehicle — creating a full backup of the source site and restoring it to the destination — is a practical alternative to dedicated migration plugins for straightforward moves. The UpdraftPlus migration process: create a full backup on the source → copy the backup files to the destination server (or download then re-upload) → install a fresh WordPress on the destination → install UpdraftPlus → Settings → Existing Backups → scan the backup location → restore. The restoration process handles database import and file extraction; the remaining manual steps are updating the WordPress home URL and site URL in wp-config.php or via phpMyAdmin to match the new domain. This backup-as-migration approach works reliably for same-hosting-type migrations (cPanel to cPanel, Linux to Linux) and produces identical site states without requiring specialised migration knowledge beyond the standard backup and restoration procedure.
Regulatory requirements affect WordPress backups retention periods for sites in specific industries: HIPAA (healthcare) requires audit trails and data retention for up to 6 years; PCI DSS (payment card data) requires 12 months of logs; GDPR requires that personal data is not retained longer than necessary but also that it is recoverable if needed for legal obligations. For most WordPress sites, 30-day rolling backups with a monthly archive kept for 1 year balances practical recovery needs against storage costs. Consult legal counsel for industry-specific retention requirements that may require longer backup retention than the standard UpdraftPlus default of 2–7 backup sets. Store long-term archive backups in cold storage (Amazon S3 Glacier, Google Cloud Archive) at a fraction of standard storage costs to make multi-year retention economically practical without consuming expensive hot storage. You might also run into How to Fix WordPress Cron Not Running Safely With a Proven Reliable Method.
