Sauvegardes chiffrées automatiques avec restic et Backblaze B2 en 2026 (guide complet)

Il y a deux types d’administrateurs de serveur : ceux qui font des sauvegardes, et ceux qui vont en faire. Un VPS qui héberge votre Nextcloud, vos bases de données ou votre site n’est jamais à l’abri d’un disque qui lâche, d’une mauvaise commande rm -rf, d’un ransomware ou d’un hébergeur qui ferme. La règle des 3-2-1 (trois copies, deux supports, une hors-site) reste la référence en 2026, et la copie hors-site est celle qu’on néglige le plus souvent.

Dans ce guide, on met en place une stratégie de sauvegarde sérieuse, automatique et chiffrée avec restic, le couteau suisse du backup, vers Backblaze B2, l’un des stockages objet les moins chers du marché (environ 6 $/To/mois). restic chiffre tout côté client avant l’envoi : même Backblaze ne peut pas lire vos données. On couvre l’initialisation du dépôt, la déduplication, la planification via systemd, la rétention automatique, la vérification d’intégrité et surtout la restauration, car une sauvegarde jamais restaurée n’est qu’une hypothèse.

Prérequis

Un serveur Linux (Ubuntu 24.04 / Debian 12) à sauvegarder. Idéalement déjà durci ; voir installer et sécuriser un VPS Ubuntu.
Un compte Backblaze : créez-le sur backblaze.com. Les 10 premiers Go de B2 sont gratuits, largement de quoi tester.
Accès sudo sur le serveur.
Un gestionnaire de mots de passe pour stocker en lieu sûr la phrase secrète du dépôt et les clés B2. Si vous perdez la phrase secrète, vos sauvegardes sont irrécupérables, par conception.

Si vous hésitez sur le choix de l’outil ou du stockage objet, nos comparatifs restic vs Borg vs Kopia et Backblaze B2 vs Wasabi vs Storj vous aideront à trancher.

Étape 1 : Créer un bucket et une clé d’application sur Backblaze B2

Connectez-vous à votre compte Backblaze, puis :

Allez dans B2 Cloud Storage > Buckets > Create a Bucket.
Donnez un nom globalement unique (ex: backup-srv-selfhostr-2026), réglez l’accès sur Private, et laissez le chiffrement par défaut.
Notez l’Endpoint du bucket affiché dans ses détails (ex: s3.eu-central-003.backblazeb2.com).
Allez dans App Keys > Add a New Application Key.
Restreignez la clé à votre bucket uniquement (principe du moindre privilège). Cochez l’autorisation de lecture et écriture.
Notez le keyID et l’applicationKey affichés. L’applicationKey n’est montré qu’une seule fois, copiez-le immédiatement dans votre gestionnaire de mots de passe.

Bonne pratique : Activez le versioning sur le bucket (ou la rétention d’objets) côté Backblaze. C’est une protection supplémentaire contre un ransomware qui chiffrerait/supprimerait vos sauvegardes : même si l’attaquant accède à la clé, les versions antérieures restent récupérables.

Étape 2 : Installer restic

restic est disponible dans les dépôts, mais une version récente vaut mieux pour les dernières optimisations. Sur Ubuntu/Debian :

sudo apt update && sudo apt install -y restic

Vérifiez la version (visez 0.16 ou supérieure) :

restic version

Si la version des dépôts est trop ancienne, mettez restic à jour vers la dernière release officielle :

sudo restic self-update

Étape 3 : Configurer les variables d’environnement

restic se pilote via des variables d’environnement pour les identifiants et la phrase secrète. On les stocke dans un fichier protégé, lisible uniquement par root. Créez le répertoire et le fichier :

sudo mkdir -p /etc/restic
sudo nano /etc/restic/b2.env

restic communique avec Backblaze via l’API S3-compatible. Renseignez :

# Endpoint S3 de votre bucket (relevé à l'étape 1)
export RESTIC_REPOSITORY="s3:https://s3.eu-central-003.backblazeb2.com/backup-srv-selfhostr-2026"

# Identifiants de la clé d'application B2
export AWS_ACCESS_KEY_ID="VOTRE_keyID"
export AWS_SECRET_ACCESS_KEY="VOTRE_applicationKey"

# Phrase secrète de chiffrement du dépôt (longue et unique !)
export RESTIC_PASSWORD="une-phrase-secrete-tres-longue-et-aleatoire"

Verrouillez les permissions, ce fichier contient des secrets critiques :

sudo chmod 600 /etc/restic/b2.env
sudo chown root:root /etc/restic/b2.env

