My host says they back up the server. Isn't that enough?

Maybe — but don't let "backups included" answer the important questions. Confirm what's covered, how often it runs, how long copies are kept, whether they're isolated from your hosting account, whether you can restore them yourself, and what happens if the provider or the account itself is unavailable. Keep an independent copy when losing the site would really hurt.

Why keep more than last night's backup?

Because the most recent copy is not always the safe one. A bad update, a quiet hack, or corruption can go unnoticed for days or weeks — back up nightly over one copy and you'll faithfully preserve the broken version while overwriting the good one. Several generations let you reach back to before the trouble started.

How often should I test a restore?

At least once or twice a year for a simple informational site, more often for a frequently changing or business-critical one — and again whenever the backup system, hosting platform, database version or procedure changes. Restore into a protected test environment and confirm the site genuinely works. An untested backup is a hope, not a safeguard.

Could you restore your website from a clean backup today?

"We have backups" is one of the most dangerous half-truths in running a website. Plenty of businesses discover, on the worst possible day, that the backups were incomplete, months stale, deleted along with the hacked account, or simply wouldn't restore. A backup is a stored copy; a recovery plan is the proven ability to rebuild a clean, working site within an acceptable time. This tip is about earning the second one.

Decide what losing means — first

Two numbers shape everything else. Your RPO (recovery point objective) is how much data you can afford to lose: if losing a day of orders is unacceptable, one nightly database backup isn't enough — while a brochure site edited monthly needs far less. Your RTO (recovery time objective) is how long the site may stay down while you restore. Set both honestly, and the right frequency and method follow.

Automatic, independent, and complete

Automatic and scheduled. Manual backups get skipped; a copy must exist whether or not anyone remembered.
Independently controlled. A snapshot inside the hosting account is genuinely useful for a quick rollback — but it's not enough on its own, because the same compromise, deletion or provider failure can take the live site and its backups together. Keep at least one copy outside the production account, under separate credentials, encrypted, with some immutable or offline generations that can't be silently overwritten. And keep the decryption keys stored separately and provably recoverable — an encrypted backup whose key is lost is no backup at all.
Complete, and consistent. Back up the website files, the database via a database-aware export or consistent snapshot (copying a live database file is not a valid backup), user uploads, configuration, custom code and scheduled-job definitions — from compatible points in time, so Tuesday's database doesn't meet Thursday's uploads. Separately, document what a rebuild needs but a backup can't hold: the DNS, registrar, hosting and service accounts, software versions, the restore procedure, and who does what. Secrets and API keys don't belong in the archive or the README — keep them in a password manager or secrets service the recovery team can reach even when production is locked out.

Generations you can trust — and jobs you can see

Keep a ladder of copies scaled to your RPO — for a small site, say daily for two weeks, weekly for two months, several monthlies — because restorable is not the same as clean: a backup taken after ransomware or a quiet compromise began just preserves the damage. Recovering means choosing a generation from before the problem, then checking logs, scanning the restored copy, updating vulnerable software and rotating exposed credentials before it goes back into production.

And watch the machinery: automatic backups fail automatically, for months, behind a green check. Make every job report success, completion time and expected size to a monitored address, and investigate an archive that's suddenly empty — or suddenly twice the size.

Test the restore, not just the backup

The only proof is a periodic complete restore into a protected test environment — access-controlled, not indexable, and unable to send real email, because restored production data is still personal data. Then test the recovery, not just the homepage: content and recent uploads present, admin login, forms sending, scheduled tasks running, HTTPS re-establishable, integrations reconnecting — ideally performed from the written instructions by someone other than their author. Time it against your RTO, and fix every step that needed guesswork.

Do this and a hacked, deleted, or broken site becomes a planned recovery with a known duration — rather than an existential threat to your business.

What to do

Set your RPO and RTO first — how much data you can lose, how long you can be down — and let them set frequency.
Back up files, database (database-aware), uploads and configuration at compatible recovery points; document accounts, versions and procedures separately, with secrets and decryption keys secured outside production.
Keep independent, encrypted copies under separate credentials, with immutable or offline generations, retained far enough back to escape a late-noticed problem.
Monitor every backup job for success, recency, size and integrity, with failures alerting a monitored address.
Restore the complete site into a protected test environment on a schedule — and after any change to the backup system, platform or procedure — verifying function and the cleanliness of the chosen recovery point.
Keep the written recovery steps current, so restoring never depends on one person's memory during a crisis.