Sauvegardes : la règle du 3-2-1 en pratique

Un serveur qui brûle, un disque Ceph qui perd un PG au pire moment, un plugin WordPress qui vide la base, un employé qui lance rm -rf dans le mauvais terminal, un ransomware qui chiffre tout ce qui est monté en SMB. La question n'est jamais « est-ce que ça va arriver » mais « quand ». La règle du 3-2-1 est la réponse minimale acceptable, et elle tient en trois chiffres.

La règle en 30 secondes

• 3 copies de la donnée : l'originale plus deux sauvegardes.
• 2 supports de nature différente : pas deux fois le même disque, pas deux fois le même datacenter.
• 1 copie hors site : physiquement ailleurs, chez un autre prestataire ou à la maison.

Pourquoi ces chiffres, concrètement

3 copies : l'arithmétique du risque

Avec une seule copie (l'originale), la moindre panne efface tout. Avec deux, si la première sauvegarde est sur le même serveur que la prod, un ransomware chiffre les deux d'un coup. Trois copies permettent d'en perdre deux simultanément et de repartir quand même. C'est ce qui sauve lors d'un incident type « le backup Plesk local est là mais le pirate a obtenu l'accès admin et l'a effacé avant de chiffrer ».

2 supports : ne pas mettre tous ses œufs dans le même Ceph

Un backup Plesk stocké sur le même abonnement que la prod n'est pas un backup, c'est une copie locale. Si le disque logique saute, les deux partent ensemble. Il faut au minimum un deuxième support : un autre serveur, un S3 compatible, un NAS, un Nextcloud dédié aux sauvegardes.

1 hors site : parce que les datacenters brûlent aussi

Strasbourg 2021, tout le monde s'en souvient. Un datacenter bien conçu peut disparaître en une nuit. Une copie physiquement ailleurs (autre région, autre opérateur, un NAS chiffré chez vous) est la dernière ligne de défense. Chez Datacampus on héberge au Futuroscope, le site offsite doit donc être à Paris, à Lyon, à Francfort, ou dans votre bureau à Niort. Peu importe, du moment que ce n'est pas Cassin1.

Traduction pratique pour un client Datacampus

Ce que Datacampus fournit par défaut

• Offres Plesk mutualisé : backup Plesk automatique quotidien, rétention 7 jours, stocké sur un volume Ceph distinct de la prod. C'est votre copie n°2.
• VPS et clusters Proxmox : snapshots Proxmox possibles à la demande ou via cron, et option Datacampus Backup Externe qui réplique vers un second cluster Ceph isolé (toujours au Futuroscope). Ça couvre bien la copie n°2, mais ce n'est pas offsite.
• La copie n°3 (offsite) reste à votre charge. C'est le point où on voit le plus de clients se faire avoir. L'option existe, elle n'est pas activée par défaut.

Exemple concret : script mysqldump + rclone vers S3

Cas type : un WordPress en mutualisé Plesk. On veut une copie offsite hebdomadaire sur un bucket Scaleway ou Backblaze B2, chiffrée au repos, avec rétention de 8 semaines.

1. Installer rclone et le configurer

# En SSH sur votre abonnement
curl https://rclone.org/install.sh | sudo bash

# Configuration interactive (à faire une fois)
rclone config
# Choisir : n (new remote)
# Nom : backup-offsite
# Type : s3
# Provider : Scaleway (ou BackBlaze, Wasabi, AWS selon votre choix)
# Renseigner access key / secret / endpoint / région

2. Le script de sauvegarde

#!/bin/bash
# /var/www/vhosts/exemple.fr/backup-offsite.sh
set -euo pipefail

VHOST="/var/www/vhosts/exemple.fr"
STAMP=$(date +%Y-%m-%d)
TMPDIR=$(mktemp -d)
trap 'rm -rf "$TMPDIR"' EXIT

# 1. Dump SQL (credentials dans ~/.my.cnf, jamais en clair dans le script)
mysqldump --single-transaction --quick --default-character-set=utf8mb4 \
    wp_exemple | gzip > "$TMPDIR/db-$STAMP.sql.gz"

# 2. Archive fichiers (on exclut les caches, inutile d'exporter 3 Go de cache WP)
tar --exclude='wp-content/cache' \
    --exclude='wp-content/uploads/cache' \
    --exclude='.git' \
    -czf "$TMPDIR/files-$STAMP.tar.gz" \
    -C "$VHOST" httpdocs

# 3. Chiffrement avec age (clé publique, la clé privée reste hors serveur)
for f in "$TMPDIR"/*.gz; do
    age -r "$(cat ~/.config/age/backup.pub)" -o "$f.age" "$f"
    rm "$f"
done

# 4. Upload vers S3, dossier daté
rclone copy "$TMPDIR/" "backup-offsite:exemple-fr-backups/$STAMP/" \
    --s3-storage-class=STANDARD_IA

# 5. Rétention : 8 semaines
rclone delete "backup-offsite:exemple-fr-backups/" \
    --min-age 56d

3. Le cron hebdomadaire

# Dans les tâches planifiées Plesk, ou via crontab -e
# Tous les dimanches à 2 h 30
30 2 * * 0 /var/www/vhosts/exemple.fr/backup-offsite.sh >> /var/www/vhosts/exemple.fr/logs/backup.log 2>&1

Chiffrer, toujours

Un backup qui part chez un tiers doit être chiffré. Pas parce que Scaleway ou Backblaze vont vous trahir, mais parce que :

• Vos credentials S3 peuvent fuiter (GitHub public par accident, poste compromis).
• Un employé du prestataire pourrait techniquement y accéder (dans les faits non, mais RGPD oblige).
• Si le bucket est mal configuré (public par erreur), au moins les fichiers restent illisibles.

Trois options, par ordre de robustesse :

1. Chiffrement côté client avec age ou gpg avant upload. C'est le modèle du script ci-dessus. Zero-knowledge : le prestataire ne peut jamais lire.
2. restic ou BorgBackup : chiffrement natif, déduplication, rétention intégrée. Plus élégant qu'un script bash, et c'est ce qu'on recommande pour du volume.
3. Chiffrement côté serveur S3 (SSE-S3, SSE-KMS). Simple à activer, mais le prestataire détient les clés. Mieux que rien, pas suffisant pour des données sensibles.

Tester la restauration, sinon ça ne compte pas

Procédure de test recommandée :

1. Une fois par trimestre, télécharger la dernière sauvegarde offsite depuis le bucket S3.
2. La déchiffrer avec la clé privée (vérifie que la clé est toujours accessible et que vous savez comment faire).
3. Restaurer sur un environnement de préprod isolé. Voir la doc Copier la prod vers la préprod pour le workflow.
4. Vérifier : le site se lance, la base est cohérente, les uploads sont là, les dates sont bonnes.
5. Noter la date du test dans un tableau partagé avec l'équipe. En cas d'audit (RGPD, ISO), c'est ce qui fait foi.

Rétention et RGPD

Garder des sauvegardes indéfiniment n'est ni utile ni légal. Quelques repères :

Concrètement : documentez qui peut accéder aux backups (liste courte, MFA obligatoire), où sont stockées les clés de déchiffrement, et combien de temps chaque jeu de sauvegardes est conservé. Ce document s'intègre au registre des traitements RGPD.

La variante moderne : 3-2-1-1-0

Pour les structures plus exposées (e-commerce, SaaS, données sensibles), la règle s'étend :

• 3 copies, 2 supports, 1 offsite : la base.
• + 1 copie immuable : impossible à effacer ou modifier pendant X jours (object lock S3, WORM). Protège contre un pirate qui aurait obtenu les clés.
• + 0 erreur : la dernière restauration test s'est bien passée. Pas de « ça devrait marcher », c'est vérifié.

Scaleway Object Storage, OVH S3, Backblaze B2 et AWS S3 supportent tous l'object lock. C'est une case à cocher à la création du bucket, ça ne coûte rien de plus, et ça change tout contre un ransomware qui saurait utiliser vos credentials.

Récapitulatif

1. Trois copies : prod + backup local (Plesk / Proxmox) + backup offsite.
2. Deux supports différents : pas tout sur le même cluster.
3. Une copie hors du datacenter Datacampus : chez un autre prestataire S3 ou chez vous.
4. Chiffrement côté client (age, restic, Borg). La clé privée ne vit pas sur le serveur.
5. Rétention définie et documentée (RGPD).
6. Test de restauration trimestriel minimum, documenté.
7. Pour les cas sensibles : object lock S3 pour l'immutabilité.

Besoin d'un coup de main pour poser la tuyauterie ? Ouvrez un ticket sur le ServiceDesk Datacampus, l'équipe peut cadrer le script, fournir l'option backup externe Ceph, et vous orienter vers un S3 compatible adapté au volume.