Piège classique : Le nom du bucket dans RESTIC_REPOSITORY doit correspondre exactement, et l’endpoint doit être celui de votre région (le numéro après eu-central- varie). Une erreur ici donne un Access Denied peu explicite.

Étape 4 : Initialiser le dépôt restic

Chargez les variables et initialisez le dépôt chiffré (à faire une seule fois) :

sudo bash -c 'source /etc/restic/b2.env && restic init'

Vous obtenez un message de confirmation avec l’ID du dépôt. C’est à cet instant que la structure chiffrée est créée sur Backblaze. À partir de maintenant, toute donnée envoyée est dédupliquée et chiffrée en AES-256 côté client avant transfert.

Vérifiez que le dépôt répond bien :

sudo bash -c 'source /etc/restic/b2.env && restic snapshots'

La liste est vide pour l’instant, mais l’absence d’erreur confirme que les identifiants et la phrase secrète sont corrects.

Étape 5 : Première sauvegarde manuelle

Sauvegardons des répertoires typiques d’un serveur : données applicatives, configuration et volumes Docker. Adaptez les chemins à votre cas :

sudo bash -c 'source /etc/restic/b2.env && restic backup \
  /etc \
  /home \
  /var/lib/docker/volumes \
  --exclude="/var/lib/docker/volumes/*/_data/cache" \
  --tag manuel'

restic affiche la progression, le nombre de fichiers et la quantité de données réellement transférées (grâce à la déduplication, seuls les blocs nouveaux ou modifiés partent sur le réseau). À la fin, un nouveau snapshot apparaît :

sudo bash -c 'source /etc/restic/b2.env && restic snapshots'

Sauvegarder une base de données proprement

Ne copiez jamais à chaud les fichiers d’une base de données : vous risquez une sauvegarde corrompue. Faites un dump puis sauvegardez le flux. Exemple PostgreSQL dans un conteneur Docker, en pipant directement vers restic via stdin :

sudo bash -c 'source /etc/restic/b2.env && \
  docker exec -t mon-postgres pg_dumpall -U postgres | \
  restic backup --stdin --stdin-filename postgres-dump.sql --tag db'

Pour MySQL/MariaDB, remplacez par mysqldump --all-databases. Cette méthode garantit une sauvegarde cohérente, point par point.

Étape 6 : Automatiser avec un script et systemd

On crée un script de sauvegarde qui inclut aussi le nettoyage de la rétention. Créez le fichier :

sudo nano /etc/restic/backup.sh

#!/usr/bin/env bash
set -euo pipefail
source /etc/restic/b2.env

# 1. Dump de la base de données
docker exec -t mon-postgres pg_dumpall -U postgres \
  | restic backup --stdin --stdin-filename postgres-dump.sql --tag db

# 2. Sauvegarde des fichiers
restic backup /etc /home /var/lib/docker/volumes \
  --exclude-caches \
  --tag auto

# 3. Application de la politique de rétention
restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --prune

Rendez-le exécutable :

sudo chmod 700 /etc/restic/backup.sh

La politique de rétention ci-dessus conserve les 7 dernières sauvegardes quotidiennes, 4 hebdomadaires et 6 mensuelles, puis --prune libère réellement l’espace des données qui ne sont plus référencées. Un bon équilibre coût/historique.

Créer le service et le timer systemd

systemd est plus robuste qu’un cron classique (gestion des logs, des dépendances, des échecs). Créez l’unité de service :

sudo nano /etc/systemd/system/restic-backup.service

[Unit]
Description=Sauvegarde restic vers Backblaze B2
After=network-online.target docker.service
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/etc/restic/backup.sh
Nice=10
IOSchedulingClass=best-effort
IOSchedulingPriority=7

Puis le timer qui le déclenche chaque nuit :

sudo nano /etc/systemd/system/restic-backup.timer

[Unit]
Description=Lance la sauvegarde restic quotidienne

[Timer]
OnCalendar=*-*-* 03:30:00
RandomizedDelaySec=900
Persistent=true

[Install]
WantedBy=timers.target

Persistent=true rattrape une sauvegarde manquée si le serveur était éteint à l’heure prévue. Activez le timer :

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer

Vérifiez la planification :

systemctl list-timers restic-backup.timer

Lancez une exécution immédiate pour tester le script complet de bout en bout :

sudo systemctl start restic-backup.service
journalctl -u restic-backup.service -n 50 --no-pager

Étape 7 : Vérifier l’intégrité des sauvegardes

Une sauvegarde corrompue silencieusement est pire que pas de sauvegarde. restic peut contrôler l’intégrité du dépôt. Une vérification rapide des métadonnées :

