A Backup Routine That Actually Restores

What a complete backup contains

Three parts, and a backup missing any one of them will not bring a site back:

• The database. Everything editorial: articles, menus, users, extension settings.
• The files. Extensions, templates, overrides, and images/ — which is usually the largest part and the only copy of it that exists.
• configuration.php. Credentials, paths, secret. Small, easy to forget, and the site does not start without it.

What you can skip: cache/, tmp/, and the session table's contents. Excluding those often halves the archive size.

Doing it by hand

# database
mysqldump --single-transaction --quick \
  -u dbuser -p dbname | gzip > db-$(date +%F).sql.gz

# files
tar czf files-$(date +%F).tar.gz \
  --exclude='cache/*' --exclude='tmp/*' \
  /path/to/site

--single-transaction is the flag that matters. Without it, a dump of an InnoDB database taken while the site is being written to can capture a half-finished state — tables consistent individually, inconsistent with each other. That produces a backup which restores without errors and is subtly wrong.

Where it must not live

Not on the same server. A backup on the machine you are backing up protects against your own mistakes and nothing else — not disk failure, not a compromised account, not the host suspending you.

Not in the web root either. An archive at /backups/site-2026-08.tar.gz is a downloadable copy of your database credentials, and these paths get guessed.

The rule of thumb worth keeping: three copies, two kinds of storage, one of them somewhere else entirely. For a small site that is the server, your machine, and object storage or a cloud drive.

Encrypt what leaves the server

The archive contains your database password, the Joomla secret, and every user record on the site. Encrypt it before it goes to third-party storage:

gpg --symmetric --cipher-algo AES256 files-2026-08-11.tar.gz

Then store the passphrase somewhere that is not the same account as the backups.

Extensions

A backup component is worth using — the good ones handle the dump, the exclusions, the upload and the schedule, and their restore tooling rebuilds a site on a different host without you assembling it by hand.

Check two things: that it can write to remote storage, not just local disk, and that its restore process works without the component being installed. A backup you can only restore with a working copy of the site is a backup for the wrong scenario.

The part everyone skips

Restore one. Not in theory — take the most recent archive, build the site somewhere else, load it in a browser, sign in.

The failures this exposes are ordinary and fatal: the dump is truncated because disk filled up, images/ was never included, the database user in the restored config no longer exists, the archive needs a passphrase nobody wrote down. Every one of those is trivial to fix on a Tuesday and unrecoverable during an outage.

Do it once when you set the routine up, then once every few months, and after any change to what is being backed up.

Before every update

Separate from the schedule: take a backup before updating Joomla or any extension, and know how to put it back. Most sites that die during an update die because rolling back was not part of the plan.