Restauration Restic testée mensuellement : tutoriel 2026

Un backup non testé est un backup mort. Voici la procédure de test de restauration mensuel à mettre en place pour valider que votre Restic fonctionne vraiment.

Voir notre guide Restic complet.

Pourquoi tester

• Vérifier que les snapshots ne sont pas corrompus
• Vérifier que vous avez encore le password Restic
• Mesurer le RTO réel (temps de restauration)
• Détecter une fuite progressive (lignes manquantes, fichiers exclus par erreur)

Procédure mensuelle (1er du mois)

1. Provisionner un VPS staging temporaire (Hetzner CX23, ~5 € pour quelques heures)
2. Installer Restic et configurer credentials lecture
3. Restaurer le dernier snapshot dans /restore
4. Vérifier intégrité :
   • Liste des fichiers comparée au répertoire prod
   • Comptage : find /restore -type f | wc -l
   • Données critiques : ouvrir un fichier connu, vérifier son contenu
   • Postgres : pg_restore dans une instance test, count tables
5. Documenter dans un journal : date, snapshot ID, RTO, anomalies
6. Détruire le VPS staging

Script automatisé partiel

#!/bin/bash
# /usr/local/bin/restic-test-restore.sh
set -e
source /root/.restic.env

mkdir -p /tmp/restore-test
restic restore latest --target /tmp/restore-test --include /etc

# Vérifier nb fichiers
COUNT=$(find /tmp/restore-test -type f | wc -l)
if [ "$COUNT" -lt 100 ]; then
    echo "ALERTE : moins de 100 fichiers restaurés ($COUNT)" | mail -s "Restic test FAIL" admin@exemple.sn
    exit 1
fi

echo "Test restauration OK : $COUNT fichiers"
rm -rf /tmp/restore-test

Pg_dump test

# Restaurer le dump dans un container Postgres test
restic restore latest --target /tmp/restore --include /var/backups/pg

docker run --rm -v /tmp/restore/var/backups/pg:/dumps -d --name pg-test postgres:16
sleep 5
docker exec -i pg-test psql -U postgres < /dumps/all-databases.sql.gz
docker exec pg-test psql -U postgres -c "SELECT count(*) FROM users;"
docker stop pg-test

Documenter le runbook

Créer un document interne avec procédure de restauration complète en cas de désastre. Quelqu’un d’autre que le sysadmin principal doit pouvoir l’exécuter en français. Critique en cas d’absence ou de turnover.

Pour explorer plus loin

• Guide Restic
• Backup VPS

Etape 1 : pourquoi un test de restauration mensuel est obligatoire

Une sauvegarde non testee n’est pas une sauvegarde, c’est un espoir. Statistiquement, 30 % des entreprises decouvrent au moment d’un sinistre que leurs sauvegardes sont corrompues, illisibles ou incompletes. Pour une PME basee a Dakar, Abidjan ou Cotonou qui sauvegarde sa comptabilite, ses contrats clients et son code source sur Backblaze B2 ou Wasabi via Restic, planifier un test de restauration mensuel est non negociable.

L’objectif du test : prouver une fois par mois qu’on peut restaurer un snapshot complet sur une machine vierge, en moins de 60 minutes, sans intervention manuelle complexe. Si l’exercice echoue ou depasse cette duree, la procedure ou la doc doit etre corrigee immediatement, pendant que tout le monde a encore le contexte.

Etape 2 : preparer une machine de test isolee

Le test ne doit jamais toucher la machine de production. On utilise soit un VPS jetable chez Hostinger ou Contabo (a partir de 4 EUR/mois soit environ 2625 FCFA), soit une VM locale dans VirtualBox ou UTM. La machine doit etre une distribution propre (Ubuntu Server 24.04 LTS de preference) sans aucun outil prealable. C’est ce qui simule fidelement le scenario « laptop vole, on rachete un poste neuf chez Coin Afrique ».

# Provisionner une VM Ubuntu Server 24.04 minimale
sudo apt update && sudo apt install -y curl bzip2 jq
curl -LO https://github.com/restic/restic/releases/download/v0.18.0/restic_0.18.0_linux_amd64.bz2
bunzip2 restic_0.18.0_linux_amd64.bz2
sudo install -m 0755 restic_0.18.0_linux_amd64 /usr/local/bin/restic
restic version

La sortie attendue est « restic 0.18.0 compiled with go1.23 on linux/amd64 ». Si tu vois une autre version, c’est que le repo apt a installe une version plus ancienne, supprime-la avec apt remove avant de continuer.

Etape 3 : recuperer les credentials depuis le coffre-fort

Sur la machine de test, recree le fichier ~/.restic-b2.env exactement comme sur la prod, en lisant les valeurs depuis ton coffre-fort (Bitwarden, 1Password, KeePassXC). C’est le moment de verite : si tu n’as pas archive correctement les credentials, le test echoue immediatement.

