Sauvegardes, surveillance et la routine mensuelle

Le site est en ligne. Cette page fait en sorte que, le jour où quelque chose casse, tu sois le premier au courant et que tu puisses tout remettre en place. Tu décides de ce qui mérite d'être sauvegardé, tu trouves les sauvegardes d'OVH, tu envoies chaque nuit une copie chiffrée hors site avec restic, tu restaures une fois pour prouver que ça marche, tu mets une surveillance externe sur le site, tu plafonnes les logs, et tu termines par une routine de dix minutes à faire une fois par mois.

Avant de commencer

Les pages 3 à 6 sont faites : tu te connectes avec ssh vps, Caddy sert le site en HTTPS, et les déploiements passent par vps-deploy. Tout ce qui suit se lance sur le serveur après ssh vps, en ops, sauf les tableaux de bord web et les blocs marqués pour le Mac.

$systemctl is-active caddy

active

Quoi sauvegarder

La source du site ne vit que dans le dossier du projet sur ton Mac, ~/sites/example.com/src : c'est de là que le site se reconstruit et se redéploie en quelques minutes (pages 1 et 6). Ce que le Mac ne sait pas reconstruire, c'est l'état du serveur lui-même.

Sauvegardes et snapshots OVH

Dans l'espace client OVH, ouvre ton VPS (Bare Metal Cloud → Serveurs privés virtuels → le VPS). L'onglet Accueil liste les options : Sauvegarde automatique et Snapshot.

• Sauvegarde automatique : incluse avec le VPS, une par jour, un jour de rétention. Le ... à côté → Restaurer.
• Snapshot : une option payante. Tu le prends à la main, avant un changement risqué : une montée de version majeure de Debian, une config Caddy dont tu n'es pas sûr, un changement de pare-feu.

Créer le bucket et les clés

La copie hors site part vers un stockage objet S3 : un bucket, plus un utilisateur S3 dont restic utilise les clés. Chez OVH, dans l'espace client :

1. Public Cloud → crée un projet si tu n'en as pas (il faut un moyen de paiement).
2. Object Storage → Créer un conteneur d'objets : API S3, classe standard, région GRA (Gravelines), nom site-backups.
3. Object Storage → Utilisateurs S3 → crée un utilisateur, donne-lui lecture/écriture sur le conteneur, et copie sa clé d'accès et sa clé secrète dans le panneau des valeurs et dans ton gestionnaire de mots de passe.

Mettre en place restic

restic fait des snapshots chiffrés et dédupliqués de répertoires dans un « dépôt », ici le bucket. Installe-le, puis écris ses identifiants dans un fichier que seul root peut lire.

$sudo apt install -y restic
$sudo install -d -m 700 /etc/restic
$sudo install -m 600 /dev/null /etc/restic/env

Puis écris les identifiants dedans : copie la commande et colle-la dans le terminal. Le fichier existe déjà en mode 600, et tee garde ce mode : seul root peut lire les secrets.

RESTIC_REPOSITORY=s3:https://s3.gra.io.cloud.ovh.net/site-backups
AWS_ACCESS_KEY_ID=${S3_ACCESS_KEY}
AWS_SECRET_ACCESS_KEY=${S3_SECRET_KEY}
RESTIC_PASSWORD=${RESTIC_PASSWORD}

Ensuite la liste de ce qu'on ignore, /etc/restic/excludes :

