Restic + Backblaze B2 : tutoriel backup économique 2026

Tutoriel pour configurer Restic avec Backblaze B2 comme backend en 2026 (informations vérifiées en avril 2026, susceptibles d’évoluer), le combo le plus économique pour PME.

Voir notre guide Restic complet.

Étape 1 — Créer compte Backblaze B2

1. Aller sur backblaze.com/sign-up/cloud-storage
2. Email + mot de passe + 2FA
3. Buckets → Create Bucket → « server-backups-prod »
4. Object Lock : recommandé pour anti-ransomware (mode Compliance 30 jours)
5. App Keys → Add a New Application Key → restreindre au bucket de backup
6. Copier keyID et applicationKey

Étape 2 — Variables d’env

# /root/.restic.env (chmod 600)
export B2_ACCOUNT_ID=keyID
export B2_ACCOUNT_KEY=applicationKey
export RESTIC_REPOSITORY=b2:server-backups-prod:/srv-prod-01
export RESTIC_PASSWORD=...32+chars random...

Étape 3 — Initialiser et tester

source /root/.restic.env

# Init repo (UNE FOIS)
restic init

# Premier backup test
restic backup /etc

# Vérifier
restic snapshots

Étape 4 — Tarifs B2 typiques

• Stockage : 6 USD par To/mois
• Download (egress) : 0,01 USD/Go (gratuit jusqu’à 3x votre stockage / mois si vous utilisez Cloudflare R2 / Bunny CDN comme partner)
• Class B / C transactions : très peu (négligeable pour backups)

Pour 100 Go de backup typique avec dédup : ~0,60 USD/mois. Pour 1 To : ~6 USD/mois. Imbattable.

Étape 5 — Object Lock (anti-ransomware)

Activer Object Lock côté B2 (configurable au bucket) en mode Compliance 30 jours. Restic fonctionne avec ; les snapshots créés ne peuvent être supprimés pendant la rétention même par un attaquant ayant les credentials.

Étape 6 — Service account write-only

Créer une App Key séparée avec capabilities limitées : writeFiles, listFiles, readFiles uniquement. Pas de deleteFiles. Avec Object Lock + permissions write-only, votre setup est anti-ransomware par construction.

Note : restic forget --prune demande capability deleteFiles. Solution : faire le forget+prune avec une App Key admin séparée, depuis un workstation, mensuellement (et pas en cron quotidien).

Dans la continuité

• Guide Restic complet
• Object Lock anti-ransomware

Etape 1 : choisir Backblaze B2 et ouvrir un compte depuis l’Afrique

Backblaze B2 est aujourd’hui la solution de stockage objet S3-compatible la plus economique pour un freelance ou une PME basee a Dakar, Abidjan, Cotonou ou Yaounde. Le tarif au 1 mars 2026 est de 6 USD par To et par mois (egress 9 USD/To, mais 3x egress gratuit relatif au stockage). Pour 100 Go de sauvegardes, on paye environ 0,60 USD/mois soit ~390 FCFA/mois (taux fixe 1 EUR = 655,957 FCFA, USD ~610 FCFA en mars 2026). C’est moins cher que tout VPS local avec disque equivalent.

Cree un compte sur backblaze.com avec une carte Visa internationale ou un compte Wise. Une fois connecte, va dans App Keys, Add a New Application Key. Donne un nom explicite (« restic-laptop-2026 »), choisis un bucket precis (jamais « All Buckets » pour le principe de moindre privilege), et coche les permissions readWrite et listFiles. Note immediatement le keyID et l’applicationKey : la cle ne sera plus jamais reaffichee.

# Verifier la connexion B2 depuis le terminal
curl -u "KEY_ID:APP_KEY" https://api.backblazeb2.com/b2api/v3/b2_authorize_account

Le retour JSON doit contenir accountId, apiInfo.storageApi.s3ApiUrl et un authorizationToken. Si tu vois « 401 Unauthorized », la cle est mal copiee (espace en debut/fin) ou le bucket associe n’existe plus.

Etape 2 : creer un bucket B2 avec lifecycle et chiffrement

Dans la console B2, va dans Buckets puis Create a Bucket. Nom unique global (ex. backup-itsc-dakar-2026), type Private, default encryption SSE-B2 (chiffrement cote serveur AES-256, gratuit). Active Object Lock en mode « Compliance » si tu veux te proteger contre un ransomware qui aurait obtenu tes cles : meme avec ces cles, l’attaquant ne peut pas supprimer les snapshots avant la duree de retention configuree.

Ajoute une lifecycle rule : « Keep prior versions for this number of days = 30 ». Les fichiers Restic etant immuables (pack files), cette regle nettoie automatiquement les artefacts orphelins en cas de prune incomplet. Sans elle, la facture peut grimper de 20-30 % en quelques mois.

Etape 3 : installer Restic 0.18 et verifier l’integrite du binaire

