ITSkillsCenter
Cybersécurité

Sauvegarde 3-2-1 sur connexion limitée : la stratégie pragmatique pour PME africaines

12 min de lecture

Lecture : 14 minutes · Niveau : intermédiaire · Mise à jour : avril 2026

Tutoriel pratique pour mettre en place une stratégie de sauvegarde 3-2-1 (3 copies, 2 supports, 1 hors-site) sur une PME ouest-africaine où la bande passante upload est souvent limitée à quelques Mbps. Restic comme moteur, Backblaze B2 ou Wasabi comme cloud, rsync pour la copie locale. Tous les scripts sont testés sur Ubuntu 22.04 et reproductibles immédiatement.

La stratégie 3-2-1 reste la référence industrielle parce qu’elle adresse les trois grands modes de défaillance d’une PME : panne matérielle (un disque tombe), incident local (incendie, vol, dégât des eaux dans les locaux), et compromission logique (ransomware qui chiffre tout y compris le NAS connecté). Une seule copie locale tombe au premier incident sérieux. Deux copies locales tombent ensemble au feu ou au vol. Trois copies dont une chiffrée et offsite donnent une chance réelle de récupération.

L’enjeu spécifique au contexte ouest-africain est la bande passante d’upload. Beaucoup de PME ont des connexions asymétriques avec download confortable mais upload de 1-5 Mbps. Sauvegarder plusieurs Go par jour vers le cloud sature alors la connexion en heures ouvrées. Les solutions présentées ici prennent ce contexte en compte : sauvegardes incrémentales très efficaces (Restic dédupliqué), envoi en heures creuses, limitation de débit configurée, repli local immédiat en cas de coupure réseau.

Autre enjeu : les coupures électriques. Un script de backup interrompu en cours peut laisser un repo dans un état partiellement cohérent. Restic gère bien ce cas (les snapshots ne deviennent visibles qu’après commit final) mais il faut prévoir un onduleur sur le serveur de sauvegarde lui-même, pas seulement sur le serveur principal.

Voir aussi → Cybersécurité PME Sénégal : guide complet.


Sommaire

  1. La règle 3-2-1 expliquée
  2. Installer Restic
  3. Repo Restic local + clé chiffrée
  4. Repo Restic Backblaze B2
  5. Premier backup et estimation taille
  6. Politique de rétention forget/prune
  7. Optimiser la bande passante (bandwidth limit)
  8. Cron + monitoring (healthchecks.io)
  9. Restauration testée
  10. Disque externe USB chiffré (LUKS)
  11. FAQ

1. La règle 3-2-1 expliquée

3 copies des données
2 supports différents (ex. : SSD interne + disque externe + cloud)
1 hors-site (cloud ou disque chez un autre lieu physique)

Pour une PME : 1 = production live (serveur ou laptop), 2 = NAS/disque externe, 3 = cloud chiffré offsite.

Pourquoi cette règle est devenue le standard. La règle 3-2-1 a été formalisée par Peter Krogh, photographe professionnel confronté à la perte de fichiers numériques irremplaçables. Adoptée ensuite par les sysadmin et reprise dans les recommandations d’agences gouvernementales de cybersécurité. Elle survit aux modes parce qu’elle ne dépend pas d’une technologie particulière mais d’un principe de redondance applicable à tout contexte. Une variante moderne, 3-2-1-1-0, ajoute une copie immuable et zéro erreur de vérification — pertinente pour les PME exposées aux ransomwares.

Calcul de RPO et RTO pour PME. Le RPO (Recovery Point Objective) répond à la question « combien de données peut-on se permettre de perdre ». Le RTO (Recovery Time Objective) répond à « combien de temps pour redémarrer ». Pour une PME standard : RPO 24h (un backup quotidien suffit), RTO 4-8h (une restauration depuis cloud sur un nouveau serveur prend ce temps). Pour une PME e-commerce à fort volume : RPO 1h (snapshots toutes les heures), RTO 1h (réplication chaude). Adapter la stratégie au profil de l’activité.


2. Installer Restic

Restic = sauvegarde incrémentale chiffrée, dédupliquée, multi-backend. Open-source, écrit en Go.

# Ubuntu / Debian
sudo apt install restic -y
restic version
# Doit afficher : restic 0.16.x

# Mise à jour si version < 0.16
sudo restic self-update

Sur macOS :

brew install restic

3. Repo Restic local + clé chiffrée

# Créer le repo sur disque local (NAS, second SSD)
sudo mkdir -p /mnt/backup-local/restic
sudo chown $USER:$USER /mnt/backup-local/restic

# Initialiser - prompt mot de passe
restic -r /mnt/backup-local/restic init

Sortie :

enter password for new repository: ********
created restic repository abc123def at /mnt/backup-local/restic

⚠️ Le mot de passe est non récupérable. Sans lui les données sont perdues. Stocker dans un coffre-fort de mots de passe (Bitwarden, KeePassXC) ET dans un coffre physique.

Stocker pour réutilisation :

mkdir -p ~/.config/restic
echo 'MotDePasseFortIci' > ~/.config/restic/password.txt
chmod 600 ~/.config/restic/password.txt

