{"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\/de\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","title":{"rendered":"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam zu v10 wurde","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Das Capacity Tier (oder wie wir es intern nennen \u2013 KapTier) wurde bereits zur Zeit von Veeam Backup and Replication 9.5 Update 4 unter dem Namen Archive Tier eingef\u00fchrt. Die zugrunde liegende Idee ist es, die M\u00f6glichkeit zu schaffen, Backups, die das sogenannte operational restore window \u00fcberschreiten, in Objektspeicher zu verschieben. Dies half Benutzern, die \u00fcber wenig Speicherplatz verf\u00fcgten, Speicherplatz freizugeben. Diese Option wurde Move Mode genannt.<\/p>\n<p>Um diese recht einfache (wie es scheint) Aktion durchzuf\u00fchren, mussten zwei Bedingungen erf\u00fcllt sein: Alle Punkte des verschobenen Backups m\u00fcssen au\u00dferhalb des oben genannten operational restore window liegen, das im UI explizit festgelegt wird. Und zweitens: Die Kette muss in einem sogenannten \"versiegelten Zustand\" (sealed backup chain oder Inactive Backup Chain) sein. Das bedeutet, dass sich im Laufe der Zeit in dieser Kette keine \u00c4nderungen ergeben.<\/p>\n<p>In VBR v10 wurde das Konzept jedoch um neue Funktionen erg\u00e4nzt \u2014 Copy Mode, Sealed Mode und eine Sache mit dem kompliziert auszusprechenden Namen Immutability wurden eingef\u00fchrt.<\/p>\n<p>Dar\u00fcber werden wir heute sprechen. Zuerst dar\u00fcber, wie das in VBR9.5u4 funktionierte, und dann \u00fcber die \u00c4nderungen in der zehnten Version.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam zu v10 wurde\" src=\"\/wp-content\/uploads\/2020\/06\/954adcc5592fe2a7ea64ec24b06ecc91.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUnd m\u00f6gen mir die Verfechter einer reinen Sprache verzeihen, aber zu viele Begriffe lassen sich nicht \u00fcbersetzen.<br \/>\nDeshalb wird es hier eine Menge Anglizismen geben.<br \/>\nUnd viele GIFs. <br \/>\nUnd Bilder.<\/p>\n<ul>\n<li>Ohne jede Reue. Der Autor des Artikels.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1>Wie zuvor<\/h1>\n<p>\nNun, lassen Sie uns mit der Analyse des operational restore window und der sealed backup (oder wie sie in der Dokumentation hei\u00dfen: Inactive Backup Chain) beginnen. Ohne das Verst\u00e4ndnis dieser Konzepte kann die weitere Erkl\u00e4rung nicht erfolgen.<\/p>\n<p>Wie wir im Bild sehen, haben wir eine Backup-Kette mit Datenbl\u00f6cken, die sich im Performance tier eines SOBR-Repositories befindet, zu dem das Capacity Tier angeschlossen ist. Unser operatives Backup-Fenster betr\u00e4gt drei Tage.<\/p>\n<p>Daher versiegelt das am Montag erstellte .vbk die vorherige Kette, deren Fenster auf drei Tage eingestellt ist. Und somit kann alles, was \u00e4lter als diese drei Tage ist, problemlos ins Capacity Tier verschoben werden.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam zu v10 wurde\" src=\"\/wp-content\/uploads\/2020\/06\/430f31d181bb79c2bd6001011511e3f9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWas genau wurde jedoch unter einer versiegelten Kette verstanden und was konnte in Update 4 ins Capacity Tier verschoben werden?<\/p>\n<p>F\u00fcr Forward Incremental ist das Merkmal der Versiegelung einer Kette die Erstellung eines neuen Full Backups. Dabei spielt es keine Rolle, wie dieses Full Backup erstellt wird: sowohl synthetic full als auch active full Backups z\u00e4hlen.<\/p>\n<p>Im Falle von Reverse sind es alle Dateien, die nicht im operativen Fenster liegen. <\/p>\n<p>Im Falle von Forward-Inkrementen mit Rollbacks handelt es sich um alle Rollbacks und .vbk, wenn sich auf dem Performance-Extent ein weiteres .vbk befindet.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam zu v10 wurde\" src=\"\/wp-content\/uploads\/2020\/06\/4cb6f168862acabadbdab771cc48fe7f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBetrachten wir nun die Arbeitsweise mit Backup Copy-Ketten. Hier wurde nur das abgegeben, was unter die GFS-Aufbewahrung f\u00e4llt. Denn alles, was in neueren Backup Copy-Ketten gespeichert ist, kann auf die eine oder andere Weise ge\u00e4ndert werden.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam zu v10 wurde\" src=\"\/wp-content\/uploads\/2020\/06\/4c263058110b7c502501f01940977f1a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLassen Sie uns nun unter die Haube schauen. Dort findet ein Prozess statt, der Dehydratisierung genannt wird \u2013 das Beibehalten leerer Backup-Dateien auf dem Extent und das Verschieben von Bl\u00f6cken aus diesen Dateien in das Capacity Tier. Zur Optimierung dieses Prozesses wird der sogenannte Dehydratisierungsindex verwendet, der es erm\u00f6glicht, Bl\u00f6cke, die bereits in das Capacity Tier kopiert wurden, nicht nochmals zu kopieren. <\/p>\n<p>Betrachten wir, wie dies am Beispiel aussieht: Angenommen, wir haben eine .vbk, die aus dem Betriebszeitfenster herausgefallen ist und zu einer versiegelten Kette geh\u00f6rt. Das bedeutet, wir haben das volle Recht, sie in das Capacity Tier zu verschieben. Im Moment des Umzugs wird eine Metadaten-Datei im Capacity Tier erstellt sowie die Bl\u00f6cke der verschobenen Datei. In der Metadaten-Datei werden auf der Verlinkungsebene beschrieben, aus welchen Bl\u00f6cken unsere Datei besteht. Im Bild besteht unsere erste Datei aus den Bl\u00f6cken a, b, c, und in den Metadaten befinden sich Links zu diesen Bl\u00f6cken. Wenn wir eine zweite .vbk-Datei haben, die bereit ist, umgezogen zu werden und aus den Bl\u00f6cken a, b und d besteht, erkennen wir durch die Analyse des Dehydratisierungsindex, dass nur der Block d verschoben werden muss. Und ihre Metadaten-Datei wird Links zu den beiden vorherigen Bl\u00f6cken und einem neuen enthalten.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam zu v10 wurde\" src=\"\/wp-content\/uploads\/2020\/06\/5c502030b8727ecd85c5229df1761c85.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDementsprechend wird der Prozess des R\u00fcckf\u00fcllens dieser Leerbl\u00f6cke mit Daten Reghydratisierung genannt. Hierbei wird bereits der eigene Reghydratisierungsindex verwendet, der sich auf die \u00e4lteste .vbk-Datei auf dem lokalen Performance-Extent st\u00fctzt. Das bedeutet, wenn der Benutzer eine Datei aus dem Capacity Tier zur\u00fcckholen m\u00f6chte, erstellen wir zun\u00e4chst den Blockindex des \u00e4ltesten vollst\u00e4ndigen Backups und \u00fcbertragen nur die fehlenden Bl\u00f6cke aus dem Capacity Tier. Im dargestellten Beispiel fehlt uns f\u00fcr die Reghydratisierung von FullBackup1.vbk gem\u00e4\u00df dem Reghydratisierungsindex nur der Block C, den wir aus dem Capacity Tier holen. Wenn das Capacity Tier objektbasierter Cloud-Speicher ist, erm\u00f6glicht dies enorme Einsparungen.<\/p>\n<p>Hier mag es scheinen, als w\u00e4re diese Technologie identisch mit der in WAN-Beschleunigern verwendeten, aber das ist nur ein Schein. In den Beschleunigern erfolgt die globale Deduplikation, hier hingegen wird lokale Deduplikation innerhalb jeder Datei nach einem bestimmten Offset verwendet. Dies geschieht aufgrund der unterschiedlichen zu l\u00f6senden Aufgaben: Hier m\u00fcssen wir gro\u00dfe Dateien aus vollst\u00e4ndigen Backups kopieren, und nach unseren Untersuchungen liefert ein solcher Deduplikationsalgorithmus selbst dann bessere Ergebnisse, wenn zwischen ihnen ein gro\u00dfer Zeitraum verstrichen ist.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam zu v10 wurde\" src=\"\/wp-content\/uploads\/2020\/06\/1db1a696e289187ae02bd84d9edd6f66.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAber mehr Indizes dem Gott der Indizes! Es gibt auch einen Index zur Datenwiederherstellung! Wenn wir die Wiederherstellung einer Maschine im Capacity-Tier starten, lesen wir nur die einzigartigen Datenbl\u00f6cke, die im Performance-Tier nicht vorhanden sind.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam zu v10 wurde\" src=\"\/wp-content\/uploads\/2020\/06\/257593c39e63bfb6f7e13d228bcebbae.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>Wie es geworden ist<\/h1>\n<p>\nDamit sind wir am Ende des einf\u00fchrenden Teils. Dieser ist recht detailliert, wie bereits erw\u00e4hnt, aber ohne diese Details l\u00e4sst sich nicht erkl\u00e4ren, wie die neuen Funktionen funktionieren. Daher ohne weitere Vorrede kommen wir zum Ersten.<\/p>\n<h3>Kopiermodus<\/h3>\n<p>\nBaut stark auf bestehenden Technologien auf, tr\u00e4gt jedoch eine v\u00f6llig andere Nutzungslogik in sich.\u00a0<\/p>\n<p>Ziel dieses Modus ist es, sicherzustellen, dass alle Daten, die sich im lokalen Extent befinden, eine Kopie im Capacity-Tier haben.<\/p>\n<p>Wenn wir Move- und Copy-Modi direkt vergleichen, ergibt sich Folgendes:<\/p>\n<ul>\n<li>Bewege nur die versiegelte Kette. Im Copy-Modus wird absolut alles transportiert, unabh\u00e4ngig davon, was in der Backup-Job geschieht.<\/li>\n<li>Verschieben tritt in Kraft, wenn Dateien das Zeitfenster des operativen Backups \u00fcberschreiten, w\u00e4hrend das Kopieren sofort erfolgt, sobald die Backup-Datei verf\u00fcgbar ist.<\/li>\n<li>Die Verfolgung neuer Daten zum Kopieren erfolgt kontinuierlich, w\u00e4hrend das Verschieben alle 4 Stunden aktiv war.<\/li>\n<\/ul>\n<p>\nBei der Betrachtung des neuen Modus schlage ich vor, von einfachen Beispielen zu komplexeren \u00fcberzugehen.<\/p>\n<p>Im einfachsten Fall erscheinen einfach neue Dateien mit Inkrementen, und wir kopieren sie einfach in das Capacity-Tier. Unabh\u00e4ngig davon, welcher Modus in der Backup-Job verwendet wird, ob sie zur versiegelten Kette geh\u00f6rt oder nicht, unabh\u00e4ngig davon, ob unser operatives Fenster abgelaufen ist oder nicht. Einfach genommen und kopiert.<\/p>\n<p>Der Prozess, der dahintersteht, ist nach wie vor die Dehydrierung, wie oben beschrieben. Im Kopiermodus sorgt er auch daf\u00fcr, dass wir keine bereits vorhandenen Bl\u00f6cke in unserem Objekt Speicher kopieren. Der einzige Unterschied besteht darin, dass wir im Bewegungsmodus die echten Dateien durch Platzhalterdateien ersetzt haben; hier ber\u00fchren wir sie nicht und lassen alles so, wie es ist. Ansonsten ist es genau dasselbe Dehydrierungs-Index, der sorgf\u00e4ltig versucht, Ihr Geld und Ihre Zeit zu sparen.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam zu v10 wurde\" src=\"\/wp-content\/uploads\/2020\/06\/b3a033f4a0d0cbce8cecee152660c67c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEs stellt sich die Frage: Wenn man sich die Benutzeroberfl\u00e4che ansieht, gibt es die M\u00f6glichkeit, beide Optionen gleichzeitig auszuw\u00e4hlen. Wie wird ein solcher Kombinationsmodus funktionieren?<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam zu v10 wurde\" src=\"\/wp-content\/uploads\/2020\/06\/12f658765a05e120dc5068920886edb5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLass uns das kl\u00e4ren.<\/p>\n<p>Der Anfang ist Standard: Eine Sicherungsdatei wird erstellt und sofort kopiert. Dann wird ein Inkrement erstellt und ebenfalls kopiert. Dies geschieht, bis wir merken, dass die Dateien aus unserem Betriebsfenster herausgefallen sind und eine versiegelte Kette entstanden ist. In diesem Moment f\u00fchren wir die Dehydrierungsoperation durch und ersetzen diese Dateien durch Platzhalter. Nat\u00fcrlich kopieren wir erneut nichts auf das Kapazit\u00e4ts-Tier.<\/p>\n<p>F\u00fcr all diese faszinierende Logik ist nur ein H\u00e4kchen in der Benutzeroberfl\u00e4che verantwortlich: Copy backups to object storage as soon as they are created.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam zu v10 wurde\" src=\"\/wp-content\/uploads\/2020\/06\/1a0e27c04428ebd48b13d8927a453d62.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Warum brauchen wir diesen Kopiermodus? <\/h3>\n<p>\nEs w\u00e4re sogar besser, die Frage so umzuformulieren: Vor welchen Risiken sch\u00fctzen wir uns damit? Welches Problem hilft es uns zu l\u00f6sen?<\/p>\n<p>Die Antwort ist offensichtlich: Es geht um die Wiederherstellung von Daten. Wenn wir im Objekt Speicher eine vollst\u00e4ndige Kopie unserer lokalen Daten haben, spielt es keine Rolle, was mit unserem Produkt passiert, wir k\u00f6nnen die Daten immer von den in einem hypothetischen Amazon gespeicherten Dateien wiederherstellen.<\/p>\n<p>Lass uns daher die m\u00f6glichen Szenarien von dem einfachsten zum komplexeren durchgehen.<\/p>\n<p>Das einfachste Ungl\u00fcck, das uns widerfahren kann, ist die Nichterreichbarkeit einer der Dateien in der Sicherungskette.<\/p>\n<p>Eine traurigere Geschichte ist, dass einer der Extents unseres SOBR-Repositorys kaputt gegangen ist.<\/p>\n<p>Es wird noch schlimmer, wenn das gesamte SOBR-Repository nicht mehr verf\u00fcgbar ist, aber das Kapazit\u00e4ts-Tier weiter funktioniert.<br \/>\nUnd alles ist ganz schlecht, wenn der Backup-Server ausf\u00e4llt und dein erster Wunsch ist, zu versuchen, in zehn Minuten zur kanadischen Grenze zu gelangen.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam zu v10 wurde\" src=\"\/wp-content\/uploads\/2020\/06\/868d71412901ed362956e1e2157ed895.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUnd jetzt lassen Sie uns jede Situation einzeln betrachten.<\/p>\n<p>Wenn wir eine (oder auch mehrere) Sicherungsdateien verlieren, reicht es aus, den Rescan-Prozess des Repositories zu starten, und die verlorene Datei wird durch eine Platzhalterdatei ersetzt. Mit Hilfe des Regenerationsprozesses (dar\u00fcber haben wir zu Beginn des Artikels gesprochen) kann der Benutzer die Daten aus dem Capacity-Tier in den lokalen Speicher herunterladen.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam zu v10 wurde\" src=\"\/wp-content\/uploads\/2020\/06\/5066a21cbd17565569891f8e23cac4fd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJetzt ist die Situation komplizierter. Angenommen, unser SOBR besteht aus zwei Extents, die im Performance-Modus arbeiten, was bedeutet, dass unsere .vbk- und .vib-Dateien ziemlich ungleichm\u00e4\u00dfig \u00fcber sie verteilt sind. Und irgendwann wird einer der Extents unzug\u00e4nglich, w\u00e4hrend der Benutzer dringend eine Maschine wiederherstellen muss, deren Daten sich genau auf diesem Extent befinden. <\/p>\n<p>Der Benutzer startet den Wiederherstellungsassistenten, w\u00e4hlt den Zeitpunkt aus, auf den er wiederherstellen m\u00f6chte, und der Assistent kommt im Verlauf seiner Arbeit zu dem Ergebnis, dass er nicht alle f\u00fcr die Wiederherstellung ben\u00f6tigten Daten lokal hat, und deshalb m\u00fcssen diese aus dem Capacity-Tier heruntergeladen werden. Die Bl\u00f6cke, die sich im lokalen Speicher befinden, werden nicht aus der Cloud heruntergeladen. Ruhm dem Restore-Index (ja, auch dar\u00fcber haben wir zu Beginn des Artikels gesprochen).<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam zu v10 wurde\" src=\"\/wp-content\/uploads\/2020\/06\/88b38ddf122d20a3e41a0afcba544749.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEine Unterart dieses Falls \u2014 das gesamte SOBR-Repository ist unzug\u00e4nglich geworden. In diesem Fall haben wir nichts von den lokalen Speichern zu kopieren, und alle Bl\u00f6cke werden aus der Cloud heruntergeladen.<\/p>\n<p>Und die interessanteste Situation \u2014 der Backup-Server ist ausgefallen. Hier gibt es zwei M\u00f6glichkeiten: Der Admin hat gute Arbeit geleistet und konfigurationsbezogene Backups erstellt, oder der Admin hat sich selbst einen Strich durch die Rechnung gemacht und kein konfigurationsbezogenes Backup erstellt.<\/p>\n<p>Im ersten Fall reicht es aus, irgendwo eine saubere Installation von VBR zu erstellen und seine Datenbank mit den Standardmitteln aus einem Backup wiederherzustellen. Am Ende dieses Prozesses wird alles wieder beim Alten sein. Alternativ wird es anhand eines der oben beschriebenen Szenarien wiederhergestellt.<\/p>\n<p>Aber wenn der Administrator sich selbst schadet oder auch das Backup der Konfiguration ein mythisches Missgeschick erleidet, werden wir ihn hier nicht dem Schicksal \u00fcberlassen. F\u00fcr diesen Fall haben wir ein neues Verfahren eingef\u00fchrt, das Import Object Storage genannt wird. Es erm\u00f6glicht, den manuellen Prozess der Wiederherstellung des SOBR-Repositories und das Anf\u00fcgen des Kapazit\u00e4tstiers mit anschlie\u00dfendem Rescan zu \u00fcberspringen und einfach den Object Storage in die WIMA-Oberfl\u00e4che hinzuzuf\u00fcgen und das Verfahren Import Storage Repository zu starten. Das Einzige, was zwischen Ihnen und Ihren Backups stehen kann, ist die Aufforderung, ein Passwort einzugeben, falls Ihre Backups verschl\u00fcsselt waren.<\/p>\n<p>Damit sind wir bei Copy Mode wohl am Ende und gehen weiter zu<\/p>\n<h3>Sealed Mode<\/h3>\n<p>\nDie Grundidee ist, dass auf dem ausgew\u00e4hlten Extent des SOBR-Repositories keine neuen Backups erstellt werden k\u00f6nnen. Bis zur Version v10 hatten wir nur den Wartungsmodus, bei dem jegliche Arbeiten am Repository vollst\u00e4ndig verboten waren. Eine Art Hardcore-Modus, um den Speicher aus dem Betrieb zu nehmen, in dem nur die Schaltfl\u00e4che Evacuate zur Verf\u00fcgung steht, die einmalig Backups auf einen anderen Extent verschob.<\/p>\n<p>Der Sealed Mode ist eine Art \u201esanfte\u201c Variante: Wir verbieten die Erstellung neuer Backups und entfernen die alten schrittweise gem\u00e4\u00df der gew\u00e4hlten Aufbewahrungsrichtlinie, verlieren aber dabei nicht die M\u00f6glichkeit, aus den gespeicherten Punkten wiederherzustellen. Sehr n\u00fctzlich, wenn entweder die Lebensdauer des Ger\u00e4ts dem Ende zugeht und es ersetzt werden muss oder es einfach f\u00fcr etwas Wichtigeres freigegeben werden muss, ohne alles auf einmal verschieben zu k\u00f6nnen. Oder es kann nicht gel\u00f6scht werden. <\/p>\n<p>Entsprechend ist der Arbeitsprinzip sehr einfach: Alle Schreiboperationen (Erscheinen neuer Daten) m\u00fcssen verboten werden, w\u00e4hrend Leseoperationen (Wiederherstellungen) und L\u00f6schoperationen (Aufbewahrung) erlaubt sind.<\/p>\n<p>Beide Modi k\u00f6nnen gleichzeitig verwendet werden, man muss jedoch ber\u00fccksichtigen, dass der Wartungsmodus Vorrang hat.<\/p>\n<p>Nehmen wir als Beispiel ein SOBR, das aus zwei Extents besteht. Angenommen, in den ersten vier Tagen wurden Backups im Forward Forever Incremental-Modus erstellt, und dann versiegeln wir den Extent. Das f\u00fchrt dazu, dass wir die Erstellung eines neuen Aktiv-Full Backups auf dem zweiten verf\u00fcgbaren Extent initiieren. Wenn unsere Aufbewahrung vier betr\u00e4gt, dann wird die gesamte Kette, die sich auf dem versiegelten Extent befindet, gel\u00f6scht, sobald sie dessen Grenzen \u00fcberschreitet.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam zu v10 wurde\" src=\"\/wp-content\/uploads\/2020\/06\/5476ebcf9b57eeb6c0326499ac42763f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEs gibt Situationen, in denen die L\u00f6schung fr\u00fcher erfolgt. Zum Beispiel beim Forward Incremental mit zeitweiligen Full-Backups. Wenn wir an den ersten zwei Tagen vollst\u00e4ndige Backups erstellt haben und am Donnerstag entscheiden, das Repository zu versiegeln, wird am Freitag bei der Erstellung eines neuen Full-Backups die Datei vom Montag gel\u00f6scht, da es bis zu diesem Punkt keine Abh\u00e4ngigkeiten gibt. Und dieser Punkt ist von niemandem abh\u00e4ngig. Danach warten wir, bis vier Punkte im verf\u00fcgbaren Extent erstellt wurden, und l\u00f6schen die verbleibenden drei, die nicht unabh\u00e4ngig voneinander gel\u00f6scht werden k\u00f6nnen.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam zu v10 wurde\" src=\"\/wp-content\/uploads\/2020\/06\/c6cc452f98336803731163dfd794f828.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBei Reverse Incremental verh\u00e4lt es sich einfacher. Hier sind die \u00e4ltesten Punkte von nichts abh\u00e4ngig und k\u00f6nnen problemlos gel\u00f6scht werden. Sobald ein neues .vbk im neuen Extent erstellt wird, werden die alten .vrb nacheinander gel\u00f6scht.<\/p>\n<p>\u00dcbrigens, warum erstellen wir jedes Mal ein neues .vbk: Wenn wir es nicht erstellen und die alte Kette der Inkremente fortsetzen w\u00fcrden, w\u00fcrde das alte .vbk f\u00fcr unendlich lange Zeit in jedem Modus h\u00e4ngen bleiben und seine L\u00f6schung verhindern. Daher wurde beschlossen, dass sobald der Extent versiegelt ist, wir ein Full Backup im freien Extent erstellen.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam zu v10 wurde\" src=\"\/wp-content\/uploads\/2020\/06\/3757fae46ad76d64cdddfb941309d557.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKomplizierter ist die Situation mit dem Capacity Tier. <\/p>\n<p>Betrachten wir zuerst den Copy Mode. Angenommen, wir haben vier Tage lang aktiv Backups erstellt und danach wurde der Capacity Tier versiegelt. Wir l\u00f6schen nichts und warten geduldig auf die Retention, bevor wir die Daten vom Capacity Tier l\u00f6schen.<\/p>\n<p>Es passiert ungef\u00e4hr dasselbe im Move Mode \u2013 wir warten auf die Retention, l\u00f6schen das Alte im lokalen Speicher und entfernen das, was im Object Storage gespeichert ist.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam zu v10 wurde\" src=\"\/wp-content\/uploads\/2020\/06\/391d3b231c7de5da1d13e19c31bd6b7c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEin interessantes Beispiel ist das Forever Forward Incremental. Wir setzen die Retention auf drei Punkte und beginnen am Montag mit der Erstellung von Backups, die zuverl\u00e4ssig in die Cloud kopiert werden. Nach dem Versiegeln des Speichers werden weiterhin Backups erstellt, die die drei Punkte einhalten, aber die im Capacity Tier gespeicherten Daten bleiben abh\u00e4ngig und k\u00f6nnen nicht gel\u00f6scht werden. Daher warten wir bis Donnerstag, wenn unser .vbk die Retention \u00fcberschreitet, und l\u00f6schen dann die gesamte gespeicherte Kette.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam zu v10 wurde\" src=\"\/wp-content\/uploads\/2020\/06\/617a42452060210b58148e1fe942a540.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUnd eine kleine Anmerkung: Alle hier gezeigten Beispiele beziehen sich auf eine Maschine. Wenn Sie mehrere in einem Backup haben, wird die Retention je nach aktivem Full Backup unterschiedlich ausfallen.<\/p>\n<p>Das ist im Prinzip alles. Lassen Sie uns also zur h\u00e4rtesten Funktion \u00fcbergehen \u2013 <\/p>\n<h3>Immutability <\/h3>\n<p>\nWie bei den vorherigen Punkten geht es zuerst darum, welches Problem diese Funktion l\u00f6st. Sobald wir unsere Backups irgendwo zur Speicherung ablegen, entsteht der dringende Wunsch, ihre Integrit\u00e4t zu garantieren, das hei\u00dft, ihre L\u00f6schung und jede Modifikation w\u00e4hrend der festgelegten Aufbewahrungsfrist physisch zu verhindern. Auch durch Administratoren oder unter ihren Root-Konten. Dies sch\u00fctzt sie vor versehentlicher oder absichtlicher Besch\u00e4digung. Wer mit AWS arbeitet, k\u00f6nnte auf eine \u00e4hnliche Funktion mit dem Namen Object Lock gesto\u00dfen sein.<\/p>\n<p>Jetzt betrachten wir den Modus in allgemeinen Worten und tauchen dann in die Details ein. In unserem Beispiel wird die Unver\u00e4nderlichkeit f\u00fcr unser Kapazit\u00e4tstier mit einer Aufbewahrungsfrist von vier Tagen aktiviert. Im Backup ist der Modus Kopie aktiviert.<\/p>\n<p>Die Unver\u00e4nderlichkeit hat keinerlei Einfluss auf die allgemeine Aufbewahrungsfrist. Sie f\u00fcgt keine zus\u00e4tzlichen Punkte oder \u00e4hnliches hinzu. Einfach gesagt kann eine Person die Backup-Dateien w\u00e4hrend der vier Tage nicht l\u00f6schen. Wenn am Montag ein Backup erstellt wird, kann die Datei erst am Freitag gel\u00f6scht werden.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam zu v10 wurde\" src=\"\/wp-content\/uploads\/2020\/06\/131e50058c1a015ec78089ed4d038bfc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAlle zuvor erkl\u00e4rten Konzepte der Dehydrierung, Indizes und Metadaten funktionieren weiterhin genau gleich. Mit einer Ausnahme \u2013 die Sperre wird nicht nur f\u00fcr die Daten, sondern auch f\u00fcr die Metadaten gesetzt. Dies dient dem Zweck, falls ein hinterh\u00e4ltiger Angreifer unsere Metadatenbank l\u00f6schen m\u00f6chte und damit die Daten nicht in eine nutzlose bin\u00e4re Suppe verwandelt werden.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam zu v10 wurde\" src=\"\/wp-content\/uploads\/2020\/06\/edfe5c04a082594cf5d67f4bafeccb3a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUnd jetzt ist der perfekte Zeitpunkt, um unsere Technologie der Blockerzeugung zu erkl\u00e4ren. Oder block generation. Lassen Sie uns daf\u00fcr die Situation betrachten, die zu ihrer Entstehung f\u00fchrte.<\/p>\n<p>Lassen Sie uns einen Zeitrahmen von sechs Tagen nehmen und von unten die Zeit des erwarteten Ablaufs der Unver\u00e4nderlichkeit markieren. Am ersten Tag erstellen wir eine Datei, die aus Block a und seinen Metadaten besteht. Wenn die Unver\u00e4nderlichkeit auf drei Tage festgelegt ist, ist es logisch anzunehmen, dass am vierten Tag die Daten entsperrt und gel\u00f6scht werden. Am zweiten Tag f\u00fcgen wir eine neue file2 hinzu, die aus Block b mit denselben Einstellungen besteht. Block a sollte am vierten Tag immer noch gel\u00f6scht werden. Am dritten Tag passiert jedoch etwas Schreckliches \u2013 eine Datei File3 wird erstellt, die aus dem neuen Block d und einem Verweis auf den alten Block a besteht. Das bedeutet, dass der Unver\u00e4nderlichkeitsflag f\u00fcr Block a auf eine neue Frist zur\u00fcckgesetzt werden muss, die auf den sechsten Tag verschoben wird. Hier entsteht ein Problem \u2013 in realen Backups solcher Bl\u00f6cke gibt es eine riesige Menge. Und um die Unver\u00e4nderlichkeitsdauer zu verl\u00e4ngern, m\u00fcssen jedes Mal eine enorme Anzahl von Anfragen gestellt werden. Das wird tats\u00e4chlich ein nahezu endloser t\u00e4glicher Prozess sein, denn mit gro\u00dfer Wahrscheinlichkeit werden wir bei jeder Kopie riesige Mengen deduplizierter Bl\u00f6cke finden. Und was bedeutet eine gro\u00dfe Anzahl von Anfragen bei den Anbietern von Objektspeichern? Richtig! Eine riesige Rechnung am Ende des Monats.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam zu v10 wurde\" src=\"\/wp-content\/uploads\/2020\/06\/ce9c5d0da67f99019b00c4a666302fee.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUnd um nicht grundlos eine ma\u00dfgebliche Summe f\u00fcr unsere gesch\u00e4tzten Kunden zu veranschlagen, wurde der Mechanismus der Blockerzeugung erfunden. Das ist ein zus\u00e4tzlicher Zeitraum, den wir zu dem festgelegten Zeitraum der Unver\u00e4nderlichkeit hinzuf\u00fcgen. Im folgenden Beispiel betr\u00e4gt dieser Zeitraum zwei Tage. Aber das ist nur ein Beispiel. In der Realit\u00e4t wird eine eigene Formel verwendet, die etwa zehn zus\u00e4tzliche Tage bei einer monatlichen Sperre ergibt. <\/p>\n<p>Lass uns dasselbe Szenario betrachten, aber jetzt mit Blockgeneration. Am ersten Tag erstellen wir file1 aus Block a und Metadaten. Wir summieren den Generationenzeitraum und die Unver\u00e4nderlichkeit \u2013 das bedeutet, dass die M\u00f6glichkeit, die Datei zu l\u00f6schen, am sechsten Tag bestehen wird. Wenn wir am zweiten Tag File2 erstellen, das aus Block b und einem Verweis auf Block a besteht, passiert mit dem erwarteten L\u00f6schdatum nichts. Es bleibt wie am sechsten Tag stehen. So versuchen wir, Geld bei der Anzahl der Anfragen zu sparen. Die einzige Situation, in der der Zeitraum verschoben werden kann, ist, wenn der Generationenzeitraum abgelaufen ist. Das hei\u00dft, wenn am dritten Tag die neue File3 einen Verweis auf Block a enth\u00e4lt, wird die Generation 2 hinzugef\u00fcgt, da Gen1 bereits abgelaufen ist. Und das erwartete L\u00f6schdatum von Block a verschiebt sich auf den achten Tag. Dies erm\u00f6glicht es uns, die Anzahl der Anfragen zur Verl\u00e4ngerung der Lebensdauer deduplizierter Bl\u00f6cke dramatisch zu reduzieren, was unseren Kunden viel Geld spart.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam zu v10 wurde\" src=\"\/wp-content\/uploads\/2020\/06\/2056d0c15e4e7fcdd67a56b11f973119.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDie Technologie selbst steht den Nutzern von S3 und S3-kompatibler Hardware zur Verf\u00fcgung, deren Hersteller garantieren, dass ihre Implementierung sich nicht von der von Amazon unterscheidet. Daraus ergibt sich die berechtigte Frage, warum Azure nicht unterst\u00fctzt wird \u2013 sie haben eine \u00e4hnliche Funktion, aber diese funktioniert auf Container-Ebene und nicht auf der Ebene einzelner Objekte. \u00dcbrigens gibt es bei Amazon selbst Object Lock in zwei Modi: Compliance und Governance. Im zweiten Fall bleibt die M\u00f6glichkeit bestehen, dass der gr\u00f6\u00dfte Admin \u00fcber den Admins und Root \u00fcber den Roots, trotz Object Lock, dennoch Daten l\u00f6schen kann. Im Compliance-Fall ist alles fest verankert, und Backups k\u00f6nnen von niemandem gel\u00f6scht werden. Selbst nicht von den Admins bei Amazon (laut ihren offiziellen Aussagen). Wir unterst\u00fctzen genau diesen Modus.<\/p>\n<p>\nUnd traditionell ein paar n\u00fctzliche Links:<\/p>\n<ul>\n<li>\u00dcber <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/block_generation.html?ver=100\">Blockgeneration<\/a><\/noindex> in allen Einzelheiten.<\/li>\n<li>Alle Informationen zu <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/overview.html?ver=100\">Veeam Backup &amp; Replication 10<\/a><\/noindex> in bester Form<\/li>\n<li>O <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/capacity_tier.html?ver=100\">Kapazit\u00e4tsstufe<\/a><\/noindex> im Detail<\/li>\n<\/ul>\n<p>Quelle: <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.1.1 - 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\/de\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\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\/de\/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\udd47Was hat sich in der Kapazit\u00e4tsstufe ge\u00e4ndert, als Veeam v10 wurde | ProHoster","description":"Die Kapazit\u00e4tsstufe (oder wie wir sie intern in Veeam nennen \u2013 KapTier) wurde noch in den Zeiten von Veeam Backup and Replication 9.5 Update 4 unter dem Namen Archive Tier eingef\u00fchrt.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","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\/de\/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\/de\/wp-json\/wp\/v2\/posts\/84809","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=84809"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/84809\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/84810"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=84809"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=84809"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=84809"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}