Restic 0.18 (sortie fin 2025) apporte la compression zstd par defaut et un nouveau format d’index plus rapide. Sur Ubuntu/Debian, le paquet officiel est souvent en retard ; on telecharge directement depuis GitHub et on verifie la signature.

VERSION="0.18.0"
curl -LO https://github.com/restic/restic/releases/download/v0.18.0/restic_0.18.0_linux_amd64.bz2
curl -LO https://github.com/restic/restic/releases/download/v0.18.0/SHA256SUMS
sha256sum -c SHA256SUMS --ignore-missing
bunzip2 restic_0.18.0_linux_amd64.bz2
sudo install -m 0755 restic_0.18.0_linux_amd64 /usr/local/bin/restic
restic version

Le signal de succes : la commande affiche « restic 0.18.0 compiled with go1.23 on linux/amd64 ». Si le checksum echoue, ne pas installer un binaire altere serait catastrophique pour des sauvegardes.

Etape 4 : initialiser le repository Restic sur B2

On declare les variables d’environnement dans un fichier sourceable, jamais en clair dans le shell history. Cree ~/.restic-b2.env avec les bons droits :

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/marie/.restic-password"
EOF
chmod 600 ~/.restic-b2.env
openssl rand -base64 48 > ~/.restic-password
chmod 600 ~/.restic-password
source ~/.restic-b2.env
restic init

Le mot de passe genere par openssl rand est imprimable mais cryptographiquement fort. Stocke-le aussi dans un coffre-fort (Bitwarden, 1Password, ou KeePassXC sur ta machine) : si tu perds ce mot de passe, les sauvegardes sont irrecuperables. Aucun bouton « mot de passe oublie » n’existe pour Restic, c’est une feature, pas un bug.

Etape 5 : premier backup et verification du chiffrement

Lance le premier backup d’un dossier important :

restic backup ~/Documents ~/Projets --tag laptop --tag $(hostname)

Sur un dossier de 5 Go avec une connexion fibre Sonatel a Dakar (50 Mbps upload), compte 15-20 minutes la premiere fois. Les suivantes sont incrementales : Restic ne re-uploade que les blocs differents (deduplication par chunk de 1 Mo en moyenne).

Verifie que les donnees sur B2 sont bien chiffrees : restic snapshots liste tes snapshots cote client, mais si tu ouvres la console B2 et regardes les fichiers du bucket, tu ne dois voir que des packs binaires illisibles avec des noms en hexadecimal. Aucun nom de fichier original ne doit fuiter, c’est la garantie du chiffrement bout-en-bout.

Etape 6 : automatiser via systemd timer

