A bad update, a compromised plugin, or a host that loses a disk can take a small site offline with no warning. A backup turns that scare into a ten minute recovery, but only if the copy exists somewhere safe and the restore has been proven to work. Here’s the whole setup for a typical small site: what to back up, how often, and how to test that the backup actually brings the site back.
Back up files and the database together
A website is two piles of data. The files are the theme, plugins, and uploads (images, PDFs, logos). The database holds the posts, pages, comments, product listings, and user accounts. Sites running on a host’s site builder have the same split, just hidden behind a dashboard.
Covering one pile and forgetting the other is the most common gap. The site comes back with all its images and none of its words, or the words return with broken image links everywhere. Whatever tool you pick has to capture both.
Choose the tool
For WordPress sites, a backup plugin does this without any terminal work. UpdraftPlus is the widely used option: it runs on a schedule, breaks large sites into manageable chunks, and pushes copies to remote storage automatically. Plenty of hosts offer their own backup tools too, but check where the copies land. If they sit on the same server as the site, one host problem takes the site and the backup at the same time.
For a static site or a custom setup, the old command line tools still work fine. Tar up the web directory and dump the database with `mysqldump`, which MySQL documents on its own site, then push the results somewhere with `rsync` or a scheduled job. The part that matters is the word automatic. Hand-run backups stop happening the first busy month.
Set the schedule and decide what to keep
Frequency should match how often the site changes. A blog or shop publishing every week wants daily backups. A brochure site that changes twice a year can settle for weekly. Match the retention to your own memory: keep four weekly snapshots plus three monthly ones, and that covers most of the accidents people notice late, like a page deleted in March and missed until April. After that, prune. Storage is cheap, but 400 daily files makes finding the right one harder than fixing the original problem.
Two rules about location. Keep the copies off the server, in a cloud drive, a bucket, or a machine at home. And keep at least one copy on a service with no connection to your host. If the account gets locked or the host has a bad week, that copy is what brings the site back.
Test the restore twice a year
A backup that’s never been restored is a guess. A test takes about half an hour and catches the failures no dashboard reports: truncated database dumps, missing upload folders, storage permissions that quietly stopped working months ago.
Restore into a staging subdomain or a local install, never over the live site. For a WordPress site that means creating an empty database, importing the dump, dropping the files into place, and updating the site URL in the options table so the copy points at its temporary home. Then click through it. Open the home page, read one post, upload an image, submit the contact form. If everything behaves, note the date and how long the restore took. That number is the real cost of a future incident, and it’s usually reassuringly small.
Keep the restore notes beside the backups
During an incident, nobody remembers the database prefix or which folder the uploads live in. Write a plain text note covering four things: where the backups are stored, how to download one, the steps to restore it, and the date of the last successful test. Store the note with the backups and somewhere you can reach without the host, like a password manager entry.
That’s the practice in full: automatic backups of files and database, copies kept away from the host, a bit of history, and a test restore every six months. The backup job takes five minutes to set up. The test is what makes those files worth keeping.