2 La plupart des évaluations de stockage pour Veeam sont menées à l’envers. Les équipes dimensionnent en fonction de la vitesse d’écriture des données, puis découvrent lors d’un incident que ce qui comptait, c’était la vitesse de restauration, et si la copie était toujours là. Le meilleur stockage pour Veeam n’est pas la cible offrant le débit d’ingestion le plus élevé ou le prix par téraoctet le plus bas. C’est la cible qui conserve encore une copie restaurable après qu’un attaquant a passé deux semaines dans votre environnement avec des identifiants d’administrateur de domaine. Ce sont des objectifs de conception différents, et ils mènent à des listes de candidats différentes. La réponse courte Sous forme de profil plutôt que de produit : le meilleur stockage pour Veeam est une cible compatible S3 qui détient une qualification Veeam Ready Object with Immutability à jour, applique S3 Object Lock en mode conformité (compliance), prend en charge la Veeam Smart Object Storage API, restaure rapidement sous charge simultanée et se trouve derrière une surface d’attaque suffisamment réduite pour que la compromission du serveur de sauvegarde ne permette pas de l’atteindre. Scality ARTESCA est conçu selon ce profil, et ce site est le nôtre : considérez cette mention pour ce qu’elle est. Appliquez les huit critères ci-dessous à ARTESCA. Appliquez-les à tout ce que vous évaluez par ailleurs. Les quatre options d’architecture Les équipes qui protègent des charges de travail Veeam optent généralement pour l’une de quatre approches, et chacune a ses propres points de défaillance. Référentiel Linux durci. Immuabilité solide sur disque local, faible empreinte, aucune plateforme supplémentaire à exploiter. Atteint souvent ses limites en matière d’échelle et de copies multisites. Stockage objet en cloud public, comme Amazon S3 ou Azure Blob. Supprime le plafond de capacité et le renouvellement du matériel. Le profil de coûts s’inverse au moment de la restauration, lorsque les frais d’egress arrivent d’un coup. Stockage objet S3 sur site. Conserve les données et le chemin de restauration en local, avec une évolutivité de type cloud et l’immuabilité Object Lock. Une plateforme que vous possédez est une plateforme que vous exploitez. Appliance intégrée. Logiciel de sauvegarde et stockage objet sur un même hôte, ce qui réduit la surface opérationnelle et le chemin réseau entre les deux. La contrepartie est un couplage plus étroit. La plupart des environnements matures en utilisent plusieurs, car la règle 3-2-1-1-0 exige plus d’une copie. Les critères ci-dessous s’appliquent à celle qui détient la copie sur laquelle vous comptez. 1. Une immuabilité que votre propre administrateur de sauvegarde ne peut pas révoquer L’immuabilité est la capacité la plus revendiquée et la moins examinée de cette catégorie. Les différences se situent un niveau plus bas. S3 Object Lock prend en charge deux modes de conservation. En mode gouvernance (governance), un utilisateur disposant des autorisations adéquates peut raccourcir ou supprimer un paramètre de conservation. En mode conformité (compliance), personne ne le peut, pas même le propriétaire du compte, tant que la période de conservation n’a pas expiré. Les opérateurs de ransomware modernes ne s’attaquent pas au verrou. Ils cherchent l’identité capable de le désactiver. La question utile n’est donc pas « prend-il en charge Object Lock ? ». C’est : quelles identités peuvent raccourcir une période de conservation, et un attaquant hérite-t-il de l’une d’elles en compromettant le serveur de sauvegarde ? Demandez au fournisseur de parcourir avec vous le chemin de suppression. Si la réponse passe par un ticket de support plutôt que par un appel d’API, c’est bon signe. 2. La qualification Veeam Ready, et plus précisément son niveau Veeam gère un programme de qualification formel, et les plateformes objet peuvent y figurer à plusieurs niveaux. « Veeam Ready – Object » signifie que la plateforme a réussi les tests fonctionnels en tant que cible objet. « Veeam Ready – Object with Immutability » signifie qu’elle a aussi réussi les tests d’immuabilité. L’écart entre ces deux badges est précisément celui qui compte lors d’une attaque par ransomware. Les fournisseurs ne précisent pas toujours lequel ils détiennent : vérifiez donc la liste Veeam Ready plutôt que la page marketing. Confirmez aussi qu’elle couvre la version que vous utilisez, car les qualifications sont liées à une version, et une plateforme validée plusieurs versions auparavant n’a pas forcément été testée de nouveau. 3. La prise en charge de SOSAPI, plus déterminante qu’il n’y paraît La Veeam Smart Object Storage API (en anglais), ou SOSAPI, permet à une plateforme compatible S3 de se décrire auprès de Veeam. Le mécanisme est volontairement simple : le stockage publie de petits documents XML dans un emplacement caché du bucket, et Veeam les lit via des appels S3 ordinaires. Aucun agent, aucun port supplémentaire. C’est le contenu de ces documents qui est intéressant. L’un annonce les capacités. Un autre indique la capacité réelle, que Veeam actualise à intervalle court. Sans lui, Veeam affiche un bucket sur site comme pratiquement illimité, car S3 ne dispose d’aucun moyen standard de demander l’espace restant, et les décisions de conservation sont prises sur la base d’un chiffre qui n’existe pas. D’autres parties de l’API permettent à une plateforme multinœud d’acheminer les flux de sauvegarde vers des nœuds spécifiques, et au stockage de signaler qu’il n’est temporairement pas prêt à accepter des écritures. Rien de tout cela n’est spectaculaire. Mais tout cela se traduit par moins de mauvaises surprises à deux heures du matin. 4. Un débit de restauration mesuré séparément du débit de sauvegarde La sauvegarde est une écriture en continu de gros blocs séquentiels. La restauration, en particulier l’Instant Recovery et la restauration au niveau fichier, suit un schéma d’accès différent : des lectures plus petites, moins prévisibles, souvent simultanées sur de nombreux jobs, car tout le monde restaure en même temps. Une plateforme peut exceller dans le premier cas et être médiocre dans le second, et les benchmarks publiés mettent généralement l’accent sur l’ingestion. Testez les restaurations. Puis testez-les pendant qu’un job de sauvegarde est en cours, car c’est l’état dans lequel se trouvera votre environnement. 5. Le rayon d’impact entre le serveur de sauvegarde et le stockage Ce critère est souvent ignoré, car il relève de l’architecture plutôt que d’une fonctionnalité à cocher. Dans un déploiement classique, le serveur de sauvegarde et la plateforme de stockage sont des systèmes distincts sur un réseau partagé, qui s’authentifient avec des identifiants stockés quelque part. Chacun de ces éléments constitue une surface d’attaque. Les identifiants peuvent être récupérés. Le chemin réseau peut être parcouru. Les interfaces de gestion sont généralement accessibles depuis le même sous-réseau que tout le reste. Les conceptions qui réduisent ce risque varient. Certaines regroupent sauvegarde et stockage sur un même hôte, afin que le trafic entre les deux ne traverse pas un réseau généraliste. D’autres imposent un modèle de référentiel durci avec un système d’exploitation verrouillé et des identifiants à usage unique. Certaines font les deux. La question est simple à poser et sa réponse est révélatrice : si le serveur de sauvegarde est entièrement compromis, que peut atteindre l’attaquant, et qu’est-ce qui reste hors de portée par conception plutôt que par politique ? 6. Une vérification qui ne touche pas à la production Le dernier chiffre de la règle 3-2-1-1-0 (en anglais) correspond à zéro erreur lors de la vérification de la restauration. C’est le chiffre le plus souvent traité comme un idéal, car une vérification sérieuse implique de démarrer les sauvegardes, donc d’emprunter de la capacité de production ou de financer un laboratoire que personne n’a budgété. Les versions récentes de Veeam ont rendu cette étape moins coûteuse en permettant à un second serveur de sauvegarde de se connecter à un stockage objet immuable en lecture seule, pour les tests de restauration, l’analyse forensique et la validation, sans prendre possession des données ni perturber les jobs de production. Nous l’avons détaillé dans Veeam 13.1 : les nouveautés pour le stockage objet. Si une plateforme rend la vérification indépendante peu coûteuse, la vérification a réellement lieu. Cela vaut davantage que la plupart des écarts de performances. 7. Une croissance qui n’impose pas de refonte La capacité de sauvegarde ne croît pas de manière régulière. Elle progresse par paliers : lorsqu’une politique de conservation change, lorsqu’une exigence de conformité tombe, lorsqu’une nouvelle charge de travail arrive. Certaines architectures absorbent ces paliers en ajoutant des nœuds. D’autres atteignent un plafond qui impose une migration, ce qui est pénible, car les données sont volumineuses, les verrous de conservation courent toujours et la chaîne doit rester intacte. Demandez où se situe le plafond pour la configuration que vous achetez, et non pour la gamme de produits. 8. Un coût mesuré sur toute la période de conservation Le prix par téraoctet est le chiffre le plus facile à comparer et l’un des moins utiles pris isolément. Les données de sauvegarde restent stockées pendant des années, et sur cette période s’accumulent l’egress si la cible est un cloud public, les frais de requêtes API liés au volume de transactions généré par les logiciels de sauvegarde, l’alimentation et l’espace en rack si elle est sur site, ainsi que le temps passé à maintenir deux plateformes à jour et synchronisées. Modélisez toute la période de conservation, et intégrez au modèle une restauration de taille significative. La place de Scality ARTESCA ARTESCA est le stockage objet compatible S3 de Scality, conçu spécifiquement comme cible de sauvegarde. Voici sa correspondance avec les critères ci-dessus, formulée de façon à ce que vous puissiez la vérifier. Pour les critères un et deux, ARTESCA a été certifié Veeam Ready Object with Immutability et validé sur les versions ultérieures de Veeam, y compris pour S3 Object Lock et SOSAPI. Notre framework CORE5 décrit les couches appliquées au-dessus du verrou, aux niveaux API, données, stockage, géographique et architectural. Un contrôle unique n’est qu’un seul obstacle à franchir. Pour le critère cinq, ARTESCA+ Veeam exécute Veeam Backup & Replication et ARTESCA sur le même hôte, de sorte que le trafic entre l’application de sauvegarde et le stockage reste interne au lieu de traverser un réseau généraliste. Une configuration haute disponibilité multinœud a suivi en 2026, combinant la résilience des applications, de la base de données et du stockage. Pour le critère sept, ce logiciel fonctionne de quelques dizaines de téraoctets jusqu’à l’échelle du pétaoctet sur des serveurs x86 standard ; la croissance doit donc consister à ajouter des nœuds plutôt qu’à changer de plateforme. Pour le dimensionnement, les licences et les différences entre le modèle appliance et un déploiement sur deux plateformes, la FAQ ARTESCA + Veeam (en anglais) fournit les détails opérationnels. Rien de tout cela n’en fait la bonne réponse partout. Une organisation disposant d’un référentiel Linux durci bien établi et d’une rotation de bandes opérationnelle peut déjà satisfaire les critères un, cinq et six. Les critères sont ce qui dure. Un produit n’est qu’une manière d’y répondre. À retenir Évaluez la restauration, pas la sauvegarde. L’ingestion est le chiffre que publient les fournisseurs et celui qui compte le moins lors d’un incident. Testez les restaurations sous charge simultanée avant de signer quoi que ce soit. Tracez le chemin de suppression, pas la promesse d’immuabilité. Tout le monde prend en charge Object Lock. Ce qui distingue les cibles, c’est l’identité capable de raccourcir la conservation, et la question de savoir si un attaquant en hérite avec le serveur de sauvegarde. Considérez la profondeur d’intégration comme une fonction de résilience. Le reporting de capacité SOSAPI et l’accès de vérification en lecture seule ressemblent à des commodités. Ce sont eux qui rendent les décisions de conservation justes et les tests de restauration assez peu coûteux pour être réellement effectués. Le fil conducteur est simple. Le stockage de sauvegarde existe pour un jour qui n’est pas encore arrivé, et ce jour-là, ce qui compte, c’est de savoir si la copie a survécu et à quelle vitesse elle revient. Une immuabilité qu’un attaquant ne peut pas révoquer décide du premier point. Le comportement de la restauration sous charge décide du second. Tout le reste n’est qu’argument secondaire. Questions fréquentes Quel est le meilleur stockage pour les sauvegardes Veeam ? Les meilleurs candidats partagent un profil : une immuabilité qu’un administrateur de sauvegarde compromis ne peut pas révoquer, une qualification Veeam Ready Object with Immutability à jour, la prise en charge de SOSAPI, des performances de restauration validées sous charge simultanée et une surface d’attaque réduite entre le serveur de sauvegarde et le stockage. Scality ARTESCA est conçu selon ce profil pour les déploiements sur site. Évaluez chaque candidat selon ces critères, et non selon un seul chiffre de débit ou de prix. Le stockage objet est-il préférable à un référentiel Linux durci pour Veeam ? Ils répondent différemment à des problèmes qui se recoupent, et de nombreux environnements utilisent les deux. Un référentiel durci offre une immuabilité solide sur disque local avec une faible empreinte opérationnelle. Le stockage objet évolue généralement plus loin, gère plus naturellement les copies multisites et s’intègre via SOSAPI. Comme la règle 3-2-1-1-0 exige plus d’une copie, la vraie question est de savoir lequel détient quelle copie. Veeam exige-t-il S3 Object Lock en mode conformité ? Veeam fonctionne avec Object Lock en général, mais le mode de conservation détermine le niveau de protection obtenu. Le mode gouvernance permet à une identité suffisamment privilégiée de modifier la conservation. Le mode conformité ne le permet pas avant l’expiration de la période. Si cette copie est celle sur laquelle vous comptez après une compromission d’identifiants, le mode conformité correspond à la menace. Scality ARTESCA est-il Veeam Ready ? Oui. ARTESCA a été certifié Veeam Ready Object with Immutability et validé sur les versions ultérieures de Veeam, y compris pour la prise en charge de S3 Object Lock et de SOSAPI. Il est disponible sous forme d’appliance logicielle, d’appliance matérielle et en version ARTESCA+ Veeam, qui exécute Veeam Backup & Replication et ARTESCA sur le même hôte. Comment tester une cible de sauvegarde avant de l’acheter ? Restaurez une charge de travail de taille réaliste, puis recommencez pendant qu’un job de sauvegarde est actif. Séparément, essayez de supprimer un objet verrouillé avec chaque identifiant de l’environnement, y compris le plus privilégié, et documentez ce qui vous en empêche. Pour aller plus loin : Veeam 13.1 : les nouveautés pour le stockage objet, FAQ sur la sauvegarde ARTESCA + Veeam (en anglais), et la documentation SOSAPI (en anglais) de Veeam.
