Eine geplante Sicherung schützt Sie vor gestern. Ein Update, das die Seite zerlegt, zerlegt sie jetzt, und die letzte Kopie ist vielleicht zwanzig Stunden alt, mit einem Tag Bestellungen dazwischen. Die Sicherung, auf die es ankommt, ist die unmittelbar vor der Änderung.

Ein Befehl

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

Automatisieren Sie es, wo die Werkzeuge es zulassen

  • Ein Deploy-Skript führt ihn als ersten Schritt aus, bevor irgendetwas kopiert wird.
  • Paket-Updates: apt-Hooks oder ein Wrapper, den Sie statt apt benutzen.
  • CMS-Updates: die meisten haben ein Plugin, das vorher einen Snapshot zieht — nutzen Sie es, und behalten Sie zusätzlich Ihre eigene Kopie.

Wissen Sie, wie Sie zurückkommen, BEVOR Sie vorgehen

Schreiben Sie den Rollback-Befehl neben den Snapshot-Pfad. Ist er nicht eine Zeile zum Einfügen, kommt das Zurückrollen nicht schnell genug, um noch zu helfen.

# rollback
tar -xzf /srv/backup/pre-change/2026-09-05-0930/files.tar.gz -C /var/www/site
zcat /srv/backup/pre-change/2026-09-05-0930/db.sql.gz | mysql dbname
Die Datenbank zurückzuspielen macht jede Bestellung und jede Registrierung seit dem Snapshot rückgängig. Auf einer gut besuchten Seite stellen Sie zuerst die DATEIEN wieder her und fassen die Datenbank nur an, wenn der Fehler wirklich in den Daten steckt.

Und räumen Sie auf

find /srv/backup/pre-change -maxdepth 1 -type d -mtime +14 -exec rm -rf {} +
Aktualisieren Sie eines nach dem anderen. Fünf Plugins auf einmal heißt, der Fehler kann in jedem stecken, und das Zurückrollen verliert alle fünf Verbesserungen, um einen Fehler zu finden.