# Variables d'environnement
cat >> ~/.bashrc <<'EOF'
export RESTIC_REPOSITORY=/mnt/backup-local/restic
export RESTIC_PASSWORD_FILE=$HOME/.config/restic/password.txt
EOF
source ~/.bashrc

4. Repo Restic Backblaze B2

Backblaze B2 : stockage S3-like à très bas coût, pas de frais d’egress excessifs. Comparable Wasabi (offre similaire).

1. Créer un bucket B2 : backupb2.backblaze.com → New Bucket → Private → générer Application Key (avec accès lecture+écriture sur le bucket uniquement).

2. Configurer Restic :

export B2_ACCOUNT_ID="000abc..."
export B2_ACCOUNT_KEY="K000xyz..."
restic -r b2:mon-bucket-pme:/restic init

3. Pour ne pas répéter à chaque backup, créer ~/.config/restic/env-b2.sh :

#!/bin/bash
export RESTIC_REPOSITORY="b2:mon-bucket-pme:/restic"
export RESTIC_PASSWORD_FILE="$HOME/.config/restic/password.txt"
export B2_ACCOUNT_ID="000abc..."
export B2_ACCOUNT_KEY="K000xyz..."
chmod 600 ~/.config/restic/env-b2.sh

Tarifs B2 (à vérifier sur backblaze.com) : stockage et egress facturés au Go. Pour une PME avec quelques centaines de Go, les coûts mensuels restent très accessibles.


5. Premier backup et estimation taille

# Estimer la taille avant l'envoi
du -sh /var/www /home/data /etc
# Exemple sortie : 12G  /var/www
#                   8G  /home/data
#                  50M  /etc

# Premier backup vers repo local
restic backup /var/www /home/data /etc \
  --exclude='*.log' \
  --exclude='/var/www/*/wp-content/cache' \
  --exclude='node_modules' \
  --tag initial

Sortie type :

files:       45123 new,     0 changed
dirs:         2341 new,     0 changed
data:        18.4 GiB / 18.4 GiB
duration:    0:23:14
snapshot abcd1234 saved

Le premier backup est plus long. Les suivants sont incrémentaux + dédupliqués : seuls les blocs modifiés sont uploadés.


6. Politique de rétention forget/prune

# Garder : 7 daily, 4 weekly, 12 monthly, 3 yearly
restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 12 \
  --keep-yearly 3 \
  --prune

--prune recompacte le repo et supprime les blocs orphelins. Sans --prune, l’espace n’est pas libéré (forget marque seulement les snapshots).

Exécuter forget --prune en hebdomadaire suffit. Pas à chaque backup (coûteux en I/O et bande passante sur repo distant).


7. Optimiser la bande passante (bandwidth limit)

Sur connexion fibre PME ouest-africaine typique 4-8 Mbps upload, saturer ralentit toutes les autres applications.

Limiter Restic à 500 KiB/s :

restic backup ... --limit-upload 500

Programmer en heures creuses : crontab :

# Backup local quotidien 2h - sans limite (réseau interne)
0 2 * * * /usr/local/bin/backup-local.sh

# Backup cloud B2 quotidien 23h - limité 500 KiB/s
0 23 * * * /usr/local/bin/backup-b2.sh

Compresser au préalable les contenus volumineux peu compressibles : photos en RAW → JPG, vidéos en codec efficient avant stockage.


8. Cron + monitoring (healthchecks.io)

/usr/local/bin/backup-b2.sh :

#!/bin/bash
set -euo pipefail

# Charger env
source "$HOME/.config/restic/env-b2.sh"

# URL ping healthchecks.io (créer projet gratuit sur healthchecks.io)
HC_URL="https://hc-ping.com/UUID-VOTRE-CHECK"

# Notifier début
curl -fsS -m 10 --retry 3 "$HC_URL/start" > /dev/null

# Backup
restic backup /var/www /home/data /etc \
  --exclude='*.log' \
  --exclude='node_modules' \
  --limit-upload 500 \
  --tag daily

# Forget hebdo le dimanche
if [ "$(date +%u)" = "7" ]; then
  restic forget \
    --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --keep-yearly 3 \
    --prune
fi

# Vérification intégrité mensuelle (jour 1 du mois)
if [ "$(date +%d)" = "01" ]; then
  restic check --read-data-subset=10%
fi

# Notifier succès
curl -fsS -m 10 --retry 3 "$HC_URL" > /dev/null
chmod +x /usr/local/bin/backup-b2.sh

Healthchecks.io alerte par email/SMS si le ping ne survient pas dans la fenêtre attendue → backup silencieusement échoué détecté en moins de 24h.


9. Restauration testée

Lister les snapshots :

restic snapshots
# ID        Date              Tags        Paths
# abc12345  2026-04-25 02:00  daily       /var/www
# def67890  2026-04-24 02:00  daily       /var/www

Restaurer à un dossier :

restic restore abc12345 --target /tmp/restore
ls /tmp/restore/var/www/

Restaurer un fichier spécifique :

restic restore abc12345 \
  --target /tmp/restore \
  --include /var/www/boutique/wp-config.php

