Sauvegardes automatiques et chiffrées d'un VPS avec restic

Une sauvegarde fiable ne doit jamais dépendre d’un seul disque, d’un seul serveur ou d’un seul site. La règle 3-2-1 recommande de conserver trois copies des données, sur deux supports différents, dont une copie externalisée. Pour un VPS, cela signifie que les sauvegardes ne doivent pas rester uniquement sur le volume système ou sur un second disque attaché à la même machine.

Cette copie distante doit aussi être chiffrée. Une erreur de configuration, une fuite d’identifiants ou un accès non autorisé au stockage ne doit pas exposer vos fichiers, configurations et bases de données. Restic répond bien à ce besoin : cet outil en ligne de commande chiffre les sauvegardes de bout en bout par défaut, déduplique les données et crée des snapshots incrémentaux. Il peut utiliser un dépôt local ou distant, notamment via SFTP ou un stockage objet compatible S3.

Ce guide complète notre stratégie de sauvegarde d’un serveur avec un outil concret et automatisable.

Prérequis

Vous devez disposer des éléments suivants :

• Un VPS Linux avec un accès administrateur.
• Suffisamment d’espace temporaire pour les éventuels dumps de bases de données.
• Un dépôt situé hors du VPS.
• Des identifiants dédiés au stockage distant.
• Une estimation des volumes, de la fréquence des changements et de la durée de rétention souhaitée.

Pour un stockage compatible S3, un dépôt peut prendre cette forme :

export RESTIC_REPOSITORY="s3:https://stockage.example.com/nom-du-bucket/restic-vps"
export AWS_ACCESS_KEY_ID="identifiant"
export AWS_SECRET_ACCESS_KEY="secret"

Pour un serveur SFTP :

export RESTIC_REPOSITORY="sftp:sauvegarde@backup.example.net:/srv/restic/vps-prod"

Dans ce second cas, utilisez de préférence une clé SSH dédiée, protégée et limitée au compte de sauvegarde. Vérifiez aussi la clé d’hôte du serveur distant avant toute automatisation.

Le dépôt doit être réellement indépendant du VPS. Un répertoire comme /backup situé sur le même disque ne protège ni contre une panne matérielle, ni contre la suppression du serveur, ni contre une compromission complète.

Installer restic

Sur Debian ou Ubuntu, restic peut être installé depuis les dépôts de la distribution :

sudo apt update
sudo apt install -y restic
restic version

Cette méthode facilite les mises à jour de sécurité, même si la version fournie peut être moins récente que la version officielle.

Pour utiliser le binaire officiel, téléchargez l’archive correspondant à l’architecture du VPS depuis les publications du projet. Vérifiez impérativement sa somme de contrôle avant l’installation :

sha256sum -c SHA256SUMS --ignore-missing
bunzip2 restic_*_linux_amd64.bz2
sudo install -m 0755 restic_*_linux_amd64 /usr/local/bin/restic
restic version

Adaptez amd64 à l’architecture du serveur. Conservez ensuite une procédure de mise à jour documentée.

Initialiser le dépôt chiffré

Restic demande un mot de passe lors de la création du dépôt. Il sert à protéger les clés permettant de déchiffrer les sauvegardes.

Créez un fichier accessible uniquement à l’administrateur :

sudo install -d -m 0700 /root/.config/restic
sudo sh -c 'umask 077; read -r -s RESTIC_SECRET; printf "%s\n" "$RESTIC_SECRET" > /root/.config/restic/password'
sudo chmod 0600 /root/.config/restic/password

Définissez ensuite les variables nécessaires :

export RESTIC_REPOSITORY="s3:https://stockage.example.com/nom-du-bucket/restic-vps"
export RESTIC_PASSWORD_FILE="/root/.config/restic/password"

Initialisez le dépôt une seule fois :

restic init

Attention : si vous perdez tous les mots de passe valides du dépôt, les données sont irrécupérables. Ni l’hébergeur du VPS, ni l’opérateur du stockage, ni restic ne pourront les déchiffrer. Conservez une copie du mot de passe dans un gestionnaire de secrets ou un coffre sécurisé, séparé du VPS et du dépôt.

Évitez RESTIC_PASSWORD dans une automatisation permanente. RESTIC_PASSWORD_FILE limite les risques d’exposition accidentelle dans des scripts, des journaux ou certains outils d’administration.

Effectuer une première sauvegarde

Pour sauvegarder les configurations, les répertoires utilisateurs et les données web :

restic backup /etc /home /var/www

Restic parcourt les fichiers, chiffre les données avant leur transfert et ne renvoie vers le dépôt que les blocs absents. Les sauvegardes suivantes sont donc incrémentales, tout en restant représentées sous forme de snapshots complets lors d’une restauration.

Excluez les caches, fichiers temporaires et autres données reproductibles :

restic backup /etc /home /var/www \
  --exclude="/home/*/.cache" \
  --exclude="/var/www/*/cache"

Pour maintenir une liste versionnée et lisible, utilisez plutôt un fichier :

/home/*/.cache
/var/www/*/cache
/var/tmp
*.tmp

Puis lancez :

restic backup /etc /home /var/www \
  --exclude-file="/etc/restic/excludes.txt"

Ne sauvegardez pas aveuglément tout /. Des systèmes virtuels comme /proc, /sys, /dev ou /run ne sont pas des données restaurables ordinaires. Inventoriez les services et sélectionnez les configurations, contenus, certificats, données applicatives et secrets réellement nécessaires.

Sauvegarder une base de données proprement

Copier directement les fichiers internes d’une base active peut produire une sauvegarde incohérente. Utilisez les outils natifs du moteur pour créer une vue logique cohérente.

Avec PostgreSQL, le dump peut être envoyé directement à restic :

