A disaster recovery runbook for your new WordPress site
An IT expert explains RPO, RTO, offsite backups and a tested recovery plan for WordPress sites migrated from AI builders.
Convert2WP – convert your AI website to WordPressClick here
Hosting is not a recovery plan
On an AI builder, the platform takes care of infrastructure, and most users never think about disasters. After moving to WordPress, you own that responsibility. Many site owners assume the host's backups are enough, until they discover those backups are stored on the same server or only kept for three days.
A disaster recovery plan answers one question: if the site disappeared right now, how fast and with how little data loss could we bring it back?
Defining RPO and RTO
Two numbers drive every decision. The recovery point objective, RPO, is how much data you can afford to lose, measured in time. A brochure site might accept a day. A busy shop might accept fifteen minutes. The recovery time objective, RTO, is how long the site may be down.
I agree these numbers with the client in plain terms: if we lose the last day of edits, is that acceptable? If the shop is offline for four hours, what does that cost? The answers determine how much the backup setup should cost.
What to back up
A WordPress site consists of the database, the uploads folder, the theme and plugins, and configuration such as wp-config and server settings. The theme and custom plugins are in Git, so they can be restored from there. The database and uploads are what really need regular backups.
I also document DNS records, email settings and licence keys for premium plugins. These are often forgotten and can slow recovery down by hours when nobody knows where they are.
Offsite, encrypted and versioned
Backups must live somewhere other than the web server, preferably with a different provider. Object storage services are cheap and reliable. I encrypt backups before upload and keep multiple versions: daily for two weeks, weekly for two months, monthly for a year.
Versioning protects against a quiet problem: malware or data corruption that goes unnoticed for days. If you only keep the latest backup, you may be restoring an already infected copy.
Automating the routine
Database backups run on a schedule matching the RPO, through a plugin, a host feature or a server cron job with WP-CLI. Uploads are synced incrementally so only new files are transferred. Every backup job reports success or failure to a place someone actually looks at.
Silent failures are the real risk. I have seen backup jobs fail for months because a password changed and the notification went to an old mailbox.
Testing the restore
A backup you have never restored is a hope, not a backup. Every quarter I restore the latest backup into a fresh test environment, time how long it takes and check that the site works. That measured time is your real RTO, which is often longer than people expect the first time.
Each test also improves the written runbook. Steps that were unclear get rewritten, missing credentials get added and the process becomes faster each round.
The runbook itself
The runbook is a short document with numbered steps: who decides a disaster is happening, where backups are, how to provision a new server, how to restore files and database, how to update DNS and how to verify the site. It includes contact details for the host, the domain registrar and the developer.
It is stored outside the website and outside the hosting account, for example in a shared drive and on paper. If the hosting account is compromised, you still need to be able to read the plan.
Incidents that are not disasters
Most incidents are smaller: a plugin update breaks a page, an editor deletes content, a form stops sending. The same backups help here through partial restores of a single page or table. Knowing how to do that calmly prevents small problems from becoming big ones.
Small glitches after a conversion are normal and easy to fix later. A solid recovery plan simply makes sure that even the rare big problem stays manageable.