Stratégie de sauvegarde cloud : un guide complet

Une stratégie de sauvegarde cloud opérationnelle suit la règle 3-2-1 : trois copies de vos données, sur deux types de supports différents, avec une copie hors site — en pratique, cela signifie un stockage principal (production), une sauvegarde locale (NAS ou disque externe), et au moins un niveau cloud (Backblaze B2, AWS S3 Glacier Deep Archive, ou Wasabi). Ajoutez l'immuabilité via Object Lock, chiffrez côté client avec AES-256 avant l'envoi, automatisez chaque nuit via restic ou Borg, et — c'est l'étape que la plupart des équipes sautent — testez une restauration complète chaque trimestre. Sans restauration testée, vous avez de l'espoir, pas une sauvegarde.

Pourquoi la règle 3-2-1 tient toujours en 2026

La règle 3-2-1 date de la photographie argentique, mais le calcul n'a pas changé. Trois copies offrent une redondance suffisante pour que toute défaillance unique (panne disque, ransomware, rm -rf accidentel) laisse deux copies intactes. Deux types de supports couvrent les pannes systémiques — une mauvaise version de firmware briquant tout un modèle de SSD, ou une panne de région chez un fournisseur cloud. La copie hors site protège contre les événements au niveau du bâtiment : incendie, inondation, vol, ou le camion de déménagement qui percute votre rack.

Des variantes modernisées existent. 3-2-1-1-0 ajoute une copie immuable et exige zéro erreur dans les tests de restauration. 4-3-2 (utilisé par de nombreux MSP) conserve quatre copies et deux fournisseurs cloud. Choisissez-en une, documentez-la, et tenez-vous-y. Le chiffre exact importe moins que la discipline.

Choisir les niveaux de stockage : coût contre vitesse de récupération

Les fournisseurs cloud proposent des classes de stockage à des prix radicalement différents :

| Niveau | Coût par Go/mois | Latence premier octet | Frais d'egress | |--------|-----------------|----------------------|----------------| | S3 Standard | 0,023 $ | millisecondes | 0,09 $/Go | | S3 Glacier Instant | 0,004 $ | millisecondes | 0,03 $/Go | | S3 Glacier Flexible | 0,0036 $ | 3-5 minutes | 0,02 $/Go | | S3 Glacier Deep Archive | 0,00099 $ | 12 heures | 0,02 $/Go | | Backblaze B2 | 0,006 $ | millisecondes | 0,01 $/Go | | Wasabi | 0,0069 $ | millisecondes | gratuit (jusqu'à 1x stocké/mois) | | Cloudflare R2 | 0,015 $ | millisecondes | gratuit |

Pour la sauvegarde spécifiquement, Glacier Deep Archive atteint environ 1 $ par To par mois, mais la latence de restauration signifie que vous ne pouvez pas l'utiliser pour « j'ai supprimé le fichier d'hier par erreur ». Une approche à deux niveaux fonctionne mieux : les sauvegardes récentes dans un niveau chaud (B2 ou R2), les données de plus de 30 jours migrées vers Glacier Deep Archive.

La règle 3-2-1 en termes concrets

Un exemple de pile pour un ensemble de données de 2 To :

Production : portables, serveurs, données SaaS (copie principale)
Local : NAS avec ZFS et snapshots, 4 To utilisables, miroir hebdomadaire sur un disque USB externe dans un coffre ignifuge
Cloud chaud : bucket Backblaze B2 avec restic, incrémentiel nocturne, rétention 90 jours à ~12 $/mois pour 2 To
Cloud froid : S3 Glacier Deep Archive via politique de cycle de vie, snapshots annuels, rétention 7 ans à ~24 $/an pour 2 To

Coût mensuel total : moins de 20 $ pour une couverture 3-2-1 complète avec un historique de sept ans. Moins cher qu'un portable de remplacement.

Automatiser les sauvegardes avec des outils fiables

Restic est le choix par défaut pour les sauvegardes incrémentielles chiffrées vers le stockage objet. Il déduplique, compresse, chiffre avec AES-256-CTR plus Poly1305, et supporte B2, S3, Azure, GCS et SFTP nativement :

restic -r b2:hexa-backups:production init
restic -r b2:hexa-backups:production backup /var/data \
  --exclude-file=/etc/restic/exclude.txt \
  --tag nightly
restic -r b2:hexa-backups:production forget \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

Exécutez-le chaque nuit via un timer systemd ou cron, avec le mot de passe du référentiel dans un fichier lisible uniquement par root. Borg Backup est une excellente alternative, particulièrement si vous avez besoin de support de référentiels locaux ; Kopia est plus récent et dispose d'une interface plus conviviale.

Pour les postes Windows, Duplicati ou l'historique de fichiers Windows intégré plus une cible cloud couvre les bases. Pour Mac, Time Machine vers un NAS local plus Arq Backup vers Backblaze B2 est une combinaison éprouvée.

Rendre les sauvegardes immuables contre les ransomwares

Les ransomwares qui chiffrent vos données de production vont aussi tenter de chiffrer vos sauvegardes. Object Lock l'empêche. AWS S3 et Backblaze B2 supportent le « mode conformité » où même le compte root ne peut pas supprimer les objets avant l'expiration de la période de rétention :