Mount du snapshot (FUSE) – lecture comme un disque :

mkdir /mnt/restic
restic mount /mnt/restic
# Dans un autre terminal
ls /mnt/restic/snapshots/abc12345/
# Ctrl+C dans le premier terminal pour démonter

Test mensuel automatisé :

#!/bin/bash
# /usr/local/bin/test-restore.sh
LATEST=$(restic snapshots --json | jq -r '.[-1].id')
TMP=$(mktemp -d)
restic restore "$LATEST" --target "$TMP" --include /etc/hostname
[ -f "$TMP/etc/hostname" ] && echo "OK" || (echo "FAIL"; exit 1)
rm -rf "$TMP"

10. Disque externe USB chiffré (LUKS)

Préparation initiale :

# Identifier le disque USB
lsblk
# Disons /dev/sdb

# ⚠️ DESTRUCTIF - confirme bien la cible
sudo cryptsetup luksFormat /dev/sdb1
sudo cryptsetup open /dev/sdb1 backup_usb
sudo mkfs.ext4 /dev/mapper/backup_usb -L BACKUP_USB
sudo mkdir -p /mnt/backup-usb
sudo mount /dev/mapper/backup_usb /mnt/backup-usb

Initialiser repo Restic dessus :

restic -r /mnt/backup-usb/restic init

Script de backup hebdo manuel (PME : faire tourner le disque USB toutes les semaines, en garder un toujours hors-site) :

#!/bin/bash
# backup-usb.sh
sudo cryptsetup open /dev/sdb1 backup_usb
sudo mount /dev/mapper/backup_usb /mnt/backup-usb

restic -r /mnt/backup-usb/restic backup /var/www /home/data /etc

sudo umount /mnt/backup-usb
sudo cryptsetup close backup_usb
echo "Backup USB terminé. Retirer le disque physiquement."

Rotation 2 disques :
– Lundi matin : disque-A au bureau (en cours), disque-B chez le DG (offsite)
– Lundi suivant : on échange.

→ Toujours un disque hors site quoi qu’il arrive.


FAQ

Restic vs BorgBackup vs Duplicati ?

Restic : multi-backend (local, S3, B2, SFTP, REST), Go (binaire unique), excellent. BorgBackup : excellent aussi, supporte mieux le SSH-only. Duplicati : interface web, plus pour postes de travail. Pour PME serveur Linux : Restic recommandé.

Combien de Go cloud B2 prévoir ?

Compter 1.5× la taille des données live (Restic dédupliqué + rétention multiple). 50 Go data = ~75 Go cloud. Vérifier les tarifs B2/Wasabi sur leur site officiel pour estimer.

Que faire si le mot de passe Restic est perdu ?

Rien. Les données sont chiffrées AES-256 et sans mot de passe il est impossible de les déchiffrer. C’est pourquoi le mot de passe doit absolument être stocké en double : gestionnaire de mots de passe (Bitwarden) + papier dans un coffre.

Comment chiffrer les variables d’environnement B2 ?

Utiliser pass (gestionnaire de secrets en CLI) ou gopass :

pass insert restic/b2-key
# Saisir la clé
export B2_ACCOUNT_KEY=$(pass restic/b2-key)

Restic peut-il sauvegarder une base de données live ?

Pas directement (état incohérent). Solution : pré-script qui dump la DB d’abord puis Restic backup le dump.

mysqldump -u USER -pPASS DB > /backup/db-$(date +%F).sql
restic backup /backup /var/www
rm /backup/db-*.sql

Comment monitorer plusieurs serveurs en même temps ?

1 healthchecks.io par job, dashboard regroupé. Alternative : Prometheus + node_exporter + alertmanager si déjà en place.

Que faire en cas d’attaque ransomware sur le serveur principal ?

  1. Couper réseau du serveur infecté
  2. Vérifier que le repo Restic distant n’a pas été supprimé (ransomware peut chercher à effacer les backups)
  3. Restaurer sur un nouveau serveur propre depuis le snapshot précédent l’infection
  4. Conserver le serveur infecté pour forensic

Protection clé : clé B2 avec permission « écriture sans suppression » (B2 supporte les Object Lock / immutability) → un ransomware ne peut pas effacer les backups même avec la clé.

Faut-il chiffrer un disque USB en plus de Restic ?

Restic chiffre déjà les données. LUKS ajoute une couche : si le disque est volé, l’attaquant doit casser LUKS ET trouver le mot de passe Restic. Recommandé pour les disques transportés / stockés hors-site.


Articles liés (cluster Cybersécurité PME)

Voir aussi : Linux administration avancée pour PME pour les fondamentaux sysadmin, Cloud abordable pour PME pour comparer les options de stockage offsite.


Article mis à jour le 25 avril 2026. Pour signaler une erreur ou suggérer une amélioration, écrivez-nous.

Besoin d'un site web ?

Confiez-nous la Création de Votre Site Web

Site vitrine, e-commerce ou application web — nous transformons votre vision en réalité digitale. Accompagnement personnalisé de A à Z.

À partir de 250.000 FCFA
Parlons de Votre Projet
Publicité