An untested backup is a hope, not a plan. Recovery depends on four answers you should give today: what is copied, where copies live if your hosting account is lost, how far back you can reach, and how long a restore takes.
The short answer: the plan on one page — what is copied, where it lives, how far back, who acts, how it is rehearsed (table)
| Plan element | The decision to write down |
|---|---|
| What is copied | Files, database and configuration, as one matched set |
| Where copies live | Three copies, two storage types, one off-site, one deletion-proof |
| How often, how far back | Frequency and retention matched to site change |
| Recovery objectives | Data you can lose (RPO); downtime you can take (RTO) |
| Who acts | A named owner and runbook, in a fixed order |
| How it is proven | A rehearsed test restore, repeated |
The problem: your only copy sits on the same server that can fail, be hacked or be switched off
Many owners assume the host keeps copies, so they are covered. Sometimes it does — for a few days, on the same account, restorable only while the account stands. That fails when a plan is needed: a bad update corrupts the site and its copies, an attacker deletes the backups, a billing dispute switches the account off, or a deletion surfaces weeks later.
The thread: the only copy sits inside the same failure. A plan breaks it by deciding, in writing, what is copied, where it lives, and who can bring it back. See also our website handover and ownership checklist.
Backup is not a plan: the difference between having copies and being able to recover
A backup is a copy of data. A disaster recovery plan is the ability to return to business: the copies, plus objectives they must meet, people and access needed, the order services come back, and proof from rehearsal that the chain works. Sites fail at the joins: the copy exists but nobody has the storage password, or restore takes days, not hours.
This plan treats failure broadly — bad update, host failure, deletion and compromise share one recovery spine. Responding to a compromise is a separate discipline (our hacked-site recovery guide, once published); its job is a clean copy and a rehearsed route back.
What a complete website backup contains: files, database, configuration — and the parts everyone forgets
WordPress.org's backup documentation makes the point: a complete backup needs both files and database, and copying one does not copy the other — the database sits outside the website folder. Files hold code, themes, plugins and uploads. It holds pages, posts, settings, users and, on a store, orders and customers. Configuration ties them together — on WordPress, wp-config.php.
Forgotten parts sit around it: DNS settings, email records, premium licence keys, payment and CRM credentials, and the runbook. Record secrets separately, under separate access control — a restore needs them, but they should never travel inside a site copy. Treat files and database together as one matched, date-labelled set.
Where copies live: the 3-2-1 rule, off-site copies and one copy an attacker cannot delete
The standard baseline, reflected in CISA's StopRansomware guidance, is the 3-2-1 rule: three copies of data, on two storage types, with one copy off-site. For a website: the live site, a copy held by your backup tool or host, and one in cloud storage your business controls.
Add one protection the classic rule predates: at least one copy should be immutable or offline — unchangeable and undeletable for a set period, even by someone holding your admin passwords. CISA stresses offline, encrypted backups and regular testing. Give backup storage separate credentials and send failure alerts to a named person.
Frequency and retention: how often to copy and how far back to keep, by site type (table)
Frequency follows how much change you can afford to lose; retention, how late a problem might be noticed. Corruption may be spotted weeks later, so yesterday's copy is never enough.
| Site type | Suggested frequency | Suggested retention |
|---|---|---|
| Brochure site, updated rarely | Weekly, plus before any update | At least 4 weekly and 3 monthly copies |
| Content or lead-generation site | Daily | At least 30 days, plus monthly copies for a year |
| Online store or booking site | Daily, with extra database copies if orders are heavy | At least 30–90 days, plus monthly copies for a year |
These are starting points to agree with your provider, not guarantees. Add one rule: take a manual copy before updates, plugin changes or migrations, and keep it until the change beds in — routine care such as the WordPress maintenance routine.
Recovery objectives in plain English: how much data you can lose (RPO) and how long you can be down (RTO)
Two objectives frame the decision. The recovery point objective (RPO) asks: how much data can we afford to lose, in time? If losing a day of enquiries is acceptable, daily backups meet it; if losing an hour of orders is not, a store needs more frequent copies. The recovery time objective (RTO) asks: how long can the site be down — hours for a store, a day for a brochure site.
Write both down and let them set frequency, storage and rehearsal. Treat them as objectives to validate, never tool promises: the only honest RTO is the one your last rehearsal achieved.
"The host backs it up" — the four questions that test whether that is enough
Host backups can be one layer — only once these four questions have written answers. One: what is copied, and how often? Two: how far back does retention reach — can you restore a three-week-old copy? Three: do copies survive loss or compromise of the hosting account? Four: who can trigger a restore, how long did the last take, and can you download a copy you control?
Vague answers count as no. If the host passes all four, record it as one layer and keep your own off-site copy. Any failure defines what your layer must add.
The runbook: contacts, access, restoration order and who decides — written before you need it
The runbook is what someone follows under pressure, possibly when the site is unreachable. Keep it short, current, stored independently of the website. It names who authorises a restore, host contacts, where copies live, and where credentials are held — references to a password store, not passwords.
It fixes the restoration order: hosting and DNS first, then files and database as a matched set, then configuration and connections like payment and email, then checks — homepage, enquiry form, checkout, admin login — before declaring the site back. Review it whenever a provider changes. If a plugin change caused the failure, start from a plugin audit.
Rehearse it: the test restore that turns an assumption into a plan
A plan becomes real when a restore succeeds in rehearsal. Restore the latest copy into staging — never over the live site — and work the runbook as written: find the copy, use recorded access, restore, then run the checks. Time it: that is your current RTO.
Record failures, fix the runbook. Rehearse at least twice a year, and after major changes such as a host move or rebuild. Owners who skip this own copies, not a plan: rehearsal failures are cheap; mid-incident failures stretch an outage.
Customer data in backups: access control and UAE-aware handling
Backups concentrate data a business must protect: customer details, enquiries, orders and accounts. Under the UAE's Personal Data Protection Law (Federal Decree-Law 45/2021), personal data must be handled securely and kept only as needed for its purpose — principles applying to copies as to the live site. This is owner guidance, not legal advice.
In practice: encrypt copies in transit and at rest where tools support it, restrict access to named people with separate credentials, and apply retention discipline — copies kept forever become an uncontrolled archive. Know where your off-site storage sits; never expose a customer database on a forgotten staging address.
Common mistakes
The most common mistake is trusting an assumption: "the host backs it up" accepted without the four questions, never tested. Close behind: keeping every copy in the same account, so one failure takes site and backups together.
Other errors: backing up files but not the database, keeping only days of retention, storing credentials in the backup, never rehearsing. Finally, many plans have no owner: when whoever set the backups up leaves, nobody knows the schedule.
FAQ
What should a website backup include?
Files, database and configuration, as one matched set. On WordPress: site files including uploads, the database with content, settings and orders, and configuration such as wp-config.php — plus separately recorded licence keys.
How often should I back up my website?
As often as your recovery point objective requires. A rarely changed brochure site may suit weekly copies; a store usually needs daily copies at minimum.
Are my host's backups enough?
Only if they pass four tests: full contents covered; retention reaches far enough back; copies survive loss of the hosting account; and you can restore a copy yourself. Otherwise add your own.
What is the difference between RPO and RTO?
RPO is how much data you can afford to lose, in time — it sets backup frequency. RTO is how long the site can be down — it sets how rehearsed your restore must be.
Why do I need to test a restore?
Because untested backups fail quietly: missing files, wrong credentials, a process nobody remembers. A rehearsal into staging proves the chain works and gives you a real recovery time.
Have the plan built and rehearsed for your site (CTA)
If any row of the one-page plan is blank for your site — no off-site copy, no named owner, no restore ever tested — fixing it is urgent, unglamorous work. WebStackRank builds websites with ownership transfer on final payment; starter packages include 3 months free maintenance covering health checks, updates and defect fixes. A backup plan can be scoped alongside, with an itemised proposal in 24 business hours. Start with our web development services for the UAE or our website development company in Dubai, backed by our core web development services. WhatsApp: +971 52 595 3174.
