Sauvegarder vos données avec restic

Stéphane Robert Principal DevSecOps Engineer

Mis à jour le 13 octobre 2026 Publié le 4 décembre 2024

28 min de lecture

Améliorer cette page

Que voulez-vous signaler ?

L’issue s’ouvre déjà remplie avec le titre et l’adresse de cette page.

Restic sauvegarde vos fichiers de manière incrémentale, chiffrée (AES-256) et dédupliquée vers n'importe quel backend : stockage local, serveur SFTP, Amazon S3, MinIO, Google Cloud Storage, Azure Blob... C'est un binaire unique, sans dépendances, qui fonctionne sur Linux, macOS et Windows.

Avec restic, vous pouvez :

Sauvegarder automatiquement vos données avec chiffrement de bout en bout
Restaurer un fichier, un dossier ou un snapshot complet
Gérer la rétention avec des politiques flexibles (garder les X derniers jours/semaines/mois)
Vérifier l'intégrité de vos sauvegardes à tout moment

Installation

Restic est distribué sous forme de binaire statique unique, sans runtime ni dépendance à installer : il suffit de le placer dans le PATH. Les dépôts des distributions le proposent aussi, mais avec un décalage de version fréquent de plusieurs mois. Choisissez le téléchargement direct si vous voulez la version testée dans ce guide.

Téléchargez le binaire officiel (recommandé pour avoir la dernière version) :

base=https://github.com/restic/restic/releases/download/v0.19.1
wget "$base/restic_0.19.1_linux_amd64.bz2" "$base/SHA256SUMS"
sha256sum --check --ignore-missing SHA256SUMS
bzip2 -d restic_0.19.1_linux_amd64.bz2
chmod +x restic_0.19.1_linux_amd64
sudo mv restic_0.19.1_linux_amd64 /usr/local/bin/restic

La commande sha256sum --check doit afficher restic_0.19.1_linux_amd64.bz2: OK avant que vous décompressiez quoi que ce soit. Le fichier SHA256SUMS vient du même dépôt de publication que l'archive : il détecte un téléchargement corrompu, mais pas une publication compromise. Pour ce second cas, comparez l'empreinte avec une valeur obtenue par un autre canal. Pour cette version, l'empreinte SHA-256 de l'archive Linux amd64 est f415415624dcc452f2a02b8c33641791a8c6d6d3b65bbb3543fcf9a25151585c.

Ou via le gestionnaire de paquets (version potentiellement plus ancienne) :

# Debian/Ubuntu
sudo apt install restic

# Fedora
sudo dnf install restic

# Arch Linux
sudo pacman -S restic

Avec Homebrew :

brew install restic

Téléchargez le binaire depuis les releases officielles, extrayez-le et ajoutez le dossier à votre PATH.

Ou avec winget :

winget install restic.restic

Vérifiez l'installation :

restic version

restic 0.19.1 compiled with go1.26.4 on linux/amd64

Environnement de test avec RustFS

Pour tester les commandes de ce guide, déployons un stockage compatible S3 en local, avec Docker. MinIO ne publie plus d'image communautaire récupérable : au 9 octobre 2026, minio/minio sur Docker Hub et quay.io/minio/minio ne se téléchargent plus. Ce guide utilise donc RustFS, un autre stockage compatible S3. RustFS est publié en version stable (1.0.1) ; ici, il ne sert que de banc d'essai local. Vous pourrez ensuite adapter l'endpoint à votre provider (AWS S3, Outscale, Scaleway...).

Lancez RustFS sur le port 9000, limité à 127.0.0.1 :

export AWS_ACCESS_KEY_ID=demo-local-access
export AWS_SECRET_ACCESS_KEY=demo-local-secret-key
docker run -d --name rustfs -p 127.0.0.1:9000:9000 \
  -e RUSTFS_ACCESS_KEY="$AWS_ACCESS_KEY_ID" \
  -e RUSTFS_SECRET_KEY="$AWS_SECRET_ACCESS_KEY" \
  -e RUSTFS_VOLUMES=/data \
  -v rustfs-data:/data \
  rustfs/rustfs:1.0.1@sha256:1803faef57627e2d9c2e7d89d655d712ddded5389040054987163043fecb6a3c

