freedzhost.cloud

Homelab 5 : des sauvegardes qui survivent à une attaque de votre serveur

Niveau IntermédiaireTemps estimé 1 hÀ lire avant Homelab 1 : Proxmox, la base sous chaque serviceUn mot inconnu ? Lexique

Une sauvegarde vous protège d'un disque mort. Une bonne sauvegarde vous protège aussi de votre propre serveur qui se retourne contre vous : une erreur lancée en root, un rançongiciel, un attaquant. Le conseil habituel, c'est « garder une copie ailleurs ». Le détail qui le rend efficace, c'est le sens : la seconde copie doit être tirée par une autre machine, pas poussée par le serveur.

Hyperviseurécrit la copie 1, 02:00Copie 1disque externe, 7 jours + 4 semainessauvegarde nocturneUne autre machinetire la copie 2, 03:00Copie 2miroir + quarantainetirée avec une clé en lecture seule (rrsync -ro)aucun accès, aucune écriture
La copie 1 est écrite par l'hyperviseur chaque nuit. La copie 2 est tirée par une autre machine, avec une clé qui ne sait que lire : ce qui prendrait le contrôle de l'hyperviseur ne peut pas l'atteindre.

1. Copie 1 : chaque nuit, sur un autre disque

Dans Proxmox (Homelab 1), Datacenter → Backup → Add : chaque invité, chaque nuit, vers un stockage sur un disque séparé. Notre rétention garde 7 points quotidiens et 4 hebdomadaires :

keep-daily=7, keep-weekly=4

Nous gardions trois points en tout : un problème remarqué trois jours trop tard, et chaque point l'aurait contenu. Comptez combien de jours il vous faudrait pour remarquer un problème, puis doublez.

Un disque externe survit à une carte mère morte. Mais il reste monté et écrit par le serveur : tout ce qui détruit à travers le serveur l'atteint aussi. C'est à ça que sert la copie 2.

2. Copie 2 : tirée avec une clé qui ne sait que lire

Sur le serveur, créez un utilisateur non privilégié dont la clé SSH ne sait faire qu'une chose : lire le dossier des sauvegardes. Dans son ~/.ssh/authorized_keys, une ligne :

command="/usr/bin/rrsync -ro /chemin/des/sauvegardes",restrict ssh-ed25519 AAAA… copie2

rrsync est fourni avec rsync ; -ro le met en lecture seule et enferme la clé dans ce dossier ; restrict retire tout le reste (shell, redirections). Puis, sur l'autre machine, chaque nuit après la copie 1 :

rsync -a --delete \
  --backup --backup-dir=../quarantaine/$(date +%F) \
  sauvegarde@votre-serveur:./ /chemin/de/la/copie2/

--delete garde un miroir exact ; --backup-dir déplace tout ce qui est supprimé ou remplacé dans une quarantaine datée au lieu de le perdre. Gardez une semaine de quarantaine.

Vérifiez la clé comme le ferait un attaquant, quatre tests : ouvrir un shell doit être refusé, lire doit marcher, écrire doit être refusé, s'échapper avec .. doit être refusé.

3. Restaurer, pour de vrai

Une fois par mois, restaurez un invité depuis la copie 2 sous un nouvel identifiant inutilisé, sur une machine de test, et démarrez-le. Une sauvegarde jamais restaurée est un espoir, pas une sauvegarde.

Pièges

L'utilisateur de sauvegarde doit pouvoir lire les archives : vérifiez leurs droits après la première nuit, sinon la copie 2 reste vide sans erreur.

Donnez un plancher à la machine qui tire : si l'espace libre passe sous un seuil, elle refuse de tourner et le dit. Un disque plein au milieu d'une copie laisse un miroir à moitié écrit.

Une copie ne vaut que l'alarme qui dit qu'elle a échoué. Faites remonter le résultat de la tâche nocturne là où vous regardez vraiment.

Utile ? Dites-nous ce qu'il faut mesurer ensuite.