Why most WordPress backups fail
Many sites have backups, but they do not actually work. Teams set up automated backups, forget about them, and discover during a disaster that the backups are corrupted or incomplete.
A backup is only valuable if it can be restored. Backing up a database without the file system means you cannot restore. Backing up files without the database means your site is broken. Both are required.
Also, backups need to be tested. Periodically restore a backup to a test environment to verify that the backup actually works and that you have the documentation to do a full restore under pressure.
What to back up
WordPress consists of three parts: the application files, uploaded media, and the database. All three need to be backed up together regularly.
Application files change when you update WordPress, themes, or plugins. Keep historical backups so you can restore to a previous version if an update breaks something.
Uploaded media files also need backing up. These are usually customer uploads or images you have created. Losing them means losing content.
The database contains all your posts, pages, comments, user data, and custom data. This is your most critical data. Backup the database separately and frequently.
Backup frequency and retention
How often should you back up? It depends on how much you can afford to lose. If you publish new content daily, a daily backup is appropriate. If your site changes weekly, weekly backups are acceptable.
A common strategy: daily backups for 7 days, weekly backups for 4 weeks, monthly backups for 12 months. This gives you recovery options across different timeframes without storing infinite backups.
Keep at least 3 backups at all times: today is backup, last week is backup, and last month is backup. That way, if today is backup is corrupted, you have recent alternatives.
Delete old backups. There is no reason to keep backups from 2 years ago. They take storage space and increase the attack surface.
Where to store backups
Backups on the same server are not really backups. If the server is hacked or the hard drive fails, both the live site and the backup are lost.
Store backups separately: cloud storage (AWS S3, Google Cloud Storage), a secondary server, or a backup service. The goal is that a complete server failure does not mean losing your backups.
Use geographically distributed storage if possible. If your primary server is in one region and it burns down (literally or via cloud region failure), you still have backups elsewhere.
Encrypt backups in transit and at rest. Backups contain sensitive data. Do not store unencrypted backups on cloud services.
Testing your backup strategy
The only way to know your backups work is to restore them. Every month, restore a backup to a test environment and verify that the site works correctly.
This catches multiple failure modes: corrupted backups, incomplete backups, missing files or database tables, and configuration issues that only appear during restoration.
Document the restoration process. If your team is stressed during an actual disaster, they will make mistakes. A clear, step-by-step restoration guide reduces errors.
Have one person follow the restoration guide from scratch to verify that it works. If the guide is unclear or missing steps, fix it now.
Bottom Line
These are the kinds of decisions that separate systems that age well from systems that become expensive to change.