Les deux valeurs demo-local-* sont des valeurs de démonstration, valables uniquement pour ce conteneur local lié à 127.0.0.1. Ne les réutilisez jamais sur un vrai stockage.

Configurez le dépôt restic. restic lit les clés S3 dans les mêmes variables AWS_*. Le mot de passe du dépôt est aussi une valeur de démonstration locale :
Fenêtre de terminal
```
export RESTIC_REPOSITORY="s3:http://127.0.0.1:9000/restic-backup"
export RESTIC_PASSWORD="mot-de-passe-de-demo-local"
```
Pas besoin de créer le bucket : restic init le crée.

Pour tout supprimer en fin de test : docker rm -fv rustfs && docker volume rm rustfs-data.

Concepts fondamentaux

Trois notions suffisent à comprendre toutes les commandes qui suivent. Elles décrivent respectivement où restic écrit, ce qu'il écrit à chaque exécution, et comment il évite de réécrire deux fois la même donnée. Le vocabulaire est repris tel quel dans les sorties de commande, il vaut la peine de le fixer maintenant.

Repository (dépôt)

Le repository est l'emplacement où restic stocke vos sauvegardes. Il peut être :

Un dossier local (/backup/restic-repo)
Un bucket S3 (s3:s3.amazonaws.com/mon-bucket)
Un serveur SFTP (sftp:user@serveur:/backup)
Un stockage compatible S3 comme Outscale OOS ou MinIO

Snapshots

Chaque sauvegarde crée un snapshot : une photo de vos fichiers à un instant T. Vous pouvez restaurer n'importe quel snapshot, même ancien.

Déduplication et chiffrement

Restic découpe vos fichiers en blobs (morceaux). Si un blob existe déjà dans le repository (même contenu dans un autre fichier ou snapshot), il n'est pas envoyé une seconde fois. Tous les blobs sont chiffrés avec AES-256 avant d'être envoyés.

Source · SVG

Initialiser un repository

L'initialisation crée la structure de dossiers du dépôt et une clé de chiffrement protégée par votre mot de passe. Elle ne se fait qu'une fois par dépôt : toutes les sauvegardes ultérieures réutilisent cette clé. La commande lit RESTIC_REPOSITORY et RESTIC_PASSWORD dans l'environnement, inutile donc de repasser l'emplacement en argument :

restic init

created restic repository d55b62d896 at s3:http://192.168.49.2:31019/restic-backup

Please note that knowledge of your password is required to access
the repository. Losing your password means that your data is
irrecoverably lost.

L'adresse du dépôt affichée dans cette sortie est celle d'un autre banc d'essai que le vôtre : seul compte le message created restic repository.

Sauvegarder des fichiers

La commande backup prend un ou plusieurs chemins et en crée un snapshot. Elle ne demande aucune configuration préalable : pas de fichier de règles, pas de déclaration de jeux de sauvegarde. Le comportement change seulement selon qu'un snapshot précédent existe ou non pour les mêmes chemins.

Première sauvegarde

Sans snapshot antérieur, restic lit l'intégralité des fichiers et remonte no parent snapshot found :

restic backup /home/user/documents

repository d55b62d8 opened (version 2, compression level auto)
no parent snapshot found, will read all files

Files:           4 new,     0 changed,     0 unmodified
Dirs:            4 new,     0 changed,     0 unmodified
Added to the repository: 102.967 KiB (102.055 KiB stored)

processed 4 files, 100.052 KiB in 0:00
snapshot 158bc701 saved

Sauvegardes incrémentales

