Pourquoi VBR devrait posséder vos copies Sauvegarde

Les organisations utilisant Veeam visent presque toujours à respecter la règle 3-2-1 : trois copies des données, sur deux supports différents, dont une hors site. C’est simple, mais cela existe pour une raison très concrète — reprise après sinistre. Si vous perdez un site, un périphérique de stockage ou un centre de données entier, et qu’il contient votre unique copie de sauvegarde, les conséquences sont graves. La règle 3‑2‑1 est conçue pour éviter cela. 

Une question récurrente qui revient lors de la mise en place de l’architecture de stockage de sauvegarde d’une organisation est : « Est-ce que Veeam Sauvegarde & Replication (VBR) doit créer et gérer toutes les copies de sauvegarde, ou la réplication du stockage doit-elle gérer les copies supplémentaires ? » 

Certains fournisseurs de stockage font la promotion agressive de la réplication comme une « fonctionnalité », en avançant souvent des bénéfices de déport de charge, de simplicité ou de performances. Mais lorsqu’on examine le fonctionnement réel de Veeam — et ce dont les administrateurs ont besoin lors des restaurations, des audits et des scénarios de PRA — la réponse devient évidente : un 3‑2‑1 piloté par Veeam est plus simple, plus flexible, plus résilient et évite un risque d’architecture à long terme. 

Pourquoi le 3‑2‑1 existe et pourquoi VBR doit le gérer  

L’objectif du 3‑2‑1 est d’empêcher qu’une seule défaillance n’élimine toutes les copies de sauvegarde. Incendies, inondations, tremblements de terre, ouragans, pannes matérielles, défauts logiciels et coupures réseau peuvent tous mettre hors service un site principal. Pour éviter cela, les copies de sauvegarde doivent être séparées et elles doivent être immuables. 

Lorsque VBR gère toutes les copies, il conserve une visibilité complète sur les chaînes de sauvegarde, les politiques de rétention, les fenêtres d’immuabilité et les points de restauration. Les administrateurs travaillent depuis une console unique, ce qui permet des tests reprise après sinistre prévisibles, des audits simples et une visibilité claire sur les opérations de sauvegarde. 

Lorsque la réplication du stockage crée des copies supplémentaires hors du contrôle de VBR, VBR ne peut ni suivre ni valider ces copies. Les administrateurs doivent consulter plusieurs interfaces pour comprendre l’ensemble du paysage de sauvegarde, ce qui introduit une complexité permanente. 

Réplication du stockage vs. tâches de copie VBR 

Les fournisseurs de stockage présentent souvent la réplication comme un moyen de réduire la charge ou de simplifier les opérations. En pratique, la réplication déplace la responsabilité hors de VBR (le système qui comprend les chaînes de sauvegarde, la logique de rétention, les fenêtres d’immuabilité et les workflows de restauration) pour la confier à des plateformes de stockage qui n’ont pas été conçues pour gérer des copies de sauvegarde. 

Ce déplacement introduit des compromis majeurs. Dès que vous commencez à utiliser une réplication basée sur le stockage, vous perdez en flexibilité, vous ajoutez de la complexité et vous dépensez plus d’argent que nécessaire. 

Perte de visibilité et de contrôle VBR 

Lorsque la réplication du stockage crée des copies supplémentaires, VBR n’en a aucune connaissance. Même si le système de stockage peut afficher ces copies, VBR ne peut pas valider leur intégrité, suivre leur rétention, imposer l’immuabilité ni les utiliser directement pour les opérations de restauration. Les administrateurs doivent consulter plusieurs interfaces pour comprendre l’ensemble du paysage de sauvegarde, ce qui complique reprise après sinistre, les audits, la supervision et le dépannage. 

Angles morts opérationnels 

Si la réplication démarre, s’arrête ou échoue, VBR ne reçoit aucune indication. Les administrateurs ne peuvent pas déterminer facilement si les copies hors site sont à jour, si les politiques de rétention sont appliquées ou si l’immuabilité est intacte. 

Un point de défaillance unique 

La réplication place souvent les deux copies sur la même plateforme de stockage. Cela contredit l’intention du 3‑2‑1. Une seule panne matérielle, un problème de micrologiciel, un événement de rançongiciel ou une catastrophe physique peut compromettre toutes les copies. 

Flexibilité réduite et coûts plus élevés 