aws s3api put-object-lock-configuration \
  --bucket backup-immutable \
  --object-lock-configuration '{
    "ObjectLockEnabled":"Enabled",
    "Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}
  }'

Pendant 30 jours après l'envoi, personne — même un administrateur compromis — ne peut supprimer la sauvegarde. Combinez cela avec le versionnement, MFA-delete, et un rôle IAM qui peut écrire mais pas écraser, et vous avez fermé le chemin d'attaque ransomware dominant.

Chiffrer côté client avant l'envoi

Même avec le chiffrement côté fournisseur (SSE-KMS), votre fournisseur cloud détient les clés, ce qui signifie que des demandes de réquisition judiciaire peuvent contraindre le déchiffrement. Pour les données sensibles — dossiers médicaux, documents juridiques, CUI de contractants de défense — chiffrez avant que les octets ne quittent votre réseau. Restic le fait automatiquement ; pour les fichiers ad hoc, age est un bon choix :

age -r age1xyz... -o archive.tar.gz.age archive.tar.gz
aws s3 cp archive.tar.gz.age s3://backups/

Stockez la clé privée age dans 1Password ou une clé de sécurité matérielle comme YubiKey. Sauvegardez la clé elle-même sur papier, chiffrée avec une phrase secrète, dans un coffre-fort bancaire. Une clé de chiffrement perdue est aussi catastrophique que des données perdues.

Les tests de restauration, c'est la sauvegarde

Chaque trimestre, choisissez un fichier ou un serveur aléatoire et restaurez-le de bout en bout dans un environnement propre. Mesurez :

RTO (Recovery Time Objective) : de la décision à la restauration
RPO (Recovery Point Objective) : quelle quantité de données a été perdue (heures, jours)
Intégrité : les octets restaurés correspondent-ils au hash d'origine ?

Un exemple réel : une équipe effectuant des sauvegardes nocturnes vers S3 Glacier Deep Archive a découvert lors de son premier test de restauration que le provisionnement des permissions de restauration plus l'attente de la récupération en 12 heures donnait un RTO de 18 heures alors que l'entreprise avait besoin de 4. Elle a déplacé la rétention active vers Glacier Flexible (récupération en 3-5 minutes) et conservé Deep Archive uniquement pour l'historique de conformité. Ce test leur a évité d'apprendre la leçon lors d'un vrai incident.

Documentez le runbook au fur et à mesure : commandes, identifiants, phrases secrètes de déchiffrement, qui peut autoriser une restauration. Testez-le sur un portable neuf pour vous assurer que le runbook fonctionne sans votre environnement local.

Exigences réglementaires de rétention

De nombreux cadres réglementaires spécifient une rétention minimale :

RGPD : pas de durée fixe ; conservez uniquement le temps nécessaire aux finalités déclarées
HIPAA : 6 ans pour les journaux d'audit et les politiques
SOX : 7 ans pour les documents financiers
PCI DSS 4.0 : 1 an pour les pistes d'audit, 3 mois « immédiatement disponibles »
FINRA 17a-4 : 3-6 ans, stockage conforme WORM requis

En France, la CNIL applique les principes du RGPD sur la minimisation des données et les durées de conservation : ni plus longtemps que nécessaire (problème RGPD), ni moins longtemps que requis (problème SOX). Étiquetez les sauvegardes avec des métadonnées de rétention et appliquez-les via des politiques de cycle de vie.

Surveillance et alertes

Les sauvegardes qui échouent silencieusement sont pires qu'aucune sauvegarde. Chaque tâche restic ou Borg doit émettre des métriques : durée, octets transférés, fichiers modifiés, succès/échec. Envoyez vers Prometheus, Datadog, ou un journal cron simple surveillé par un outil de type Dead Man's Snitch qui alerte quand le battement de cœur attendu n'arrive pas. Le mode d'échec que vous cherchez à détecter est « les sauvegardes sont cassées depuis 90 jours et personne ne l'a remarqué ».

Alertez sur : échec de tâche, tâche ignorée, corruption du référentiel (restic check), changement de taille inhabituel (perte de données ou croissance inattendue), et test de restauration échoué.

HexaTransfer n'est pas un outil de sauvegarde — il est conçu pour les transferts chiffrés ponctuels — mais les mêmes principes de chiffrement de bout en bout s'appliquent quand vous envoyez une archive de sauvegarde à un collègue. Essayez-le sur https://hexatransfer.com — gratuit, sans compte, 10 Go maximum.

De la stratégie à la discipline

Une stratégie de sauvegarde cloud vit ou meurt par la discipline plus que par l'architecture. Les exécutions nocturnes, les tests de restauration trimestriels, les révisions annuelles du runbook, la rétention immuable, et le chiffrement côté client ne sont pas glamour, mais ils font la différence entre « nous avions une sauvegarde » et « nous avions une récupération ». Notez ce que vous faites, automatisez ce que vous pouvez, testez ce que vous ne pouvez pas automatiser, et maintenez le coût mensuel total suffisamment bas pour que personne en finance ne vous demande jamais de le réduire. Pas cher et ennuyeux bat coûteux et brillant à chaque fois.