/home/*/.cache
/var/lib/caddy/.local/share/caddy/locks

Et le dépôt lui-même :

$sudo bash -c 'set -a; . /etc/restic/env; restic init'

$sudo vim /etc/restic/env

Maintenant le travail de nuit : un service systemd qui fait la sauvegarde et élague les vieux snapshots, et un timer qui le lance.

[Unit]
Description=Nightly restic backup to off-site S3
Wants=network-online.target
After=network-online.target
[Service]
Type=oneshot
EnvironmentFile=/etc/restic/env
Environment=RESTIC_CACHE_DIR=/var/cache/restic
CacheDirectory=restic
Nice=10
ExecStart=/usr/bin/restic backup /etc /var/lib/caddy /home /var/www/example.com --exclude-file=/etc/restic/excludes --tag nightly
ExecStartPost=/usr/bin/restic forget --prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6
ExecStartPost=-/usr/bin/curl -fsS -m 10 --retry 3 -o /dev/null ${HC_PING_URL}

Copie chaque bloc et colle-le dans le terminal du serveur : chacun écrit son fichier. Puis active le timer et lance une sauvegarde tout de suite :

$sudo systemctl daemon-reload
$sudo systemctl enable --now restic-backup.timer
$sudo systemctl start restic-backup.service

$systemctl is-active restic-backup.timer

active

$sudo systemctl show -p Result restic-backup.service

Result=success

Tester une restauration

Une sauvegarde jamais restaurée est un espoir, pas une sauvegarde. Restaure la configuration de Caddy dans un dossier de test et compare-la avec celle en service :

$sudo bash -c 'set -a; . /etc/restic/env; restic restore latest --target /tmp/restore-test --include /etc/caddy'
$sudo diff -r /etc/caddy /tmp/restore-test/etc/caddy && echo "restore OK"

$sudo diff -r /etc/caddy /tmp/restore-test/etc/caddy && echo 'restore OK'

restore OK

Ensuite, supprime la copie de test avec sudo rm -rf /tmp/restore-test.

Être prévenu quand ça casse

Un service externe interroge le site depuis internet et t'envoie un email quand il ne répond plus. UptimeRobot en est un exemple ; Better Stack et d'autres marchent pareil. Crée un compte gratuit et ajoute une sonde :

• Type Keyword (mot-clé), URL https://example.com/, toutes les 5 minutes.
• Mot-clé : un mot que seule ta vraie page d'accueil contient, par exemple ton nom dans le titre.
• Contact d'alerte : ${ADMIN_EMAIL}.

La sonde surveille le site ; healthchecks.io surveille la sauvegarde. Il marche dans l'autre sens : ton serveur le pingue après chaque sauvegarde, et il t'écrit quand le ping n'arrive pas. Sur healthchecks.io, crée un compte puis Add Check :

• Période 1 day, délai de grâce 2 hours.
• Intégrations : email vers ${ADMIN_EMAIL} (actif par défaut pour l'adresse du compte).
• Copie l'URL de ping, affichée sur la page du check, dans ${HC_PING_URL}. Si tu as déjà écrit restic-backup.service plus haut, recopie son bloc (il contient maintenant l'URL) et colle-le sur le serveur, puis recharge systemd et lance une sauvegarde :

$sudo systemctl daemon-reload
$sudo systemctl start restic-backup.service

Garder les logs sous contrôle

Par défaut, journald garde jusqu'à 10 % du disque, plafonné à 4 Go. Sur un VPS de 40 Go, plafonne-le à 500 Mo avec un fichier complémentaire, /etc/systemd/journald.conf.d/size.conf :

$sudo mkdir -p /etc/systemd/journald.conf.d

[Journal]
SystemMaxUse=500M

Copie la commande et colle-la dans le terminal, puis redémarre journald et regarde sa taille :

$sudo systemctl restart systemd-journald
$journalctl --disk-usage

$systemd-analyze cat-config systemd/journald.conf | grep '^SystemMaxUse'

SystemMaxUse=500M

La routine mensuelle

Dix minutes, une fois par mois, le même jour chaque mois. Depuis ton portable, ssh vps, puis :

$# 1. Paquets à mettre à jour : installe-les avec sudo apt upgrade
$sudo apt update && apt list --upgradable
$# 2. Après une mise à jour du noyau : sudo reboot, puis vérifie le site
$[ -f /var/run/reboot-required ] && echo "reboot needed"
$# 3. L'occupation du disque doit rester sous 80 %
$df -h /
$# 4. Adresses bannies (si fail2ban a été choisi page 3) : rien à faire, sauf si l'une est la tienne
$sudo fail2ban-client status sshd 2>/dev/null || echo "fail2ban not installed"
$# 5. Attendu : "0 loaded units listed"
$systemctl --failed
$# 6. Les erreurs du mois : lis-les une fois, cherche les nouvelles
$sudo journalctl -p err --since '30 days ago' | tail -n 30

Ensuite les sauvegardes : le timer montre le prochain passage, et le dernier snapshot doit dater de la nuit dernière.

$systemctl list-timers restic-backup.timer
$sudo bash -c 'set -a; . /etc/restic/env; restic snapshots --latest 3'

Pour finir, ouvre le tableau de bord de la sonde et regarde la disponibilité et les incidents du mois. Puis, sur le Mac, vérifie que Time Machine a sauvegardé le dossier du projet récemment :

$tmutil latestbackup

Terminé

L'état de ton serveur est sauvegardé de trois façons, et une restauration a fait ses preuves. Tu reçois un email quand le site ne répond plus, les logs ne peuvent plus remplir le disque, et une routine mensuelle vérifie que tout ça tient.

La page suivante, Checklist de lancement, repasse sur tout une dernière fois avant que tu annonces le site.