Veeam permet à chaque copie de sauvegarde d’avoir sa propre durée de rétention, sa fenêtre d’immuabilité et sa stratégie de tiering. La réplication ne le permet pas. La réplication exige que la copie 1 et la copie 2 soient identiques, ce qui limite la capacité à satisfaire les exigences réglementaires, à optimiser les coûts de stockage ou à ajuster les politiques à mesure que les besoins métier évoluent. Lorsque les exigences changent, les organisations se retrouvent souvent face à une réarchitecture coûteuse ou à la nécessité d’acheter beaucoup plus de stockage. 

Voici une comparaison : 

Capacité	Tâches de copie VBR	Réplication du stockage
Rétention indépendante	Oui	Non
Fenêtres d’immuabilité indépendantes	Oui	Non
Flexibilité du tiering	Oui	Non
Possibilité de mixer les fournisseurs	Oui	Non
Capacité à s’adapter à de nouvelles exigences réglementaires	Oui	Limité/coûteux

Cette flexibilité est nécessaire pour s’adapter à des exigences métier et réglementaires qui évoluent fréquemment. Avec la réplication, s’adapter à de nouvelles exigences de rétention ou d’immuabilité impose souvent de réarchitecturer l’environnement ou d’acheter beaucoup plus de stockage.  

Surcoût opérationnel accru 

Répartir la logique de sauvegarde entre VBR et les systèmes de stockage aboutit à plusieurs consoles, systèmes d’alerte, mécanismes de rétention, modèles d’immuabilité et modes de défaillance. Cela ne réduit pas la charge ; cela augmente le surcoût opérationnel. Les chaînes Sauvegarde deviennent opaques, les workflows de restauration se fragmentent et reprise après sinistre devient moins prévisible. La formation et la gestion continue deviennent également plus exigeantes. 

Pourquoi S3 ne s’aligne pas avec les modèles de réplication 

Le versioning S3 combiné à Object Lock ne s’aligne pas avec la réplication au niveau stockage. La plupart des plateformes de stockage sur site ne peuvent pas répliquer des buckets S3 avec Object Lock activé. En conséquence, les fournisseurs s’appuient souvent sur des mécanismes d’immuabilité propriétaires qui manquent de vérifiabilité. C’est pourquoi Object First utilise S3 pour garantir l’Immuabilité absolue et pourquoi les tâches de copie VBR constituent le mécanisme approprié pour gérer plusieurs copies de sauvegarde. 

Pourquoi les fournisseurs promeuvent la réplication 

La réplication est fréquemment mise en avant parce qu’elle augmente les ventes de stockage. Vendre deux systèmes de stockage au lieu d’un est financièrement avantageux pour les fournisseurs. La réplication encourage aussi l’enfermement dans un écosystème, puisque les deux copies doivent résider sur la même plateforme. Certains fournisseurs ont initialement développé la réplication pour des produits de sauvegarde moins capables et l’appliquent désormais largement, même lorsqu’elle ne s’aligne pas avec les bonnes pratiques Veeam. 

Ces motivations profitent au fournisseur, pas au client. 

Recommandations pour concevoir des architectures de sauvegarde 

La bonne pratique Veeam est simple : respecter le 3‑2‑1, rendre chaque copie immuable et laisser VBR gérer toutes les copies. Une stratégie multi-copies robuste doit privilégier la simplicité, la flexibilité et l’adaptabilité à long terme. Les fenêtres de rétention doivent être faciles à ajuster, les choix de stockage doivent rester ouverts et les politiques doivent évoluer au rythme des exigences métier. 

Une restauration prévisible — que ce soit lors de restaurations de routine, d’audits, d’incidents cyber ou d’un reprise après sinistre complet — dépend du fait que VBR dispose d’une visibilité totale sur chaque copie de sauvegarde. Lorsque VBR gère toutes les copies, les workflows de restauration restent cohérents et fiables. 

La réplication du stockage peut sembler pratique, mais elle introduit une complexité opérationnelle, réduit la visibilité de Veeam, limite la flexibilité, augmente les coûts et crée un risque d’architecture à long terme. Évitez l’enfermement fournisseur, évitez la complexité inutile et évitez toute conception dans laquelle VBR ne peut pas voir ou gérer toutes les copies de sauvegarde. 

Pour une restauration prévisible et résiliente, la création des copies de sauvegarde doit rester dans VBR.