Le niveau de capacité (ou comme nous l'appelons dans Vim - captir) est apparu à l'époque de Veeam Backup and Replication 9.5 Update 4 sous le nom de niveau d'archive. L'idée derrière cela est de permettre de déplacer les sauvegardes qui sont tombées en dehors de la fenêtre de restauration dite opérationnelle vers le stockage objet. Cela a permis de libérer de l'espace disque pour les utilisateurs qui en disposaient peu. Et cette option s’appelait Move Mode.

Pour effectuer cette action simple (semble-t-il), il suffisait de remplir deux conditions : tous les points de la sauvegarde déplacée doivent être en dehors des limites de la fenêtre de restauration opérationnelle mentionnée ci-dessus, qui est définie explicitement dans l'interface utilisateur. Et deuxièmement : la chaîne doit être sous la forme dite « scellée » (chaîne de sauvegarde scellée ou Inactive Backup Chain). Autrement dit, aucun changement ne se produit dans cette chaîne au fil du temps.

Mais dans VBR v10, le concept a été complété par de nouvelles fonctions - le mode copie, le mode scellé et une chose avec le nom difficile à prononcer Immutabilité est apparue.

Ce sont les choses fascinantes dont nous allons parler aujourd’hui. Tout d'abord, sur la façon dont cela fonctionnait dans VBR9.5u4, puis sur les modifications apportées à la dixième version.

Et que les champions du langage pur me pardonnent, mais il y a trop de termes qui ne peuvent être traduits.
Il y aura donc une tonne d'anglicismes ici.
Et beaucoup de gifs.
Et des photos.

• Sans le moindre regret. Auteur de l'article.

Comme c'était

Eh bien, commençons par analyser la fenêtre de restauration opérationnelle et la sauvegarde scellée (ou comme on les appelle dans la documentation de la chaîne de sauvegarde inactive). Sans leur compréhension, aucune explication supplémentaire ne sera possible.

Comme nous le voyons sur l'image, nous avons une sorte de chaîne de sauvegarde avec des blocs de données, qui se situe sur le SOBR du niveau Performance du référentiel auquel le niveau capacité est connecté. Notre fenêtre de sauvegarde opérationnelle est de trois jours.

Ainsi, le .vbk créé lundi scelle la chaîne précédente, dont la fenêtre est fixée à trois jours. Et cela signifie que vous pouvez commencer à transporter en toute sécurité tout ce qui date de plus de ces trois jours jusqu'au champ de tir.

Mais qu’entendait-on exactement par chaîne scellée et que pouvait-on envoyer au stand de tir de capacité dans la mise à jour 4 ?

Pour Forward Incremental, un signe de scellement de la chaîne est la création d’une nouvelle sauvegarde complète. Et peu importe la manière dont cette sauvegarde complète est obtenue : les sauvegardes complètes synthétiques et actives sont prises en compte.

Dans le cas de Reverse, ce sont tous des fichiers qui n'entrent pas dans la fenêtre d'exploitation.

Dans le cas d'une incrémentation avant avec restaurations, ce sont toutes des restaurations et .vbk, s'il existe un autre .vbk sur l'étendue des performances.

Considérons maintenant la possibilité de travailler avec des chaînes de copie de sauvegarde. Seuls les objets relevant de la rétention GFS ont été transportés ici. Parce que tout ce qui est stocké dans les chaînes de copies de sauvegarde les plus récentes peut être modifié d’une manière ou d’une autre.

Regardons maintenant sous le capot. Là, un processus appelé déshydratation se produit - laissant les fichiers de sauvegarde vides sur l'étendue et faisant glisser les blocs de ces fichiers vers le champ de tir de capacité. Pour optimiser ce processus, on utilise ce qu'on appelle l'indice de déshydratation, ce qui permet d'éviter de copier des blocs déjà copiés vers le champ de tir de capacité.

Voyons à quoi cela ressemble avec un exemple : disons que nous avons un .vbk qui est sorti de la fenêtre de transaction et appartient à une chaîne scellée. Cela signifie que nous avons parfaitement le droit de le déplacer vers le champ de tir de capacité. Au moment du déplacement, un fichier de métadonnées est créé dans la capacité des tirets et des blocs du fichier transféré. Le fichier de métadonnées au niveau du lien décrit les blocs constitués par notre fichier. Dans le cas de l'image, notre premier fichier est constitué de blocs a, b, c et les métadonnées contiennent des liens vers ces blocs. Lorsque nous disposons d'un deuxième fichier .vbk, prêt à être déplacé et composé des blocs a, b et d, nous, en analysant l'indice de déshydratation, comprenons que seul le bloc d doit être transféré. Et son fichier de métadonnées contiendra des liens vers deux blocs précédents et un nouveau.

En conséquence, le processus consistant à remplir ces espaces vides avec des données est appelé réhydratation. Il utilise déjà son propre index de réhydratation, basé sur le plus ancien fichier .vbk sur l'étendue des performances locales. Autrement dit, si l'utilisateur souhaite restituer un fichier du stand de tir de capacité, nous créons d'abord un index des blocs de la sauvegarde complète la plus ancienne et transférons uniquement les blocs manquants du stand de tir de capacité. Dans le cas présenté sur la photo, pour réhydrater FullBackup1.vbk selon l'indice de réhydratation, nous n'avons besoin que du bloc C, que nous prenons dans le champ de tir de capacité. Si un objet cloud de stockage sert de champ de tir de capacité, cela vous permet d'économiser d'énormes sommes d'argent.

Ici, il peut sembler que cette technologie est identique à celle utilisée dans les accélérateurs WAN, mais ce n'est qu'une apparence. Dans les accélérateurs, la déduplication est globale ; ici, la déduplication locale est utilisée dans chaque fichier à un décalage spécifique. Cela se produit en raison de la différence dans les tâches à résoudre : ici, nous devons copier de gros fichiers de sauvegarde complète, et selon nos recherches, même si une longue période de temps s'écoule entre eux, cet algorithme de déduplication donne le meilleur résultat.

Mais plus d'index pour le dieu des index ! Il existe également un index pour la récupération de données ! Lorsque nous commençons à restaurer une machine située dans le tableau de bord de capacité, nous lirons uniquement les blocs de données uniques qui ne figurent pas dans le tableau de bord de performances.

Comme il est devenu

C'est tout pour la partie introductive. C'est assez détaillé, mais comme mentionné ci-dessus, sans ces détails, il ne sera pas possible d'expliquer le fonctionnement des nouvelles fonctions. Alors, sans plus attendre, passons au premier.

Mode copie

Il s’appuie en grande partie sur des technologies existantes, mais porte une toute autre logique d’usage. 

Le but de ce mode est de garantir que toutes les données situées sur l’étendue locale ont une copie dans le tableau de bord de capacité.

Si vous comparez de front les modes Déplacer et Copier, cela ressemblera à ceci :

• Seule la chaîne scellée peut être déplacée. Dans le cas d'un mode copie, absolument tout est transféré, indépendamment de ce qui se passe lors du travail de sauvegarde.
• Le déplacement est déclenché lorsque les fichiers dépassent les limites de la fenêtre de sauvegarde opérationnelle, et la copie est déclenchée dès l'apparition du fichier de sauvegarde.
• La surveillance des nouvelles données pour la copie est constante et pour le déplacement, elle est déclenchée toutes les 4 heures.

En considérant le nouveau mode, je propose de passer d'exemples simples à des exemples complexes.

Dans le cas le plus courant, nous avons simplement de nouveaux fichiers par incréments, et nous les copions simplement dans le champ de tir de capacité. Quel que soit le mode utilisé dans le travail de sauvegarde, qu'il appartienne ou non à la partie scellée de la chaîne, que notre fenêtre de fonctionnement ait expiré. Ils l'ont simplement pris et copié.

Le processus derrière cela est toujours la déshydratation comme décrit ci-dessus. En mode copie, cela garantit également que nous ne copions pas les blocs qui se trouvent déjà sur notre stockage. La seule différence est que si en mode film nous remplaçons les vrais fichiers par des fichiers factices, ici nous n'y touchons en aucun cas et laissons tout tel quel. Sinon, c'est exactement le même indice de déshydratation, qui essaie soigneusement d'économiser votre argent et votre temps.

La question se pose : si vous regardez l'interface utilisateur, il est possible de sélectionner les deux options en même temps. Comment fonctionnera un tel mode combiné ?

Occupons-nous.

Le début est standard : un fichier de sauvegarde est créé et copié immédiatement. Un incrément y est créé et également copié. Cela se produit jusqu'au moment où nous nous rendons compte que les fichiers ont quitté notre fenêtre d'exploitation et qu'une chaîne scellée est apparue. À ce stade, nous effectuons une opération de déshydratation et remplaçons ces fichiers par des fichiers factices. Bien entendu, nous ne copions rien dans le champ de tir de capacité.

Toute cette logique fascinante n’est responsable que d’une seule case à cocher dans l’interface : copier les sauvegardes vers le stockage objet dès leur création.

Pourquoi avons-nous besoin de ce mode Copie ?

Il est encore mieux de reformuler la question ainsi : de quels risques sommes-nous protégés grâce à son aide ? Quel problème cela nous aide-t-il à résoudre ?

La réponse est évidente : bien sûr, il s’agit de récupération de données. Si nous disposons d'une copie complète des données locales sur le stockage d'objets, peu importe ce qui arrive à notre produit, nous pouvons toujours restaurer les données à partir de fichiers situés dans l'Amazon conditionnel.

Passons donc en revue les scénarios possibles, du plus simple au plus complexe.

Le malheur le plus simple qui puisse nous tomber sur la tête est l'inaccessibilité de l'un des fichiers de la chaîne de sauvegarde.

Une histoire plus triste est que l'une des extensions de notre référentiel SOBR est tombée en panne.

La situation est encore pire lorsque l'ensemble du référentiel SOBR est devenu inaccessible, mais que la capacité de tir fonctionne.
Et tout va vraiment mal - c'est à ce moment-là que le serveur de sauvegarde tombe en panne et que votre premier désir est d'essayer de courir jusqu'à la frontière canadienne en dix minutes.

Examinons maintenant chaque situation séparément.

Lorsque nous avons perdu un (et même plusieurs) fichiers de sauvegarde, il nous suffit alors de lancer le processus de nouvelle analyse du référentiel et le fichier perdu sera remplacé par un fichier factice. Et en utilisant le processus de réhydratation (qui a été évoqué au début de l'article), l'utilisateur pourra télécharger les données du champ de tir de capacité vers le stockage local.

Aujourd’hui, la situation est plus compliquée. Supposons que notre SOBR se compose de deux extensions exécutées en mode Performance, ce qui signifie que nos .vbk et .vib sont répartis sur eux dans une couche plutôt inégale. Et à un moment donné, une des extensions devient indisponible, et l'utilisateur a un besoin urgent de restaurer la machine dont une partie des données réside précisément sur cette étendue.

L'utilisateur lance l'assistant de récupération, sélectionne le point auquel il souhaite restaurer, et l'assistant, tout en travaillant, se rend compte qu'il ne dispose pas de toutes les données nécessaires à la récupération localement et doit donc être téléchargé depuis la capacité de prise de vue. Galerie. Dans le même temps, les blocs restant sur le stockage local ne seront pas téléchargés depuis le cloud. Gloire à l’index de restauration (oui, cela a aussi été évoqué en début d’article).

Un sous-type de ce cas est que l'intégralité du référentiel SOBR est devenu inaccessible. Dans ce cas, nous n'avons rien à copier depuis le stockage local et tous les blocs sont téléchargés depuis le cloud.

Et la situation la plus intéressante est que le serveur de sauvegarde est mort. Il y a deux options ici : l'administrateur est génial et a effectué des sauvegardes de configuration, et l'administrateur est lui-même un méchant Pinocchio et n'a pas effectué de sauvegardes de configuration.

Dans le premier cas, il lui suffira simplement de déployer quelque part une nouvelle installation de VBR et de restaurer sa base de données à partir d'une sauvegarde par des moyens standards. A la fin de ce processus, tout redeviendra normal. Ou il sera restauré selon l'un des scénarios ci-dessus.

Mais si l'administrateur est soit son propre ennemi, soit que la sauvegarde de la configuration a également subi un échec épique, alors même ici, nous ne le laisserons pas à la merci du destin. Pour ce cas, nous avons introduit une nouvelle procédure appelée Import Object Storage. Il vous permet d'ignorer le processus de recréation manuelle d'un référentiel SOBR et d'y attacher un champ de tir de capacité avec une nouvelle analyse ultérieure, et d'ajouter simplement un objet de stockage à l'interface Vim et d'exécuter la procédure Importer un référentiel de stockage. La seule chose qui peut faire obstacle entre vous et vos sauvegardes est une demande de saisie d'un mot de passe si vos sauvegardes ont été cryptées.

Il s'agit probablement du mode Copie et nous passons à

Mode scellé

L'idée principale est que les nouvelles sauvegardes ne peuvent pas apparaître sur l'étendue SOBR sélectionnée du référentiel. Avant la v10, nous n'avions que le mode maintenance, lorsque tout travail avec le référentiel était totalement interdit. Une sorte de mode hardcore pour arrêter le stockage, où seul le bouton Évacuer est disponible, qui transporte les sauvegardes dans une autre mesure une fois.

Et le mode scellé est une sorte d'option « douce » : nous interdisons la création de nouvelles sauvegardes et supprimons progressivement les anciennes en fonction de la conservation choisie, mais dans le processus nous ne perdons pas la possibilité de restaurer à partir des points stockés. Une chose très utile lorsque soit nous avons un matériel en fin de vie et devons le remplacer, soit nous avons simplement besoin de le libérer pour quelque chose de plus important, mais il n'y a nulle part où l'emmener et tout déplacer en même temps. Ou alors, il ne peut pas être supprimé.

Ainsi, le principe de fonctionnement est assez simple : il faut interdire toutes les opérations d'écriture (apparition de nouvelles données), de sortie de lecture (restaurations) et de suppression (conservation).

Les deux modes peuvent être utilisés simultanément, mais gardez à l’esprit que la maintenance a une priorité plus élevée.

À titre d’exemple, considérons un SOBR composé de deux extensions. Supposons que pendant les quatre premiers jours, nous ayons créé des sauvegardes en mode Forward Forever Incremental, puis que nous scellions l'étendue, ce qui conduit au fait que nous lançons la création d'une nouvelle extension complète active sur la deuxième extension disponible. Si notre rétention est de quatre, alors lorsque toute la chaîne située sur l'étendue scellée dépasse ses limites, elle est supprimée en toute bonne conscience.

Il existe des situations où la suppression se produit plus tôt. Par exemple, il s'agit d'un Forward incrémentiel avec des fulls périodiques. Si nous avons créé des sauvegardes complètes pour les deux premiers jours et que jeudi nous décidons de sceller le référentiel, alors vendredi, lorsqu'une nouvelle sauvegarde est créée, le fichier de lundi sera supprimé car il n'y a aucune dépendance à ce stade. Et le point en lui-même ne dépend de personne. Ensuite, nous attendons que quatre points soient créés sur l'étendue disponible et supprimons les trois autres, qui ne peuvent pas être supprimés indépendamment les uns des autres.

Les choses sont plus simples avec Reverse Incremental. Dans celui-ci, les points les plus anciens ne dépendent de rien et peuvent être supprimés en toute sécurité. Par conséquent, dès qu'un nouveau .vbk est créé sur une nouvelle extension, les anciens .vrbs seront supprimés un par un.

Au fait, pourquoi créons-nous un nouveau .vbk à chaque fois : si nous ne le créions pas, mais continuions l'ancienne chaîne d'incréments, alors l'ancien .vbk se figerait pendant une durée infiniment longue dans n'importe quel mode, empêchant sa suppression. Il a donc été décidé que dès que l'extension serait scellée, nous créerions une sauvegarde complète sur l'extension libre.

Les choses sont plus compliquées avec le champ de tir de capacité.

Tout d'abord, regardons le mode copie. Supposons que nous créions activement des sauvegardes pendant quatre jours, puis que la capacité du stand de tir ait été scellée. Nous ne supprimons rien, mais supportons humblement la conservation, après quoi nous supprimons les données du champ de tir de capacité.

À peu près la même chose se produit en mode déplacement : nous attendons la retouche, supprimons l'ancienne dans le stockage local et supprimons celle stockée dans le stockage d'objets.

Un exemple intéressant avec Forever forward incrémental. Nous installons la rétention en trois points et commençons à faire des sauvegardes dès lundi, qui sont régulièrement copiées dans le cloud. Après avoir scellé le stockage, les sauvegardes continuent d'être créées, en conservant trois points, mais les données stockées dans le tableau de bord de capacité restent dépendantes et ne peuvent pas être supprimées. Par conséquent, nous attendons jusqu'à jeudi, lorsque notre .vbk dépasse la limite de rétention, et alors seulement nous supprimons calmement toute la chaîne enregistrée.

Et un petit avertissement : tous les exemples ici sont présentés avec une seule machine. Si vous en avez plusieurs dans votre sauvegarde, alors leur retouche sera différente selon que Active Full a été réalisé ou non.

C'est essentiellement tout ce qu'il y a à faire. Passons donc à la fonctionnalité la plus hardcore :

Immutabilité

Comme pour les points précédents, la première chose est de savoir quel problème cette fonction résout. Dès que nous téléchargeons nos sauvegardes quelque part pour les stocker, il existe une volonté forte de garantir leur sécurité, c'est-à-dire d'interdire physiquement leur suppression et toute modification lors d'une conservation donnée. Y compris les administrateurs, y compris sous leurs comptes root. Cela vous permet de les protéger des dommages accidentels ou intentionnels. Toute personne travaillant avec AWS a peut-être rencontré une fonctionnalité similaire appelée Object Lock.

Examinons maintenant le mode en termes généraux, puis approfondissons les détails. Dans notre exemple, l'immuabilité sera activée pour notre champ de tir de capacité avec une rétention de quatre jours. Et le mode Copie est activé dans la sauvegarde.

L'immuabilité n'interagit en aucune manière avec la rétention générale. Par exemple, cela n’ajoute pas de points supplémentaires ou quoi que ce soit du genre. C’est juste qu’une personne ne peut pas supprimer les fichiers de sauvegarde dans les quatre jours. Si vous effectuez une sauvegarde lundi, vous ne pourrez supprimer son fichier que vendredi.

Tous les concepts de déshydratation, d’index et de métadonnées expliqués précédemment continuent de fonctionner exactement de la même manière. Mais à une condition : le bloc est défini non seulement pour les données, mais également pour les métadonnées. Ceci est fait au cas où un attaquant rusé déciderait d'effacer notre base de données de métadonnées et d'empêcher les blocs de données de se transformer en bouillie binaire inutile.

C’est le moment idéal pour expliquer notre technologie de génération de blocs. Ou génération de blocs. Pour ce faire, considérons la situation qui a conduit à son apparition.

Prenons une échelle de temps de six jours et ci-dessous nous marquerons l'heure de l'expiration prévue de l'immuabilité. Le premier jour, nous prenons et créons un fichier composé du bloc de données a et de ses métadonnées. Si l'immuabilité est fixée à trois jours, il est logique de supposer que le quatrième jour, les données seront déverrouillées et supprimées. Le deuxième jour, nous ajouterons un nouveau fichier2, composé du bloc b avec les mêmes paramètres. Le bloc a doit encore être supprimé le quatrième jour. Mais le troisième jour, quelque chose de terrible se produit : un fichier File3 est créé, composé d'un nouveau bloc d et d'un lien vers l'ancien bloc a. Cela signifie que pour un bloc et son indicateur d'immuabilité, il faut réinitialiser à une nouvelle date, qui est décalée au sixième jour. Et ici, un problème se pose : dans les sauvegardes réelles, il existe un grand nombre de ces blocs. Et afin de prolonger leur période d'immuabilité, il faut à chaque fois faire un grand nombre de demandes. Et en fait, ce sera un processus quotidien presque sans fin, car avec un degré de probabilité élevé, nous trouverons de lourdes piles de blocs dédupliqués avec chaque copie. Que signifie un grand nombre de demandes de la part des fournisseurs de stockage objet ? Droite! Grosse facture à la fin du mois.

Et afin de ne pas exposer à l'improviste vos clients préférés pour de l'argent substantiel, le mécanisme de génération de blocs a été inventé. Il s'agit d'une période supplémentaire que nous ajoutons à la période d'immuabilité fixée. Dans l'exemple ci-dessous, ce délai est de deux jours. Mais ce n'est qu'un exemple. En réalité, ils utilisent leur propre formule, qui donne environ dix jours supplémentaires lors d'un blocage mensuel.

Continuons à considérer la même situation, mais avec la génération de blocs. Le premier jour, nous créons le fichier 1 à partir du bloc a et des métadonnées. Nous additionnons la période de génération et l'immuabilité - cela signifie que la possibilité de supprimer le fichier aura lieu le sixième jour. Si le deuxième jour nous créons le Fichier2, composé du bloc b et d'un lien vers le bloc a, alors rien ne se passe à la date de suppression prévue. Elle se leva comme le sixième jour. Et ainsi nous essayons d'économiser de l'argent sur le nombre de demandes. La seule situation dans laquelle le délai peut être décalé est si la période de génération est expirée. Autrement dit, si le troisième jour le nouveau File3 contient un lien pour bloquer a, alors la génération 2 sera ajoutée puisque Gen1 a déjà expiré. Et la date prévue pour la suppression du bloc a sera décalée au huitième jour. Cela nous permet de réduire considérablement le nombre de demandes visant à prolonger la durée de vie des blocs dédupliqués, ce qui permet aux clients d'économiser beaucoup d'argent.

La technologie elle-même est disponible pour les utilisateurs de matériel S3 et compatible S3, dont les fabricants garantissent que leur mise en œuvre ne diffère pas de celle d’Amazon. D'où la réponse à la question légitime de savoir pourquoi Azure n'est pas pris en charge : ils ont une fonctionnalité similaire, mais elle fonctionne au niveau des conteneurs et non des objets individuels. À propos, Amazon lui-même dispose d'un verrouillage d'objet selon deux modes : conformité et gouvernance. Dans le deuxième cas, il reste la possibilité que le plus grand administrateur au-dessus des admins et la racine au-dessus des racines, malgré le verrouillage des objets, suppriment toujours les données. En cas de conformité, tout est bien verrouillé et personne ne peut supprimer les sauvegardes. Même les administrateurs d'Amazon (selon leurs déclarations officielles). C'est le mode que nous prenons en charge.

Et comme d'habitude quelques liens utiles :

• Sur Génération de blocs dans chaque détail.
• Toutes les informations sur Veeam Sauvegarde et réplication 10 à son meilleur
• О Niveau de capacité en détail

Source: habr.com