Daily hosting backups: how often to back up and how to verify the restore works

Everyone thinks they have backups sorted — until the moment they need them. That's when it shows whether the backup exists, whether it's fresh enough and, above all, whether the site can be restored from it at all. Let's go through how to back up so that a backup actually saves you in a crisis, rather than betraying you at the worst possible moment.

Why deal with backups even if the host has its own

Many providers back up their servers themselves, but these backups serve mainly them — for an infrastructure disaster. Don't automatically count on them restoring your site when you accidentally delete data or get hit by malware. Your own backups, ones you control, are therefore a necessity, not a luxury. Backups are part of the security basics we summarise in SSL, backups and 2FA.

How often to back up

The frequency should match how much data you can afford to lose. This rule is formally called RPO (recovery point objective) — simply "how much work at most I'm willing to lose". From that follows how often to back up:

• A static site that changes once in a while — a weekly backup is enough.
• A blog with regular posts — go daily.
• A store where orders arrive every hour — daily backups are the minimum, and with heavier traffic back up several times a day or continuously.

Automatically, not manually

A manual backup you have to remember will sooner or later be skipped. Require automatic backups from the host and check how far back they reach — many providers keep daily backups only a few days back, which may not be enough when you spot the problem late. On a compromised site it's often found that it was breached weeks ago.

The 3-2-1 rule

The proven rule says: keep at least three copies of your data, on two different media, and one off the main server. In practice that means not relying solely on a backup stored on the same server as the site — when the server or data centre fails, you lose the site and the backup at once. At least one copy belongs elsewhere, ideally in another location or on cloud storage.

Where to store backups

A good "off-server" copy is usually cloud storage (an S3-compatible service, for example) or your own disk. The important thing is that the backup isn't accessible with the same credentials as the site — if an attacker gains access to the site, they shouldn't be able to reach the backups through it and delete them. Separate storage with its own access is therefore safer than a backup "right next to" the site.

Watch where the data physically sits too. For customers' personal data (typically on a store), it's good to know which country the storage is in and whether it meets GDPR requirements. Some providers keep storage within the EU, which simplifies the paperwork around data protection. A backup is, after all, a copy of personal data and the same rules apply to it as to the site itself.

Don't forget the database and email

A complete site backup isn't just files. It includes the database (content, orders, users) and often email mailboxes too. A backup of files alone without the database is useless on WordPress or a store — the site wouldn't start from it. So always verify you're backing up both.

Versioning and ransomware protection

A backup protects you not just from deletion or a crash, but from compromise too. If an attacker encrypts or damages the site, you need to return to a version from when it was still fine — which could easily be a week ago. So a single "latest" backup isn't enough; it may already be infected. It's valuable to keep several historical versions (daily for the last few days, weekly for the last few months).

The second thing is that the attacker shouldn't be able to reach the backups at all. When they're on the same server and accessible with the same credentials as the site, they get wiped along with it. Safer are "write-once" backups or separate storage the site has no direct access to. That turns a backup from a paper shield into a real insurance policy. The ideal is a so-called immutable backup that can't be overwritten or deleted for a set period after creation — that's what turns a ransomware attack into a mere nuisance instead of a catastrophe.

A backup you haven't tested isn't a backup

The most common and most painful mistake: backups are created for years, but no one ever tried a restore — and in a crisis it turns out they're corrupted or incomplete. So at least once in a while, try the restore: load a backup onto a test site and verify the site and database come up. You'll use the same skill during migrating a site to another provider, where restoring from a backup is part of the move.

It's useful not just to try the restore but to time it — how long it takes to get the site back online. This is called RTO (recovery time objective) and on a store, where every hour of downtime costs money, it's as important a number as the backup frequency. When you know the restore takes two hours, you can plan accordingly; when you never try it, you find out at the worst possible moment. Only a backup you've restored from successfully and on time is one you can rely on.