sudo bash -c 'source /etc/restic/b2.env && restic check'

Pour une vérification approfondie qui retélécharge et contrôle un échantillon de données réelles (recommandé une fois par mois) :

sudo bash -c 'source /etc/restic/b2.env && restic check --read-data-subset=10%'

Étape 8 : Tester la restauration (l’étape qu’on saute toujours)

C’est l’étape la plus importante et la plus négligée. Restaurez sur un emplacement temporaire pour valider que vos données sont récupérables :

# Lister les snapshots et repérer l'ID voulu
sudo bash -c 'source /etc/restic/b2.env && restic snapshots'

# Restaurer le dernier snapshot dans /tmp/restore-test
sudo bash -c 'source /etc/restic/b2.env && \
  restic restore latest --target /tmp/restore-test'

Inspectez /tmp/restore-test et vérifiez que vos fichiers sont intacts. Pour restaurer un seul fichier ou dossier, utilisez --include :

sudo bash -c 'source /etc/restic/b2.env && \
  restic restore latest --target /tmp/restore-test --include /etc/caddy/Caddyfile'

Pour restaurer un dump de base de données, montez d’abord le dépôt en lecture ou utilisez restic dump :

sudo bash -c 'source /etc/restic/b2.env && \
  restic dump latest postgres-dump.sql | docker exec -i mon-postgres psql -U postgres'

Planifiez un test de restauration réel tous les trimestres. C’est le seul moyen d’être certain que votre stratégie tient.

Bonnes pratiques et sécurité

Conservez la phrase secrète hors du serveur. Si le serveur est compromis, l’attaquant ne doit pas pouvoir lire ni détruire vos sauvegardes. Idéalement, la clé B2 utilisée par le serveur n’a que le droit d’écrire (append-only), pas de supprimer.
Activez la rétention d’objets côté Backblaze pour transformer vos sauvegardes en immuables sur une fenêtre donnée : protection ransomware ultime.
Surveillez les échecs. Couplez le timer à une alerte (e-mail, webhook, ou une sonde Uptime Kuma de type « push ») pour être prévenu si une sauvegarde échoue. Voir notre guide superviser son homelab avec Uptime Kuma et Grafana.
Documentez la procédure de restauration dans un endroit accessible même si le serveur est mort (gestionnaire de mots de passe, wiki perso).
Ne mettez jamais les secrets dans le script : le fichier .env en 600/root est le bon endroit.

FAQ

Pourquoi restic plutôt que rsync ou un simple tar ?

restic apporte trois choses qu’un tar ou rsync ne donnent pas nativement : la déduplication (les blocs identiques ne sont stockés qu’une fois, économie massive d’espace), le chiffrement de bout en bout (vos données sont illisibles côté hébergeur), et le versioning par snapshots avec rétention automatique. Pour comparer avec Borg et Kopia, lisez restic vs Borg vs Kopia en 2026.

Combien ça coûte vraiment sur Backblaze B2 ?

B2 facture environ 6 $ par To et par mois pour le stockage, et le trafic sortant (restauration) est gratuit jusqu’à 3× la taille stockée chaque mois. Pour un serveur dont les données dédupliquées tiennent en 50 Go, vous payez quelques dizaines de centimes par mois. Les 10 premiers Go sont gratuits. C’est l’une des options les moins chères, comme le montre notre comparatif B2 vs Wasabi vs Storj.

Que faire si j’oublie la phrase secrète du dépôt ?

Rien. C’est volontaire : restic chiffre tout côté client, sans phrase secrète il n’existe aucune porte dérobée pour déchiffrer. Vos sauvegardes deviennent définitivement inutilisables. C’est pourquoi cette phrase doit être stockée dans un gestionnaire de mots de passe fiable, séparé du serveur, dès l’initialisation.

La sauvegarde ralentit-elle mon serveur ?

Très peu si vous suivez ce guide. Les directives Nice=10 et IOSchedulingClass=best-effort du service systemd donnent une priorité basse à restic, qui cède le pas aux processus applicatifs. En la planifiant à 3h30 du matin, l’impact est négligeable pour la quasi-totalité des usages.

Puis-je sauvegarder plusieurs serveurs dans le même dépôt ?

Oui, et c’est même un avantage : la déduplication fonctionne entre serveurs, donc les fichiers communs (binaires système, images Docker) ne sont stockés qu’une fois. Utilisez des --tag distincts par machine pour vous y retrouver. Attention toutefois à la concurrence : restic verrouille le dépôt pendant prune, échelonnez donc les horaires.