Backup externalisé : une copie hors site, mais pas encore une sauvegarde invulnérable
Un backup externalisé consiste à conserver une copie des données de l’entreprise dans un environnement distant, distinct des serveurs de production et des locaux. Cette séparation protège les fichiers, les applications et les machines virtuelles lorsqu’un incident touche le site principal : ransomware, panne matérielle, incendie, dégât des eaux, suppression accidentelle ou vol. Une copie envoyée dans le cloud ne suffit toutefois pas toujours. Elle doit être isolée, protégée et surtout restaurable.
Le backup externalisé protège une copie, pas seulement un espace de stockage
Également appelé sauvegarde externalisée, sauvegarde hors site ou télésauvegarde, le backup externalisé transfère les données vers une cible distante : cloud, datacenter, stockage objet S3, second site de l’entreprise ou architecture distribuée. L’objectif n’est pas de remplacer la sauvegarde locale, mais d’éviter qu’un même incident détruise à la fois la production et ses copies.
Une sauvegarde locale sur un NAS ou un serveur interne reste utile pour récupérer rapidement un fichier ou une machine. En revanche, elle partage souvent le même bâtiment, la même alimentation électrique et parfois le même réseau que les systèmes protégés. Si un incendie, un dégât des eaux ou un chiffrement malveillant se propage, cette proximité devient un point de faiblesse. La copie hors site ajoute une séparation géographique qui réduit ce risque.
Les trois méthodes de sauvegarde à combiner intelligemment
La sauvegarde complète copie l’ensemble des données sélectionnées. Elle simplifie la restauration, mais demande davantage de capacité et de temps. La sauvegarde incrémentielle n’enregistre que les changements depuis la dernière sauvegarde, ce qui réduit la fenêtre de sauvegarde. La sauvegarde différentielle conserve les changements depuis la dernière copie complète. En pratique, une stratégie associe souvent une base complète périodique et des incrémentielles fréquentes, puis externalise ces jeux de sauvegarde selon une politique de rétention définie.
Pourquoi une copie hors site doit être isolée du ransomware
L’erreur la plus fréquente consiste à considérer qu’une sauvegarde accessible en permanence depuis le réseau interne est automatiquement protégée. Un ransomware peut compromettre les identifiants d’administration, atteindre les partages connectés ou supprimer les points de restauration avant de chiffrer la production. Une copie distante reste donc vulnérable si elle est modifiable avec les mêmes comptes, depuis les mêmes accès et sans barrière supplémentaire.
Immuabilité, versioning et air gap : trois protections différentes
L’immuabilité bloque la modification ou la suppression d’une sauvegarde pendant une durée fixée. Le versioning conserve plusieurs états d’un même fichier ou jeu de données afin de revenir avant une corruption ou une suppression. L’air gap ajoute une séparation : la copie n’est pas directement accessible en continu depuis l’environnement de production. Ces mécanismes ne se remplacent pas. Ils se complètent pour limiter les effets d’une attaque ou d’une erreur humaine.
Il est utile de penser la protection comme une matrice à deux axes : d’un côté, la distance entre la production et la copie ; de l’autre, le niveau de contrôle permettant de modifier cette copie. Une sauvegarde très éloignée mais administrable avec un compte compromis reste exposée. À l’inverse, une copie immuable mais hébergée dans le même local ne résistera pas forcément à un sinistre physique. Cette approche oblige à vérifier séparément la géographie, les accès, les identités, les clés de chiffrement et les délais de récupération.
Chiffrement et intégrité ne répondent pas au même besoin
Le chiffrement protège la confidentialité des données pendant leur transfert et leur stockage. Le chiffrement AES-256 est couramment employé dans ce cadre. La gestion des clés mérite une attention particulière : il faut savoir qui les détient, comment elles sont protégées, renouvelées et récupérées en cas d’urgence. Le hachage sert, quant à lui, à détecter une altération et à contrôler l’intégrité des sauvegardes. Une donnée chiffrée n’est pas nécessairement intacte, et une donnée intègre n’est pas nécessairement inaccessible à un tiers. Les deux contrôles répondent donc à des besoins différents.
Appliquer la règle 3-2-1-1-0 sans compliquer l’exploitation
La règle 3-2-1 repose sur 3 copies des données, sur 2 supports différents, dont 1 copie hors site. Elle réduit la dépendance à un équipement unique et prépare l’entreprise à la perte d’un site. La version renforcée, 3-2-1-1-0, ajoute 1 copie immuable ou isolée et 0 erreur de récupération. Cette dernière exigence implique des vérifications et des tests réguliers.
| Élément | Objectif opérationnel | Exemple de contrôle |
|---|---|---|
| 3 copies | Éviter le point de défaillance unique | Production, copie locale, copie externalisée |
| 2 supports | Réduire le risque matériel commun | Disque local et stockage objet |
| 1 copie hors site | Résister à la perte des locaux | Datacenter distant ou cloud |
| 1 copie immuable ou isolée | Limiter la destruction par ransomware | Verrouillage de rétention ou air gap |
| 0 erreur de récupération | Valider la restaurabilité | Test documenté de restauration |
Cette méthode doit être adaptée aux priorités métier. Le RPO, ou objectif de point de reprise, indique la quantité maximale de données que l’entreprise accepte de perdre. Il détermine la fréquence des sauvegardes. Le RTO, ou objectif de temps de reprise, fixe la durée acceptable d’interruption. Il influence l’architecture, le débit disponible et le type de restauration attendu.
Choisir l’architecture adaptée au volume, à la souveraineté et au délai de reprise
Il n’existe pas de cible universelle. Le choix dépend des données à protéger, de leur sensibilité, du volume, des exigences réglementaires, du débit réseau et du temps nécessaire pour remettre l’activité en route. Le stockage objet via le protocole S3 est apprécié pour son élasticité et sa capacité à absorber des volumes croissants. Un datacenter distant peut répondre à des besoins de localisation, de supervision et de contractualisation plus précis. Une architecture distribuée peut réduire la dépendance à un site unique, à condition de maîtriser sa gouvernance.
| Option | Atout principal | Point de vigilance |
|---|---|---|
| Sauvegarde locale | Restauration rapide | Exposition au sinistre et au réseau local |
| Support physique hors site | Isolement fort | Manipulation, rotation et délais logistiques |
| Cloud ou stockage S3 | Capacité évolutive | Débit, coûts de sortie et paramétrage des accès |
| Datacenter distant | Hébergement structuré et géographique | Localisation, réversibilité et conditions de restauration |
| Architecture distribuée | Résilience multi-site | Complexité de pilotage et responsabilités |
Compatibilité et restauration : les critères qui départagent les offres
Une solution de backup externalisé doit s’intégrer au logiciel déjà utilisé ou au mode d’accès souhaité. Veeam Cloud Connect, Acronis, Atempo, Rubrik, Commvault, Nakivo et NetBackup sont des outils ou environnements que les prestataires peuvent prendre en charge selon leur offre. Les protocoles SMB et NFS répondent à certains usages de fichiers, tandis que S3 vise le stockage objet. La compatibilité annoncée ne dispense pas d’un test sur les charges réelles. Les machines virtuelles, les bases de données, les postes de travail et les données SaaS n’ont pas les mêmes contraintes.
Mettre en place une sauvegarde réellement récupérable
Le projet commence par un inventaire des données critiques, des applications, des dépendances, des volumes, des propriétaires métiers et des obligations de conservation. Il faut ensuite fixer la fréquence, la durée de rétention, le RPO et le RTO, puis configurer le chiffrement, les droits d’accès, l’immuabilité et les alertes d’échec. La première synchronisation peut être longue. La bande passante et la fenêtre de sauvegarde doivent donc être évaluées avant le déploiement.
- Classer les données selon leur criticité et leur délai de reprise.
- Conserver une copie locale pour les restaurations courantes et une copie réellement hors site.
- Séparer les comptes d’administration de sauvegarde des comptes de production.
- Définir des rétentions cohérentes avec les besoins métier et réglementaires.
- Tester une restauration granulaire, une restauration complète et, si nécessaire, une restauration bare metal.
- Documenter les rôles du client et du prestataire, y compris les clés, la réversibilité et les coûts de sortie.
La sauvegarde devient un véritable levier de résilience lorsqu’elle alimente un plan de reprise d’activité (PRA). Le PRA organise le redémarrage après un incident ; le plan de continuité d’activité (PCA) vise à maintenir les fonctions essentielles pendant la crise. Dans les deux cas, le test est décisif. Une sauvegarde réussie dans un tableau de bord n’a de valeur que si les données restaurées sont exploitables par les équipes métier.