Stratégies de Backup : Restic, BorgBackup, Velero et Disaster Recovery

Pourquoi le backup est une compétence critique en DevOps

En production, la question n’est pas si tu perdras des données, mais quand. Un disque qui lâche, un DROP TABLE en prod lancé par erreur, un ransomware qui chiffre tout un NAS à 3h du matin — ces scénarios arrivent dans toutes les entreprises, des startups aux grands groupes. Le backup est le dernier rempart entre un incident et une catastrophe.

Pourtant, beaucoup d’équipes traitent encore le backup comme une corvée secondaire. On configure un cron, on oublie de vérifier, et le jour J, on découvre que les dumps sont corrompus depuis six mois. Ce cours te donne les fondations solides : la stratégie, les outils modernes (Restic, Borg, Velero) et surtout la discipline pour construire un vrai plan de disaster recovery.

🧠 À retenir — Un backup qui n’a jamais été testé en restauration n’est pas un backup, c’est un espoir.

La règle 3-2-1 et les métriques RPO/RTO

Avant de toucher un seul outil, il faut comprendre la stratégie. La règle 3-2-1 est le socle de toute politique de backup sérieuse :

• 3 copies de tes données (l’original + 2 backups)
• 2 supports de stockage différents (SSD serveur + NAS, ou disque + cloud)
• 1 copie hors site (off-site), géographiquement séparée

Pour les environnements critiques (finance, santé, SaaS B2B), on pousse vers la variante 3-2-1-1-0 : une copie supplémentaire air-gapped (déconnectée du réseau, donc intouchable par un ransomware) et zéro erreur vérifiée lors de tests de restauration.

Deux métriques pilotent toute ta stratégie :

• RPO (Recovery Point Objective) — la quantité maximale de données que tu acceptes de perdre. Un RPO de 1 heure signifie que tu backups au moins toutes les heures.
• RTO (Recovery Time Objective) — le temps maximum de downtime acceptable. Un RTO de 4 heures signifie que tu dois pouvoir restaurer un service complet en moins de 4 heures.

💡 Tip DevOps — Définis le RPO et le RTO avec le métier, pas seul dans ton coin. Un RPO de 5 minutes sur une base e-commerce a un coût très différent d’un RPO de 24 heures sur un wiki interne.

🔥 Cas réel — Une fintech européenne a perdu 72h de transactions parce que le backup S3 était configuré dans la même région que la base RDS. Quand la région AWS est tombée, les deux ont disparu en même temps. La copie off-site cross-region aurait tout sauvé.

Restic : le couteau suisse du backup moderne

Restic est devenu l’outil de référence pour les backups en environnement DevOps. Ses atouts : chiffrement AES-256 de bout en bout, déduplication au niveau des blocs (seules les parties modifiées sont re-uploadées), support natif de S3, SFTP, Azure Blob, GCS, et des snapshots immutables avec vérification d’intégrité.

On commence par initialiser un repository de backup. Ici, on utilise S3 comme backend — le cas le plus courant en production :

# Installation
sudo apt install restic    # Debian/Ubuntu
brew install restic         # macOS

# Variables d'environnement pour le repo S3
export AWS_ACCESS_KEY_ID="AKIA..."
export AWS_SECRET_ACCESS_KEY="..."
export RESTIC_PASSWORD="un-mot-de-passe-très-long-et-random"
export RESTIC_REPOSITORY="s3:s3.eu-west-1.amazonaws.com/my-backups"

# Initialisation du repo (une seule fois)
restic init

Un backup basique se lance en une commande. Restic gère la déduplication automatiquement — les runs suivants seront beaucoup plus rapides car seuls les blocs modifiés sont envoyés :

# Backup d'un répertoire PostgreSQL
restic backup /var/lib/postgresql/data \
    --tag postgres --tag production \
    --exclude="*.tmp" --exclude="pg_wal/*"

# Vérifier les snapshots existants
restic snapshots

La restauration est tout aussi directe. Restic permet de restaurer un snapshot complet, un sous-dossier, ou même de monter le backup en lecture seule via FUSE pour explorer les fichiers avant de décider quoi récupérer :