Les sauvegardes suivantes sont incrémentales : seuls les fichiers nouveaux ou modifiés sont envoyés. Restic s'appuie sur le snapshot parent (la sauvegarde précédente des mêmes chemins) pour comparer taille et date de modification, et ne relit que ce qui a changé. Le snapshot produit reste malgré tout complet : il référence l'ensemble de l'arborescence, y compris les fichiers inchangés, et se restaure seul sans avoir besoin des sauvegardes antérieures.

# Ajouter un fichier
echo "Nouveau contenu" > /home/user/documents/nouveau.txt

# Relancer la sauvegarde
restic backup /home/user/documents

repository d55b62d8 opened (version 2, compression level auto)
using parent snapshot 158bc701

Files:           1 new,     0 changed,     4 unmodified
Dirs:            0 new,     3 changed,     1 unmodified
Added to the repository: 2.564 KiB (1.481 KiB stored)

processed 5 files, 100.073 KiB in 0:00
snapshot 6f1a7cec saved

Exclure des fichiers

Les motifs d'exclusion s'écrivent soit en ligne de commande avec --exclude (répétable), soit dans un fichier passé à --exclude-file, à raison d'un motif par ligne. La seconde forme est préférable dès que la liste dépasse deux entrées : elle se versionne et se partage entre plusieurs machines.

# Exclure par pattern
restic backup /home/user --exclude="*.log" --exclude=".cache"

# Utiliser un fichier d'exclusions
cat > /tmp/excludes.txt << 'EOF'
*.log
*.tmp
.cache
node_modules
EOF

restic backup /home/user --exclude-file=/tmp/excludes.txt

Lister et explorer les snapshots

Une fois plusieurs sauvegardes accumulées, il faut pouvoir retrouver la bonne avant de restaurer. Deux commandes suffisent : l'une donne l'inventaire des snapshots, l'autre le contenu de l'un d'eux. Les deux travaillent uniquement sur les métadonnées du dépôt, elles ne téléchargent pas les données de fichiers.

Voir tous les snapshots

La sortie liste un snapshot par ligne, avec son identifiant court, la machine d'origine et les chemins sauvegardés :

restic snapshots

repository d55b62d8 opened (version 2, compression level auto)
ID        Time                 Host        Tags        Paths                  Size
---------------------------------------------------------------------------------------
158bc701  2026-01-23 15:05:35  master1                 /home/user/documents   100.052 KiB
6f1a7cec  2026-01-23 15:06:10  master1                 /home/user/documents   100.073 KiB
---------------------------------------------------------------------------------------
2 snapshots

Lister les fichiers d'un snapshot

ls affiche l'arborescence enregistrée dans un snapshot, ce qui permet de vérifier qu'un fichier y figure bien avant de lancer une restauration :

restic ls latest

snapshot 6f1a7cec of [/home/user/documents] at 2026-01-23 15:06:10:
/home
/home/user
/home/user/documents
/home/user/documents/rapport.txt
/home/user/documents/notes.md
/home/user/documents/nouveau.txt

Restaurer des données

La restauration écrit les fichiers dans le répertoire désigné par --target, qui est obligatoire : restic n'écrase jamais l'emplacement d'origine sans qu'on le lui demande explicitement. Restaurez de préférence dans un répertoire vide, puis déplacez les fichiers une fois le contenu vérifié. Toute restauration part d'un snapshot, complet ou filtré.

Restaurer un snapshot complet

Sans filtre, la totalité du snapshot est recréée sous la cible, arborescence de chemins comprise :

restic restore latest --target /tmp/restore

restoring snapshot 6f1a7cec to /tmp/restore
Summary: Restored 9 files/dirs (100.073 KiB) in 0:00

Restaurer un fichier ou dossier spécifique

L'option --include restreint la restauration à un chemin, en utilisant le chemin absolu tel qu'il apparaît dans le snapshot (celui affiché par restic ls), pas un chemin relatif à la cible :

# Restaurer uniquement un dossier
restic restore latest --target /tmp/restore --include "/home/user/documents"

# Restaurer un fichier précis
restic restore latest --target /tmp/restore --include "/home/user/documents/rapport.txt"

Restaurer depuis un snapshot ancien