Un backup manuel est un backup oublie. Sur Linux, on cree une unit systemd et un timer qui s’execute toutes les nuits a 02h30 (heure GMT, donc 02h30 a Dakar et Abidjan, 03h30 a Cotonou et Yaounde) :

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Restic backup to B2
[Service]
Type=oneshot
EnvironmentFile=/home/marie/.restic-b2.env
ExecStart=/usr/local/bin/restic backup /home/marie/Documents /home/marie/Projets --tag nightly
ExecStartPost=/usr/local/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune
User=marie

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Run restic backup nightly
[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true
[Install]
WantedBy=timers.target

Active avec sudo systemctl enable –now restic-backup.timer. Verifie avec systemctl list-timers restic-backup.timer : la prochaine execution doit s’afficher. La politique forget+prune de l’exemple garde 7 jours quotidiens, 4 semaines, 12 mois, soit environ 23 snapshots actifs en regime stable, ce qui est suffisant pour la majorite des cas.

Etape 7 : verifier l’integrite du repository (etape critique)

Une sauvegarde non testee n’est pas une sauvegarde. Une fois par mois, lance un check complet :

restic check --read-data-subset=10%

Cette commande lit 10 % des packs aleatoirement et verifie leurs hash. Sur un repo de 100 Go, ca prend 30-40 minutes mais consomme 10 Go d’egress B2 (environ 90 cents). Une fois par trimestre, lance un restic check –read-data complet pour une garantie absolue.

Le signal de reussite : sortie « no errors were found ». Si tu vois « Pack ID does not match », il y a corruption, n’utilise pas restic rebuild-index avant d’avoir compris la cause (panne disque cote source ou cote B2). Contacte le support B2 si la corruption est cote serveur, ils ont des SLA stricts.

Etape 8 : surveiller les couts et les quotas

Dans la console B2, onglet Caps and Alerts, configure une alerte email si le stockage depasse 200 Go ou si l’egress mensuel depasse 50 Go. Pour une PME senegalaise qui sauvegarde 5 postes a 100 Go chacun, le cout total reel est de 3 USD/mois (environ 1830 FCFA), moins cher qu’un cafe au restaurant.

Si tu utilises Mixx by Yas (anciennement Free Money) ou Wave pour tes paiements pro, attention : aucune ne paye directement Backblaze. Il faut une Visa internationale ou un compte Wise/Revolut. Beaucoup de freelances dakarois passent par leur banque (Ecobank, BOA, CBAO) qui delivre une Visa Classique en 7-10 jours apres ouverture de compte.

Etape 9 : le plan de restauration en moins de 5 minutes

L’objectif final n’est pas de sauvegarder, c’est de restaurer. Garde dans ton coffre-fort un document texte avec : URL du bucket B2, B2_ACCOUNT_ID, B2_ACCOUNT_KEY, RESTIC_REPOSITORY, mot de passe Restic, et la commande exacte de restauration. Le jour ou ton laptop est vole un dimanche soir, tu dois pouvoir relancer ton activite lundi matin sur un poste neuf en moins d’une heure.

# Restauration sur poste neuf
sudo apt install restic
source ~/.restic-b2.env
restic snapshots
restic restore latest --target /tmp/recovery

Dans la continuité, lis aussi le test de restauration mensuel et Borg vs Restic : comparaison.

Etape 10 : durcir avec un compte B2 dedie aux sauvegardes

Pour une protection maximale contre le ransomware, cree un compte B2 totalement separe de tes autres services, avec une adresse email differente et la 2FA activee. Cette segmentation evite qu’un attaquant qui compromet ton compte principal puisse aussi effacer tes sauvegardes. C’est le principe air-gap logique, et il a deja sauve des milliers de PME en 2024-2025.

Etape 11 : tester la bande passante reelle vers B2

La latence Dakar – region B2 us-west est d’environ 180-220 ms. Le debit reel depend de ta connexion et de la qualite du peering. Mesure avec un upload de 1 Go avant de lancer un backup massif, pour savoir combien de temps prendra ta premiere full. Sur fibre Sonatel a Dakar, on observe 30-45 Mbps soutenus en upload vers B2 us-west, soit environ 4 Mo/s. Pour 100 Go, compte 7 a 8 heures la premiere nuit.

Si tu prefers une region plus proche, B2 propose aussi eu-central-003 (Amsterdam) avec une latence Dakar – Amsterdam autour de 60-90 ms via le cable submarine SAT-3 ou ACE. La region se choisit a la creation du bucket et ne peut plus etre changee ensuite.

Etape 12 : signal final de mise en production

Tu peux declarer la sauvegarde « prod-ready » quand : le timer systemd a tourne 7 nuits consecutives sans erreur, restic check –read-data-subset=10 a passe, et tu as restaure un fichier au hasard sur un autre poste avec succes. C’est la regle 3-2-1 minimum (3 copies, 2 supports, 1 hors site) appliquee en pratique sur Backblaze B2.

Etape 13 : exclure les caches et fichiers volumineux non critiques

Sauvegarder node_modules, le dossier .cache, les ISO ou les videos brutes gonfle inutilement le repository et la facture egress. Cree un fichier ~/.restic-excludes :

node_modules
.cache
.next
__pycache__
.venv
target
*.iso
*.vmdk
Library/Caches
.Trash
.DS_Store

Puis modifie l’ExecStart du service systemd pour ajouter –exclude-file=/home/marie/.restic-excludes. Sur un poste developpeur typique, cette exclusion divise par 3 ou 4 la taille du repo, et reduit les temps de backup de 60 a 70 %.

Etape 14 : preparer le runbook d’incident pour l’equipe

Si plusieurs personnes utilisent le meme bucket avec leurs propres sous-dossiers (laptop-marie, laptop-amadou, srv-prod), redige un runbook d’une page place dans le wiki interne. Il contient l’ordre de restauration prioritaire (production avant postes individuels), les responsables astreinte par fuseau (un a Dakar, un a Cotonou pour couvrir 24h), et le numero de ticket support Backblaze.

Ce runbook se teste tous les 3 mois lors d’un exercice « fire drill » : on simule la perte du laptop principal et on chronometre la restauration sur un poste de remplacement. Si l’exercice depasse 90 minutes, c’est que la doc ou les automatisations doivent etre ameliorees. C’est le critere final pour valider la chaine complete de sauvegarde.

Etape 15 : alerter en cas d’absence de backup pendant 48 heures

Le pire scenario est une sauvegarde silencieusement cassee : le timer systemd a un probleme, plus rien ne s’execute, et personne ne s’en rend compte avant le sinistre. Pour eviter cela, configure une supervision externe avec healthchecks.io (gratuit jusqu’a 20 verifications). Cree un check « restic-laptop-marie » avec une grace period de 26 heures et une URL de ping unique.

ExecStartPost=/usr/local/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune
ExecStartPost=/usr/bin/curl -fsS -m 10 https://hc-ping.com/UUID-UNIQUE

A chaque backup reussi, le ping declenche le check. Si le check ne recoit aucun ping pendant plus de 26 heures, healthchecks.io t’envoie un email et un SMS (option payante 5 USD/mois). Le signal de reussite : tu coupes volontairement le timer pendant 30 heures, et tu recois bien l’alerte. Une fois ce test passe, ta supervision est fonctionnelle et tu peux dormir tranquille.