# Restaurer le dernier snapshot complet
restic restore latest --target /var/restore/

# Extraire un seul fichier depuis le dernier snapshot
restic dump latest "/var/backups/postgres/full_dump.sql" > /tmp/restore.sql

# Monter pour explorer (nécessite FUSE)
mkdir /mnt/restic && restic mount /mnt/restic &
ls /mnt/restic/snapshots/latest/

⚠️ Attention — Ne stocke jamais RESTIC_PASSWORD en clair dans un script versionné. Utilise RESTIC_PASSWORD_FILE pointant vers un fichier protégé (mode 600) ou un secret manager (Vault, AWS Secrets Manager).

En production, le backup est automatisé via un script qui combine dump de base, envoi restic, politique de rétention et vérification d’intégrité. Voici un exemple complet pour PostgreSQL :

#!/bin/bash
# /usr/local/bin/backup-postgres.sh
set -euo pipefail

export RESTIC_REPOSITORY="s3:s3.eu-west-1.amazonaws.com/backups-prod"
export RESTIC_PASSWORD_FILE="/etc/restic/password"

BACKUP_DIR="/var/backups/postgres"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)

# 1. Dump PostgreSQL
pg_dumpall -U postgres > "${BACKUP_DIR}/full_dump_${TIMESTAMP}.sql"

# 2. Envoi vers restic (dédupliqué + chiffré)
restic backup "${BACKUP_DIR}" --tag postgres --tag "dump-${TIMESTAMP}"

# 3. Nettoyage des dumps locaux > 3 jours
find "${BACKUP_DIR}" -name "full_dump_*.sql" -mtime +3 -delete

# 4. Politique de rétention
restic forget \
    --keep-hourly 24 --keep-daily 30 \
    --keep-weekly 12 --keep-monthly 24 \
    --keep-yearly 5 --prune

# 5. Vérification d'intégrité (le dimanche)
if [ "$(date +%u)" -eq 7 ]; then
    restic check --read-data-subset=10%
fi

# 6. Notification Slack
curl -s -X POST "${SLACK_WEBHOOK}" \
    -H 'Content-Type: application/json' \
    -d '{"text":"✅ Backup PostgreSQL OK"}'

BorgBackup et Velero : alternatives spécialisées

BorgBackup excelle sur un point : la compression. Là où Restic ne compresse pas nativement, Borg propose lz4, zstd et zlib. Sur des données textuelles (logs, dumps SQL), Borg peut réduire la taille de stockage de 60 à 80%. Il est idéal pour les backups vers un NAS local via SSH.

# Initialiser un repo Borg chiffré
borg init --encryption=repokey-blake2 ssh://backup-server/~/borg-repo

# Backup avec compression zstd
borg create --stats --compression zstd,6 \
    ssh://backup-server/~/borg-repo::'{hostname}-{now}' \
    /etc /var/lib/docker/volumes /home/app

# Résultat typique :
# Original size: 12.45 GB → Deduplicated: 892 MB

Velero est l’outil de backup natif pour Kubernetes. Il sauvegarde à la fois les ressources du cluster (Deployments, Services, ConfigMaps, Secrets) et les Persistent Volumes. C’est indispensable : un backup des données sans l’état du cluster ne permet pas une restauration complète.

# Backup d'un namespace complet
velero backup create prod-backup \
    --include-namespaces production --ttl 720h

# Backup planifié quotidien
velero schedule create daily-backup \
    --schedule="0 2 * * *" \
    --include-namespaces production --ttl 720h

# Restauration (y compris dans un namespace différent)
velero restore create --from-backup prod-backup \
    --namespace-mappings production:dr-production

💡 Tip DevOps — Utilise Restic pour les VMs et serveurs classiques, Borg quand la compression est critique (backups vers un NAS avec espace limité), et Velero pour tout ce qui tourne sur Kubernetes. Ces outils sont complémentaires, pas concurrents.

Construire un Disaster Recovery Plan qui tient la route

Un DR plan n’est pas un document Word oublié dans un SharePoint. C’est un runbook opérationnel, testé régulièrement, que n’importe quel membre de l’équipe on-call peut exécuter sous stress à 3h du matin.

