Client Website Backups You Can Actually Restore

A backup that has never been restored is only a file that feels reassuring. When a client site breaks after a plugin update or a malware incident, what you need is a copy that can run again on staging in a known amount of time.

This is the backup standard I want in place before I hand a project over.

Three parts that must all exist

1. Application files — core, theme, plugins, and media. A hosting snapshot that copies a disk you have never inspected is not enough.
2. Database — a dump you can import, not only an “automatic backup” whose restore button has never been tried.
3. DNS and account notes — where the domain points, who owns it, and where passwords live. Without this, intact files still cannot go online.

Keep a copy off the same server. A backup on the disk that fails does not help.

Test the restore, do not only tick the schedule

Once before go-live, and again after a large change:

• restore files and the database to staging or a subdomain;
• open the homepage, one inner page, and a form;
• confirm URLs are not still pointing at production by accident;
• write down how long it took.

“15 minutes until staging is up” is more useful to a client than “daily backups are on.”

When a fresh copy is mandatory

• before a WordPress, theme, or plugin update;
• before a hosting or domain migration;
• after malware cleanup, as a clean copy stored apart from the infected one;
• after a large content drop (catalog, school pages, gallery).

Retention I like for a small business site: 7 daily copies, 4 weekly copies, plus one post-launch copy that is not overwritten.

A handover that is not confusing

Document a few lines:

• where backups are stored;
• who can download them;
• the short restore steps;
• what is not included (email, the DNS registrar) when that sits outside the package.

A backup plugin is fine to use. Trusting it without one trial restore is not.