cat > ~/.restic-b2.env <<EOF
export B2_ACCOUNT_ID="000xxxxxxxxxxxx0000000001"
export B2_ACCOUNT_KEY="K005abcdefghijklmnopqrstuvwxyz1234"
export RESTIC_REPOSITORY="b2:backup-itsc-dakar-2026:/laptop-marie"
export RESTIC_PASSWORD_FILE="/home/test/.restic-password"
EOF
chmod 600 ~/.restic-b2.env
echo "MOT_DE_PASSE_RESTIC_DU_COFFRE" > ~/.restic-password
chmod 600 ~/.restic-password
source ~/.restic-b2.env
restic snapshots

Le signal de succes : la commande restic snapshots affiche la liste des snapshots avec leurs IDs, dates et hosts. Si tu vois « wrong password or no key found », c’est que le mot de passe est mauvais. Stop tout et corrige le coffre-fort.

Etape 4 : restaurer le snapshot le plus recent dans /tmp/recovery

On restaure dans un dossier temporaire pour ne pas ecraser le systeme. Garde l’oeil sur le debit : sur fibre Sonatel a Dakar, on observe 30-40 Mbps en download depuis B2 us-west, soit environ 4 Mo/s. Pour 50 Go de donnees, compte 3 a 4 heures.

mkdir -p /tmp/recovery
time restic restore latest --target /tmp/recovery

La sortie indique a la fin « restoring snapshot … to /tmp/recovery » puis « Files restored: X / Bytes restored: Y ». Le time devant la commande mesure la duree exacte, c’est cette valeur que tu reportes dans le runbook chaque mois pour suivre la derive (si la duree double en 6 mois, c’est que le repo grossit anormalement et qu’il faut ajuster la politique forget).

Etape 5 : verifier l’integrite des fichiers restaures

Restorer ne suffit pas, il faut prouver que les fichiers sont bien identiques aux originaux. La methode la plus fiable est de comparer un manifeste de hash genere avant le sinistre avec un manifeste recalcule apres restauration. Sur la machine de prod, genere chaque mois :

cd /home/marie/Documents
find . -type f -exec sha256sum {} \; | sort > ~/manifest-prod-$(date +%Y%m).txt
cp ~/manifest-prod-*.txt /chemin/coffre/

Sur la machine de test apres restauration :

cd /tmp/recovery/home/marie/Documents
find . -type f -exec sha256sum {} \; | sort > ~/manifest-test.txt
diff ~/manifest-prod-202605.txt ~/manifest-test.txt
echo "Exit code: $?"

Le signal de reussite absolu : exit code 0 et aucune sortie de diff. Si tu vois des lignes differentes, identifie precisement quels fichiers sont concernes et investigue (corruption ? fichier modifie entre le manifeste et le backup ?). Tout ecart non explique est un signal d’alarme.

Etape 6 : tester la restauration partielle d’un fichier specifique

Le scenario « j’ai supprime par erreur un fichier important » est plus frequent qu’un sinistre total. Teste donc aussi la restauration ciblee :

restic restore latest --target /tmp/single --include "/home/marie/Documents/factures-2026/F-0042.pdf"
ls -la /tmp/single/home/marie/Documents/factures-2026/

Le fichier doit apparaitre avec sa taille originale et un mtime coherent (date de modification d’origine, pas la date du jour). Si le fichier n’existe pas dans le snapshot, le retour est « no matching files found », et tu peux explorer les snapshots precedents avec restic ls SNAPSHOT_ID pour retrouver une version anterieure.

Etape 7 : chronometrer le RTO reel et l’inscrire au runbook

Le RTO (Recovery Time Objective) est le temps maximum admissible pour restaurer le service. Pour une PME senegalaise qui facture 100 000 FCFA/jour, chaque heure d’indisponibilite coute environ 12 500 FCFA en manque a gagner. Un RTO de 4 heures est un compromis raisonnable.

Le test mensuel doit produire un chiffre concret : « le 5 mai 2026, restauration complete en 47 minutes sur VPS Hostinger 2 vCPU 2 Go RAM, debit moyen 38 Mbps ». Cette ligne va dans un fichier RUNBOOK.md du repo Git. Sur 12 mois, tu peux suivre l’evolution et anticiper le moment ou tu devras passer a un VPS plus rapide ou changer de region B2.

Etape 8 : detruire la machine de test proprement

Une fois le test valide, detruis la VM ou le VPS pour ne pas accumuler de couts inutiles et eviter qu’une copie clear de tes donnees traine quelque part. Sur Hostinger ou Contabo, c’est 1 clic dans le panel. Sur VirtualBox/UTM, suppression du fichier .vdi/.qcow2.

# Detruire les donnees restaurees avant de detruire la VM (defense en profondeur)
sudo shred -u -n 3 /tmp/recovery/**/*.pdf 2>/dev/null || true
sudo rm -rf /tmp/recovery /tmp/single
history -c
shutdown -h now