Pour revenir à un état antérieur, remplacez latest par l'identifiant du snapshot visé ; les 8 premiers caractères suffisent tant qu'ils sont uniques dans le dépôt :

# Lister les snapshots pour trouver l'ID
restic snapshots

# Restaurer depuis un snapshot spécifique
restic restore 158bc701 --target /tmp/restore-ancien

Gérer la rétention avec forget et prune

Sans ménage, un dépôt accumule un snapshot par exécution et grossit indéfiniment. Le nettoyage se fait en deux temps distincts, et c'est la source de confusion la plus fréquente chez les nouveaux venus : forget décide quels snapshots ne sont plus utiles, prune récupère l'espace disque correspondant. Tant que prune n'a pas tourné, la volumétrie du dépôt ne bouge pas.

Supprimer des snapshots (forget)

forget marque les snapshots pour suppression mais ne libère pas l'espace :

# Supprimer un snapshot par ID
restic forget 158bc701

# Appliquer une politique de rétention
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6

Libérer l'espace (prune)

prune supprime effectivement les données qui ne sont plus référencées :

restic prune

loading indexes...
finding data that is still in use for 1 snapshots
searching used packs...

to repack:             5 blobs / 1.715 KiB
this removes:          4 blobs / 1.147 KiB
to delete:             0 blobs / 0 B
total prune:           4 blobs / 1.147 KiB
remaining:            10 blobs / 101.828 KiB
unused size after prune: 0 B (0.00% of remaining size)

repacking packs
rebuilding index
removing 1 old packs
done

Combiner forget et prune

L'option --prune enchaîne les deux opérations, et ne déclenche le nettoyage que si forget a effectivement retiré quelque chose. C'est la forme à utiliser dans un script planifié :

# En une seule commande
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

Vérifier l'intégrité

Une sauvegarde qu'on n'a jamais vérifiée n'est qu'une hypothèse. Restic propose deux niveaux de contrôle : un contrôle de cohérence structurelle, rapide, qui valide les index et les métadonnées, et un contrôle de contenu, qui relit les données et recalcule leurs empreintes. Le second détecte la corruption silencieuse du stockage, que le premier ne peut pas voir.

Vérification rapide (index et structure)

Ce contrôle télécharge les index et les arbres de métadonnées, mais pas les données de fichiers ; il se termine en quelques secondes même sur un gros dépôt :

restic check

using temporary cache in /tmp/restic-check-cache-1215412186
load indexes
check all packs
check snapshots, trees and blobs
no errors were found

Vérification complète (avec lecture des données)

Avec --read-data, restic récupère chaque pack de données et vérifie son empreinte : c'est le seul moyen de détecter un fichier altéré côté stockage.

restic check --read-data

Statistiques du repository

stats renvoie par défaut la taille en mode restore-size, c'est-à-dire le volume qu'occuperaient les fichiers une fois restaurés, et non la place réellement prise dans le dépôt après déduplication :

restic stats

Stats in restore-size mode:
     Snapshots processed:  2
        Total File Count:  17
              Total Size:  200.125 KiB

Backends supportés

Le backend se choisit uniquement par le préfixe de l'URL de dépôt, passée avec -r ou via RESTIC_REPOSITORY. Aucune autre option ne change : les commandes backup, restore ou prune sont identiques quel que soit le stockage derrière. Les accès S3 et compatibles lisent leurs identifiants dans AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY, comme dans l'exemple RustFS plus haut.

Backend	Format repository	Exemple
Local	`/chemin/vers/repo`	`restic -r /backup/repo init`
SFTP	`sftp:user@host:/path`	`restic -r sftp:bob@server:/backup init`
Amazon S3	`s3:endpoint/bucket`	`restic -r s3:s3.amazonaws.com/mybucket init`
MinIO, RustFS	`s3:endpoint/bucket`	`restic -r s3:rustfs.local:9000/backup init`
Backblaze B2	`b2:bucket:path`	`restic -r b2:mybucket:/restic init`
Azure Blob	`azure:container:/`	`restic -r azure:mycontainer:/ init`
Google Cloud	`gs:bucket:/path`	`restic -r gs:mybucket:/restic init`
REST Server	`rest:http://host:port/`	`restic -r rest:http://localhost:8000/ init`
Rclone	`rclone:remote:path`	`restic -r rclone:gdrive:/backup init`

