The backup that didn't save the site
We get recovery requests when people are already in trouble.
A customer came to us after a WordPress site went down following a plugin conflict. They had backups — they'd set up a plugin six months earlier and assumed it was running. When they tried to restore, two problems emerged. First, the backup files were stored in the same hosting account as the site. When the account had storage issues, the backups were affected too. Second, the backup had been silently failing for three weeks because the plugin had hit a memory limit during the scheduled export.
The site was recovered from a partial backup that was 23 days old. Three weeks of content and product data were gone.
The backup setup looked right. The backup strategy had two critical gaps that only became visible when something went wrong.
What "backing up WordPress" actually means
A WordPress site is not one thing. It is three separate systems that need to be captured together to enable a complete recovery:
The database. This contains everything created through WordPress — posts, pages, products, orders, customer data, comments, settings, plugin configuration. The database is the business-critical data. If you lose the database and have no backup, the site's content is gone.
The WordPress files. The WordPress core files, your theme files, and the plugin files that extend the site. These can generally be reinstalled from sources if lost, but your customisations — theme modifications, child theme files, custom templates — live here and cannot be recovered from a clean install.
The uploads directory. Images, PDFs, documents, videos, and other media uploaded through WordPress media library. For many sites, this is gigabytes of content that cannot be recovered if the files are lost.
A backup that only captures the database recovers the structure and content text but leaves all uploaded media missing. A backup that only captures files recovers the site shell but loses all content created through WordPress. Complete recovery requires all three components.
How often you actually need to back up
The right backup frequency depends on one variable: how much work are you willing to redo?
For sites updated daily — publishing content, processing orders, adding products: Daily database backups are the minimum. A 48-hour-old database backup means potentially redoing two days of content or, worse, losing two days of customer orders.
For sites updated weekly — occasional posts, static business pages: Weekly full backups are reasonable. If the site doesn't change much, weekly coverage keeps the potential loss window small.
For WooCommerce stores processing orders: Database backups should run every few hours, or at minimum twice daily. An order lost because the backup was 12 hours old when something went wrong is a real business problem.
For sites undergoing significant changes — major updates, theme changes, plugin installations: Manual backup immediately before the change. Every time. The update breaks things more often than developers admit, and having a backup from 30 seconds before the breaking change is the cleanest recovery path.
The staging environment pattern is worth mentioning here: for any significant change to a production site, Hostao's Professional and Business plans support testing changes on a staging instance before applying them live. That's not a backup alternative — it's a change management approach that reduces the situations where you need the backup at all.
Where backups should actually go
Same-server backup is the most common mistake in self-managed WordPress backup setups.
If the backup plugin stores backups in the wp-content/backups folder of the same hosting account, those backups are subject to the same risks as the site itself. Server failure, account suspension, storage limits, malware affecting the account — any of these affect both the site and the backup simultaneously.
Offsite storage is the requirement, not the nice-to-have. The practical options:
Remote storage services: Most backup plugins (UpdraftPlus, BackWPup, Duplicator Pro) support direct backup to Google Drive, Dropbox, Amazon S3, or similar. The backup is created on the server and immediately transferred to offsite storage. The local copy can be kept as a faster recovery option.
A separate hosting account: For businesses managing multiple sites, storing backups from one site in an account at a different hosting provider creates genuine separation. Both would need to fail simultaneously to lose the backup.
Local storage: Downloading a copy to a local machine or NAS. Slower and more manual, but the backup exists in a physically separate location.
The three-copy principle that applies in general data backup — original, offsite copy, different-medium copy — is achievable for WordPress without significant cost. The free tier of Google Drive or Dropbox handles most site backups comfortably.
Checking that backups are actually working
The discovery-at-recovery-time failure is more common than it should be.
A backup plugin is configured, the schedule is set, and then nothing is done to verify that the backups are actually completing successfully. Memory limits, database connection timeouts, disk space exhaustion, and plugin conflicts can all cause backups to fail silently. The plugin logs the attempt; it does not always surface the failure clearly.
The verification practice worth building: once a month, check the actual backup files. Not the plugin dashboard — look at the actual stored files and confirm the date of the most recent successful backup matches expectations.
For the serious test: restore to a staging environment annually. Not a full production restore — spinning up the backup on a staging instance and verifying the site loads correctly, the admin panel works, and recent content is present. This confirms both that the backup files are intact and that the restore process works before it is needed under pressure.
At Hostao, our hosting plans ($3/month Basic, $4.50/month Professional, $6/month Business) include cPanel access, which provides server-level backup tools alongside what your backup plugin provides. Having two backup paths — plugin-level and server-level — creates redundancy that covers plugin failure scenarios.
The retention question most setups skip
How many backup copies do you keep?
If the backup schedule runs daily and retains only the most recent backup, a corrupted backup overwrites the previous one. The site has a corrupt backup and no historical copy to fall back to.
The retention approach that works: keep at least seven daily backups in rotation, plus monthly snapshots going back three to six months. This covers the scenario where a problem is introduced and not noticed for several days — you can restore from before the problem was introduced without being limited to only the most recent backup.
Plugin storage limits often cause people to reduce retention to avoid running up storage costs. The monthly snapshot approach addresses this: daily backups cover the recent window, monthly snapshots provide longer historical coverage at significantly lower storage cost.
One thing to do today
If there is a backup plugin installed on the WordPress site, open it and check the date of the last successful backup.
If it is more than 48 hours old for an active site, or more than seven days old for any site, the backup schedule is either not running or failing silently. Fix that before anything else.
If the backup destination is the same hosting account, adding an offsite destination takes about ten minutes with UpdraftPlus and a Google Drive account. Ten minutes against the cost of losing weeks of work.
For businesses driving traffic to WordPress sites through WhatsApp campaigns — using tools like AutoChat at autochat.in — the conversion that happens when that traffic arrives is stored in the WordPress database. That data is only as safe as the backup strategy protecting it.
Image suggestion: a simple diagram showing three backup storage locations — hosting server, Google Drive/cloud storage, local download — with arrows showing the backup flow and a warning icon over the "same server" path.