A backup only has value when you can restore the right version quickly and completely. Creating a daily zip file is not a strategy by itself. You need to know what is copied, where copies live, how long they are retained and whether a recovery test succeeds.
What belongs in a complete WordPress backup?
WordPress has two connected parts:
- Database: posts, pages, users, settings, WooCommerce orders and much plugin data.
- Files: uploads, themes, plugins,
wp-config.phpand custom files.
A database dump without uploads produces missing images. Restoring files alone does not recover recent orders or settings. Capture both as one recovery point and record its time, WordPress version and environment.
The 3-2-1 rule as a dependable foundation
- 3 copies: the live website and at least two backups.
- 2 different media or systems: for example hosting storage and encrypted object storage.
- 1 copy outside the primary environment: with separate credentials and preferably immutable or offline.
A backup on the same disk cannot protect against disk failure, ransomware, a compromised administrator account or a maintenance mistake. External storage needs genuine logical separation from production.
How often should you back up?
Frequency follows your Recovery Point Objective (RPO): how much new data may be lost? A brochure site may accept a daily backup. A store receiving continuous orders may need hourly or near-real-time database protection. Also define the Recovery Time Objective (RTO): how long may recovery take?
| Website | Practical starting point |
|---|---|
| Static company site | Daily, plus before updates |
| Active blog or membership site | Several times per day |
| Store or booking platform | Hourly or more often for the database |
| Major change or migration | Complete snapshot immediately beforehand |
Retention means more versions, not merely more copies
If malware remains unnoticed for three weeks, seven daily copies may all be infected. Use tiered retention, such as seven daily, four weekly and several monthly points. Personal data should not be retained forever: encrypt it, restrict access and document an appropriate retention period.
Consistent backups for busy websites
WordPress can change while files are being copied. On a store, the database may then represent a different moment from the uploads. Use a method that creates a consistent database dump or snapshot. Schedule heavy archive work outside peak hours and exclude caches, temporary files and unnecessary logs.
A seven-step restore test
- Choose an isolated staging domain or test environment.
- Download the backup through the same route used during a real incident.
- Verify checksums, readability and encryption.
- Restore files and database according to the documented procedure.
- Change URLs and secrets only where the test environment requires it.
- Test login, forms, media and scheduled jobs; for stores also test cart and orders.
- Record the true recovery time, failures and improvements.
A successful plugin notification proves that a job finished, not that its archive can be restored.
Protect backups like production data
Archives can contain customer information, password hashes, configuration and API keys. Use encryption in transit and at rest, multi-factor authentication, least privilege and separate credentials. The production account should not have unlimited power to erase historical copies. Monitor failures and unexpected size changes.
Frequently asked questions
Is a hosting backup enough?
It is an important layer, but a separately controlled second copy is wise for critical sites. Verify retention, recovery procedure and exclusions.
Should cache be included?
Usually not. Cache can be rebuilt. Excluding temporary data reduces time and storage.
When should I take an extra backup?
Before WordPress, plugin and theme updates, migrations, large imports, database maintenance and major design changes.
Do you need a recoverable backup design rather than another archive? Explore our hosting solutions or discuss your RPO and RTO with Gigatech.
