What Does a Complete WordPress Backup Include?
A typical WordPress website consists of two principal parts: website files and the database. WordPress’s official administration guidance states that both are normally required to restore a complete site.[1]
WordPress files
The website’s files may include WordPress core files, themes, plugins, uploaded images and documents, custom code, configuration files, server rules and language files. The wp-content directory is particularly important because it generally contains themes, plugins and uploaded media. The wp-config.php file may also contain important database and website configuration information.[3]
The WordPress database
The database normally stores pages, blog posts, comments, user accounts, website and plugin settings, menu structures, product information, orders, customer records and form-related data. WordPress provides separate guidance for exporting and restoring its database.[2]
Why both components matter
A files-only backup may recover themes, plugins and images but omit recent posts, settings, customers or orders. A database-only backup may recover content and settings but omit uploaded images, custom themes or plugin files. For most websites, a full recovery requires compatible copies of both components from approximately the same point in time.
What Is Backup Frequency?
Backup frequency means how often a new backup is created. Common schedules include monthly, weekly, daily, every 12 hours, every six hours, hourly and real-time or near-real-time.
The correct frequency depends on how often important information changes. The main question is: How much recent data could the website afford to lose?
If a daily backup runs at midnight and the website fails at 11:00 pm, restoring the most recent copy could remove almost a full day of changes. For an ecommerce website, that could mean losing orders, new accounts, stock changes, customer messages, product updates and reviews.
Suggested Backup Frequencies by Website Type
The following are practical editorial guidelines rather than fixed technical requirements.
| Website type | Possible starting frequency | Main concern |
|---|---|---|
| Small static brochure website | Weekly or daily | Content and configuration changes |
| Frequently updated business site | Daily | Page edits, forms and plugin settings |
| Active blog or publication | Daily or several times daily | New articles, comments and editorial work |
| Lead-generation website | Daily or more frequently | Enquiries and form data |
| Small WooCommerce store | Every few hours | Orders, customers and stock |
| Busy ecommerce website | Hourly or near-real-time | Continuous transactional data |
| Membership website | Hourly or several times daily | Accounts, subscriptions and user activity |
| Booking platform | Hourly or near-real-time | Reservations and availability |
| Development website | Before significant changes | Code, configuration and database changes |
What Is Backup Retention?
Backup retention means how long old backup copies remain available before they are deleted. Retention matters because some problems are not discovered immediately, including malware, database corruption, deleted content or a broken form.
The UK National Cyber Security Centre advises retaining backups for a period of time rather than relying on a single rolling copy.[7]
How Much Retention Does a Website Need?
There is no universal retention period. A useful policy may combine frequent recent backups, daily backups for several weeks, weekly backups for several months and monthly archival backups.
| Backup type | Frequency | Example retention |
|---|---|---|
| Transactional backup | Every hour | 24–72 hours |
| Daily backup | Once per day | 14–30 days |
| Weekly backup | Once per week | 8–12 weeks |
| Monthly archive | Once per month | 6–12 months |
Frequency and Retention Are Different
Frequency tells you how often a copy is created. Retention tells you how long it remains available. Always evaluate both features together.
Full, Database and Incremental Backups
| Type | What it contains | Main consideration |
|---|---|---|
| Full | All selected files, database and configuration | Clearer recovery but greater storage and processing |
| Database-only | WordPress database | Useful for changing content or transactions, but not a complete site copy |
| File-only | Website files | Useful before code or configuration changes, but omits database data |
| Incremental | Changes since a previous backup | Reduces storage and transfer time but relies on linked backup components |
Kinsta describes its managed WordPress backups as snapshots including files, database, redirects and relevant server configuration. This is one provider’s implementation rather than a universal definition.[12]
Where Are WordPress Backups Stored?
Backups may be stored on the hosting server, elsewhere on the hosting platform, in another data centre, in external cloud storage, on a local computer, offline or across several locations.
The NCSC recommends keeping multiple copies in different locations and refers to the 3-2-1 approach: three copies of important data, stored using two different forms of storage, with one copy held offsite.[7]
Hosting Backups vs Backup Plugins
Hosting-provider backups
A provider may offer automatic schedules, control-panel restoration, staging recovery, downloadable copies, pre-update restore points and optional hourly backups. Limitations may include short retention, restoration fees, limited scheduling and dependence on the provider.
WordPress backup plugins
A plugin may provide custom schedules, external storage, database-only or full-site backups, migration tools, archives and reports. Possible limitations include server usage, failed tasks, storage charges and paid restoration features. WordPress identifies hosting-provider backups, plugins and manual backups as common methods.[6]
Manual WordPress Backups
A manual backup can be created by separately downloading the files and exporting the database. It may be useful before updates, migrations, configuration changes or redesigns, but routine protection should generally be automated, monitored and tested.
What Is a Pre-Update Backup?
A pre-update backup is created immediately before WordPress, a theme or a plugin is updated. WordPress advises backing up both the database and files before upgrading.[4] It should supplement rather than replace the regular schedule.
How WordPress Restoration Works
Restoration means replacing damaged, missing or unwanted website data with information from a previous backup.
Typical full restoration process
- Identify the incident and when it began.
- Choose a backup created before the problem.
- Preserve the current website where appropriate.
- Prepare a clean destination.
- Restore the files and database.
- Update configuration details when necessary.
- Clear caches and test the website.
- Reapply legitimate changes made after the selected backup.
WordPress warns that a successful rollback is difficult without a complete pre-upgrade backup.[5]
Choosing the Correct Restore Point
The newest backup is not always the safest. The owner may need to investigate when the problem began, compare restore points, restore to staging, scan the restored version, update vulnerable software and reset credentials. The NCSC recommends restoring only to a known clean system.[8]
Full Restoration vs Selective Restoration
A full restoration may suit severe corruption, failed migration, accidental deletion or a broad security incident, but legitimate newer data may be removed. Selective restoration recovers only an affected component and preserves more recent information, but not every provider supports it.
Why Ecommerce Restoration Is More Complicated
A WooCommerce store changes whenever customers order, register, update details, review products or adjust stock. Before restoration, determine what changed and whether selective recovery is possible.
Should You Restore Directly to the Live Website?
Not always. Restoring to staging first can confirm that the backup is usable, the original problem is absent, functionality works and no obvious malware remains.
Why Backups Must Be Tested
A backup that has never been restored is unverified. The NCSC recommends testing regularly and confirming that the organisation knows how to restore before an incident occurs.[7]
Recovery Point and Recovery Time
How much data can be lost?
This determines the required frequency. A shop that can tolerate losing no more than one hour of orders needs a shorter interval than a business able to lose one day of changes.
How long can the website remain unavailable?
This influences the required restoration process. A business-critical website may need self-service restoration, priority support, documented steps, staging recovery, accessible credentials and an independent copy.
Example: Managed WordPress Backup Retention
Kinsta documents automatic daily backups, a minimum 14-day retention period, optional hourly backups and system-generated restore points. These illustrate questions to ask and are not universal managed-hosting features.[9][10][11]
Questions to Ask a Hosting Provider
- Coverage
- Are files, database, uploads, themes, redirects, server settings and staging included?
- Frequency
- How often are backups created, and are hourly or pre-deployment copies available?
- Retention
- How long are automatic and manual backups kept, and what happens after cancellation?
- Storage
- Are backups separate, downloadable, encrypted and excluded from the storage allowance?
- Restoration
- Is recovery self-service, available to staging, granular and free of extra charges?
- Reliability
- Are failures reported, completion verified and emergency support available?
A Practical Backup Strategy for a Small Business Website
A standard business website could begin with automatic daily full-site backups, 14–30 days of retention, a backup before significant updates, one independently stored copy, periodic restoration testing, written instructions and secure multi-factor access.
A more active website may need hourly database backups, longer retention, transactional-data protection, staging restoration, more frequent testing and a defined incident-response process.
Common WordPress Backup Mistakes
- Assuming the hosting provider handles everything
- Backing up files but not the database
- Keeping backups only on the live server
- Retaining only one restore point
- Never testing restoration
- Using staging as the only backup
- Running backups too infrequently
- Storing backups indefinitely
- Forgetting access credentials
- Restoring malware
WordPress Backup Checklist
- Both files and database are covered
- Backups run automatically
- Failed jobs generate an alert
- Frequency matches the website’s rate of change
- Retention covers delayed discovery
- At least one copy is stored separately
- Backups are protected from unauthorised access
- Restoration instructions are documented
- The restore process has been tested
- Important changes trigger an additional backup
- Old copies are deleted according to a defined policy
- The system is reviewed after major website changes
Final Verdict
WordPress backups are not simply archived copies of a website. They are part of a recovery process involving three connected decisions:
- Frequency: how often a restore point is created
- Retention: how long old restore points remain available
- Restoration: how the website will be recovered and verified
For a simple website, daily backups with several weeks of retention may provide a reasonable starting point. For an ecommerce, booking or membership website, more frequent database protection and a carefully planned restoration workflow may be necessary.
Whatever method you choose, make sure the system includes both WordPress files and the database, keeps at least one separately controlled copy and is tested before an emergency occurs.
The best backup is not merely the newest copy. It is a clean, complete and accessible copy that can restore the website within an acceptable period while limiting the amount of legitimate data lost.
Research and Editorial Note
This article was prepared using official WordPress documentation, UK National Cyber Security Centre guidance and publicly available Kinsta documentation.
The backup-frequency and retention examples are editorial guidelines rather than universal technical requirements. References to Kinsta illustrate one provider’s documented system. Features, limits and retention periods vary and may change.
References
- WordPress.org. “Backups.” Updated 4 June 2026. Accessed 25 July 2026.
- WordPress.org. “Backing Up Your Database.” Updated 14 January 2026. Accessed 25 July 2026.
- WordPress.org. “Backing Up Your WordPress Files.” Accessed 25 July 2026.
- WordPress.org. “Dashboard Updates Screen.” Accessed 25 July 2026.
- WordPress.org. “Upgrading WordPress.” Updated 1 July 2026. Accessed 25 July 2026.
- Learn WordPress. “How to Back Up Your Site.” Accessed 25 July 2026.
- National Cyber Security Centre. “Data Security.” Accessed 25 July 2026.
- National Cyber Security Centre. “Mitigating Malware and Ransomware Attacks.” Accessed 25 July 2026.
- Kinsta. “WordPress Backups.” Updated 21 January 2026. Accessed 25 July 2026.
- Kinsta. “Disaster Recovery—Backups.” Updated 21 January 2026. Accessed 25 July 2026.
- Kinsta. “Managed WordPress Hosting Services.” Accessed 25 July 2026.
- Kinsta. “Create a WordPress Database Backup.” Updated 15 October 2025. Accessed 25 July 2026.