Plan de sauvegarde et récupération : protégez vos fichiers

Un plan de sauvegarde et de récupération répond à deux questions numériques : le RPO (quelle perte de données peut-on accepter, mesurée en temps) et le RTO (combien de temps peut-on se permettre d'être hors service). Définissez-les pour chaque charge de travail, puis concevez à rebours. Une base de données avec un RPO de 5 minutes nécessite du WAL shipping continu ; un rapport marketing hebdomadaire avec un RPO de 24 heures n'a besoin que d'un job nocturne. Combinez avec la règle 3-2-1 — trois copies, sur deux types de supports, avec une hors site — et testez les restaurations chaque trimestre. La plupart des histoires « on a des sauvegardes » se terminent mal parce que personne n'a jamais exercé la restauration.

RPO et RTO : les chiffres de départ

RPO (Recovery Point Objective) = perte de données maximale acceptable dans le temps. RTO (Recovery Time Objective) = durée d'indisponibilité maximale acceptable.

Exemples par charge de travail :

Base de données de production pour un site e-commerce : RPO 5 min, RTO 1 heure
Envois de fichiers par les clients : RPO 15 min, RTO 2 heures
Serveur de fichiers interne : RPO 24 heures, RTO 8 heures
Archive e-mail : RPO 24 heures, RTO 48 heures
Analyses marketing : RPO 24 heures, RTO 72 heures

Des RPO/RTO plus serrés coûtent plus cher. Un RPO de 5 minutes implique une réplication continue (infrastructure coûteuse) ; un RPO de 24 heures n'implique qu'un job nocturne (économique). Ne surdimensionnez pas — toutes les charges de travail n'ont pas besoin d'un standby à chaud.

La règle 3-2-1 reste valable

Trois copies des données, sur deux types de stockage différents, avec une hors site. La règle 3-2-1 précède le cloud et reste pertinente :

Primaire : stockage de production (S3, EBS, disque PostgreSQL)
Secondaire : sauvegarde sur un support différent ou dans une région différente (autre bucket S3 avec réplication, Glacier)
Tertiaire : hors site, idéalement chez un fournisseur différent ou physiquement isolé (Backblaze B2, bande sur site, disques physiques dans un coffre)

La diversité des fournisseurs est importante. Un compte AWS root compromis peut supprimer toutes vos sauvegardes AWS. Une copie secondaire chez Backblaze, Wasabi ou sur site survit à ce scénario. Pour les entreprises de moins de 50 M€ de chiffre d'affaires, une copie chez un second fournisseur ajoute peut-être 50 à 200 € par mois et assure contre les incidents catastrophiques au niveau du locataire.

Sauvegarde complète, incrémentale et synthétique complète

Trois stratégies de sauvegarde :

Complète : copiez tout à chaque fois. Simple, restauration rapide (un seul fichier), stockage lourd.
Incrémentale : copiez uniquement ce qui a changé depuis la dernière sauvegarde. Économe en stockage, la restauration nécessite la sauvegarde complète + toutes les incrémentales.
Synthétique complète : fusion côté serveur de la complète + des incrémentales en une nouvelle complète virtuelle. Restauration rapide depuis n'importe quel point.

Les outils de sauvegarde modernes (Veeam, Rubrik, restic avec prune, BorgBackup) utilisent l'incrémental permanent avec des complètes synthétiques en arrière-plan. Le schéma : incrémentale nocturne, synthétique complète hebdomadaire, conserver 30 journaliers + 12 mensuels + 7 annuels (rotation grand-père-père-fils).

Pour un serveur de fichiers de 2 To avec un taux de changement quotidien de 5 %, l'incrémental permanent stocke environ 3 à 5 To au total pour un an de rétention — contre plus de 700 To si vous faisiez une complète chaque nuit.

Chiffrement avant toute transmission

Les sauvegardes ne doivent pas voyager ni rester non chiffrées. Le chiffrement côté client avec AES-256-GCM (par défaut dans restic, Borg, Duplicacy, Veeam et autres) garantit que l'hôte de sauvegarde ne voit jamais de texte clair.

La gestion des clés compte plus que le choix de l'algorithme. Une sauvegarde chiffrée avec une clé stockée dans le même compte AWS que la sauvegarde n'est qu'une mise en scène — un attaquant avec l'accès IAM obtient les deux. Stockez les clés dans :

AWS KMS avec une clé dans un compte séparé (déchiffrement inter-comptes)
HashiCorp Vault dans un environnement hors bande
Un module de sécurité matériel (YubiKey, HSM) pour la clé racine
Une copie papier imprimée et scellée pour les clés vraiment critiques

Faites une rotation régulièrement (annuellement), journalisez chaque utilisation, et testez la récupération avec une clé ayant subi une rotation avant que celle-ci prenne effet en production.

L'immuabilité : la réponse aux ransomwares

Les attaques de ransomware ciblent couramment les sauvegardes en premier — chiffrez les données de production, puis supprimez ou chiffrez les sauvegardes pour empêcher la récupération. Les sauvegardes immuables déjouent cette stratégie.

Implémentations :

S3 Object Lock (mode Compliance) : même le root ne peut pas supprimer pendant la période de rétention
Stockage immuable Azure Blob : similaire, appliqué au niveau du conteneur
Veeam Hardened Linux Repository : append-only, SSH uniquement, pas d'API de suppression
Bande physique dans un coffre : l'isolement physique ultime

Pour les données critiques, au moins une copie de sauvegarde doit être immuable pendant la période de rétention. Le coût supplémentaire est généralement nul — vous alliez de toute façon la conserver. La valeur quand le ransomware frappe est totale.

Les tests : la partie non négociable

Une sauvegarde que vous n'avez jamais restaurée n'est pas une sauvegarde ; c'est de l'espoir. Calendrier de tests par priorité :

Niveau 1 (mission critique) : exercice de restauration complet chaque trimestre, restauration de fichier aléatoire chaque mois
Niveau 2 (important pour l'activité) : exercice de restauration complet semestriel, restauration de fichier aléatoire chaque trimestre
Niveau 3 (standard) : exercice de restauration complet annuel, restauration de fichier aléatoire chaque trimestre

Documentez dans le test :

Combien de temps a duré la restauration (à comparer avec le RTO)
Les données correspondaient-elles à l'état de production (sommes de contrôle contre un point connu)
Des permissions ou configurations ont-elles échoué à la restauration
Ce qui a dysfonctionné et comment c'a été résolu

Les entreprises qui sautent les tests découvrent les sauvegardes corrompues lors d'incidents réels, ce qui est le moment le plus coûteux pour découvrir quoi que ce soit.

Les sauvegardes de bases de données nécessitent leur propre plan

Les fichiers et les bases de données se sauvegardent différemment. Un répertoire .pgdata copié en cours de transaction est corrompu. Utilisez les outils natifs :

PostgreSQL : pg_basebackup + archivage WAL pour la PITR, pg_dump pour le logique
MySQL : Percona XtraBackup pour le physique à chaud, mysqldump pour le logique
MongoDB : mongodump, jeux de réplicas avec secondaires différés
Microsoft SQL Server : sauvegarde native avec BACKUP DATABASE, log shipping pour la PITR

Pour une base de données PostgreSQL de 500 Go avec un RPO de 5 minutes, des sauvegardes de base nocturnes + archivage WAL continu vers S3 donnent une récupération à un instant précis jusqu'à n'importe quelle seconde des 30 derniers jours. Temps de restauration : récupérer la sauvegarde de base (30 min), rejouer le WAL jusqu'au temps cible (5 à 30 min). Un RTO serré implique un réplica tiède prêt à promouvoir.

Instantanés cohérents avec l'application

Les instantanés du système de fichiers (ZFS, Btrfs, AWS EBS, disques managés Azure, disque persistant GCP) figent un point dans le temps au niveau bloc. Pour les bases de données, combinez avec la mise en quiescence de l'application :

pg_start_backup('label') (PostgreSQL) ou FLUSH TABLES WITH READ LOCK (MySQL)
Prenez l'instantané
pg_stop_backup() ou déverrouillez

L'instantané est cohérent avec l'application — utilisable pour la restauration sans récupération après crash. AWS Backup, Azure Backup et Google Cloud Backup automatisent ce schéma pour les bases de données courantes.

Distribuer des archives de sauvegarde à des tiers

Quand des sauvegardes doivent aller chez des tiers — auditeurs, autorités de contrôle, mandataires successeurs — le transfert lui-même demande des précautions. FTP est archaïque ; les pièces jointes e-mail atteignent des limites de taille ; remettre des clés USB est lent.

Le transfert de fichiers chiffré de bout en bout gère proprement la distribution ponctuelle de sauvegardes. HexaTransfer déplace des fichiers jusqu'à 10 Go avec chiffrement AES-256-GCM côté client et un lien à usage unique. Idéal pour envoyer un instantané de base de données à un commissaire aux comptes sans lui accorder l'accès à vos buckets S3.

La documentation fait partie de la sauvegarde

La meilleure sauvegarde du monde est inutile si la personne qui sait la restaurer est en vacances et que personne d'autre ne sait. Documentez :

Ce qui est sauvegardé et ce qui ne l'est pas (exclusions explicites)
Calendrier et rétention par charge de travail
Gestion des clés et accès
Runbooks de restauration avec commandes étape par étape
Liste de contacts (support fournisseur, astreinte)
Résultats des tests et dates

Imprimez une copie. Conservez une copie dans le coffre physique avec les clés d'urgence. Si votre runbook de sauvegarde ne vit que dans une page Confluence servie par la même infrastructure qui vient de tomber, vous avez un problème. Le papier fonctionne encore quand rien d'autre ne marche.

Définissez le RPO/RTO, implémentez le 3-2-1 avec immuabilité, chiffrez côté client, testez chaque trimestre, documentez obsessionnellement. Le succès des sauvegardes, c'est 10 % de technologie et 90 % de discipline.

Essayez sur hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.