Direct answer
WordPress backup and recovery should include the database, files, media library, themes, plugins, uploads, configuration, offsite storage, retention rules, restore testing and a clear process for getting the site back online. A backup is only half the job. Recovery is what proves the backup can actually protect the business.
The real question is not “Do we have backups?” It is “Can we restore the right version quickly if something goes wrong?”
The real problem
Many site owners assume their website is safe because a backup plugin is installed or the host says backups are included. That may be true, but it is not enough detail to rely on.
A backup can be incomplete. It can be stored in the same place that fails. It can be too old. It can be too large to restore easily. It can exclude key files. It can fail silently. It can exist, but nobody knows how to use it.
That is why backup and recovery should be planned together.
The useful distinction: backup file vs recovery ability
A backup file is a stored copy.
Recovery ability is the practical capacity to bring the site back.
You need both.
A backup that cannot be restored, cannot be found, or is too old to matter gives a false sense of safety. Recovery requires access, process, testing, timing and responsibility.
What should be included
1. Database backup
The database stores posts, pages, settings, users, orders, form entries and many plugin-controlled items. Without the database, the site may lose its actual content and configuration.
2. File backup
Files include WordPress core files, theme files, plugins, uploads, images, PDFs and other media. For most business websites, the media library is part of the site’s value.
3. Full-site backup option
A full backup is useful when the whole site needs to be restored or migrated. Partial backups may help in specific cases, but they should not be the only recovery route.
4. Offsite storage
Backups should not exist only on the same server as the website. If the hosting account fails, is compromised or becomes inaccessible, same-server backups may not help.
Offsite storage creates separation.
5. Backup frequency
The right frequency depends on how often the site changes. A brochure site may need less frequent backups than an ecommerce, membership or publishing site.
Ask how much work or data you can afford to lose.
6. Retention period
Retention defines how long old backups are kept. This matters because not every problem is discovered immediately. If malware, data loss or a mistake is discovered late, yesterday’s backup may not be enough.
7. Restore testing
A backup strategy should include some form of restore confidence. That might be periodic testing, documented restore steps or verification that the backup is usable.
Untested backups are assumptions.
8. Recovery responsibility
Who restores the site? The host? The developer? The care-plan provider? The owner?
This should be clear before an incident.
Common mistake
The common mistake is treating backups as a plugin setting instead of a business continuity issue.
A plugin can create backup files, but someone still has to decide what is backed up, where it is stored, how long it is kept and how recovery happens.
If nobody owns that process, the business may only discover the weakness during an emergency.
When this does not apply
A very small, static or low-risk site may not need an advanced backup system. But even a simple site should have a basic recovery route.
If rebuilding the site from scratch would be painful, expensive or slow, backups matter.
If the site handles sales, enquiries, user data or regular updates, recovery planning becomes more important.
Soft next step
To assess your backup setup, ask three questions:
- What exactly is backed up?
- Where is it stored?
- Who can restore it if the site fails?
If any answer is unclear, you do not yet have a reliable recovery plan.