Backups & recovery, the policy in plain terms

What gets backed up, and how often

Database: daily. Posts, pages, orders, customers, settings, the stuff that changes and cannot be rebuilt. Files: weekly, plus before and after any significant change (updates, deployments, theme work, the staging discipline keeps a pre-change snapshot anyway). High-volume stores can justify more frequent database snapshots; quiet brochure sites can justify weekly everything, the cadence follows how much data you can afford to lose, which is a number you get to choose.

Where the copies live, the 3-2-1 pattern

Three copies, two different media, one off-site. In practice: the live site, a backup on separate storage, and an off-server copy in a different location from the web host. The off-server copy is the one that matters, ransomware, a compromised hosting account, or a provider incident takes the server and everything on it, which includes any backup stored on the same machine. This is also why the restore page opens with backup inventory before anything else: the most common finding is "backups exist on the server that just died."

The restore test, the part that separates policy from hope

A backup is proven by restoring it, on a staging environment, periodically, for real. The drill checks: does it restore, does the site run after restore, is the data complete and current to the expected point, and how long does the whole thing take (that duration is your recovery-time reality). The result gets reported in the monthly report. The uncomfortable industry truth: most sites have never run this test once, and the first time is never during a real emergency, the restore emergency page documents why that first test is done carefully, with the current state preserved first.

What is promised, with real numbers, not vibes

• Recovery point: with daily database backups, the worst realistic data loss is one day of changes. Stores needing tighter windows run more frequent snapshots, chosen, not assumed.
• Recovery time: a clean restore to the same host is typically hours; to a new host, longer (DNS propagation adds its own tail, the launch page explains why). The honest promise: a stated time based on a tested drill, not a heroic guess.
• Retention: daily backups retained ~30 days, weekly longer, enough runway to reach back past a problem nobody noticed immediately.
• What is NOT promised: instant recovery, zero data loss, or immunity from disaster when no backup exists. If backups are absent or corrupt when the emergency arrives, that gets named immediately and honestly, the emergency pages all state the same rule: bad news early, in plain words.

Whose job is this on your site?

It should be written down, scheduled, monitored for freshness, and proven by a test, which is exactly the loop the maintenance retainer runs. If your current arrangement is "the host says they do backups," ask three questions: how often, where stored, and when was the last restore test. If any answer is a shrug, this page is the fix.