A scheduled backup protects you from yesterday. An update that breaks the site breaks it now, and the last copy may be twenty hours old with a day of orders in between. The backup that matters is the one taken immediately before the change.

One command

#!/usr/bin/env bash\n# /usr/local/bin/snap\nset -euo pipefail\nSITE=/var/www/site\nOUT=/srv/backup/pre-change/$(date +\%F-\%H\%M)\nmkdir -p "$OUT"\ntar -czf "$OUT/files.tar.gz" -C "$SITE" .\nmysqldump --single-transaction --quick --routines --triggers dbname | gzip > "$OUT/db.sql.gz"\necho "$OUT"
sudo snap && sudo apt-get upgrade

Make it automatic where the tools allow it

  • A deploy script runs it as its first step, before anything is copied.
  • Package updates: apt hooks, or a wrapper you use instead of apt.
  • CMS updates: most have a plugin that snapshots first - use it, and keep your own copy too.

Know how to go back BEFORE you go forward

Write the rollback command down next to the snapshot path. If it is not one line you can paste, the rollback will not happen quickly enough to matter.

# rollback\ntar -xzf /srv/backup/pre-change/2026-09-05-0930/files.tar.gz -C /var/www/site\nzcat /srv/backup/pre-change/2026-09-05-0930/db.sql.gz | mysql dbname
Restoring the database undoes every order and every registration since the snapshot. On a busy site, restore the FILES first and only touch the database if the fault is genuinely in the data.

Clean them up

find /srv/backup/pre-change -maxdepth 1 -type d -mtime +14 -exec rm -rf {} +
Update one thing at a time. Five plugins at once means the fault could be any of them, and the rollback loses all five improvements to find one fault.