---
title: "Sauvegarde hétérogène : comment protéger les environnements informatiques mixtes sans créer de lacunes en matière de restauration"
published_at: "2026-10-02T14:06:36+00:00"
modified_at: "2026-10-02T14:07:31+00:00"
url: "https://www.baculasystems.com/fr/blog-fr/sauvegarde-heterogene/"
markdown_url: "https://www.baculasystems.com/fr/blog-fr/sauvegarde-heterogene.md"
---

[Bienvenue](https://www.baculasystems.com/fr/)
 > [Blog sur la sauvegarde et la restauration](https://www.baculasystems.com/fr/blog-fr/)
 > Sauvegarde hétérogène : comment protéger les environnements informatiques mixtes sans créer de lacunes en matière de restauration

# Sauvegarde hétérogène : comment protéger les environnements informatiques mixtes sans créer de lacunes en matière de restauration

Mis à jour 2nd octobre 2026, Rob Morrison

## Qu’est-ce que la sauvegarde hétérogène ?

La sauvegarde hétérogène est une stratégie qui protège différents types de charges de travail, notamment les serveurs physiques, les machines virtuelles, les bases de données, Kubernetes, les applications SaaS et les charges de travail dans le cloud, dans le cadre de politiques de restauration communes. Les cibles de restauration communes ne nécessitent pas de méthodes de sauvegarde identiques.

Une sauvegarde réussie ne garantit pas une restauration réussie. La sauvegarde hétérogène protège différents types de charges de travail selon des objectifs de restauration communs. De nombreux environnements informatiques d’entreprise combinent plusieurs systèmes d’exploitation, hyperviseurs, bases de données, services cloud et plateformes héritées. Plus précisément, on peut rencontrer des entreprises qui exploitent leurs opérations sur des serveurs Windows et Linux et qui utilisent des machines virtuelles VMware et Hyper-V. De plus, ces entreprises peuvent utiliser simultanément des clusters Kubernetes, des charges de travail dans le cloud public, des applications SaaS (Software-as-a-Service), des bases de données, des systèmes de stockage en réseau (NAS) et d’anciennes plateformes physiques ou Unix, telles que les mainframes IBM System z (z/OS) et IBM AIX sur Power Systems (ou Oracle Solaris / HP-UX).

Les environnements mixtes peuvent résulter d’acquisitions, de migrations vers le cloud, de la modernisation des applications, du maintien de systèmes hérités et d’achats technologiques décentralisés. Ainsi, le défi en matière de sauvegarde consiste à assurer une restauration fiable sur l’ensemble des systèmes associés à différentes interfaces de programmation d’applications (API), mécanismes de cohérence, identités, métadonnées et modes de défaillance. Une API représente un ensemble de règles permettant à deux composants logiciels de communiquer sur la base d’un ensemble de définitions et de protocoles.

Une stratégie de **sauvegarde hétérogène** utilise une architecture coordonnée de protection des données pour protéger plusieurs systèmes d’exploitation, applications, bases de données, hyperviseurs, plateformes de stockage et environnements cloud.

La stratégie de sauvegarde hétérogène vise à établir des résultats de reprise communs, tels que les [objectifs de point de reprise (RPO)](https://blog.bcm-institute.org/it-disaster-recovery/recovery-time-and-point-objectives)
, les [objectifs de délai de reprise (RTO)](https://docs.oracle.com/en-us/iaas/mysql-database/doc/recovery-time-objective-rto-and-recovery-point-objective-rpo.html)
, la conservation, l’immuabilité, le contrôle d’accès et les tests. Les tests de reprise font partie intégrante de la conception de la sauvegarde.

Le RPO correspond à la perte de données maximale acceptable qu’une organisation peut tolérer avant que son activité ne soit affectée. Le RTO correspond à la durée maximale pendant laquelle une entreprise peut rester hors service avant que la perturbation n’entraîne un impact inacceptable.

Les bases de données, les machines virtuelles et les applications Kubernetes peuvent partager un même RPO tout en utilisant des mécanismes de protection différents. Il est essentiel de normaliser les objectifs de reprise plutôt que d’imposer à chaque charge de travail le même processus de sauvegarde.

Parallèlement, cette stratégie permet de préserver les méthodes spécifiques à chaque charge de travail, telles que celles des bases de données et des machines virtuelles, nécessaires à leur réalisation.

Il est important de noter que le fait que toutes les tâches d’un tableau de bord soient au vert ne signifie pas pour autant qu’une entreprise est en mesure de restaurer ses applications. Une sauvegarde hétérogène efficace normalise les politiques et les preuves, tout en respectant les différences techniques, telles que les sauvegardes de bases de données cohérentes au niveau de l’application avec des journaux de transactions pour une restauration à un instant donné, et les sauvegardes d’images au niveau de l’hyperviseur pour une restauration complète des machines virtuelles.

## Qu’est-ce qui rend un environnement de sauvegarde hétérogène ?

Un environnement de sauvegarde est hétérogène lorsque ses charges de travail nécessitent des méthodes de sauvegarde ou de restauration différentes et sont soumises à des méthodes de restauration différentes. Les environnements informatiques mixtes nécessitent des méthodes de sauvegarde spécifiques à chaque charge de travail.

Un environnement mixte peut inclure :

- macOS, serveurs Unix, Linux, Windows physique
- Machines virtuelles Proxmox, VMware, Nutanix, Hyper-V, machines virtuelles basées sur le noyau
- Volumes persistants, clusters Kubernetes, manifestes, secrets et métadonnées d’applications
- Bases de données (par exemple, Microsoft SQL Server, Oracle, PostgreSQL, MySQL, SAP HANA, MongoDB)
- Par exemple, des appliances NAS et des systèmes de fichiers
- Par exemple, un cloud privé et des charges de travail moins courantes ou techniquement complexes
- Par exemple, Salesforce et Microsoft 365
- Des mainframes, des applications propriétaires ou des systèmes ne prenant pas en charge un agent moderne

L’infrastructure représente une couche. Les exigences en matière de restauration varient. Une base de données transactionnelle peut subir une perte de données. Cependant, une archive peut permettre un [objectif de point de restauration (RPO)](https://csrc.nist.gov/glossary/term/rpo)
 de 24 heures. Le RPO représente le moment précis auquel les données doivent être restaurées après une panne.

Pour les systèmes de [production](https://www.baculasystems.com/fr/cybersecurite-industrielle/)
 qui doivent continuer à fonctionner pendant les pannes de réseau étendu (WAN), une infrastructure de restauration locale peut être nécessaire même lorsque le [réseau étendu (WAN)](https://aws.amazon.com/what-is/wan/)
 n’est pas disponible. Un réseau étendu est la technologie qui relie vos bureaux, vos centres de données, vos applications cloud et votre stockage cloud.

Les durées de conservation dépendent de la juridiction applicable, du type de document, du contrat et du cadre réglementaire. Et seuls quelques points de restauration peuvent être nécessaires pour un environnement de développement de courte durée.

C’est pourquoi « prend en charge de nombreuses plateformes » est une définition incomplète de la sauvegarde hétérogène. Une plateforme peut ingérer des données provenant de nombreuses sources. La restauration cohérente au niveau de l’application n’est pas courante pour toutes les sources. Il en va de même pour la restauration multiplateforme testée, la restauration de configuration ou la restauration granulaire.

## Pourquoi des charges de travail différentes nécessitent-elles des méthodes de sauvegarde différentes ?

Les différentes charges de travail nécessitent des mécanismes de sauvegarde différents, car elles atteignent un état récupérable de différentes manières. Il est utile de standardiser les différentes charges de travail, mais une uniformité littérale comporte des risques cachés. Les classes de charges de travail atteignent un état récupérable de diverses manières.

Un instantané d’hyperviseur peut servir de base à la sauvegarde d’une machine virtuelle lorsque le produit de sauvegarde capture également la configuration et l’état requis de l’application. Une API de sauvegarde native, des journaux de transactions et une coordination de la troncature des journaux peuvent être nécessaires pour une base de données. Une application Kubernetes peut nécessiter des données persistantes et des manifestes, des ressources personnalisées, des secrets et des informations sur les dépendances.

Une plateforme SaaS (Software-as-a-Service) n’expose que les objets et les [interfaces de programmation d’applications (API)](https://www.ibm.com/think/topics/api)
 autorisés par son fournisseur. Une API représente des règles et des protocoles, permettant à différents logiciels de communiquer entre eux. Des fichiers, l’état du système et des données de restauration « bare-metal » peuvent être nécessaires pour un serveur physique.

Les charges de travail disposant d’un instantané quotidien et d’une politique de conservation de 30 jours présentent une configuration cohérente. Cependant, elles ne sont pas nécessairement récupérables. Le système peut poursuivre son fonctionnement sans dépendances externes, telles que les dépendances des applications Kubernetes, la configuration des identités et les clés de chiffrement. Cela concerne également la configuration des identités ou les métadonnées natives du cloud. De plus, le système ne peut pas être restauré dans une autre région, un autre cluster, un autre hyperviseur ou un autre compte.

Les charges de travail appartenant au même niveau métier doivent atteindre le même résultat escompté, même si elles disposent de mécanismes de sauvegarde différents. Par exemple, une politique de niveau 1 pourrait exiger (le niveau 1 est une classification à titre d’illustration, et non une définition universelle du secteur) :

- Perte de données maximale de 15 minutes
- Restauration du service dans un délai de deux heures
- Une copie inaltérable qui ne se trouve pas à l’intérieur du périmètre de sécurité de production
- Des tests de restauration à effectuer chaque trimestre
- Des preuves démontrant que la reprise des dépendances des applications est correctement effectuée. Ces dépendances peuvent inclure les dépendances liées à l’ordre de reprise, ainsi que l’infrastructure en amont et les services de sécurité.

Une base de données Oracle ou une application Kubernetes peut utiliser différents outils ou plug-ins pour se conformer à cette politique. Ces outils ou plug-ins peuvent inclure Oracle Recovery Manager et le plug-in Dell PowerProtect Data Manager. Le contrôle suit un parcours standardisé. La mise en œuvre est optimisée pour la charge de travail.

## Comment les équipes doivent-elles associer les charges de travail à la méthode de protection appropriée ?

Une architecture de sauvegarde hétérogène doit s’appuyer sur un inventaire axé sur la restauration, plutôt que sur une simple liste de périphériques. En règle générale, les inventaires d’infrastructure identifient les hôtes et la capacité de stockage sans mettre en évidence les éléments constitutifs d’un service métier complet.

Commencez par cartographier les applications en fonction de leurs dépendances en matière de calcul, de données, de configuration, d’identité, de réseau, de certificats et de services externes, tels que les passerelles de paiement/API tierces, les bases de données gérées en externe ou les fournisseurs d’identité SaaS.

Ensuite, classez-les en tenant compte de leur impact métier. Enfin, définissez leur objectif de point de reprise (RPO) et leur objectif de délai de reprise (RTO), ainsi que leur durée de conservation.

Par ailleurs, définissez leurs exigences légales, telles que les lois sur la souveraineté et la résidence des données (par exemple, le Règlement général sur la protection des données) et les normes de conservation obligatoires (par exemple, la [loi sur la portabilité et la responsabilité en matière d’assurance maladie](https://www.hhs.gov/hipaa/index.html)
), le lieu de reprise et le responsable.

Le [RGPD](https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/principles-gdpr_en)
 est la loi européenne relative à la confidentialité et à la sécurité des données. La [loi HIPAA](https://www.hhs.gov/hipaa/for-professionals/faq/does-hipaa-require-covered-entities-to-keep-medical-records-for-any-period/index.html)
 fixe des normes strictes pour la gestion, la transmission et le stockage des informations de santé protégées.

Envisagez d’utiliser ce tableau comme point de départ :

| Type de charge de travail | Éléments à protéger | Méthode de cohérence préférée | Vérification de la restauration |
| --- | --- | --- | --- |
| Serveur physique | État du système, fichiers, données de démarrage, données d’application | Intégration de l’agent et des applications | Test de démarrage sur matériel nu ou matériel alternatif |
| Machine virtuelle | Configuration, disques de la machine virtuelle, état des applications | Instantané de l’hyperviseur et mise en veille des applications | Démarrage de la machine virtuelle isolée et test des services |
| Base de données | Journaux, fichiers de données, configuration, clés de chiffrement | API native de la base de données ou plug-in certifié | Restauration, mise à jour et vérification de l’intégrité de la base de données |
| Application Kubernetes | Métadonnées du cluster/de l’application et volumes persistants | Hooks d’application, instantanés de l’interface de stockage des conteneurs (CSI) et découverte compatible avec Kubernetes | Utilisation d’un espace de noms ou d’un cluster vierge pour la restauration et le test des dépendances |
| Stockage en réseau (NAS) ou plateforme de fichiers | Autorisations, partages, listes de contrôle d’accès (ACL) et métadonnées de fichiers | Sauvegarde au niveau des fichiers ou intégration d’instantanés/d’API | Test de restauration des autorisations, des fichiers et des répertoires volumineux |
| Service cloud modernisé | Configuration de la gestion des identités et des accès (IAM), données de service, identités et références, ainsi que contexte de région/compte | API du fournisseur et copie indépendante lorsque cela est pris en charge | Restauration vers un compte ou une région approuvés |
| Application SaaS | Autorisations, objets, pièces jointes et relations exposées par l’API | Connecteur spécifique au SaaS | Restauration granulaire des objets et vérification des relations |

Il est important de noter que toutes les dépendances ne sont pas des objets de sauvegarde. Les éléments suivants, qui font partie du plan de reprise, peuvent nécessiter des procédures distinctes de protection ou de recréation :

- Les entrées du système de noms de domaine (DNS), telles que les enregistrements A ou AAAA et les enregistrements de nom canonique
- Les référentiels « Infrastructure-as-Code », par exemple les référentiels GitLab/GitHub (contenant des scripts Terraform ou Pulumi) et les référentiels de modèles CloudFormation d’Amazon Web Services
- La configuration des fournisseurs d’identité
- Les images de conteneurs
- Les serveurs de licences, tels que FlexNet Publisher (FlexLM) et le serveur Microsoft Key Management Services (KMS)
- Les identifiants d’API tierces, tels que les secrets client OAuth / jetons de rafraîchissement et les clés API de passerelles de paiement

## Un processus étape par étape pour concevoir une sauvegarde hétérogène

### 1. Recenser les charges de travail et attribuer leur propriété

Associez la découverte automatisée à des entretiens avec les responsables des applications, par exemple des analyses de découverte de l’infrastructure (telles que ServiceNow Discovery ou Device42), des questionnaires et des entretiens sur la continuité des activités.

Identifiez les systèmes non gérés, tels que les serveurs « Rogue » ou « Shadow IT » et les machines virtuelles de sandbox ou de préproduction des développeurs, ainsi que les comptes cloud, tels que les comptes d’abonnement AWS ou Azure créés de manière ad hoc et les espaces de travail de projet Google Cloud Platform (GCP).

De plus, identifiez les espaces de noms Kubernetes, tels que les espaces de noms de préproduction et de branches de fonctionnalités (par exemple, staging-checkout, dev-payments), ainsi que les sites distants, tels que les succursales/dépôts régionaux et les sites de fabrication/de calcul en périphérie.

Identifiez également les applications SaaS, telles que les plateformes de collaboration d’entreprise (par exemple, Microsoft 365, Google Workspace) et les plateformes héritées, telles que les mainframes hérités/systèmes AS400 et les environnements informatiques des filiales acquises.

Désignez un responsable technique et un responsable métier pour chaque service protégé.

### 2. Définissez les niveaux de reprise avant de choisir une technologie

Regroupez les services en fonction de leur impact métier. Définissez des exigences mesurables en matière de RPO, de RTO, de durée de conservation, d’emplacement de reprise et de tests, telles que des exécutions automatisées trimestrielles dans un environnement de test de reprise et des simulations semestrielles de basculement complet.

Ne laissez pas le calendrier par défaut d’un outil devenir une exigence métier.

### 3. Identifiez les données et les composants de chaque charge de travail qui doivent être capturés ensemble pour créer un point de reprise exploitable

Déterminez ce que vous devez capturer pour obtenir un point de reprise exploitable. Par exemple, envisagez de capturer les fichiers de données et les journaux d’une base de données.

Envisagez de capturer des machines virtuelles, des bases de données, des files d’attente de messages ou des ressources Kubernetes pour une application à plusieurs niveaux. Enregistrez les hooks d’application, tels que les hooks de gel avant snapshot et de dégel après snapshot, ainsi que les exigences de séquencement, telles que les dépendances de démarrage ordonnées (Infrastructure – Base de données – Application – Front-end).

### 4. Adaptez les méthodes de protection au comportement des charges de travail

Optez pour une protection avec agent, sans agent, basée sur des instantanés, basée sur une API, native à la base de données ou continue. Pour cela, vous devez tenir compte des besoins des charges de travail, tels que l’accès à l’hyperviseur/au système d’exploitation (OS), la surcharge en ressources, le volume de transactions et les taux de changement.

Utilisez les intégrations natives, telles que les API de sauvegarde natives de la base de données, comme Oracle Recovery Manager (RMAN) ou les rédacteurs du service de copie fantôme de volume (VSS) de Microsoft SQL, lorsqu’elles permettent des sauvegardes cohérentes au niveau de l’application, la coordination des journaux de transactions, des sauvegardes incrémentielles efficaces ou une restauration granulaire.

De plus, utilisez les API de snapshots natives des baies de stockage et du cloud, telles que les API de snapshots d’AWS Elastic Block Store (EBS) ou l’intégration NetApp ONTAP, lorsqu’elles améliorent la cohérence, la gestion des journaux, l’efficacité des sauvegardes incrémentielles ou la restauration granulaire.

### 5. Séparer le contrôle des sauvegardes et le stockage de l’environnement de production

Limitez les accès administratifs, exigez une authentification multifactorielle lors des opérations sur les systèmes pris en charge, et isolez les identifiants de sauvegarde, par exemple via des fournisseurs d’identité autonomes dédiés (par exemple, un annuaire local distinct ou un tenant Okta dédié) et des coffres de gestion des accès privilégiés (PAM) avec accès « juste à temps » (par exemple, CyberArk, HashiCorp Vault).

Conservez des copies immuables ou hors ligne, telles que le verrouillage d’objets S3 avec stockage WORM (Write-Once-Read-Many) et des copies de stockage physiques ou isolées par « air gap » (par exemple, bandes hors ligne ou réseaux de stockage isolés).

Une deuxième copie placée sous le contrôle du même système de gestion des identités et des accès compromis n’offre pas de protection indépendante contre la compromission de ce système d’identité.

### 6. Concevoir à la fois des chemins de restauration et de sauvegarde

Déterminez l’emplacement où les charges de travail seront restaurées au cas où la plateforme d’origine ne serait plus disponible. Vérifiez la capacité du réseau, les quotas cloud, les ressources de calcul compatibles, les versions logicielles, les clés et les compétences requises.

Si vous ne pouvez restaurer une sauvegarde que sur la plateforme source défaillante, vous risquez de vous retrouver dans une dépendance circulaire.

### 7. Testez des scénarios de défaillance représentatifs

Testez la perte de machines virtuelles, la perte de clusters, la suppression granulaire, la corruption de bases de données, les ransomwares, la compromission de comptes cloud et les défaillances liées aux sites. Évaluez les RPO et RTO réels. Ne vous contentez pas d’enregistrer la manière dont la tâche a été effectuée.

## Quels sont les problèmes de sauvegarde hétérogènes les plus courants ?

Les défaillances courantes comprennent les charges de travail manquantes, les identifiants périmés, les dépendances d’applications incomplètes, les accès administratifs excessifs et la restauration inter-plateformes non testée.

Les dépendances inter-plateformes peuvent entraîner des défaillances liées à l’identité, à l’authentification, au séquencement et à la compatibilité des API. Ces défaillances peuvent inclure des divergences au niveau de l’identité, des accès et de l’authentification inter-plateformes, ainsi que des incompatibilités de séquencement des microservices et de protocoles API, entre les plateformes prises en charge, et non au sein de celles-ci.

### Comment les nouvelles charges de travail créent-elles des lacunes dans la couverture de sauvegarde ?

Dans les environnements où les changements de provisionnement ou de configuration sont fréquents, la maintenance manuelle des politiques de sauvegarde peut laisser temporairement les nouvelles charges de travail sans protection. Les politiques de sauvegarde gérées manuellement peuvent inclure des politiques d’audit basées sur des feuilles de calcul et des politiques de marquage/étiquetage statiques sans application automatisée.

Les nouvelles machines virtuelles (VM), bases de données, espaces de noms, locataires SaaS ou comptes cloud peuvent ne jamais être répertoriés.  
 Un actif peut rester visible via une console même après l’expiration de ses identifiants ou si sa méthode de protection diffère de celle prévue par la politique.

Par conséquent, vous devez mesurer la couverture en continu. Les actifs de production détectés, tels que les inventaires d’API cloud et les objets de gestion des hyperviseurs et des clusters, doivent être recensés avec les actifs protégés.

Les actifs protégés peuvent inclure les enregistrements actifs du catalogue des tâches de sauvegarde et les manifestes de snapshots terminés. L’achèvement d’une tâche de sauvegarde prouve la capture des données, mais pas la récupérabilité de l’application.

De plus, mettez en évidence les charges de travail inconnues, exclues et non conformes, telles que les bases de données cloud orphelines ou non protégées et les identifiants périmés ou défaillants.

Par ailleurs, utilisez des balises et des étiquettes pour automatiser l’affectation. Les équipes doivent surveiller de près les métadonnées manquantes ou incorrectes, car elles constituent un échec de contrôle.

### Une sauvegarde réussie signifie-t-elle qu’une application est récupérable ?

En règle générale, un logiciel de sauvegarde confirme qu’il a lu et stocké les données. Il ne peut pas prouver automatiquement la disponibilité de toutes les dépendances des applications, telles que les fournisseurs d’Active Directory ou d’identité, les serveurs DNS, les serveurs de gestion des clés (KMS) externes et les coffres-forts de secrets. De plus, il ne peut pas garantir automatiquement que le service restauré fonctionnera.

Pour garantir la restauration, appuyez-vous sur des contrôles automatisés de démarrage ou de montage, testez l’intégrité des bases de données, recherchez les logiciels malveillants, appliquez une validation au niveau des applications et procédez à une validation périodique par le propriétaire.

Les services à fort impact, tels que les systèmes bancaires centraux et de traitement des transactions, ainsi que les plateformes de paiement et d’exécution des commandes en ligne, nécessitent également des tests complets des flux de travail, et pas seulement des tests portant sur l’infrastructure.

### Quels risques de sécurité la gestion centralisée des sauvegardes engendre-t-elle ?

Une plateforme unifiée peut réduire le nombre de consoles, de catalogues et de systèmes de politiques que les administrateurs doivent gérer.

Cependant, elle peut également constituer une cible administrative de grande valeur. Les conséquences d’une compromission peuvent se propager à l’ensemble de l’environnement informatique.

Cela se produit lorsqu’un système de gestion central supprime des politiques, met fin à la validité de copies (telles que des jeux de sauvegardes incrémentielles quotidiennes programmées qui n’ont pas encore été répliquées vers un référentiel hors site ou en isolation physique) et des instantanés de conservation à long terme destinés à l’archivage conforme à la réglementation qui n’ont pas encore atteint leur date d’expiration définie, puis accède à toutes les charges de travail.

Envisagez de séparer les rôles pour réduire ce risque. De plus, appliquez un accès administratif « juste à temps », utilisez des identifiants distincts, mettez en place des verrous de conservation fixes, un transfert d’audit et des hôtes de gestion renforcés

Par ailleurs, utilisez des domaines de sécurité distincts, tels que des comptes Amazon Web Services ou des abonnements Azure totalement isolés, ainsi que des forêts Active Directory sur site isolées ou en « air gap », pour les copies secondaires, comme les compartiments S3 WORM à verrouillage d’objets fixe et les cartouches de bande hors site en « air gap » ou les appliances de stockage isolées.

La visibilité centralisée ne doit pas se traduire par une autorité centralisée sans limites.

### Quel est l’impact de la déduplication sur les coûts de stockage des sauvegardes ?

Les données issues de charges de travail mixtes, telles que des bases de données SQL transactionnelles associées à des partages de fichiers bruts non compressés, ou des images d’infrastructure de postes de travail virtuels associées à du stockage multimédia/vidéo, ne se prêtent pas toutes de la même manière à la déduplication.

Les bases de données chiffrées, les médias compressés, les disques virtuels soumis à de nombreuses modifications et les données cloud chiffrées côté client peuvent générer de faibles taux de réduction.

Bien que la déduplication globale permette d’économiser de la capacité, vous pouvez également vous y fier pour des considérations de performances, de domaine de défaillance ou de résidence des données, telles qu’une infrastructure dédiée/segmentée dont les composants peuvent tomber en panne simultanément, ainsi que les pools de performances et l’isolation géographique et réglementaire de la résidence des données.

Les modèles de capacité doivent tenir compte des taux de modification spécifiques aux charges de travail, de la durée de conservation, du comportement des sauvegardes complètes, des surcoûts fixes, de la réplication, du trafic sortant et de l’espace de transit pour la restauration. La planification de la capacité ne doit pas reposer sur un taux de déduplication unique pour des types de charges de travail très différents.

### Pourquoi faut-il tester la restauration inter-plateformes ?

Les entreprises s’appuient souvent sur des sauvegardes pour faciliter la migration vers le cloud ou la restauration sur un autre hyperviseur. Dans la pratique, la restauration peut être bloquée par des différences liées aux pilotes, aux modes de démarrage, aux formats de disque, aux architectures réseau, à l’identité, aux fonctionnalités des services gérés et aux licences d’application.

Ainsi, la restauration sur une autre plateforme doit être considérée comme un cas d’utilisation distinct nécessitant une prise en charge et des tests documentés. L’exportation de données n’équivaut pas à la reconstruction d’une application opérationnelle.

## Faut-il utiliser une seule plateforme de sauvegarde ou plusieurs outils spécialisés ?

Les deux modèles peuvent fonctionner. Le choix dépend de la prise en charge des charges de travail, des exigences de restauration, des limites de sécurité, des compétences opérationnelles et des exigences réglementaires.

La sauvegarde hétérogène s’accompagne de deux approches courantes. Plus précisément, les entreprises peuvent utiliser une plateforme unifiée pour sécuriser divers types de charges de travail au sein d’un même catalogue et d’un même système de politiques.

Une approche fédérée conserve les produits spécialisés et ajoute des fonctionnalités partagées de surveillance, de gouvernance ou de reporting.

| Facteur décisionnel | Plateforme de sauvegarde unifiée | Outils spécialisés multiples |
| --- | --- | --- |
| Vue opérationnelle | Console, catalogue et rapports communs | Une agrégation ou une corrélation manuelle est nécessaire |
| Profondeur de la charge de travail | Peut varier d’une intégration à l’autre | Peut s’avérer utile pour une capacité native plus poussée |
| Cohérence des politiques | Plus facile à définir et à auditer de manière centralisée | Les organisations doivent harmoniser leurs politiques entre les différents produits |
| Risques de sécurité | Un système de gestion centralisé peut accroître les risques de sécurité | Davantage de systèmes de gestion centralisés et d’identifiants à sécuriser |
| Compétences et assistance | Moins de modèles opérationnels | Davantage de connaissances spécialisées et de coordination avec les fournisseurs |
| Risque de sortie | Dépendance accrue vis-à-vis d’un catalogue ou d’un format de sauvegarde | Complexité d’intégration et d’exploitation plus élevée |
| Solution la mieux adaptée | Environnement informatique largement pris en charge, doté d’opérations centrales solides | Charges de travail présentant des besoins techniques ou réglementaires variés |

Les entreprises peuvent recourir à un modèle de gouvernance commun même lorsque des charges de travail différentes nécessitent des produits de sauvegarde distincts. Le recours à un outil spécialisé pour les bases de données ou les mainframes peut se justifier si une plateforme générale n’assure pas la cohérence et ne répond pas aux exigences de performances ou de restauration, comme c’est le cas pour les clusters Oracle Real Application à haut débit nécessitant une intégration RMAN à un instant donné, ou pour les charges de travail sur mainframe et les systèmes d’exploitation hérités (par exemple, IBM z/OS ou AS/400).

Toutefois, les entreprises doivent identifier les lacunes et les défaillances, telles que les charges de travail spécialisées non enregistrées ou non protégées, les incompatibilités de restauration entre plateformes et les défaillances d’API. Cela concerne également la conformité en matière de conservation des données et les preuves issues des tests de restauration associées à chaque exception relative aux processus opérationnels courants.

Commencez par tester les charges de travail périphériques. Ne vous concentrez pas uniquement sur l’environnement informatique VMware ou Windows traditionnel. Ensuite, regroupez les outils, tels que les agents de sauvegarde ponctuels disparates fonctionnant séparément sur les bases de données Oracle, les clusters Kubernetes et les systèmes Unix hérités, qui nécessitent actuellement des consoles de gestion individuelles et des contrats de licence distincts.

Vérifiez ensuite si la plateforme candidate est capable de restaurer les métadonnées, les autorisations, les journaux et les dépendances des applications.

Vérifiez si la plateforme candidate prend en charge les versions déployées. Vérifiez si la restauration reste possible en cas d’indisponibilité du plan de contrôle SaaS ou du service de licence du fournisseur.

## Comment évaluer l’efficacité d’une sauvegarde hétérogène

Le taux de réussite des tâches de sauvegarde ne suffit pas à lui seul à mesurer la restaurabilité. Vous pouvez évaluer la protection et la restauration à l’aide d’un tableau de bord plus complet :

- **Couverture des actifs :** pourcentage des actifs de production concernés, tels que les infrastructures cloud nouvellement provisionnées, les espaces de noms Kubernetes et les volumes persistants, protégés par une politique approuvée
- **Conformité aux politiques :** pourcentage respectant les exigences en matière de RPO, de conservation, de copies et de contrôles fixes, tels que le verrouillage des objets immuables (WORM) et les copies secondaires géographiquement isolées ou en « air gap »
- **Validité des points de restauration :** pourcentage des points de restauration échantillonnés qui satisfont aux contrôles d’intégrité et de détection des logiciels malveillants
- **Récupérabilité testée :** pourcentage d’applications critiques, telles que les systèmes de planification des ressources d’entreprise (ERP) (par exemple, SAP, Oracle EBS) et les passerelles de paiement et de commerce électronique en contact avec la clientèle, restaurées et validées dans le délai de test requis
- **RPO et RTO observés :** perte de données réelle et temps de récupération écoulé lors de tests ou d’incidents, tels que le delta de restauration ponctuelle de la base de données (RPO observé) et le temps de restauration complète de l’application ainsi que de son démarrage (RTO observé).
- **Durée de dérive de la couverture :** durée pendant laquelle une charge de travail nouvelle ou modifiée reste en dehors d’une politique approuvée
- **Durée des exceptions :** durée pendant laquelle les charges de travail non prises en charge ou faisant l’objet d’une dérogation restent non résolues
- **Capacité à se rétablir dans un environnement isolé après une compromission :** vérification de l’existence des identifiants, réseaux, ressources de calcul, clés et procédures nécessaires pour effectuer la restauration en dehors de l’environnement compromis

La classe de charge de travail et le niveau métier peuvent aider à segmenter les indicateurs, par exemple les charges de travail de niveau 0/critiques pour la mission (par ex. cœur de métier bancaire, IAM/Active Directory) et les charges de travail de niveau 3/non critiques (par ex. environnements internes de développement/test, partages de fichiers d’archivage). Un taux de réussite de 98 % peut masquer des échecs répétés de certains systèmes qui génèrent la majeure partie du risque métier.

## Comment Bacula Enterprise prend en charge les environnements de sauvegarde hétérogènes

[Bacula Enterprise](https://www.baculasystems.com/fr/meilleur-logiciel-de-sauvegarde/)
 est conçu pour protéger les environnements informatiques hétérogènes sans imposer la même méthode de sauvegarde à toutes les charges de travail. Au contraire, les organisations peuvent gérer les charges de travail physiques, virtuelles, conteneurisées, de bases de données, SaaS et cloud via une plateforme commune de sauvegarde et de restauration, tout en utilisant des intégrations spécifiques à chaque charge de travail lorsque cela est nécessaire.

Ceci est important dans les environnements mixtes car, comme évoqué plus haut, une machine virtuelle, une base de données transactionnelle et une application Kubernetes peuvent partager les mêmes objectifs de restauration tout en nécessitant des mécanismes complètement différents pour créer un point de restauration exploitable.

Bacula Enterprise prend en charge ce modèle grâce à une architecture modulaire et à une large gamme de plugins et d’intégrations dédiés. Les environnements pris en charge comprennent VMware, Hyper-V, Proxmox, Nutanix, KVM, Xen/XCP-ng, OpenStack, Libvirt, Azure VM et bien d’autres, ainsi que les systèmes physiques Windows, Linux, macOS et Unix. Bacula fournit également des fonctionnalités dédiées pour Kubernetes, Docker et Red Hat OpenShift.

Pour les charges de travail liées aux applications et aux bases de données, Bacula propose des intégrations avec des technologies telles que Microsoft SQL Server, Oracle, PostgreSQL, MySQL, MariaDB, MongoDB, SAP HANA, IBM DB2 et SAP ASE. Les charges de travail SaaS, telles que Microsoft 365 et Google Workspace, peuvent également être intégrées dans l’environnement de sauvegarde global.

Les organisations peuvent ainsi appliquer des politiques opérationnelles communes sans réduire la sauvegarde hétérogène à une approche du plus petit dénominateur commun. Par exemple, les administrateurs peuvent définir de manière centralisée des plannings, des politiques de conservation et de sauvegarde, tout en utilisant une protection adaptée aux hyperviseurs pour les machines virtuelles, des méthodes spécifiques aux bases de données pour les systèmes transactionnels et des mécanismes adaptés à Kubernetes pour les applications conteneurisées.

Bacula Enterprise peut également associer ces charges de travail à différentes cibles de stockage de sauvegarde. Ses intégrations incluent le stockage sur disque, sur bande et dans le cloud, ainsi que des interfaces compatibles S3, Microsoft Azure, Google Cloud, Oracle Cloud et Amazon Glacier. Cela permet aux organisations de concevoir le stockage et la conservation en fonction du niveau de charge de travail, des exigences de restauration et des contraintes d’infrastructure, plutôt qu’en fonction de la seule plateforme source.

La gestion centralisée est assurée par la [BWeb Management Suite](https://www.baculasystems.com/fr/interface-de-gestion-de-sauvegarde-bweb-management-suite/)
, qui permet de configurer, de surveiller et d’analyser l’environnement de sauvegarde. Les administrateurs bénéficient ainsi d’une vue opérationnelle commune sur différentes technologies, tout en conservant les méthodes de sauvegarde et de restauration spécialisées requises par chaque charge de travail.

Pour les entreprises envisageant de regrouper plusieurs produits de sauvegarde, cette large prise en charge peut réduire le nombre de systèmes de sauvegarde distincts à gérer. Toutefois, la couverture des charges de travail doit tout de même être évaluée au regard des technologies et versions réellement utilisées. L’objectif n’est pas simplement de regrouper toutes les charges de travail sous une seule console, mais de vérifier que chaque système critique dispose d’une méthode de sauvegarde appropriée et d’un chemin de restauration testé.

## Foire aux questions

### Comment intégrer les systèmes hérités non pris en charge dans une stratégie de sauvegarde hétérogène ?

Inscrivez-les dans un registre officiel des exceptions précisant le responsable, l’impact métier, la méthode de restauration actuelle, les contrôles compensatoires, ainsi que la date de mise hors service ou de correction. Une seule stratégie de restauration peut régir plusieurs technologies de sauvegarde.

Vous pouvez recourir à diverses mesures, telles que les instantanés au niveau du stockage, les sauvegardes de bases de données, les exportations de fichiers, la réplication ou l’isolation. De plus, testez toutes les solutions de contournement. N’oubliez pas que même si vous copiez des données propriétaires inaccessibles, vous ne disposerez pas d’une sauvegarde exploitable.

Une stratégie de sauvegarde n’est pas complète tant que la restauration n’a pas été testée.

### Un référentiel immuable peut-il stocker en toute sécurité les sauvegardes de tous les environnements ?

Un référentiel immuable peut simplifier la gestion de la conservation et de la capacité. Cela s’applique lorsque le référentiel prend en charge l’immuabilité, le débit, l’isolation et les contrôles réglementaires requis.

Cependant, cela peut concentrer les risques opérationnels et de sécurité. Évaluez la séparation des locataires, les clés de chiffrement, les domaines administratifs, la résidence des données, les domaines de défaillance, le débit de restauration et l’impact d’une panne du référentiel.

Même lorsque les organisations mettent en œuvre une gestion unifiée, les services critiques, tels que les services d’identité et d’annuaire (par exemple, Active Directory/Entra ID, infrastructure à clé publique) et les systèmes financiers et de traitement des transactions essentiels (par exemple, SAP, système bancaire central sur mainframe), peuvent justifier des copies de sauvegarde ou des niveaux de stockage distincts, sur la base d’une évaluation des risques.

### À quelle fréquence faut-il tester la reprise hétérogène ?

Utilisez le niveau d’activité et le taux de changement pour déterminer la fréquence. Appliquez une validation automatisée pour les services critiques associés à chaque sauvegarde. N’oubliez pas les exercices de reprise d’application planifiés, tels que la simulation de basculement de reprise après sinistre (DR) sur l’ensemble de la pile et la reprise isolée en « salle blanche » après une attaque par ransomware.

Vous pouvez tester moins souvent les charges de travail des niveaux inférieurs. La fréquence des tests doit dépendre de l’impact sur l’activité, des exigences réglementaires, de la fréquence des changements et des objectifs de reprise.

Cependant, vous devez prélever des échantillons de tous les types de plateformes, processus et destinations importants utilisés pour restaurer une charge de travail. Effectuez de nouveaux tests après des mises à niveau majeures, des migrations de données, des changements d’identité ou des modifications d’architecture. Mesurez la réussite de la restauration, et pas seulement celle de la sauvegarde.

À propos de l’auteur

[https://www.linkedin.com/in/rob-morrison-3aa443/](https://www.linkedin.com/in/rob-morrison-3aa443/)

Rob Morrison est le directeur marketing de Bacula Systems. Il a commencé sa carrière dans le marketing informatique chez Silicon Graphics en Suisse, où il a obtenu de bons résultats dans divers rôles de gestion du marketing pendant près de 10 ans. Au cours des 10 années suivantes, Rob a également occupé divers postes de gestion du marketing chez JBoss, Red Hat et Pentaho, assurant la croissance des parts de marché de ces sociétés bien connues. Il est diplômé de l'université de Plymouth, titulaire d'un diplôme spécialisé en médias et communications numériques, et a suivi un programme d'études à l'étranger.

*Postes connexes*

[https://www.baculasystems.com/fr/blog-fr/sauvegarde-nutanix/](https://www.baculasystems.com/fr/blog-fr/sauvegarde-nutanix/)
[Qu'est-ce que la sauvegarde Nutanix et comment peut-elle vous aider à protéger vos données ?](https://www.baculasystems.com/fr/blog-fr/sauvegarde-nutanix/)

12 février 2024

[https://www.baculasystems.com/fr/blog-fr/souverainete-numerique-de-lue/](https://www.baculasystems.com/fr/blog-fr/souverainete-numerique-de-lue/)
[Souveraineté numérique de l'UE et contrôle des données : ce que les entreprises doivent savoir](https://www.baculasystems.com/fr/blog-fr/souverainete-numerique-de-lue/)

9 juin 2026

[https://www.baculasystems.com/fr/blog-fr/cybersecurite-dans-le-secteur-de-la-sante-risques-lies-a-la-cybersecurite-confidentialite-des-donnees-des-patients/](https://www.baculasystems.com/fr/blog-fr/cybersecurite-dans-le-secteur-de-la-sante-risques-lies-a-la-cybersecurite-confidentialite-des-donnees-des-patients/)
[La sécurité du Big Data dans les établissements de santé : risques liés à la cybersécurité, protection des données et confidentialité des données des patients](https://www.baculasystems.com/fr/blog-fr/cybersecurite-dans-le-secteur-de-la-sante-risques-lies-a-la-cybersecurite-confidentialite-des-donnees-des-patients/)

17 juillet 2026

[https://www.baculasystems.com/fr/blog-fr/meilleures-pratiques-en-matiere-de-sauvegarde-et-de-restauration-openstack/](https://www.baculasystems.com/fr/blog-fr/meilleures-pratiques-en-matiere-de-sauvegarde-et-de-restauration-openstack/)
[Sauvegarde et récupération OpenStack : Meilleures pratiques, méthodes et solutions intégrées](https://www.baculasystems.com/fr/blog-fr/meilleures-pratiques-en-matiere-de-sauvegarde-et-de-restauration-openstack/)

14 novembre 2023

[https://www.baculasystems.com/fr/blog-fr/sauvegarde-ransomware-proteger-ransomware/](https://www.baculasystems.com/fr/blog-fr/sauvegarde-ransomware-proteger-ransomware/)
[Stratégies et bonnes pratiques de sauvegarde contre les ransomwares. Comment protéger les sauvegardes contre les ransomwares ?](https://www.baculasystems.com/fr/blog-fr/sauvegarde-ransomware-proteger-ransomware/)

13 octobre 2025

[https://www.baculasystems.com/fr/blog-fr/securite-des-dossiers-medicaux-electroniques/](https://www.baculasystems.com/fr/blog-fr/securite-des-dossiers-medicaux-electroniques/)
[Sécurité des dossiers médicaux électroniques : données des patients, loi HIPAA et menaces que le secteur de la santé ne peut se permettre d'ignorer](https://www.baculasystems.com/fr/blog-fr/securite-des-dossiers-medicaux-electroniques/)

17 juin 2026