Stratégie de sauvegarde pour serveur root : celle qui tient vraiment

La checklist des 30 premières minutes se termine sur une archive tar de /etc et sur ce constat : ce n'est pas encore une sauvegarde, seulement une copie posée sur le même disque. C'est là que ce guide prend le relais, en montrant comment en faire une stratégie qui survit à une perte totale.

La phrase autour de laquelle tout tourne : une sauvegarde dont on n'a jamais rien restauré n'est pas une sauvegarde, c'est un espoir. Tout le reste sert à transformer cet espoir en affirmation vérifiée.

Toutes les commandes s'exécutent en tant que root. En utilisateur normal, faites précéder chaque commande de sudo. Les systèmes de référence sont Debian 13 (trixie), Debian 12 (bookworm), Ubuntu 24.04 LTS et Ubuntu 22.04 LTS. Là où ces quatre systèmes divergent, c'est précisé.

Avant de changer quoi que ce soit : le chemin du retour

La sauvegarde elle-même casse rarement. Ce sont les gestes autour d'elle qui sont dangereux : une restauration qui écrit par-dessus le système en fonctionnement, un dépôt qui remplit le disque système, des fichiers de clés qui remplacent votre propre accès. Quatre points au préalable.

1. Connaître l'accès console avant d'en avoir besoin

Sur les serveurs root KVM et les serveurs dédiés de KernelHost, vous atteignez la console VNC depuis l'espace client. Elle ne dépend pas de la pile réseau du système invité et répond encore quand SSH reste muet. C'est la voie de secours quand une restauration a écrasé la sshd_config ou l'authorized_keys actuelle par une ancienne version. Connectez-vous une fois par ce biais avant d'en avoir besoin et vérifiez que vous connaissez le mot de passe root.

2. Ne jamais restaurer vers / dès le premier essai

La première restauration va toujours dans un répertoire vide, par exemple /var/tmp/restore-test. De là, vous comparez et vous recopiez uniquement ce qui doit l'être. Une restauration lancée directement vers / écrase aussi les fichiers qui ont changé depuis la sauvegarde, et pour de bonnes raisons.

3. Garder une seconde session ouverte

Tant que vous travaillez sur des clés SSH ou sur l'authorized_keys de la destination, la même règle s'applique que pour la mise en place d'un pare-feu : gardez un second terminal avec une connexion établie et ne le fermez qu'une fois qu'une nouvelle connexion fonctionne.

4. Vérifier la place avant que le dépôt ne grossisse

df -h /
df -i /

La plupart des gens oublient la seconde ligne : un système de fichiers se remplit aussi alors qu'il reste des gigaoctets libres, à savoir quand les inodes viennent à manquer. Un dépôt local qui remplit le disque système compte parmi les pannes que l'on s'inflige le plus souvent à soi-même. C'est pourquoi la destination se trouve ici en dehors du serveur dès le départ.

La règle 3-2-1 appliquée à un serveur unique

• Trois copies. Les données de production sont la première copie. Il faut donc deux sauvegardes, et non une seule.
• Deux emplacements de stockage différents. Deux répertoires sur le même disque ne forment qu'un seul emplacement, et deux disques dans la même grappe RAID également : un rm malheureux touche les deux. Le RAID protège contre la panne d'un support de données, et contre rien d'autre.
• Une copie hors site. Pas le même serveur, pas le même compte d'administration, idéalement pas le même site.

Deux compléments sont nécessaires. Premièrement, une copie devrait se trouver là où le serveur lui-même ne peut pas l'effacer, car celui qui prend le contrôle de votre serveur y trouve les identifiants d'accès à la destination. Deuxièmement, une copie ne compte qu'une fois qu'elle a été vérifiée. Une image système rangée dans le même espace client est commode, mais elle ne compte pas comme copie hors site.

