How to back up a website and check that the backup works - Zephyra Studio

A backup is the only measure that returns a site to the state it was in before a problem, whatever caused it: a failed update, a code error, accidental deletion of content, or a breach. That is why a backup has to contain two things, the files and the database, and has to live outside the server the site runs on. The rule that holds up best in practice is three copies on two different media, one of them off site. Without that third part, the backup and the site share the same fate. And most importantly: a backup that has never been restored is not proof that it works, but an assumption usually tested at the worst possible moment.

What a backup has to contain

Files and database are two separate parts and both are required. The files hold the theme, plugins, images and attachments, while the database holds pages, articles, users, settings and, on stores, orders. A database-only backup gives a site that opens without any visuals, and a files-only backup gives an empty site.

Site configuration often contains database credentials and keys for payment or delivery services. Those go into the backup along with everything else, which means the backup should be treated as a confidential document with limited access, never kept somewhere reachable through the site address.

Two things a site backup does not cover, although people often assume it does: mail and DNS. If your mail runs on your hosting, check whether mailboxes are included, because restoring the site does not restore mail. DNS records are kept separately, because they are not part of the server the site runs on.

Where it is kept and how often

A copy on the same server as the site only helps with human error, not with a problem affecting the server itself. That is why one copy belongs somewhere else, with a storage provider or in separate storage space.

• For a site taking orders every day, back up daily and keep at least thirty days
• For a site with enquiries and occasional content changes, weekly is enough, plus a backup before every larger change
• Take a manual backup before updating the platform or plugins, because restoring is then fastest and simplest
• Keep copies in rotation rather than only the latest, since a problem is sometimes noticed a week later
• Let as few people as possible reach the backups, through individual accounts rather than shared files and passwords

Backups for stores and sites holding customer data

On a store a backup is larger and more sensitive than on a brochure site, because the database holds orders, addresses and customer details. It is therefore kept with limited access, never somewhere anyone who guesses the address can download it.

Frequency rises too, because losing orders means losing work already agreed. On stores taking orders daily, a backup runs every day and is kept for at least thirty days, so it is possible to go back to the state before a problem that was noticed late.

On systems holding customer data it is worth knowing in advance how long the data may be kept. A backup stored for years also preserves data whose retention period has passed, so old backups are deleted by the same rule that applies to the data in the system.

Testing a restore on a store includes checking orders, not only opening the site. If orders are missing after a restore or the cart misbehaves, the backup is incomplete even though it contains every file.

How to check that a backup really works

Testing is never done on the live site, but on a separate copy or a staging environment. Restoring onto the live site as a test is how a test becomes an incident.

The procedure is simple: restore the backup at a different address, then confirm the site opens, images appear, forms work and, on stores, the cart and checkout behave correctly. If any of that fails, the backup is not good, no matter how many files appear in the list.

The second thing to check is time. Measure how long a restore takes, because a site with thousands of photos can take hours, and that is a figure worth knowing before a problem rather than during one. Write the procedure down step by step, with the name of the person who runs it.

Automatic backups do stop working quietly: an access key expires, storage fills up, or the plugin breaks after a platform update. That is why the list of backups and the date of the latest one get checked once a month, which is the one recurring check with no exceptions.

The most common mistakes

Almost all of them follow the same pattern: a backup exists, but not in a form that helps at the moment it is needed.

• A database-only or files-only backup, which produces an incomplete site that has to be patched by hand afterwards
• A backup inside the site directory, where anyone who guesses the address can download it
• A backup on the same server, which disappears together with the site
• An automatic backup that has been running for years and has never been restored
• Relying on a host snapshot, which is short-lived and tied to that server
• No backup before an update, so the problem is discovered only days later
• One person knows where the backup is and how to restore it, so their absence stops the recovery

Source

Related guides

Key takeaways

• A backup must contain both files and database, because neither alone returns a site to a working state.
• At least one copy lives outside the server the site runs on, so a shared problem cannot destroy both.
• Frequency follows the business: daily for stores, weekly for sites with enquiries, plus a copy before every change.
• Restores are tested at a separate address, because that is the only way to know the backup works.
• Automatic backups fail quietly, so the list and the latest date are checked every month.

Conclusion

Backups are the least exciting part of running a site, which is why they get skipped most often. If you do not back up regularly, or do not know whether the last copy can be restored, that is the first thing worth fixing, before any other optimisation. If you would rather not think about it, our website maintenance packages include automatic backups and regular restore checks, and the wider protective measures are described in our articles on website security and the most common security mistakes.