pg_dump --format=custom --dbname=application \
  | restic backup --stdin \
      --stdin-filename="databases/application-postgresql.dump"

Avec MySQL ou MariaDB :

mysqldump --single-transaction --quick application \
  | restic backup --stdin \
      --stdin-filename="databases/application-mysql.sql"

Stockez les identifiants de la base dans un fichier de configuration protégé plutôt que dans la ligne de commande. Dans un script, activez aussi pipefail afin qu’un échec du dump ne soit pas masqué par le succès de restic.

Une autre méthode consiste à créer le dump sur disque, à le sauvegarder, puis à supprimer le fichier temporaire. Elle facilite une validation préalable, mais demande davantage d’espace et impose de protéger le dump en clair :

pg_dump --format=custom --file=/var/lib/backups/application.dump application
restic backup /var/lib/backups/application.dump

Automatiser la sauvegarde et la rétention

Créez /usr/local/sbin/restic-backup avec le contenu suivant :

#!/usr/bin/env bash
set -Eeuo pipefail

source /root/.config/restic/environment

exec 9>/run/lock/restic-backup.lock
flock -n 9 || exit 0

restic backup /etc /home /var/www \
  --exclude-file="/etc/restic/excludes.txt"

pg_dump --format=custom --dbname=application \
  | restic backup --stdin \
      --stdin-filename="databases/application-postgresql.dump"

restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 12 \
  --prune

Le fichier /root/.config/restic/environment peut définir RESTIC_REPOSITORY, RESTIC_PASSWORD_FILE et les identifiants du stockage. Protégez-le :

chmod 0700 /usr/local/sbin/restic-backup
chmod 0600 /root/.config/restic/environment

La politique conserve ici sept sauvegardes quotidiennes, quatre hebdomadaires et douze mensuelles. Adaptez ces valeurs aux objectifs de reprise, aux obligations internes et au volume disponible. forget retire les snapshots expirés et --prune supprime les données devenues inutiles dans le dépôt.

Pour cron, une exécution quotidienne peut être configurée ainsi :

17 3 * * * /usr/local/sbin/restic-backup >> /var/log/restic-backup.log 2>&1

Avec systemd, créez un service :

[Unit]
Description=Sauvegarde restic du VPS
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/restic-backup

Puis un timer :

[Unit]
Description=Sauvegarde restic quotidienne

[Timer]
OnCalendar=*-*-* 03:17:00
RandomizedDelaySec=15m
Persistent=true

[Install]
WantedBy=timers.target

Activez-le après avoir testé manuellement le script :

systemctl daemon-reload
systemctl enable --now restic-backup.timer
systemctl list-timers restic-backup.timer

Notre guide sur les tâches planifiées avec cron détaille l’automatisation si vous préférez cette approche.

Vérifier et restaurer les sauvegardes

Listez les snapshots disponibles :

restic snapshots

Contrôlez régulièrement la structure du dépôt :

restic check

Pour restaurer un snapshot dans un répertoire isolé :

mkdir -p /srv/restore
restic restore ID_DU_SNAPSHOT --target /srv/restore

Inspectez les fichiers restaurés avant de les remettre en production. Pour parcourir les snapshots comme une arborescence, installez le support FUSE puis utilisez :

mkdir -p /mnt/restic
restic mount /mnt/restic

Démontez ensuite le point de montage avec l’outil FUSE disponible sur votre distribution.

Un dépôt valide ne garantit pas à lui seul une reprise réussie. Organisez des tests de restauration réguliers, y compris pour les bases de données, les permissions, les certificats et les dépendances applicatives. Mesurez le temps nécessaire afin de vérifier qu’il respecte votre objectif de reprise.

Renforcer la sécurité

Le chiffrement est déjà appliqué par restic avant l’envoi des données. Il ne remplace toutefois pas les autres protections :

• Conservez le dépôt sur un emplacement distinct du VPS pour respecter la logique 3-2-1.
• Protégez le mot de passe du dépôt et gardez-en une copie séparée.
• Limitez les permissions des fichiers de secrets à l’utilisateur de sauvegarde.
• Utilisez des identifiants S3 ou SFTP dédiés au seul dépôt concerné.
• Accordez uniquement les droits nécessaires de lecture, écriture et suppression.
• Protégez le compte distant avec une authentification forte et une rotation maîtrisée.
• Mettez en place, si le stockage le permet, une protection contre la suppression ou une seconde copie avec une rétention indépendante.
• Testez les restaurations après toute modification importante de l’infrastructure.

La fonction prune nécessite la suppression d’objets. Une politique d’immutabilité mal configurée peut donc empêcher la maintenance du dépôt. Testez la compatibilité entre la rétention du stockage et celle de restic avant le passage en production.

Superviser les sauvegardes

Une sauvegarde silencieusement en échec équivaut à une absence de sauvegarde. Surveillez le code de sortie du script, la date du dernier snapshot, la durée du traitement et l’évolution du volume stocké.

Avec systemd, consultez les journaux et l’état du service :

systemctl status restic-backup.service
journalctl -u restic-backup.service

Ajoutez une alerte en cas d’échec vers votre système de supervision. Déclenchez aussi une alerte si aucun nouveau snapshot n’apparaît dans la fenêtre attendue. Exécutez restic check périodiquement, éventuellement avec une planification distincte si le dépôt est volumineux.

Pour les futurs VPS TalCloud, hébergés en France sur stockage NVMe, cette stratégie complète les protections d’infrastructure, l’Anti-DDoS Netrix, l’approche RGPD et le support humain. Elle reste toutefois sous la responsabilité de l’administrateur : définissez clairement la fréquence, la rétention, l’emplacement externalisé et la procédure de restauration avant la mise en production.