# Sauvegardes chiffrées hors site avec Restic vers Backblaze B2

> Stocker ses sauvegardes en clair chez le même hébergeur que le site revient à ne pas en avoir. Mise en place de Restic vers un stockage objet tiers, chiffré de bout en bout.

- Auteur : Clément Hadrot
- Publié le : 2022-08-04
- Mis à jour le : 2022-08-04
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/sauvegardes-chiffrees-restic-backblaze-b2/

## L’essentiel

- Restic chiffre et déduplique avant tout envoi vers le stockage distant
- Backblaze B2 offre un stockage objet économique compatible S3
- Une sauvegarde chez le même hébergeur ne protège de rien en cas d'incident global

Une agence nous a présenté sa stratégie de sauvegarde avec une certaine fierté : un script cron quotidien qui archivait chaque site WordPress dans un dossier dédié du même serveur. Techniquement, une sauvegarde existait bien. Concrètement, si ce serveur disparaissait — panne disque irrécupérable, erreur d'exploitation, incident chez l'hébergeur — la sauvegarde disparaissait avec lui. Une sauvegarde qui partage le sort de ce qu'elle protège n'est pas une sauvegarde, c'est une copie.

La bonne pratique consiste à faire sortir la sauvegarde du site, chiffrée, vers un stockage tiers indépendant de l'hébergeur principal. Restic, un outil de sauvegarde open source en ligne de commande, associé à Backblaze B2, un stockage objet économique compatible avec l'API S3, forme une combinaison simple à mettre en œuvre et peu coûteuse à faire tourner sur la durée.

## Pourquoi Restic plutôt qu'un simple tar + rsync

Restic apporte trois choses qu'un script maison néglige presque toujours : le chiffrement systématique des données avant envoi (avec une clé que seul le titulaire du dépôt possède), la déduplication au niveau du bloc (une même image présente dans plusieurs sauvegardes n'est stockée qu'une fois) et un système de snapshots incrémentaux qui ne transfère que ce qui a changé depuis la dernière exécution. Le résultat : des sauvegardes rapides après la première, et un volume de stockage distant qui ne double pas à chaque exécution.

## Mise en place, du dépôt au premier snapshot

La première étape consiste à créer un compte Backblaze B2, un « bucket » privé, et une paire de clés d'accès applicatives dédiées à cette seule tâche. Sur le serveur à sauvegarder, on installe Restic (paquet disponible dans les dépôts Debian récents ou binaire officiel), puis on initialise le dépôt distant.

```
export RESTIC_REPOSITORY="b2:mon-bucket-sauvegardes:wordpress-clientA"
export RESTIC_PASSWORD="phrase-de-passe-longue-et-unique"
export B2_ACCOUNT_ID="xxxxxxxxxxxx"
export B2_ACCOUNT_KEY="xxxxxxxxxxxxxxxxxxxxxxxxxxxx"

restic init
```

Le mot de passe du dépôt chiffre toutes les données côté client, avant tout envoi réseau : Backblaze ne voit jamais le contenu en clair, seulement des blobs chiffrés. Le perdre revient à perdre l'accès définitif aux sauvegardes, il mérite donc d'être stocké dans un gestionnaire de mots de passe, jamais uniquement dans le script cron.

> L'essentiel à retenir : Restic chiffre et déduplique avant tout envoi vers le stockage distant ; Backblaze B2 offre un stockage objet économique compatible S3 ; Une sauvegarde chez le même hébergeur ne protège de rien en cas d'incident global

## Le script de sauvegarde quotidien

Un site WordPress se sauvegarde en deux temps : un dump de la base MySQL, et les fichiers (thèmes, plugins, médias, uploads). Restic sauvegarde des fichiers, pas une base vivante ; il faut donc dumper la base dans un fichier avant de lancer Restic dessus.

```
#!/bin/bash
set -euo pipefail

DUMP_DIR=/var/backups/mysql-dump
mkdir -p "$DUMP_DIR"
mysqldump --single-transaction wordpress_clientA > "$DUMP_DIR/clientA.sql"

restic backup /var/www/clientA "$DUMP_DIR" \
  --tag clientA --tag quotidien

restic forget --keep-daily 14 --keep-weekly 8 --keep-monthly 6 --prune
```

La commande `restic forget` applique une politique de rétention qui évite une croissance infinie du stockage distant : quatorze sauvegardes quotidiennes, huit hebdomadaires, six mensuelles, au-delà les snapshots redondants sont purgés (l'option `--prune` libère effectivement l'espace, avec un coût CPU non négligeable à ne pas lancer trop fréquemment).

## Vérifier qu'une sauvegarde restaure vraiment

Une sauvegarde jamais restaurée en test n'est qu'une hypothèse. Restic facilite cette vérification avec une commande de restauration ciblée, à exécuter régulièrement sur un environnement de test, jamais en production directement.

- `restic snapshots` liste l'historique disponible pour un dépôt
- `restic restore latest --target /tmp/restauration-test` restaure le dernier snapshot dans un dossier isolé
- `restic check` vérifie l'intégrité cryptographique du dépôt distant sans tout restaurer

> Notre règle de maison : toute sauvegarde qui n'a jamais été restaurée en test compte pour zéro dans notre évaluation du risque client.

## Notre verdict

Restic vers Backblaze B2 tient sur un serveur modeste, coûte quelques centimes par mois pour un site WordPress moyen, et sort les données du périmètre de l'hébergeur principal — la condition minimale pour survivre à un incident grave sur ce dernier. Ce n'est pas la seule stratégie possible, mais c'est l'une des plus simples à auditer : un dépôt, un mot de passe, une politique de rétention lisible en une ligne de commande.