Skip to main content
10 September 2026 · 4 min read

A website backup strategy that actually works

The 3-2-1 rule, what to back up, how often and for how long — and why your host's backups still need an off-site copy you control.

A website backup strategy that actually works

Almost every site owner believes they have backups, and most discover what they actually have on the worst possible day: after a botched plugin update, a deleted table or a compromised admin account. A backup strategy is not a tool you install once; it is a set of decisions about what to copy, how often, where to keep it and how you will get it back. This guide walks through those decisions in plain terms, so that your recovery plan is something you have tested rather than something you hope for.

Start with the 3-2-1 rule: keep three copies of your data, on two different kinds of storage, with one copy off-site. For a website, the live site counts as the first copy, the host's backups as the second, and an archive you download to storage you control as the third. Then list what a full restore actually needs. Site files, uploads and databases are obvious. Less obvious are mailboxes, cron jobs, PHP settings, .htaccess or nginx rules, API keys and environment files, and an export of your DNS zone, because rebuilding forty records from memory during an outage is slow and error-prone.

Frequency follows from two questions. How much work can you afford to lose? That is the recovery point objective, or RPO. How long can the site be down while you restore it? That is the recovery time objective, or RTO. A brochure site that changes once a month can live with a daily copy. A shop that takes orders all day cannot, because every hour between backups is an hour of orders you would have to re-enter by hand. Retention matters as much as frequency: problems are often noticed days later, so keep several daily copies, a few weekly ones and at least one monthly snapshot.

Your host's backups are necessary, but they are not sufficient. On WebHostFlow shared hosting, every site and database is copied each night to separate infrastructure, kept for 14 days and restorable from the control panel, which covers most accidents in a couple of clicks. But those copies live with the same provider, under the same account. If a billing dispute, a stolen login or a mistake in the account itself is the problem, you want a copy nobody else can touch. Download a full archive regularly and store it somewhere independent, such as encrypted cloud storage or a disk in your office.

Databases need special care. Copying the raw files of a running MySQL or PostgreSQL server can produce a backup that looks complete but will not start, because the data was changing mid-copy. Use a proper dump instead: mysqldump with the --single-transaction option for InnoDB tables, or pg_dump for PostgreSQL, both of which give a consistent snapshot without locking the site. Compress the dump, put the date and time in its name, and check that the file is not suspiciously small. A zero-byte dump that ran “successfully” every night for six months is a surprisingly common discovery.

Hacked sites and ransomware change what restoring means. Attackers often sit quietly for weeks before anything visible happens, so the newest backup may already contain the backdoor. Work out when the compromise began from access logs and file modification dates, restore from a copy taken before that point, change every password and key, and update the software that let them in. This is where long retention and frequent restore points pay off: premium hosting keeps hourly backups for 30 days, so you can go further back and lose less. And test restores regularly: load a copy onto a staging site and click through it.

A simple monthly checklist keeps all of this honest. Confirm that the latest automatic backups completed and have plausible sizes. Download a fresh off-site copy of files, databases and mail. Export the DNS zone and note any configuration changes. Restore one backup to a test location and check that pages, logins and forms work. Delete off-site copies older than your retention policy. It takes under an hour, and it turns backups from a hope into a procedure. At WebHostFlow we handle the host-side half on shared and premium hosting, so your part is the off-site copy and the test.