Automatiser les sauvegardes

Une sauvegarde lancée à la main finit toujours par être oubliée. L'automatisation tient en deux morceaux : un script qui enchaîne sauvegarde, rétention et vérification, puis un planificateur qui le déclenche. Le point sensible est celui des secrets : le mot de passe du dépôt et les clés d'accès au stockage ne s'écrivent jamais dans le script. Ils vivent dans deux fichiers à accès restreint (mode 600, propriétaire root), le premier référencé par RESTIC_PASSWORD_FILE, le second chargé par le script.

Fichiers de secrets

Créez d'abord le dossier et les deux fichiers avec des droits restreints, avant d'y écrire quoi que ce soit : install -m 600 /dev/null crée un fichier vide déjà protégé, si bien que le secret n'est jamais lisible par un autre compte, même un instant.

sudo install -d -m 700 /etc/restic
sudo install -m 600 /dev/null /etc/restic/password
sudo install -m 600 /dev/null /etc/restic/s3.env
sudoedit /etc/restic/password
sudoedit /etc/restic/s3.env
printf '%s\n' '.cache' 'node_modules' '*.tmp' | sudo tee /etc/restic/excludes.txt

La dernière commande crée aussi la liste d'exclusions /etc/restic/excludes.txt, une exclusion par ligne, que le script lira : sans ce fichier, restic backup échoue et set -e arrête tout le script. Adaptez les motifs à vos données.

Le premier fichier contient le mot de passe du dépôt sur une seule ligne. Le second contient les clés d'accès, une affectation par ligne, sans le mot export :

AWS_ACCESS_KEY_ID=votre-access-key
AWS_SECRET_ACCESS_KEY=votre-secret-key

Un fichier lisible seulement par root suffit si le script tourne sous root, comme ici. Avec un compte de service, donnez-lui la propriété des deux fichiers.

Script de sauvegarde

Le set -euo pipefail en tête interrompt le script à la première commande en échec ou à la première variable non définie, pour éviter qu'une purge s'exécute après une sauvegarde ratée. Le bloc set -a / set +a exporte les variables du fichier s3.env vers restic, sans qu'elles apparaissent dans le script :

#!/bin/bash
set -euo pipefail

# Clés d'accès S3, lues dans un fichier protégé (chmod 600)
set -a
. /etc/restic/s3.env
set +a
export RESTIC_REPOSITORY="s3:s3.amazonaws.com/mon-bucket"
export RESTIC_PASSWORD_FILE="/etc/restic/password"

# Sauvegarde
restic backup /home /etc --exclude-file=/etc/restic/excludes.txt

# Rétention (à retirer si la clé de ce serveur n'a pas le droit de supprimer,
# voir la section sur l'immuabilité plus bas)
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

# Vérification (hebdomadaire)
if [ "$(date +%u)" -eq 7 ]; then
    restic check
fi

Ce script suppose une clé d'accès qui peut supprimer des objets. Si vous appliquez plus bas la clé sans droit de suppression (immuabilité), retirez la ligne forget --prune du script quotidien : elle échouerait à chaque exécution, et comme set -e interrompt le script, la vérification hebdomadaire restic check ne s'exécuterait jamais. La rétention se lance alors depuis un autre poste, avec la clé complète.

Planification avec cron

La redirection vers un fichier de log est indispensable : sans elle, la sortie de restic part dans un mail local que personne ne lit.

# Sauvegarde quotidienne à 2h du matin
0 2 * * * /usr/local/bin/backup-restic.sh >> /var/log/restic.log 2>&1

Planification avec systemd

