Qu'est-ce qu'une cible de sauvegarde ?

Une cible de sauvegarde est le système de stockage qui reçoit et conserve les données produites par un logiciel de sauvegarde. Des applications comme Veeam, Commvault ou Rubrik y écrivent les données de sauvegarde et les relisent lors d'une restauration. Sa capacité, ses performances en lecture, sa disponibilité et ses contrôles de rétention conditionnent donc à la fois le volume de sauvegardes conservable et la rapidité de restauration.

Que fait réellement une cible de sauvegarde ?

Une cible de sauvegarde se situe du côté stockage du processus de sauvegarde. C'est l'application de sauvegarde qui décide quoi protéger, quand les travaux s'exécutent et quels points de restauration sont disponibles. La cible, elle, est responsable du stockage des données produites et de leur restitution lorsqu'une restauration est demandée.

Cette distinction prend toute son importance au moment de la restauration. Un travail de sauvegarde qui se termine dans sa fenêtre planifiée confirme que la cible accepte les données au rythme requis. Il ne démontre pas que le même système saura restituer un volume important de données assez rapidement lors d'une restauration de grande ampleur.

Les performances en lecture peuvent différer sensiblement des performances en écriture selon la conception du stockage. La déduplication, l'architecture des contrôleurs, la bande passante réseau, les charges de travail concurrentes et le nombre de nœuds de stockage impliqués influent tous sur le débit de restauration.

Pour cette raison, évaluer une cible de sauvegarde suppose d'examiner le comportement en restauration autant que les performances d'ingestion.

Que faut-il évaluer dans une cible de sauvegarde ?

Les exigences varient selon les environnements, mais plusieurs caractéristiques ont un effet direct sur les opérations de sauvegarde et de restauration.

Débit de restauration

Le débit de restauration mesure la vitesse à laquelle les données protégées peuvent être lues depuis la cible de sauvegarde et rendues aux systèmes de production.

Ce point devient déterminant lors d'une restauration après ransomware ou d'une panne d'infrastructure majeure, quand des dizaines ou des centaines de charges de travail doivent être restaurées simultanément. Un système de stockage qui donne satisfaction pendant les sauvegardes planifiées peut malgré tout devenir le goulet d'étranglement de la reprise si son chemin de lecture ne supporte pas les restaurations parallèles.

Les tests doivent donc inclure des scénarios de reprise réalistes, et pas seulement les temps d'exécution des travaux de sauvegarde.

Accès concurrents

Une restauration isolée sollicite relativement peu un système de stockage moderne. Les reprises de grande ampleur, elles, sont d'une autre nature.

Plusieurs proxies de sauvegarde ou travaux de restauration peuvent demander des données en même temps. La cible doit disposer de suffisamment de ressources disque, CPU et réseau pour servir ces demandes sans faire transiter l'essentiel de la charge par un nombre limité de contrôleurs ou d'autres composants partagés.

L'emplacement de ces goulets d'étranglement dépend de l'architecture de la cible.

Immuabilité et application de la rétention

La cible peut également fournir un contrôle indépendant sur la possibilité de modifier ou de supprimer les sauvegardes conservées.

Avec S3 Object Lock, par exemple, la rétention est appliquée par le système de stockage objet. En mode conformité, une version d'objet protégée ne peut être ni écrasée ni supprimée avant l'expiration de sa période de rétention, y compris par un utilisateur disposant d'identifiants d'administration du stockage.

C'est différent d'un paramètre de rétention qui n'existe que dans la configuration du logiciel de sauvegarde. Une rétention appliquée par le stockage reste attachée à l'objet protégé même si le logiciel de sauvegarde lui-même est compromis.

Croissance de la capacité

Les référentiels de sauvegarde accumulent des données à mesure que les durées de rétention s'allongent, que les jeux de données protégés grossissent et que de nouvelles charges de travail entrent dans le périmètre de sauvegarde.

Une cible doit donc offrir un moyen pratique d'ajouter de la capacité sans créer un nouveau référentiel chaque fois qu'un système atteint sa limite.

Le modèle de montée en charge influe aussi sur les performances. Certains systèmes n'ajoutent essentiellement que de la capacité, tandis que les architectures scale-out ajoutent également des ressources de traitement et de réseau.

Comportement en cas de panne

Les cibles de sauvegarde doivent aussi être évaluées à l'aune de ce qui se passe lorsqu'un composant matériel tombe en panne.

La défaillance d'un disque, d'un nœud ou d'un contrôleur peut déclencher une reconstruction pendant que les travaux de sauvegarde et de restauration se poursuivent. Le temps nécessaire pour reconstruire les données protégées et les ressources consommées pendant cette opération peuvent affecter à la fois la protection et les performances de restauration.

D'où l'intérêt de tester en mode dégradé lors de l'évaluation d'une cible de sauvegarde pour les environnements de grande taille.

Exemple : quand les performances de sauvegarde masquent un goulet d'étranglement en restauration

Prenons un hôpital qui protège environ 400 machines virtuelles avec Veeam.

Les sauvegardes nocturnes sont écrites sur une appliance de déduplication bâtie autour d'une paire de contrôleurs. Les travaux se terminent systématiquement dans leur fenêtre planifiée : au quotidien, l'équipe infrastructure n'a guère de raison de s'interroger sur les performances de la cible.

Un incident ransomware crée une charge de travail toute différente. Soixante machines virtuelles doivent être restaurées simultanément.

