Une sauvegarde planifiée vous protège d'hier. Une mise à jour qui casse le site le casse maintenant, et la dernière copie peut avoir vingt heures, avec une journée de commandes entre les deux. La sauvegarde qui compte est celle prise juste avant la modification.

Une commande

#!/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

Automatisez-la là où les outils le permettent

  • Un script de déploiement l'exécute en première étape, avant toute copie.
  • Mises à jour de paquets : les hooks apt, ou une enveloppe que vous utilisez à la place d'apt.
  • Mises à jour de CMS : la plupart ont une extension qui prend un instantané d'abord — utilisez-la, et gardez aussi votre propre copie.

Sachez revenir en arrière AVANT d'avancer

Notez la commande de retour arrière à côté du chemin de l'instantané. Si ce n'est pas une ligne que vous pouvez coller, le retour n'arrivera pas assez vite pour servir.

# 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
Restaurer la base annule chaque commande et chaque inscription depuis l'instantané. Sur un site fréquenté, restaurez d'abord les FICHIERS et ne touchez à la base que si la panne est vraiment dans les données.

Puis faites le ménage

find /srv/backup/pre-change -maxdepth 1 -type d -mtime +14 -exec rm -rf {} +
Mettez à jour une chose à la fois. Cinq extensions d'un coup, c'est la panne qui peut venir de n'importe laquelle, et le retour arrière perd les cinq améliorations pour trouver une panne.