Fixez en plus deux chiffres : combien d'heures de perte de données vous pouvez accepter (cela détermine l'intervalle entre deux exécutions), et combien de temps la restauration peut durer (cela décide de la nécessité d'une image système supplémentaire).

Ce qui doit être sauvegardé, et ce qui ne doit pas l'être

L'erreur la plus fréquente n'est pas de sauvegarder trop peu, c'est de tout sauvegarder. Qui écrit / sans aucune exclusion emporte au passage les caches de paquets, les fichiers temporaires et le swap.

apt-mark showmanual > /root/liste-paquets.txt
dpkg --get-selections > /root/selection-paquets.txt
wc -l /root/liste-paquets.txt /root/selection-paquets.txt

apt-mark showmanual ne liste que les paquets installés de façon explicite, sans les dépendances entraînées avec eux : c'est la liste courte dont vous avez besoin pour une reconstruction.

Fichiers, base de données, image : trois méthodes qui ne se remplacent pas

Il en découle un ordre, pas un choix. D'abord le serveur de base de données écrit un dump, ensuite la sauvegarde de fichiers s'exécute, et le répertoire de données reste exclu. Une copie de fichiers de /var/lib/mysql prise en pleine activité capture différentes tables à différents instants. Savoir si elle se laisse restaurer, vous l'apprendrez au pire moment possible.

Le fichier d'identifiants, les droits et les pièges du dump sont traités dans Sauvegarder automatiquement vos bases MySQL et MariaDB. Ce qui compte ici, c'est le point de jonction : les dumps atterrissent dans /var/backups/db, y restent un à deux jours, et la conservation est prise en charge par le dépôt. Pour PostgreSQL, vous sauvegardez avec pg_dumpall en tant qu'utilisateur postgres.

restic ou Borg

Tous deux découpent les fichiers en blocs, ne stockent qu'une seule fois les blocs identiques, chiffrent et déposent des états versionnés. Tous deux sont empaquetés sur les quatre distributions. La différence qui emporte la décision figure sur la dernière ligne.

Sur un stockage où vous ne pouvez rien installer, Borg est hors jeu. S'il s'agit d'un second serveur Linux que vous administrez vous-même, le mode append-only plaide pour Borg.

Mise en place avec restic

apt update
apt install -y restic
restic version

Vérifiez la sortie avant de créer un dépôt : les quatre distributions livrent des versions très différentes, et un dépôt créé par une version récente ne s'ouvre pas forcément depuis une version plus ancienne.

Accès à la destination

La destination est ici un second serveur joignable en SSH. La clé appartient à root, car seul root a le droit de lire tous les fichiers à sauvegarder :

ssh-keygen -t ed25519 -N '' -f /root/.ssh/id_ed25519_backup -C 'sauvegarde srv01'
ssh-copy-id -i /root/.ssh/id_ed25519_backup.pub sauvegarde@203.0.113.50

cat > /root/.ssh/config <<'EOF'
Host destination-sauvegarde
    HostName 203.0.113.50
    User sauvegarde
    IdentityFile /root/.ssh/id_ed25519_backup
    BatchMode yes
EOF
chmod 600 /root/.ssh/config

Contrôle de réussite : ssh destination-sauvegarde true s'exécute sans sortie et sans question. La toute première connexion demande confirmation de la clé d'hôte : répondez maintenant, et pas plus tard dans un service qui ne peut attendre personne.

Mot de passe et dépôt

install -d -m 700 /etc/restic
head -c 32 /dev/urandom | base64 | tr -d '\n' > /etc/restic/repo.pass
chmod 600 /etc/restic/repo.pass

cat > /etc/restic/env <<'EOF'
RESTIC_REPOSITORY=sftp:destination-sauvegarde:/srv/sauvegarde/srv01
RESTIC_PASSWORD_FILE=/etc/restic/repo.pass
EOF
chmod 600 /etc/restic/env

Ce fichier convient aussi bien au shell qu'à systemd. Dans le shell :

set -a; . /etc/restic/env; set +a
restic init

Contrôle de réussite : restic cat config affiche une courte structure JSON contenant l'identifiant du dépôt. Si la question Is there a repository at the following location? apparaît, c'est que le chemin est faux ou que restic init n'a jamais été lancé.

La première exécution

cat > /etc/restic/excludes.txt <<'EOF'
/proc
/sys
/dev
/run
/tmp
/var/tmp
/var/cache
/var/lib/apt/lists
/var/lib/mysql
/swapfile
EOF

restic backup / --one-file-system --exclude-file=/etc/restic/excludes.txt --exclude-caches --tag system

--one-file-system maintient la sauvegarde sur le système de fichiers racine et laisse de côté les partages réseau montés. --exclude-caches saute les répertoires qui se sont eux-mêmes signalés comme caches. L'exclusion de /var/lib/mysql est la mise en pratique de la section précédente.

Contrôle de réussite : l'exécution se termine par une ligne du type snapshot 0a1b2c3d saved. Ensuite :

restic snapshots
restic stats latest

La liste indique l'horodatage, le nom de la machine et les chemins. Si restic stats latest affiche une taille étonnamment petite, c'est qu'une exclusion va trop loin.

La même chose avec Borg

apt install -y borgbackup
borg --version
export BORG_REPO='ssh://sauvegarde@203.0.113.50/./srv01'
borg init --encryption=repokey-blake2

borg create --stats --compression zstd ::'system-{now}' /etc /var/www /home /var/backups
borg list
borg info

Les quatre distributions livrent une version de la série 1.x. Borg doit être présent des deux côtés, et la version sur la destination ne devrait pas être plus ancienne que celle du serveur. Exploitez un dépôt distinct par serveur : cela vous évite d'avoir à limiter le nettoyage aux archives de ce serveur précis, et cela permet des clés d'accès séparées.

Contrôle de réussite : borg list affiche l'archive avec son horodatage, borg info la taille avant et après déduplication.

Conservation : plus longue que ce que prévoient la plupart des gens

La durée de conservation ne se règle pas sur le temps pendant lequel vous aimeriez garder vos données, mais sur le temps qu'il faut pour qu'un dommage se remarque. Un répertoire supprimé se voit le jour même, une table corrompue souvent des semaines plus tard. Qui ne garde que sept jours a alors sauvegardé le dommage pendant sept jours.

restic forget --dry-run --keep-daily 7 --keep-weekly 4 --keep-monthly 6
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

L'exécution à blanc montre quels états disparaîtraient. Sans --prune, seules les références partent et la place reste occupée. Chez Borg, l'opération se fait en deux temps depuis la version 1.2, et la seconde commande oubliée explique la plupart des dépôts qui refusent de rétrécir :

borg prune --list --dry-run --keep-daily=7 --keep-weekly=4 --keep-monthly=6
borg prune --list --keep-daily=7 --keep-weekly=4 --keep-monthly=6
borg compact

Contrôle de réussite : restic snapshots ou borg list montre l'échelonnement attendu, et la taille occupée sur la destination diminue.

Le chiffrement, et la clé que plus personne ne retrouve ensuite

Les deux outils chiffrent avant que les données ne quittent le serveur. La destination ne voit que des blocs illisibles, ce qui rend acceptable un stockage qui ne vous appartient pas. Le prix est sans ambiguïté : sans le mot de passe ou sans la clé, les données sont définitivement perdues. Il n'existe aucune porte dérobée.

Deux règles en découlent. Premièrement, le mot de passe a sa place à un second endroit, habituellement dans un gestionnaire de mots de passe. Un mot de passe qui n'existe que dans /etc/restic/repo.pass disparaît avec le serveur, et la sauvegarde avec lui. Deuxièmement, avec Borg en mode repokey, exportez la clé et rangez-la à l'extérieur, car elle réside sinon dans le dépôt lui-même :

borg key export ::

Contrôle de réussite : depuis une autre machine, exécutez restic snapshots avec le mot de passe tiré du gestionnaire. Un mot de passe que vous n'avez jamais utilisé depuis un autre endroit reste non confirmé.

Protéger la destination contre l'effacement

Un attaquant disposant des droits root a aussi accès au mot de passe stocké et à la clé de la destination. Il peut donc effacer la sauvegarde avant de chiffrer les données de production. Il faut par conséquent un emplacement qui accepte de nouveaux états mais n'autorise aucune suppression. Chez Borg, cela se règle dans l'authorized_keys de l'utilisateur de sauvegarde sur la destination :

command="borg serve --append-only --restrict-to-path /srv/sauvegarde/srv01",restrict ssh-ed25519 AAAA... sauvegarde srv01

La clé n'accepte alors plus que des sauvegardes, et uniquement dans ce chemin. Attendez-vous à ce qu'un prune s'exécute ici jusqu'au bout sans libérer la moindre place, parce que la suppression n'est pas effectuée sur la destination. Le nettoyage, vous le faites là où le serveur n'a aucun accès. Chez restic, ce rôle revient au serveur REST en mode append-only ou à un stockage objet avec versionnage. Un simple accès SFTP n'en est pas capable.

Automatiser avec un timer systemd

Un timer est préférable à une tâche cron, parce qu'il écrit sa sortie dans le journal, rattrape les exécutions manquées et a le droit d'étaler l'heure de démarrage. Pour la construction des unités : Créer son propre service systemd.

cat > /etc/systemd/system/sauvegarde.service <<'EOF'
[Unit]
Description=Sauvegarde quotidienne avec restic
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/etc/restic/env
Nice=10
IOSchedulingClass=idle
ExecStart=/usr/bin/restic backup / --one-file-system --exclude-file=/etc/restic/excludes.txt --exclude-caches --tag system
ExecStart=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
EOF

cat > /etc/systemd/system/sauvegarde.timer <<'EOF'
[Unit]
Description=Lance la sauvegarde quotidienne

[Timer]
OnCalendar=*-*-* 02:30:00
RandomizedDelaySec=1800
Persistent=true

[Install]
WantedBy=timers.target
EOF

systemctl daemon-reload
systemctl enable --now sauvegarde.timer
systemd-analyze calendar '*-*-* 02:30:00'

Plusieurs lignes ExecStart dans une unité oneshot s'exécutent l'une après l'autre, et un échec interrompt la chaîne. Le nettoyage ne tourne donc qu'après une sauvegarde réussie. Si la destination est un système de fichiers monté, une protection doit venir avant, sinon l'exécution écrit sans bruit dans le point de montage vide :

ExecStartPre=/usr/bin/mountpoint -q /mnt/sauvegarde

Contrôle de réussite :

systemctl start sauvegarde.service
systemctl list-timers sauvegarde.timer
journalctl -u sauvegarde.service -n 50 --no-pager

systemctl list-timers doit indiquer une prochaine heure de démarrage. S'il n'y a rien, c'est que le timer n'est pas activé. Le point le plus important vient en dernier : une exécution qui cesse discrètement de tourner, c'est la façon normale dont une sauvegarde échoue. Vérifiez systemctl is-failed sauvegarde.service, ou ajoutez comme dernière ligne ExecStart un appel à un service de supervision externe, qui donne l'alerte quand le signe de vie quotidien n'arrive pas.

Tester la restauration

Le petit test, tous les mois, cinq minutes

mkdir -p /var/tmp/restore-test
restic restore latest --target /var/tmp/restore-test --include /etc/ssh/sshd_config
diff /etc/ssh/sshd_config /var/tmp/restore-test/etc/ssh/sshd_config && echo "identique"

La même chose avec Borg, qui enregistre les chemins sans barre oblique initiale :

cd /var/tmp/restore-test
borg extract --list ::system-2026-09-03T02:30:00 etc/ssh/sshd_config

Vérifiez en plus l'intégrité du dépôt. Dans les deux cas, la seconde ligne relit les données et recalcule les sommes de contrôle, chez restic sur une fraction seulement pour que l'opération ne dure pas des heures :

restic check
restic check --read-data-subset=1/7

borg check
borg check --verify-data

Contrôle de réussite : restic check se termine par no errors were found, borg check sans message d'erreur. Un dépôt vérifié une seule fois par an peut avoir été défectueux pendant onze mois.

Le grand test, une fois par an

Le petit test prouve que les fichiers sont lisibles. Il ne prouve pas que vous arrivez à remettre le service en marche. Pour cela, il faut le parcours complet sur un second serveur vide : installer le système de base, appliquer la liste des paquets, raccorder le dépôt, rapatrier les données, importer le dump, démarrer les services. Chronométrez. Ce chiffre est votre durée de restauration réelle, et l'expérience montre qu'elle vaut plusieurs fois celle que vous aviez estimée.

Notez ce qui a manqué. Ce sont presque toujours les mêmes choses : un fichier en dehors des chemins sauvegardés, un service dont la configuration se trouve sous /opt, un certificat sans sa clé de compte, une base de données sans ses utilisateurs ni ses droits. Cette liste, c'est le bénéfice du test.

Erreurs fréquentes et solutions

Host key verification failed. Le service tourne en tant que root, et root n'a jamais confirmé la clé d'hôte de la destination. Exécutez une fois à la main ssh destination-sauvegarde true, ou ssh-keyscan -H 203.0.113.50 >> /root/.ssh/known_hosts. Cela fonctionne en console mais pas dans le timer : c'est presque toujours cette erreur.

Permission denied (publickey). Mauvais utilisateur, mauvaise clé ou mauvais droits sur la destination : .ssh a besoin de 700, authorized_keys de 600, et les deux appartiennent à l'utilisateur de la destination.

Is there a repository at the following location? restic ne trouve aucune structure de dépôt : chemin faux, restic init jamais lancé, ou destination momentanément injoignable.

Fatal: wrong password or no key found Le fichier de mot de passe ne correspond pas au dépôt, le plus souvent parce qu'il a été régénéré après coup. Vérifiez avec cat -A /etc/restic/repo.pass qu'aucun espace ne s'y est glissé.

repository is already locked exclusively by Une exécution interrompue a laissé son verrou derrière elle. Assurez-vous d'abord que plus rien ne tourne, puis lancez restic unlock. Chez Borg, le message est Failed to create/acquire the lock avec la mention (timeout), et la commande borg break-lock. Les deux commandes restent risquées tant qu'une exécution est réellement active.

Warning: The repository at location ... was previously located at ... L'adresse du dépôt a changé, et Borg pose la question de façon interactive. Dans une unité, la commande attend alors une réponse qui ne viendra jamais. Une fois que vous avez vérifié qu'il s'agit bien du même dépôt, placez BORG_RELOCATED_REPO_ACCESS_IS_OK=yes dans le fichier d'environnement.

No space left on device sur la destination. Soit le nettoyage ne tourne pas du tout, soit il tourne sans --prune ou sans borg compact. Si c'est l'inverse et qu'un dump a rempli le système de fichiers racine, Disque plein sous Linux : libérer de l'espace prend le relais.

L'exécution annonce une réussite, mais ne sauvegarde presque rien. Une exclusion va trop loin, ou un chemin est mal écrit. Comparez restic stats latest à la valeur de la veille. Une sauvegarde soudain plus petite de plusieurs ordres de grandeur est une alarme, pas une réussite.

Différences entre les distributions

• Les noms de paquets sont identiques sur les quatre systèmes : restic et borgbackup. Les versions livrées, non.
• Journalisation : Debian 13 et beaucoup d'installations Debian 12 ne fournissent pas rsyslog. Vous y trouverez la sortie de l'exécution uniquement dans le journal, donc via journalctl -u sauvegarde.service. Sous Ubuntu 22.04 et 24.04, les fichiers sous /var/log viennent s'y ajouter.
• Monter des états sauvegardés : restic mount et borg mount ont besoin de fuse3. Si le paquet manque, la commande s'interrompt en signalant un fusermount3 absent. La voie sans FUSE passe par restic restore ou borg extract.
• Outil de base de données : Debian ne livre que MariaDB, où l'outil s'appelle mariadb-dump avec mysqldump comme lien vers lui. Sous Ubuntu, MySQL 8 peut aussi tourner, et là seul mysqldump existe.

Le contrôle final

La stratégie est achevée quand vous pouvez étayer ces sept points par une commande et non par une supposition :

1. restic snapshots ou borg list montre un état de la nuit dernière.
2. systemctl list-timers sauvegarde.timer indique une prochaine heure de démarrage.
3. restic check ou borg check ne signale aucune erreur.
4. Un fichier isolé a pu être restauré ce mois-ci et s'est révélé ensuite identique.
5. L'échelonnement correspond à la conservation prévue, et le dépôt ne grossit pas sans limite.
6. Le mot de passe se trouve à un second endroit, et vous vous en êtes déjà servi depuis là-bas.
7. Au moins un emplacement accepte des sauvegardes sans que le serveur puisse les effacer.

S'il manque le point quatre, vous avez une supposition. S'il manque le point six, des données chiffrées bonnes à jeter. S'il manque le point sept, une sauvegarde qui ne survit justement pas à l'attaque contre laquelle on en a le plus urgemment besoin.