Un timer systemd remplace avantageusement cron : il journalise dans journalctl, et son option Persistent=true rattrape l'exécution manquée si la machine était éteinte à l'heure prévue. Il se compose toujours de deux unités, le service qui fait le travail et le timer qui le déclenche.

[Unit]
Description=Restic backup

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-restic.sh

[Unit]
Description=Run restic backup daily

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

[Install]
WantedBy=timers.target

sudo systemctl enable --now restic-backup.timer

Comment rendre une sauvegarde restic immuable ?

Une sauvegarde qu'un attaquant peut effacer avec la clé du serveur sauvegardé ne protège pas d'un rançongiciel. Le script ci-dessus, avec ses clés d'accès sur la machine qu'il protège, ouvre exactement cette porte : qui prend la machine prend la clé, et la clé suffit à supprimer le dépôt. La documentation de restic décrit ce risque dans sa section sur le mode « append-only » : le client qui sauvegarde doit pouvoir écrire et lire, pas supprimer ni écraser, et les opérations forget et prune se lancent depuis un autre poste, mieux protégé. Deux leviers existent sur un stockage S3.

Premier levier : une clé sans droit de suppression. La clé du script ne reçoit que la lecture, l'écriture et la liste, plus la suppression limitée au préfixe locks/ : restic y dépose des verrous temporaires qu'il doit pouvoir retirer. Voici le modèle de politique, à adapter à votre fournisseur et au nom de votre bucket :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket", "s3:GetBucketLocation"],
      "Resource": "arn:aws:s3:::mon-bucket"
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::mon-bucket/*"
    },
    {
      "Effect": "Allow",
      "Action": ["s3:DeleteObject"],
      "Resource": "arn:aws:s3:::mon-bucket/locks/*"
    }
  ]
}

Avec cette clé, restic backup doit fonctionner et restic forget --prune doit échouer : c'est voulu. La rétention se lance alors avec une seconde clé, complète, conservée hors du serveur sauvegardé. Activez aussi le versioning du bucket : une écriture sur un objet existant conserve l'ancienne version. Cette politique est un modèle : le banc RustFS de ce guide ne permet pas de la poser avec les outils présentés ici, vérifiez-la sur votre fournisseur avant de vous y fier.

Second levier : l'Object Lock. L'Object Lock est une fonction S3 qui interdit la suppression d'une version d'objet pendant une durée de rétention, même à un administrateur en mode COMPLIANCE. Restic peut écrire dans un bucket qui l'active (amélioration #2202 du journal des changements de restic), mais il ne sait pas poser de rétention lui-même : celle-ci vient de la rétention par défaut du bucket. Sur le banc RustFS, avec restic 0.19.1 et l'AWS CLI :

export AWS_DEFAULT_REGION=us-east-1
aws --endpoint-url http://127.0.0.1:9000 s3api create-bucket \
  --bucket restic-locked --object-lock-enabled-for-bucket
aws --endpoint-url http://127.0.0.1:9000 s3api put-object-lock-configuration \
  --bucket restic-locked \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":1}}}'
export RESTIC_REPOSITORY="s3:http://127.0.0.1:9000/restic-locked"
restic init
restic backup /home

init et backup réussissent sans erreur, et le dépôt se comporte comme un dépôt ordinaire tant qu'on ne cherche pas à supprimer. La différence apparaît à la suppression : sur un bucket versionné avec Object Lock, un restic forget --keep-last 1 --prune réussit en apparence (le snapshot disparaît de restic snapshots, restic check ne signale rien), mais le service n'a posé qu'un marqueur de suppression. Chaque version antérieure du snapshot reste en place, protégée par la rétention :

aws --endpoint-url http://127.0.0.1:9000 s3api list-object-versions \
  --bucket restic-locked --prefix snapshots/ \
  --query '[length(Versions), length(DeleteMarkers)]' --output text

Après deux sauvegardes puis un forget --prune qui en retire une, la commande affiche 2 1 : deux versions conservées, un marqueur de suppression. Pour détruire réellement la version, il faut la désigner par son identifiant de version, et le service refuse tant que la rétention court. L'identifiant s'obtient avec list-object-versions (champ VersionId) :

aws --endpoint-url http://127.0.0.1:9000 s3api delete-object \
  --bucket restic-locked --key <clé-du-snapshot> --version-id <identifiant-de-version>

Le service répond :

An error occurred (AccessDenied) when calling the DeleteObject operation: Object is under COMPLIANCE retention and cannot be deleted until 2026-10-13 7:35:24.298923518 +00:00:00

Le refus vaut aussi pour la clé administrateur. L'Object Lock protège donc le dépôt d'un attaquant qui détient une clé, mais ne libère pas d'espace avant la fin de la rétention : choisissez une durée égale à la période pendant laquelle vous acceptez de ne pas récupérer cet espace. Les versions masquées par un marqueur se retrouvent avec list-object-versions.

Dans les deux cas, testez la restauration depuis une copie du dépôt avant d'en dépendre : une sauvegarde immuable que personne n'a restaurée reste une hypothèse.

Dépannage

La plupart des erreurs restic viennent de trois causes : un dépôt non initialisé, un mot de passe ou des identifiants de backend erronés, ou un verrou laissé par un processus interrompu. Le tableau associe chaque message affiché à sa cause la plus probable et à la commande qui débloque la situation.

Problème	Cause probable	Solution
`Fatal: unable to open config file`	Repository non initialisé	Exécutez `restic init`
`wrong password or no key found`	Mauvais mot de passe	Vérifiez `RESTIC_PASSWORD`
`connection refused`	Backend inaccessible	Vérifiez l'URL et les credentials
`pack is damaged`	Corruption de données	Exécutez `restic check --read-data`
`repository is already locked`	Processus interrompu	Exécutez `restic unlock`
`error while unlocking: ... COMPLIANCE retention`	Stockage S3 en Object Lock qui refuse de supprimer le verrou posé par restic (non rencontré avec RustFS 1.0.1)	Attendez la fin de la rétention, ou voyez la section sur la sauvegarde immuable

À retenir

Chiffrement par défaut : toutes les données sont chiffrées avec AES-256, le mot de passe est indispensable.
Sauvegardes incrémentales : seuls les nouveaux blobs sont envoyés, économisant bande passante et stockage.
Déduplication intelligente : un même contenu n'est stocké qu'une fois, même entre fichiers différents.
Snapshots jamais modifiés : chaque sauvegarde crée un snapshot que vous pouvez restaurer à tout moment. Il reste pourtant supprimable par quiconque détient une clé avec droit de suppression : voir la section sur la sauvegarde immuable.
Rétention en deux temps : forget décide quels snapshots disparaissent, prune libère l'espace ; --prune enchaîne les deux.
Secrets hors du script : mot de passe et clés d'accès vivent dans des fichiers en mode 600, jamais dans le script.
Clé de sauvegarde sans droit de suppression, ou Object Lock : sans l'un des deux, une machine compromise peut effacer ses propres sauvegardes.
Object Lock et espace disque : un forget --prune ne pose qu'un marqueur de suppression, l'espace n'est libéré qu'à la fin de la rétention.
Vérifiez vos sauvegardes : restic check contrôle la structure, --read-data relit le contenu.
--dry-run toujours : prévisualisez les suppressions avec forget --dry-run avant de les appliquer.

Prochaines étapes

Rclone pour le transfert cloud Utilisez rclone comme backend pour accéder à 70+ services cloud

Stockage Outscale OOS Configurez restic avec Outscale Object Storage

s3cmd pour le stockage objet Gérer les buckets S3 que restic utilise comme dépôt

Documentation officielle restic Guide complet et référence des commandes

Ressources

Les sources de référence pour aller au-delà de ce guide, notamment sur les backends non couverts ici et les options avancées de backup :

Site officiel : restic.net
Documentation : restic.readthedocs.io
GitHub : github.com/restic/restic
Forum : forum.restic.net