Le plan doit couvrir des scénarios concrets avec des procédures pas à pas. Voici la structure qui fonctionne en entreprise :

# DR Plan - Service de paiement

## Classification : RTO 4h | RPO 1h | Criticité P1

## Scénario A : Perte de la base PostgreSQL
1. Lancer /ops/dr/restore-db.sh (restauration depuis restic)
2. Vérifier l'intégrité avec /ops/dr/verify-db.sh
3. Mettre à jour les connexions si nouvelle instance
→ Temps estimé : 45 minutes

## Scénario B : Perte du cluster Kubernetes
1. Provisionner nouveau cluster : terraform apply -var env=dr
2. Installer Velero, pointer vers le backup bucket
3. Restaurer : velero restore create --from-backup latest
→ Temps estimé : 2 heures

## Scénario C : Perte de la région AWS complète
1. Basculer DNS vers la région DR (eu-central-1)
2. Activer le cluster standby
3. Restaurer les données depuis le backup cross-region
→ Temps estimé : 3 heures

Le test est la partie la plus importante. Un DR plan non testé est un document fiction. Voici un script de test automatisé à exécuter mensuellement :

#!/bin/bash
# test-dr.sh — Test mensuel de disaster recovery
echo "=== Test DR $(date) ==="

# Test 1 : Restauration depuis restic
TEMP_DIR=$(mktemp -d)
restic restore latest --target "$TEMP_DIR" --tag postgres
psql -h localhost -p 5433 -U test -f "$TEMP_DIR/full_dump.sql" test_dr
echo "✅ Restauration DB réussie"

# Test 2 : Vérification intégrité du repo
restic check --read-data
echo "✅ Intégrité repo OK"

# Test 3 : Restauration Velero dans un namespace de test
velero restore create dr-test-$(date +%s) \
    --from-backup daily-latest \
    --namespace-mappings production:dr-test
sleep 120
kubectl get pods -n dr-test --no-headers | wc -l
echo "✅ Pods Kubernetes restaurés"

# Nettoyage
kubectl delete namespace dr-test
rm -rf "$TEMP_DIR"
echo "=== Test DR terminé ==="

🔥 Cas réel — GitLab a publié en 2017 un post-mortem célèbre : 5 méthodes de backup étaient en place, aucune ne fonctionnait correctement le jour de l’incident. Un seul test de restauration aurait révélé le problème des mois avant.

Bonnes pratiques et pièges à éviter

Les fondamentaux à respecter :

• Automatise tout — un backup qui dépend d’une action manuelle sera oublié
• Chiffre systématiquement — même en réseau interne, un backup non chiffré est une fuite de données en attente
• Monitore activement — configure des alertes si un backup n’a pas tourné (Prometheus, Datadog, simple cron + healthcheck)
• Teste mensuellement — chronomètre ton RTO réel et compare avec l’objectif
• Documente les procédures — le jour du DR, tu seras stressé, tes runbooks doivent être exécutables sans réfléchir

Les pièges classiques :

• Backup et données dans la même région/zone — si la région tombe, tout part
• Rétention trop courte — un ransomware peut rester dormant des semaines avant de se déclencher, si ta rétention est de 7 jours, tous tes backups sont infectés
• Ignorer les WAL/oplog — un dump quotidien donne un RPO de 24h, l’archivage des WAL (PostgreSQL) ou de l’oplog (MongoDB) permet du point-in-time recovery à la seconde près
• Oublier de tester la restauration — le piège numéro un, toujours

⚠️ Attention — La rétention de 7 jours est insuffisante pour se protéger des ransomwares. Garde au minimum 30 jours de daily, 12 semaines de weekly. Les backups air-gapped (déconnectés du réseau) sont ta meilleure protection.

🧠 À retenir — La stratégie 3-2-1 est ton minimum vital. Restic et Borg te donnent des backups chiffrés et dédupliqués. Velero protège ton état Kubernetes. Mais l’outil ne suffit pas — c’est la discipline qui fait la différence : automatiser, tester, documenter. Un bon backup, c’est un backup restauré avec succès.