{"id":84809,"date":"2020-06-11T01:42:41","date_gmt":"2020-06-10T23:42:41","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10"},"modified":"2020-06-11T01:42:41","modified_gmt":"2020-06-10T23:42:41","slug":"chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","title":{"rendered":"Qu'est-ce qui a chang\u00e9 dans le Capacity Tier depuis que Veeam est devenu v10","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Le Niveau de Capacit\u00e9 (ou comme nous l'appelons en interne chez Vima \u2014 captir) est apparu \u00e0 l'\u00e9poque de Veeam Backup and Replication 9.5 Update 4 sous le nom de Niveau d'Archive. L'id\u00e9e qu'il v\u00e9hicule est de permettre le d\u00e9placement des sauvegardes qui sont en dehors de ce que l'on appelle la fen\u00eatre de restauration op\u00e9rationnelle, vers des stockages d'objets. Cela aidait \u00e0 lib\u00e9rer de l'espace disque pour les utilisateurs qui en avaient peu. Cette option \u00e9tait appel\u00e9e Mode de D\u00e9placement.<\/p>\n<p>Pour effectuer cette action simple (comme elle semble l'\u00eatre), deux conditions doivent \u00eatre respect\u00e9es : tous les points de la sauvegarde \u00e0 d\u00e9placer doivent \u00eatre en dehors de la fen\u00eatre de restauration op\u00e9rationnelle mentionn\u00e9e, qui est d\u00e9finie explicitement dans l'interface utilisateur. Et deuxi\u00e8mement : la cha\u00eene doit \u00eatre dans ce qu'on appelle un \u00ab \u00e9tat scell\u00e9 \u00bb (sealed backup chain ou Inactive Backup Chain). Cela signifie qu'avec le temps, cette cha\u00eene ne subit pas de modifications.<\/p>\n<p>Mais dans VBR v10, le concept a \u00e9t\u00e9 enrichi de nouvelles fonctionnalit\u00e9s \u2014 sont apparus le Mode de Copie, le Mode Scell\u00e9 et une chose avec un nom difficile \u00e0 prononcer, l'Inalt\u00e9rabilit\u00e9.<\/p>\n<p>C'est de ces choses fascinantes dont nous allons parler aujourd'hui. D'abord de son fonctionnement dans VBR9.5u4, puis des changements dans la dixi\u00e8me version.<\/p>\n<p><img decoding=\"async\" alt=\"Qu&#039;est-ce qui a chang\u00e9 dans le Capacity Tier depuis que Veeam est devenu v10\" src=\"\/wp-content\/uploads\/2020\/06\/954adcc5592fe2a7ea64ec24b06ecc91.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEt que les d\u00e9fenseurs de la langue pure me pardonnent, mais trop de termes est impossible \u00e0 traduire.<br \/>\nAinsi, il y aura une multitude d'anglicismes.<br \/>\nEt beaucoup de GIFs. <br \/>\nEt d'images.<\/p>\n<ul>\n<li>Sans le moindre regret. L'auteur de l'article.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1>Comment c'\u00e9tait<\/h1>\n<p>\nEh bien, commen\u00e7ons par examiner la fen\u00eatre de restauration op\u00e9rationnelle et la sauvegarde scell\u00e9e (ou comme elle est appel\u00e9e dans la documentation, Inactive Backup Chain). Sans leur compr\u00e9hension, il n'est pas possible d'expliquer davantage.<\/p>\n<p>Comme nous le voyons sur l'image, nous avons une certaine cha\u00eene de sauvegarde avec des blocs de donn\u00e9es, qui est situ\u00e9e sur le niveau de performance du d\u00e9p\u00f4t SOBR, auquel est connect\u00e9 le Niveau de Capacit\u00e9. Notre fen\u00eatre de sauvegarde op\u00e9rationnelle est de trois jours.<\/p>\n<p>Ainsi, la sauvegarde .vbk cr\u00e9\u00e9e lundi scelle la cha\u00eene pr\u00e9c\u00e9dente, dont la fen\u00eatre est fix\u00e9e \u00e0 trois jours. Par cons\u00e9quent, nous pouvons tranquillement commencer \u00e0 transf\u00e9rer au niveau de capacit\u00e9 tout ce qui est plus ancien que ces trois jours.<\/p>\n<p><img decoding=\"async\" alt=\"Qu&#039;est-ce qui a chang\u00e9 dans le Capacity Tier depuis que Veeam est devenu v10\" src=\"\/wp-content\/uploads\/2020\/06\/430f31d181bb79c2bd6001011511e3f9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMais que signifie exactement une cha\u00eene scell\u00e9e et que pouvait-on envoyer au niveau de capacit\u00e9 dans la mise \u00e0 jour 4 ?<\/p>\n<p>Pour les Incr\u00e9mentales Avanc\u00e9es, le signe de la cha\u00eene scell\u00e9e est la cr\u00e9ation d'une nouvelle sauvegarde compl\u00e8te. Peu importe comment cette sauvegarde compl\u00e8te est obtenue : les sauvegardes compl\u00e8tes synth\u00e9tiques et actives sont toutes prises en compte.<\/p>\n<p>Dans le cas des Invers\u00e9es, ce sont tous les fichiers qui ne rentrent pas dans la fen\u00eatre op\u00e9rationnelle. <\/p>\n<p>Dans le cas d'un incrementation Forward avec des rollbacks, tous les rollbacks et .vbk, si sur l'extent de performance il y a un autre .vbk.<\/p>\n<p><img decoding=\"async\" alt=\"Qu&#039;est-ce qui a chang\u00e9 dans le Capacity Tier depuis que Veeam est devenu v10\" src=\"\/wp-content\/uploads\/2020\/06\/4cb6f168862acabadbdab771cc48fe7f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nConsid\u00e9rons maintenant le cas des cha\u00eenes de copies de sauvegarde. Ici, seules celles entrant sous la r\u00e9tention GFS sont prises en compte. Car tout ce qui est conserv\u00e9 dans des cha\u00eenes de copies de sauvegarde plus r\u00e9centes peut \u00eatre modifi\u00e9 d'une mani\u00e8re ou d'une autre.<\/p>\n<p><img decoding=\"async\" alt=\"Qu&#039;est-ce qui a chang\u00e9 dans le Capacity Tier depuis que Veeam est devenu v10\" src=\"\/wp-content\/uploads\/2020\/06\/4c263058110b7c502501f01940977f1a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJetons maintenant un coup d'\u0153il sous le capot. L\u00e0, se d\u00e9roule un processus appel\u00e9 d\u00e9shydratation - laissant des fichiers de sauvegarde vides sur l'extent et d\u00e9pla\u00e7ant des blocs de ces fichiers vers le stockage de capacit\u00e9. Pour optimiser ce processus, on utilise ce qu'on appelle un index de d\u00e9shydratation, qui permet de ne pas copier les blocs qui ont d\u00e9j\u00e0 \u00e9t\u00e9 copi\u00e9s dans le stockage de capacit\u00e9. <\/p>\n<p>Voyons \u00e0 quoi cela ressemble avec un exemple : supposons que nous avons un .vbk qui est sorti de la fen\u00eatre op\u00e9rationnelle et appartient \u00e0 une cha\u00eene scell\u00e9e. Cela signifie que nous avons tout \u00e0 fait le droit de le d\u00e9placer vers le stockage de capacit\u00e9. Au moment du d\u00e9m\u00e9nagement, un fichier de m\u00e9tadonn\u00e9es est cr\u00e9\u00e9 dans le stockage de capacit\u00e9 et les blocs du fichier transf\u00e9r\u00e9. Dans le fichier de m\u00e9tadonn\u00e9es au niveau des liens, il est d\u00e9crit de quels blocs notre fichier se compose. Dans le cas de l'image, notre premier fichier est compos\u00e9 des blocs a, b, c et les m\u00e9tadonn\u00e9es contiennent des liens vers ces blocs. Lorsque nous obtenons un deuxi\u00e8me fichier .vbk, pr\u00eat \u00e0 \u00eatre d\u00e9plac\u00e9 et compos\u00e9 des blocs a, b et d, en analysant l'index de d\u00e9shydratation, nous comprenons que nous n'avons besoin de d\u00e9placer que le bloc d. Et son fichier de m\u00e9tadonn\u00e9es contiendra des liens vers les deux blocs pr\u00e9c\u00e9dents et un nouveau.<\/p>\n<p><img decoding=\"async\" alt=\"Qu&#039;est-ce qui a chang\u00e9 dans le Capacity Tier depuis que Veeam est devenu v10\" src=\"\/wp-content\/uploads\/2020\/06\/5c502030b8727ecd85c5229df1761c85.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPar cons\u00e9quent, le processus de remplissage inverse de ces vides avec des donn\u00e9es s'appelle r\u00e9g\u00e9n\u00e9ration. Ici, un index de r\u00e9g\u00e9n\u00e9ration est utilis\u00e9, bas\u00e9 sur le fichier .vbk le plus ancien de l'extent de performance local. Donc, si un utilisateur souhaite r\u00e9cup\u00e9rer un fichier du stockage de capacit\u00e9, nous cr\u00e9ons d'abord un index des blocs de la plus ancienne sauvegarde compl\u00e8te et transf\u00e9rons du stockage de capacit\u00e9 uniquement les blocs manquants. Dans l'exemple pr\u00e9sent\u00e9 sur l'image, pour r\u00e9g\u00e9n\u00e9rer FullBackup1.vbk selon l'index de r\u00e9g\u00e9n\u00e9ration, il ne nous manque que le bloc C, que nous r\u00e9cup\u00e9rons du stockage de capacit\u00e9. Si le stockage de capacit\u00e9 est un stockage d'objet cloud, cela permet d'\u00e9conomiser des sommes consid\u00e9rables.<\/p>\n<p>Il peut sembler que cette technologie soit identique \u00e0 celle utilis\u00e9e dans les acc\u00e9l\u00e9rateurs WAN, mais ce n'est qu'une apparence. Dans les acc\u00e9l\u00e9rateurs, la d\u00e9duplication est globale, tandis qu'ici, elle est locale dans chaque fichier \u00e0 un certain d\u00e9calage. Cela est d\u00fb \u00e0 la diff\u00e9rence des t\u00e2ches \u00e0 accomplir : ici, nous devons copier de grands fichiers de sauvegardes compl\u00e8tes, et selon nos recherches, m\u00eame si un long laps de temps s'\u00e9coule entre eux, cet algorithme de d\u00e9duplication donne les meilleurs r\u00e9sultats.<\/p>\n<p><img decoding=\"async\" alt=\"Qu&#039;est-ce qui a chang\u00e9 dans le Capacity Tier depuis que Veeam est devenu v10\" src=\"\/wp-content\/uploads\/2020\/06\/1db1a696e289187ae02bd84d9edd6f66.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMais trop d'index ne sont jamais trop ! Il existe encore un index pour la r\u00e9cup\u00e9ration des donn\u00e9es ! Lorsque nous lan\u00e7ons la restauration d'une machine se trouvant dans le stockage de capacit\u00e9, nous ne lirons que les blocs de donn\u00e9es uniques, qui ne se trouvent pas dans le stockage de performance.<\/p>\n<p><img decoding=\"async\" alt=\"Qu&#039;est-ce qui a chang\u00e9 dans le Capacity Tier depuis que Veeam est devenu v10\" src=\"\/wp-content\/uploads\/2020\/06\/257593c39e63bfb6f7e13d228bcebbae.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>Comme cela est devenu<\/h1>\n<p>\nC'est tout pour l'introduction. Elle est assez d\u00e9taill\u00e9e, mais comme mentionn\u00e9 pr\u00e9c\u00e9demment, sans ces d\u00e9tails, il n'est pas possible d'expliquer comment fonctionnent les nouvelles fonctionnalit\u00e9s. Donc, sans plus de pr\u00e9ambules, passons au premier.<\/p>\n<h3>Mode copie<\/h3>\n<p>\nIl est en grande partie bas\u00e9 sur des technologies existantes, mais il comporte une logique d'utilisation compl\u00e8tement diff\u00e9rente.\u00a0<\/p>\n<p>L'objectif de ce mode est de garantir que toutes les donn\u00e9es situ\u00e9es sur l'extent local ont une copie dans le stockage de capacit\u00e9.<\/p>\n<p>Si l'on compare directement les modes Move et Copy, il en ressort ceci :<\/p>\n<ul>\n<li>On ne peut d\u00e9placer qu'une cha\u00eene scell\u00e9e. Dans le cas du mode copie, tout est transf\u00e9r\u00e9, peu importe ce qui se passe dans le travail de sauvegarde.<\/li>\n<li>Le d\u00e9placement se d\u00e9clenche lorsque les fichiers sortent des limites de la fen\u00eatre de sauvegarde op\u00e9rationnelle, tandis que la copie se d\u00e9clenche d\u00e8s qu'un fichier de sauvegarde appara\u00eet.<\/li>\n<li>Le suivi des nouvelles donn\u00e9es \u00e0 copier se fait en continu, tandis que pour le d\u00e9placement, cela se produisait une fois toutes les 4 heures.<\/li>\n<\/ul>\n<p>\nDans l'examen du nouveau mode, je propose de passer des exemples simples aux plus complexes.<\/p>\n<p>Dans le cas le plus banal, nous avons simplement de nouveaux fichiers avec des incr\u00e9ments, et nous les copions simplement dans le stockage de capacit\u00e9. Peu importe quel mode est utilis\u00e9 dans le travail de sauvegarde, peu importe s'il appartient \u00e0 la partie scell\u00e9e de la cha\u00eene ou non, peu importe si notre fen\u00eatre op\u00e9rationnelle a expir\u00e9. Nous avons simplement pris et copi\u00e9.<\/p>\n<p>Le processus derri\u00e8re cela reste la d\u00e9shydratation telle que d\u00e9crite ci-dessus. En mode copie, il veille \u00e9galement \u00e0 ce que nous ne copions pas les blocs qui sont d\u00e9j\u00e0 pr\u00e9sents dans notre stockage. La seule diff\u00e9rence est que, dans le mode de d\u00e9placement, nous rempla\u00e7ons les fichiers r\u00e9els par des fichiers vides, tandis qu'ici, nous ne les touchons pas et laissons tout tel quel. Pour le reste, c'est exactement le m\u00eame indice de d\u00e9shydratation qui essaie soigneusement d'\u00e9conomiser votre argent et votre temps.<\/p>\n<p><img decoding=\"async\" alt=\"Qu&#039;est-ce qui a chang\u00e9 dans le Capacity Tier depuis que Veeam est devenu v10\" src=\"\/wp-content\/uploads\/2020\/06\/b3a033f4a0d0cbce8cecee152660c67c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa question se pose \u2014 si l'on regarde l'interface utilisateur, il est possible de choisir les deux options en m\u00eame temps. Comment un tel mode combin\u00e9 fonctionnera-t-il ?<\/p>\n<p><img decoding=\"async\" alt=\"Qu&#039;est-ce qui a chang\u00e9 dans le Capacity Tier depuis que Veeam est devenu v10\" src=\"\/wp-content\/uploads\/2020\/06\/12f658765a05e120dc5068920886edb5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVoyons cela de plus pr\u00e8s.<\/p>\n<p>Le d\u00e9but est standard : un fichier de sauvegarde est cr\u00e9\u00e9 et copi\u00e9 imm\u00e9diatement. Un incr\u00e9ment est cr\u00e9\u00e9 et est \u00e9galement copi\u00e9. Cela se produit jusqu'au moment o\u00f9 nous comprenons que les fichiers ont d\u00e9pass\u00e9 notre fen\u00eatre op\u00e9rationnelle et qu'une cha\u00eene scell\u00e9e est apparue. \u00c0 ce moment-l\u00e0, nous effectuons l'op\u00e9ration de d\u00e9shydratation et rempla\u00e7ons ces fichiers par des fichiers vides. Bien s\u00fbr, nous ne copions rien \u00e0 nouveau sur le niveau de capacit\u00e9.<\/p>\n<p>Tout cela est r\u00e9gi par une simple case \u00e0 cocher dans l'interface : Copy backups to object storage as soon as they are created.<\/p>\n<p><img decoding=\"async\" alt=\"Qu&#039;est-ce qui a chang\u00e9 dans le Capacity Tier depuis que Veeam est devenu v10\" src=\"\/wp-content\/uploads\/2020\/06\/1a0e27c04428ebd48b13d8927a453d62.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Mais \u00e0 quoi sert ce mode Copy ? <\/h3>\n<p>\nIl serait m\u00eame pr\u00e9f\u00e9rable de reformuler la question ainsi : de quels risques nous prot\u00e9geons-nous avec son aide ? Quel probl\u00e8me nous aide-t-il \u00e0 r\u00e9soudre ?<\/p>\n<p>La r\u00e9ponse est \u00e9vidente : c'est bien s\u00fbr la r\u00e9cup\u00e9ration des donn\u00e9es. Si nous avons une copie compl\u00e8te des donn\u00e9es locales dans l'objet de stockage, peu importe ce qui arrive \u00e0 notre production, nous pouvons toujours r\u00e9cup\u00e9rer les donn\u00e9es \u00e0 partir des fichiers situ\u00e9s dans un certain Amazon.<\/p>\n<p>Examinons donc les sc\u00e9narios possibles, du plus simple au plus complexe.<\/p>\n<p>Le malheur le plus simple qui peut frapper nos t\u00eates est l'inaccessibilit\u00e9 d'un des fichiers dans la cha\u00eene de sauvegarde.<\/p>\n<p>Une histoire plus triste \u2014 un de nos extents de notre d\u00e9p\u00f4t SOBR est tomb\u00e9 en panne.<\/p>\n<p>Il devient encore pire lorsque tout le d\u00e9p\u00f4t SOBR devient inaccessible, mais le niveau de capacit\u00e9 fonctionne.<br \/>\nEt tout va encore plus mal \u2014 lorsque le serveur de sauvegarde est mort et que votre premier d\u00e9sir est d'essayer de courir jusqu'\u00e0 la fronti\u00e8re canadienne en dix minutes.<\/p>\n<p><img decoding=\"async\" alt=\"Qu&#039;est-ce qui a chang\u00e9 dans le Capacity Tier depuis que Veeam est devenu v10\" src=\"\/wp-content\/uploads\/2020\/06\/868d71412901ed362956e1e2157ed895.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMaintenant, examinons chaque situation s\u00e9par\u00e9ment.<\/p>\n<p>Lorsque nous perdons un (et m\u00eame plusieurs) fichiers de sauvegarde, il suffit de lancer le processus de rescannage du r\u00e9f\u00e9rentiel, et le fichier perdu sera remplac\u00e9 par un fichier vide. Gr\u00e2ce au processus de r\u00e9g\u00e9n\u00e9ration (d\u00e9crit au d\u00e9but de l'article), l'utilisateur pourra t\u00e9l\u00e9charger les donn\u00e9es du tir de capacit\u00e9 vers le stockage local.<\/p>\n<p><img decoding=\"async\" alt=\"Qu&#039;est-ce qui a chang\u00e9 dans le Capacity Tier depuis que Veeam est devenu v10\" src=\"\/wp-content\/uploads\/2020\/06\/5066a21cbd17565569891f8e23cac4fd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMaintenant, la situation est plus complexe. Supposons que notre SOBR soit constitu\u00e9 de deux \u00e9tendues fonctionnant en mode Performance, ce qui signifie que nos fichiers .vbk et .vib sont r\u00e9partis de mani\u00e8re in\u00e9gale entre eux. \u00c0 un moment donn\u00e9, l'une des \u00e9tendues devient indisponible, et l'utilisateur doit rapidement restaurer une machine dont une partie des donn\u00e9es se trouve pr\u00e9cis\u00e9ment sur cette \u00e9tendue. <\/p>\n<p>L'utilisateur lance l'assistant de r\u00e9cup\u00e9ration, s\u00e9lectionne le point vers lequel il souhaite restaurer, et au cours du processus, l'assistant r\u00e9alise qu'il n'a pas toutes les donn\u00e9es n\u00e9cessaires \u00e0 la r\u00e9cup\u00e9ration localement, et donc il doit les t\u00e9l\u00e9charger depuis le tir de capacit\u00e9. Les blocs qui sont rest\u00e9s dans le stockage local ne seront pas t\u00e9l\u00e9charg\u00e9s depuis le cloud. Gr\u00e2ce \u00e0 l'index de restauration (oui, cela a \u00e9galement \u00e9t\u00e9 mentionn\u00e9 au d\u00e9but de l'article).<\/p>\n<p><img decoding=\"async\" alt=\"Qu&#039;est-ce qui a chang\u00e9 dans le Capacity Tier depuis que Veeam est devenu v10\" src=\"\/wp-content\/uploads\/2020\/06\/88b38ddf122d20a3e41a0afcba544749.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUne variante de ce cas est que l'ensemble du r\u00e9f\u00e9rentiel SOBR est devenu indisponible. Dans ce cas, nous n'avons rien \u00e0 copier depuis les stockages locaux, et tous les blocs sont t\u00e9l\u00e9charg\u00e9s depuis le cloud.<\/p>\n<p>La situation la plus int\u00e9ressante est que le serveur de sauvegarde est tomb\u00e9 en panne. Il y a deux options : l'administrateur a bien fait son travail et a effectu\u00e9 des sauvegardes de configuration, ou l'administrateur est son propre ennemi et n'a pas effectu\u00e9 de sauvegarde de configuration.<\/p>\n<p>Dans le premier cas, il lui suffira de d\u00e9ployer une installation propre de VBR quelque part et de restaurer sa base \u00e0 partir d'une sauvegarde avec les outils standards. \u00c0 la fin de ce processus, tout reviendra \u00e0 la normale. Sinon, il sera restaur\u00e9 selon l'un des sc\u00e9narios ci-dessus.<\/p>\n<p>Mais si l'administrateur est son propre ennemi, ou si une malchance mythique a \u00e9galement frapp\u00e9 la sauvegarde de la configuration, m\u00eame ici nous ne le laisserons pas \u00e0 son sort. Pour ce cas, nous avons introduit une nouvelle proc\u00e9dure appel\u00e9e Import Object Storage. Elle permet de sauter le processus de recr\u00e9ation manuelle du r\u00e9f\u00e9rentiel SOBR et de son attachement \u00e0 la capacit\u00e9, suivi d'un rescannage, et d'ajouter simplement le stockage d'objets dans l'interface de Vima et de lancer la proc\u00e9dure Import Storage Repository. La seule chose qui peut se dresser entre vous et vos sauvegardes, c'est une demande de saisie de mot de passe si vos sauvegardes ont \u00e9t\u00e9 crypt\u00e9es.<\/p>\n<p>C'est tout pour le mode Copy, et nous passons \u00e0<\/p>\n<h3>Sealed Mode<\/h3>\n<p>\nLe concept principal est que de nouvelles sauvegardes ne peuvent pas appara\u00eetre sur l'extent s\u00e9lectionn\u00e9 du r\u00e9f\u00e9rentiel SOBR. Avant la version 10, nous avions seulement le mode Maintenance, qui interdisait compl\u00e8tement toute op\u00e9ration sur le r\u00e9f\u00e9rentiel. Un mode hardcore de mise hors service de stockage, o\u00f9 seul le bouton Evacuate \u00e9tait disponible, transf\u00e9rant les sauvegardes vers un autre extent.<\/p>\n<p>Le mode Sealed est une sorte de version \"douce\" : nous interdisons la cr\u00e9ation de nouvelles sauvegardes et supprimons progressivement les anciennes selon la r\u00e9tention choisie, mais tout en conservant la possibilit\u00e9 de restaurer \u00e0 partir des points stock\u00e9s. C'est tr\u00e8s utile, notamment lorsque la dur\u00e9e de vie de la machine est sur le point de se terminer et qu'elle doit \u00eatre remplac\u00e9e, ou qu'il faut simplement lib\u00e9rer de l'espace pour quelque chose de plus important, sans avoir \u00e0 tout transf\u00e9rer en une seule fois. Ou il n'est pas possible de supprimer. <\/p>\n<p>Ainsi, le principe de fonctionnement est assez simple : il faut interdire toutes les op\u00e9rations d'\u00e9criture (l'apparition de nouvelles donn\u00e9es), tout en laissant les op\u00e9rations de lecture (restaurations) et de suppression (r\u00e9tention).<\/p>\n<p>Les deux modes peuvent \u00eatre utilis\u00e9s simultan\u00e9ment, mais il faut tenir compte du fait que le mode Maintenance a une priorit\u00e9 plus \u00e9lev\u00e9e.<\/p>\n<p>Prenons l'exemple d'un SOBR compos\u00e9 de deux extents. Supposons que pendant les quatre premiers jours, nous avons cr\u00e9\u00e9 des sauvegardes en mode Forward Forever Incremental, puis nous scellons l'extent. Cela entra\u00eene la cr\u00e9ation d'un nouveau full active sur le deuxi\u00e8me extent disponible. Si notre r\u00e9tention est de quatre, alors lorsque toute la cha\u00eene situ\u00e9e sur l'extent scell\u00e9 d\u00e9passe cette limite, elle est supprim\u00e9e en toute qui\u00e9tude.<\/p>\n<p><img decoding=\"async\" alt=\"Qu&#039;est-ce qui a chang\u00e9 dans le Capacity Tier depuis que Veeam est devenu v10\" src=\"\/wp-content\/uploads\/2020\/06\/5476ebcf9b57eeb6c0326499ac42763f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl existe des situations o\u00f9 la suppression se produit plus t\u00f4t. Par exemple, dans le cas d'une sauvegarde incr\u00e9mentielle forward avec des sauvegardes compl\u00e8tes p\u00e9riodiques. Si nous avons cr\u00e9\u00e9 des sauvegardes compl\u00e8tes pendant les deux premiers jours, et que jeudi nous d\u00e9cidons de sceller le d\u00e9p\u00f4t, alors vendredi, lorsque la nouvelle sauvegarde compl\u00e8te sera cr\u00e9\u00e9e, le fichier du lundi sera supprim\u00e9, car \u00e0 ce point, il n'y a pas de d\u00e9pendances. Et ce point ne d\u00e9pend de personne. Ensuite, nous attendons que quatre points soient cr\u00e9\u00e9s sur l'extent disponible et nous supprimons les trois restants, qui ne peuvent pas \u00eatre supprim\u00e9s ind\u00e9pendamment les uns des autres.<\/p>\n<p><img decoding=\"async\" alt=\"Qu&#039;est-ce qui a chang\u00e9 dans le Capacity Tier depuis que Veeam est devenu v10\" src=\"\/wp-content\/uploads\/2020\/06\/c6cc452f98336803731163dfd794f828.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLes choses sont plus simples avec l'incr\u00e9mentiel reverse. Dans ce cas, les points les plus anciens ne d\u00e9pendent de rien et peuvent \u00eatre supprim\u00e9s sans probl\u00e8me. Par cons\u00e9quent, d\u00e8s qu'un nouveau .vbk est cr\u00e9\u00e9 sur un nouvel extent, les anciens .vrb seront supprim\u00e9s un par un.<\/p>\n<p>D'ailleurs, pourquoi cr\u00e9ons-nous \u00e0 chaque fois un nouveau .vbk : si nous ne le cr\u00e9ons pas et continuons la cha\u00eene d'incr\u00e9ments pr\u00e9c\u00e9dente, l'ancien .vbk resterait bloqu\u00e9 ind\u00e9finiment quel que soit le mode, emp\u00eachant sa suppression. Il a donc \u00e9t\u00e9 d\u00e9cid\u00e9 que d\u00e8s qu'un extent est scell\u00e9, nous cr\u00e9ons une sauvegarde compl\u00e8te sur un extent libre.<\/p>\n<p><img decoding=\"async\" alt=\"Qu&#039;est-ce qui a chang\u00e9 dans le Capacity Tier depuis que Veeam est devenu v10\" src=\"\/wp-content\/uploads\/2020\/06\/3757fae46ad76d64cdddfb941309d557.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLes choses sont plus difficiles avec le niveau de capacit\u00e9. <\/p>\n<p>Commen\u00e7ons par le mode de copie. Supposons que nous avons cr\u00e9\u00e9 activement des sauvegardes pendant quatre jours, puis que le niveau de capacit\u00e9 a \u00e9t\u00e9 scell\u00e9. Nous ne supprimons rien, mais subissons la r\u00e9tention, apr\u00e8s quoi nous supprimons les donn\u00e9es du niveau de capacit\u00e9.<\/p>\n<p>En gros, la m\u00eame chose se passe en mode de d\u00e9placement : nous attendons la r\u00e9tention, supprimons les anciennes donn\u00e9es dans le stockage local, supprimons celles qui sont dans le stockage d'objets.<\/p>\n<p><img decoding=\"async\" alt=\"Qu&#039;est-ce qui a chang\u00e9 dans le Capacity Tier depuis que Veeam est devenu v10\" src=\"\/wp-content\/uploads\/2020\/06\/391d3b231c7de5da1d13e19c31bd6b7c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUn exemple int\u00e9ressant avec l'incr\u00e9mentiel forward \u00e9ternel. Nous d\u00e9finissons la r\u00e9tention \u00e0 trois points et commen\u00e7ons \u00e0 faire des sauvegardes depuis lundi, qui sont correctement copi\u00e9es dans le cloud. Apr\u00e8s le scellement du stockage, les sauvegardes continuent \u00e0 \u00eatre cr\u00e9\u00e9es, en maintenant trois points, mais les donn\u00e9es stock\u00e9es dans le niveau de capacit\u00e9 restent d\u00e9pendantes et ne peuvent pas \u00eatre supprim\u00e9es. Par cons\u00e9quent, nous attendons jeudi, lorsque notre .vbk d\u00e9passe la r\u00e9tention, et seulement alors nous supprimons tranquillement toute la cha\u00eene sauvegard\u00e9e.<\/p>\n<p><img decoding=\"async\" alt=\"Qu&#039;est-ce qui a chang\u00e9 dans le Capacity Tier depuis que Veeam est devenu v10\" src=\"\/wp-content\/uploads\/2020\/06\/617a42452060210b58148e1fe942a540.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEt une petite remarque : tous les exemples ici sont pr\u00e9sent\u00e9s avec une seule machine. Si vous en avez plusieurs dans la sauvegarde, la r\u00e9tention sera diff\u00e9rente selon que vous avez fait un Active Full ou non.<\/p>\n<p>C'est en gros tout. Passons donc \u00e0 la fonctionnalit\u00e9 la plus hardcore \u2014 <\/p>\n<h3>Immutabilit\u00e9 <\/h3>\n<p>\nComme pour les points pr\u00e9c\u00e9dents, commen\u00e7ons par le probl\u00e8me que cette fonction r\u00e9sout. D\u00e8s que nous sauvegardons nos sauvegardes ailleurs pour les stocker, il y a un besoin pressant de garantir leur s\u00e9curit\u00e9, c'est-\u00e0-dire d'interdire physiquement leur suppression et toute modification pendant la dur\u00e9e de r\u00e9tention sp\u00e9cifi\u00e9e. Cela inclut les administrateurs, m\u00eame sous leurs comptes root. Cela permet de les prot\u00e9ger contre la corruption accidentelle ou d\u00e9lib\u00e9r\u00e9e. Ceux qui travaillent avec AWS ont pu rencontrer une fonction similaire appel\u00e9e Object Lock.<\/p>\n<p>Examinons maintenant le mode en termes g\u00e9n\u00e9raux, puis approfondissons les d\u00e9tails. Dans notre exemple, l'Immutabilit\u00e9 sera activ\u00e9e pour notre capacit\u00e9 de stockage avec une r\u00e9tention de quatre jours. Et dans la sauvegarde, le mode Copy est activ\u00e9.<\/p>\n<p>L'Immutabilit\u00e9 n'interf\u00e8re en rien avec la r\u00e9tention g\u00e9n\u00e9rale. Par exemple, elle n'ajoute pas de points suppl\u00e9mentaires ou autre chose de ce genre. Pendant quatre jours, une personne ne peut pas supprimer les fichiers de sauvegarde. Si une sauvegarde est effectu\u00e9e le lundi, le fichier ne pourra \u00eatre supprim\u00e9 que le vendredi.<\/p>\n<p><img decoding=\"async\" alt=\"Qu&#039;est-ce qui a chang\u00e9 dans le Capacity Tier depuis que Veeam est devenu v10\" src=\"\/wp-content\/uploads\/2020\/06\/131e50058c1a015ec78089ed4d038bfc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTous les concepts de d\u00e9shydratation, d'index et de m\u00e9tadonn\u00e9es pr\u00e9c\u00e9demment expliqu\u00e9s continuent \u00e0 fonctionner de la m\u00eame mani\u00e8re. Mais avec une condition \u2014 le verrou est appliqu\u00e9 non seulement aux donn\u00e9es, mais \u00e9galement aux m\u00e9tadonn\u00e9es. Cela a \u00e9t\u00e9 fait au cas o\u00f9 un malfaiteur rus\u00e9 d\u00e9ciderait de supprimer notre base de m\u00e9tadonn\u00e9es et pour que les blocs de donn\u00e9es ne se transforment pas en une bouillie binaire inutile.<\/p>\n<p><img decoding=\"async\" alt=\"Qu&#039;est-ce qui a chang\u00e9 dans le Capacity Tier depuis que Veeam est devenu v10\" src=\"\/wp-content\/uploads\/2020\/06\/edfe5c04a082594cf5d67f4bafeccb3a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEt maintenant, c'est le moment id\u00e9al pour expliquer notre technologie de g\u00e9n\u00e9ration de blocs. Ou block generation. Pour cela, consid\u00e9rons la situation qui a conduit \u00e0 son apparition.<\/p>\n<p>Prenons une chronologie de six jours et marquons en bas le temps d'expiration attendu de l'immutabilit\u00e9. Nous commen\u00e7ons par cr\u00e9er le premier jour un fichier, compos\u00e9 d'un bloc de donn\u00e9es a et de ses m\u00e9tadonn\u00e9es. Si l'immutabilit\u00e9 est fix\u00e9e \u00e0 trois jours, il est logique de supposer qu'au quatri\u00e8me jour, les donn\u00e9es seront d\u00e9verrouill\u00e9es et supprim\u00e9es. Le deuxi\u00e8me jour, nous ajouterons un nouveau file2, compos\u00e9 d'un bloc b avec les m\u00eames param\u00e8tres. Le bloc a devrait toujours \u00eatre supprim\u00e9 le quatri\u00e8me jour. Mais au troisi\u00e8me jour, quelque chose de terrible se produit : un fichier File3 est cr\u00e9\u00e9, compos\u00e9 d'un nouveau bloc d et d'un lien vers l'ancien bloc a. Cela signifie que pour le bloc a, son drapeau d'immutabilit\u00e9 doit \u00eatre r\u00e9ajust\u00e9 \u00e0 une nouvelle dur\u00e9e, qui est d\u00e9cal\u00e9e au sixi\u00e8me jour. Et ici se pose un probl\u00e8me : dans les sauvegardes r\u00e9elles de tels blocs, un nombre \u00e9norme de ces derniers se cr\u00e9e. Et pour prolonger leur p\u00e9riode d'immutabilit\u00e9, il faut chaque fois effectuer un nombre \u00e9norme de requ\u00eates. Et en fait, cela sera un processus presque infini quotidien, car avec une forte probabilit\u00e9, \u00e0 chaque copie, nous trouverons d'\u00e9normes paquets de blocs d\u00e9dupliqu\u00e9s. Et que signifie un grand nombre de requ\u00eates pour les fournisseurs de stockage d'objets ? Correct ! Une facture \u00e9norme \u00e0 la fin du mois.<\/p>\n<p><img decoding=\"async\" alt=\"Qu&#039;est-ce qui a chang\u00e9 dans le Capacity Tier depuis que Veeam est devenu v10\" src=\"\/wp-content\/uploads\/2020\/06\/ce9c5d0da67f99019b00c4a666302fee.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEt pour ne pas faire payer une somme consid\u00e9rable \u00e0 ses clients ador\u00e9s pour un rien, un m\u00e9canisme de g\u00e9n\u00e9ration de blocs a \u00e9t\u00e9 con\u00e7u. C'est une p\u00e9riode additionnelle que nous ajoutons \u00e0 la p\u00e9riode d'immutabilit\u00e9 fix\u00e9e. Dans l'exemple ci-dessous, cette p\u00e9riode \u00e9quivaut \u00e0 deux jours. Mais cela n'est qu'un exemple. En r\u00e9alit\u00e9, une formule propre est utilis\u00e9e, donnant environ dix jours suppl\u00e9mentaires lors d'un verrouillage mensuel. <\/p>\n<p>Nous allons continuer \u00e0 examiner la m\u00eame situation, mais avec la g\u00e9n\u00e9ration de blocs. Nous cr\u00e9ons, le premier jour, file1 \u00e0 partir du bloc a et des m\u00e9tadonn\u00e9es. Nous accumulons la p\u00e9riode de g\u00e9n\u00e9ration et l'immuabilit\u00e9 \u2014 ce qui signifie que la possibilit\u00e9 de supprimer le fichier sera au sixi\u00e8me jour. Si, le deuxi\u00e8me jour, nous cr\u00e9ons File2, compos\u00e9 du bloc b et d'un lien vers le bloc a, alors la date pr\u00e9vue de suppression reste inchang\u00e9e. Elle est toujours fix\u00e9e au sixi\u00e8me jour. En agissant ainsi, nous essayons d'\u00e9conomiser de l'argent sur le nombre de requ\u00eates. La seule situation o\u00f9 la date peut \u00eatre d\u00e9plac\u00e9e, c'est si la p\u00e9riode de g\u00e9n\u00e9ration est \u00e9coul\u00e9e. Autrement dit, si le troisi\u00e8me jour, le nouveau File3 contient un lien vers le bloc a, la g\u00e9n\u00e9ration 2 sera ajout\u00e9e car Gen1 est d\u00e9j\u00e0 \u00e9coul\u00e9e. La date pr\u00e9vue de suppression du bloc a sera alors d\u00e9cal\u00e9e au huiti\u00e8me jour. Cela nous permet de r\u00e9duire de mani\u00e8re significative le nombre de requ\u00eates pour prolonger la dur\u00e9e de vie des blocs d\u00e9dupliqu\u00e9s, ce qui fait \u00e9conomiser beaucoup d'argent aux clients.<\/p>\n<p><img decoding=\"async\" alt=\"Qu&#039;est-ce qui a chang\u00e9 dans le Capacity Tier depuis que Veeam est devenu v10\" src=\"\/wp-content\/uploads\/2020\/06\/2056d0c15e4e7fcdd67a56b11f973119.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa technologie elle-m\u00eame est accessible aux utilisateurs S3 et \u00e0 tout mat\u00e9riel compatible S3, dont les fabricants garantissent que leur mise en \u0153uvre ne diff\u00e8re pas de celle d'Amazon. D'o\u00f9 la r\u00e9ponse \u00e0 la question l\u00e9gitime de pourquoi Azure n'est pas pris en charge \u2014 ils ont une fonctionnalit\u00e9 similaire, mais elle fonctionne au niveau des conteneurs, et non des objets individuels. \u00c0 propos, chez Amazon, l'object lock existe en deux modes : compliance et governance. Dans le deuxi\u00e8me cas, il reste possible que le plus grand administrateur des administrateurs et le root des roots, malgr\u00e9 l'object lock, supprime tout de m\u00eame des donn\u00e9es. En mode compliance, tout est solidement fix\u00e9 et personne ne peut supprimer les sauvegardes. M\u00eame pas les administrateurs d'Amazon (selon leurs d\u00e9clarations officielles). Nous soutenons pr\u00e9cis\u00e9ment ce mode.<\/p>\n<p>\nEt, traditionnellement, quelques liens utiles :<\/p>\n<ul>\n<li>\u00c0 propos de <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/block_generation.html?ver=100\">G\u00e9n\u00e9ration de Blocs<\/a><\/noindex> en tous d\u00e9tails.<\/li>\n<li>Toutes les informations sur <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/overview.html?ver=100\">Veeam Backup &amp; Replication 10<\/a><\/noindex> de la meilleure mani\u00e8re<\/li>\n<li>O <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/capacity_tier.html?ver=100\">Capacity Tier<\/a><\/noindex> en d\u00e9tails<\/li>\n<\/ul>\n<p>Source : <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/veeam\/blog\/505818\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>Capacity Tier (\u0438\u043b\u0438 \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0435\u0433\u043e \u0443 \u0441\u0435\u0431\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u043c\u0430 \u2014 \u043a\u0430\u043f\u0442\u0438\u0440) \u043f\u043e\u044f\u0432\u0438\u043b\u0441\u044f \u0435\u0449\u0451 \u0432\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0430 Veeam Backup and Replication 9.5 Update 4 \u043f\u043e\u0434 \u0438\u043c\u0435\u043d\u0435\u043c Archive Tier. \u0417\u0430\u043b\u043e\u0436\u0435\u043d\u043d\u0430\u044f \u0432 \u043d\u0435\u0433\u043e \u0438\u0434\u0435\u044f \u2014 \u044d\u0442\u043e \u0434\u0430\u0442\u044c \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u043f\u0435\u0440\u0435\u043c\u0435\u0449\u0430\u0442\u044c \u0431\u0435\u043a\u0430\u043f\u044b, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0432\u044b\u043f\u0430\u043b\u0438 \u0438\u0437 \u0442\u0430\u043a \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c\u043e\u0433\u043e operational restore window, \u043d\u0430 \u043e\u0431\u044a\u0435\u043a\u0442\u043d\u044b\u0435 \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430. \u042d\u0442\u043e \u043f\u043e\u043c\u043e\u0433\u0430\u043b\u043e \u0440\u0430\u0441\u0447\u0438\u0449\u0430\u0442\u044c \u0434\u0438\u0441\u043a\u043e\u0432\u043e\u0435 \u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0441\u0442\u0432\u043e \u0442\u0435\u043c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84810,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84809","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"Capacity Tier (\u0438\u043b\u0438 \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0435\u0433\u043e \u0443 \u0441\u0435\u0431\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u043c\u0430 \u2014 \u043a\u0430\u043f\u0442\u0438\u0440) \u043f\u043e\u044f\u0432\u0438\u043b\u0441\u044f \u0435\u0449\u0451 \u0432\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0430 Veeam Backup and Replication 9.5 Update 4 \u043f\u043e\u0434 \u0438\u043c\u0435\u043d\u0435\u043c Archive Tier.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"fr_FR\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0427\u0442\u043e \u0438\u0437\u043c\u0435\u043d\u0438\u043b\u043e\u0441\u044c \u0432 Capacity Tier, \u043a\u043e\u0433\u0434\u0430 Veeam \u0441\u0442\u0430\u043b v10 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"Capacity Tier (\u0438\u043b\u0438 \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0435\u0433\u043e \u0443 \u0441\u0435\u0431\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u043c\u0430 \u2014 \u043a\u0430\u043f\u0442\u0438\u0440) \u043f\u043e\u044f\u0432\u0438\u043b\u0441\u044f \u0435\u0449\u0451 \u0432\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0430 Veeam Backup and Replication 9.5 Update 4 \u043f\u043e\u0434 \u0438\u043c\u0435\u043d\u0435\u043c Archive Tier.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-06-10T23:42:41+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-06-10T23:42:41+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47 Qu'est-ce qui a chang\u00e9 dans le Capacity Tier lorsque Veeam est pass\u00e9 \u00e0 v10 | ProHoster","description":"Le Capacity Tier (ou comme nous l'appelons en interne chez Veeam \u2014 captier) a \u00e9t\u00e9 introduit d\u00e9j\u00e0 \u00e0 l'\u00e9poque de Veeam Backup and Replication 9.5 Update 4 sous le nom d'Archive Tier.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0427\u0442\u043e \u0438\u0437\u043c\u0435\u043d\u0438\u043b\u043e\u0441\u044c \u0432 Capacity Tier, \u043a\u043e\u0433\u0434\u0430 Veeam \u0441\u0442\u0430\u043b v10 | ProHoster","og:description":"Capacity Tier (\u0438\u043b\u0438 \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0435\u0433\u043e \u0443 \u0441\u0435\u0431\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u043c\u0430 \u2014 \u043a\u0430\u043f\u0442\u0438\u0440) \u043f\u043e\u044f\u0432\u0438\u043b\u0441\u044f \u0435\u0449\u0451 \u0432\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0430 Veeam Backup and Replication 9.5 Update 4 \u043f\u043e\u0434 \u0438\u043c\u0435\u043d\u0435\u043c Archive Tier.","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-06-10T23:42:41+00:00","article:modified_time":"2020-06-10T23:42:41+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"84809","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 14:49:54","updated":"2022-09-29 08:38:47","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/84809","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=84809"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/84809\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/84810"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=84809"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=84809"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=84809"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}