Le shred passe 3 fois sur les fichiers sensibles avant suppression, ce qui empeche une recuperation forensique sur le disque virtuel. C’est paranoiaque mais peu couteux en temps.

Etape 9 : automatiser le rappel mensuel

Le piege classique : « je ferai le test la semaine prochaine » repete 11 fois jusqu’a la perte de donnees. Cree un evenement recurrent dans Google Calendar ou ProtonMail Calendar le 5 de chaque mois, avec rappel 24h et 1h avant. L’evenement contient un lien direct vers le runbook dans Notion ou ton wiki interne.

À lire ensuite, lis aussi Restic + Backblaze B2 : tutoriel backup et PRA pour PME africaine.

Etape 10 : signal final, le test est passe quand

Le test est valide si trois conditions sont reunies : restic snapshots a fonctionne du premier coup, le diff des manifestes a renvoye exit 0, et la duree totale est restee sous le RTO cible. Si l’une des trois echoue, on ouvre un ticket dans Linear ou GitHub Issues, on assigne un responsable, et on refait le test sous 7 jours apres correction. Pas de « ca marchera la prochaine fois » : la confiance dans une sauvegarde se construit par accumulation de tests reussis, pas par optimisme.

Etape 11 : exercice de bascule complete une fois par an

Au-dela du test mensuel, organise une fois par an un exercice complet : pendant une journee, l’equipe travaille uniquement depuis un poste restaure, comme si la machine d’origine n’existait plus. C’est la seule facon de detecter les dependances cachees : un raccourci, une cle SSH, un certificat expire, une licence logicielle qui se reactive ailleurs. Note ces decouvertes dans le runbook et corrige-les a froid avant le prochain incident reel.

Etape 12 : journaliser chaque test dans un tableau de bord lisible

Un test isole sert peu si tu ne peux pas en tirer des tendances. Maintiens un Google Sheet ou un fichier CSV partage avec les colonnes : date du test, ID du snapshot restaure, taille (Go), duree restic restore (min), debit moyen (Mbps), exit code diff, RTO total, incidents rencontres, corrections appliquees. Apres 6 mois, tu vois immediatement si le repo grossit dangereusement, si la latence vers B2 derive, ou si une etape consomme de plus en plus de temps.

Ce tableau de bord se partage avec la direction lors des revues trimestrielles. Pour une PME, c’est un argument fort en negociation d’assurance cyber : un assureur qui voit 12 lignes de tests reussis sur 12 mois reduit la prime ou augmente le plafond d’indemnisation. Le ROI du temps passe a tester est tres concret.

Etape 13 : couvrir aussi le cas du mot de passe perdu

Restic n’a aucun mecanisme de recuperation : si le mot de passe est perdu, les donnees aussi. Pour s’en proteger sans casser la securite, utilise la commande « restic key add » qui ajoute un second mot de passe au repository (max 8 cles). Stocke le mot de passe principal dans le coffre du dirigeant et le mot de passe secondaire dans un coffre physique scelle (chez le notaire ou dans un coffre bancaire CBAO/Ecobank a Dakar par exemple). Le test annuel inclut alors aussi la lecture du coffre secondaire pour verifier que le mot de passe d’urgence est toujours valide. C’est une demarche de gouvernance qui distingue les sauvegardes amateurs des sauvegardes d’entreprise.

Etape 14 : tester aussi la restauration cross-OS

Si la prod tourne sous Linux Ubuntu et que ton poste de secours est un Mac M3 ou un PC Windows 11 avec WSL2, fais au moins un test annuel cross-OS. Les permissions Unix, les liens symboliques et les attributs etendus se restaurent differemment selon la cible. Restic gere bien la majorite des cas, mais certains fichiers (avec ACL POSIX ou xattrs SELinux) peuvent perdre des metadonnees. Verifie-le avec « getfacl » et « getfattr » sur quelques fichiers critiques apres restauration. Le signal de reussite : aucun warning de Restic en fin de restore et toutes les ACL retrouvees sur les dossiers sensibles (documents RH, contrats notaires, donnees comptables ASYCUDA).

Etape 15 : passer a un test trimestriel destructeur

Une fois la routine mensuelle solide, tu peux ajouter chaque trimestre un test plus ambitieux : restaurer un environnement complet (base PostgreSQL, code source, configurations Nginx, certificats Let’s Encrypt) sur une infra de bout en bout, et faire tourner un health-check automatique qui appelle 5 endpoints applicatifs. Si les 5 endpoints repondent 200 OK avec les bons payloads, l’infra restauree est consideree comme operationnelle. Cet exercice transforme la sauvegarde brute en plan de reprise d’activite (PRA) verifiable, ce qui est la maturite recherchee par toute PME serieuse en 2026.