L'appliance doit alors lire et reconstituer d'importants volumes de données dédupliquées pendant que plusieurs travaux de restauration se disputent les mêmes ressources de contrôleur. Certaines charges de travail reviennent vite, d'autres attendent leur tour. La reprise s'étire bien au-delà de ce que laissaient présager les performances habituelles des sauvegardes.

Rien n'a nécessairement échoué dans le système de stockage. La charge de travail a révélé une contrainte que les opérations de sauvegarde de routine ne montraient pas : la cible pouvait accepter les données de sauvegarde plus vite qu'elle ne pouvait en restituer lors d'une restauration parallèle de grande ampleur.

C'est pourquoi les tests d'une cible de sauvegarde doivent mesurer le débit en ingestion comme en restauration, au niveau de concurrence attendu lors d'une reprise réelle.

Cible de sauvegarde et référentiel de sauvegarde

Les termes cible de sauvegarde et référentiel de sauvegarde sont parfois employés indifféremment, alors qu'ils peuvent désigner des choses légèrement différentes.

Une cible de sauvegarde désigne généralement le système de stockage, ou la destination, qui reçoit les données de sauvegarde.

Un référentiel est souvent la ressource de stockage logique configurée à l'intérieur du logiciel de sauvegarde. Selon le produit, un même système de stockage physique peut fournir plusieurs référentiels, buckets ou niveaux de stockage.

Garder cette distinction en tête aide au diagnostic des problèmes de performance. Une configuration de référentiel peut limiter la concurrence alors même que la cible sous-jacente dispose encore de ressources, tandis qu'une contrainte de stockage physique peut affecter plusieurs référentiels à la fois.

Cible de sauvegarde et logiciel de sauvegarde

L'application de sauvegarde et la cible de sauvegarde ont des responsabilités distinctes.

Le logiciel de sauvegarde pilote généralement la planification des travaux, la découverte des charges de travail, les politiques de sauvegarde, les catalogues et l'orchestration des restaurations. La cible de sauvegarde stocke les données produites.

Les contrôles de sécurité peuvent exister aux deux niveaux. Le logiciel de sauvegarde peut restreindre la suppression via des rôles et des permissions applicatives, tandis que la cible peut appliquer des contrôles comme la rétention au niveau de l'objet, indépendamment de l'interface d'administration du logiciel.

Une conception de sauvegarde efficace tient compte des deux couches, au lieu de traiter le référentiel comme une simple réserve de capacité.

Comment le stockage objet fonctionne comme cible de sauvegarde

De nombreux produits de sauvegarde d'entreprise peuvent écrire directement dans un stockage objet compatible S3. Le portefeuille de compatibilité actuel d'ARTESCA comprend notamment Veeam, Commvault, Rubrik et Veritas.

Au lieu de passer par une interface de système de fichiers classique, l'application écrit des objets dans des buckets via l'API S3.

Le stockage objet peut aussi associer croissance de la capacité et traitement distribué. Dans un déploiement scale-out, chaque nœud supplémentaire apporte du CPU, de la mémoire, de la bande passante réseau et du stockage, ce qui permet au débit global d'augmenter avec la taille du cluster.

Cette architecture est utile aux environnements de sauvegarde où la capacité conservée et le nombre de flux simultanés de sauvegarde ou de restauration augmentent avec le temps.

Comment ARTESCA fonctionne comme cible de sauvegarde

ARTESCA fournit un stockage objet compatible S3 utilisable comme cible de sauvegarde par des applications validées, dont Veeam, Commvault, Rubrik et Veritas.

Les données de sauvegarde peuvent être protégées par S3 Object Lock. Lorsque la rétention en mode conformité est correctement configurée, les versions d'objets verrouillées ne peuvent être ni écrasées ni supprimées avant l'expiration de leur date de rétention. La rétention est ainsi appliquée par la couche de stockage, sans dépendre uniquement des permissions du logiciel de sauvegarde.

Pour les environnements Veeam, ARTESCA est aujourd'hui documenté comme certifié Veeam Ready Repository et Veeam Ready Object with Immutability. La solution peut être utilisée comme Performance Tier ou Capacity Tier et prend en charge la Smart Object Storage API (SOSAPI) de Veeam.

SOSAPI permet à Veeam d'obtenir des informations de stockage depuis ARTESCA plutôt que de traiter la cible S3 comme un point de terminaison opaque. La documentation ARTESCA indique que la prise en charge de SOSAPI peut exposer des métriques de bucket à Veeam et qu'elle est activée automatiquement lorsqu'un bucket est provisionné via son assistant Veeam VBR.

L'architecture scale-out d'ARTESCA signifie également que l'ajout de nœuds apporte des ressources de stockage et de traitement, au lieu d'étendre la capacité derrière une paire de contrôleurs figée. Cela devient pertinent lorsque le volume de sauvegarde et le débit de restauration requis augmentent tous les deux.

Termes associés

• S3 Object Lock et immuabilité — une rétention appliquée par le stockage, qui empêche d'écraser ou de supprimer une version d'objet protégée.
• WORM (écrire une fois, lire plusieurs fois) — le modèle d'immuabilité qui sous-tend les contrôles de rétention au niveau de l'objet.
• Air gap logique — l'isolation des copies de sauvegarde vis-à-vis des identifiants et des chemins d'administration de la production.