{"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 v10 wurde?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Der Kapazit\u00e4tstier (oder wie wir intern sagen \u2014 kaptir) wurde noch zu Zeiten von Veeam Backup and Replication 9.5 Update 4 unter dem Namen Archivtier eingef\u00fchrt. Die zugrunde liegende Idee ist es, die M\u00f6glichkeit zu geben, Backups, die aus dem sogenannten operational restore window gefallen sind, in Objektspeicher zu verschieben. Dies half, den Speicherplatz f\u00fcr Benutzer zu r\u00e4umen, die nur wenig davon hatten. Diese Option wurde als Move Mode bezeichnet.<\/p>\n<p>Um diese scheinbar einfache (wie es aussieht) Aktion auszuf\u00fchren, mussten zwei Bedingungen erf\u00fcllt sein: Alle Punkte aus dem zu verschiebenden Backup mussten au\u00dferhalb des genannten operational restore window liegen, das im UI explizit festgelegt wird. Und zweitens: Die Kette musste in sogenannter \u201eversiegelter Form\u201c (sealed backup chain oder Inactive Backup Chain) vorliegen. Das bedeutet, dass es im Laufe der Zeit in dieser Kette keine \u00c4nderungen gibt.<\/p>\n<p>In VBR v10 wurde das Konzept jedoch um neue Funktionen erweitert \u2014 es kam der Copy Mode, Sealed Mode und ein schwer auszusprechender Begriff namens Immutability hinzu.<\/p>\n<p>Heute werden wir \u00fcber diese aufregenden Dinge sprechen. Zuerst dar\u00fcber, wie es in VBR9.5u4 funktionierte, und dann \u00fcber die Ver\u00e4nderungen in der zehnten Version.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam 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 der reinen Sprache vergeben, aber zu viele Begriffe sind unm\u00f6glich zu \u00fcbersetzen.<br \/>\nEs wird also eine Flut von Anglizismen geben.<br \/>\nUnd viele GIFs. <br \/>\nUnd Bilder.<\/p>\n<ul>\n<li>Ohne jegliche Reue. Der Autor des Artikels.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1>Wie bereits erw\u00e4hnt<\/h1>\n<p>\nNun, fangen wir mit der Analyse des operational restore window und sealed backup (oder wie sie in der Dokumentation Inactive Backup Chain hei\u00dfen) an. Ohne ihr Verst\u00e4ndnis kann ich nichts weiter erkl\u00e4ren.<\/p>\n<p>Wie wir auf dem Bild sehen, haben wir eine Backup-Kette mit Datenbl\u00f6cken, die auf der Performance-Tier des SOBR-Repository liegen, das mit der Capacity Tier verbunden ist. Unser operatives Backup-Fenster betr\u00e4gt drei Tage.<\/p>\n<p>Dementsprechend versiegelt das am Montag erstellte .vbk die vorherige Kette, deren Fenster auf drei Tage eingestellt ist. Und es kann also sicher begonnen werden, alles, was \u00e4lter als drei Tage ist, in die Capacity Tier zu verschieben.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam v10 wurde?\" src=\"\/wp-content\/uploads\/2020\/06\/430f31d181bb79c2bd6001011511e3f9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAber was genau war mit der sealed Kette gemeint und was konnte in der Capacity Tier im Update 4 geschickt werden?<\/p>\n<p>F\u00fcr Forward Incremental ist das Zeichen f\u00fcr das Versiegeln der Kette die Erstellung eines neuen Full Backups. Es ist egal, wie dieser Full Backup zustande kommt: sowohl synthetic full als auch active full Backups z\u00e4hlen.<\/p>\n<p>Im Falle von Reverse sind das alle Dateien, die nicht im Betriebsfenster liegen. <\/p>\n<p>Im Fall von Forward-Inkrement mit Rollbacks handelt es sich um alle Rollbacks und .vbk, wenn sich auf dem Performance-Extent ein weiterer .vbk befindet.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam v10 wurde?\" src=\"\/wp-content\/uploads\/2020\/06\/4cb6f168862acabadbdab771cc48fe7f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSchauen wir uns nun die Arbeitsweise mit Backup Copy-Ketten an. Hier wurde nur das unter GFS-Retention fallende Material transportiert. Denn alles, was in neueren Backup Copy-Ketten gespeichert ist, k\u00f6nnte auf die eine oder andere Weise ver\u00e4ndert werden.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam v10 wurde?\" src=\"\/wp-content\/uploads\/2020\/06\/4c263058110b7c502501f01940977f1a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWerfen wir nun einen Blick unter dieHaube. Dort findet ein Prozess statt, der als Dehydrierung bezeichnet wird \u2014 das Hinterlassen von leeren Backup-Dateien auf dem Extent und das Verschieben von Bl\u00f6cken aus diesen Dateien in das Capacity Tier. Zur Optimierung dieses Prozesses wird ein sogenannter Dehydrierungsindex verwendet, der es erm\u00f6glicht, Bl\u00f6cke nicht zu kopieren, die bereits in das Capacity Tier kopiert wurden. <\/p>\n<p>Betrachten wir, wie das anhand eines Beispiels aussieht: Angenommen, wir haben eine .vbk Datei, die aus dem Operation Window stammt und zu einer versiegelten Kette geh\u00f6rt. Das bedeutet, wir haben das volle Recht, sie in das Capacity Tier zu verschieben. Bei der Verschiebung wird eine Metadaten-Datei im Capacity Tier erstellt sowie die Bl\u00f6cke der zu verschiebenden Datei. In der Metadaten-Datei auf der Verlinkungsebene wird beschrieben, aus welchen Bl\u00f6cken unsere Datei besteht. In dem Bild besteht unsere erste Datei aus den Bl\u00f6cken a, b, c, und in den Metadaten sind die Links zu diesen Bl\u00f6cken platziert. Wenn wir eine zweite .vbk Datei haben, die bereit zur Verschiebung ist und aus den Bl\u00f6cken a, b und d besteht, erkennen wir durch die Analyse des Dehydrierungsindex, dass nur der Block d verschoben werden muss. Und seine Metadaten-Datei wird Links zu den zwei vorherigen Bl\u00f6cken und einem neuen enthalten.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam v10 wurde?\" src=\"\/wp-content\/uploads\/2020\/06\/5c502030b8727ecd85c5229df1761c85.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDer Prozess, diese Platzhalter mit Daten zu f\u00fcllen, wird als Rehydrierung bezeichnet. Dabei wird bereits der spezifische Rehydrierungsindex verwendet, der auf der \u00e4ltesten .vbk-Datei im lokalen Performance-Extent basiert. Das bedeutet, wenn der Nutzer eine Datei aus dem Capacity-Tier wiederherstellen m\u00f6chte, erstellen wir zun\u00e4chst einen Blockindex des \u00e4ltesten vollst\u00e4ndigen Backups und \u00fcbertragen nur die fehlenden Bl\u00f6cke aus dem Capacity-Tier. Im dargestellten Beispiel m\u00fcssen wir, um FullBackup1.vbk gem\u00e4\u00df dem Rehydrierungsindex zu rehydrieren, lediglich Block C beschaffen, den wir aus dem Capacity-Tier entnehmen. Wenn das Capacity-Tier ein Cloud-Object-Storage ist, erm\u00f6glicht das enorme Kosteneinsparungen.<\/p>\n<p>Hier mag es den Anschein erwecken, dass diese Technologie der in WAN-Beschleunigern verwendeten \u00e4hnelt, aber das ist nur eine T\u00e4uschung. In den Beschleunigern erfolgt die globale Deduplication, w\u00e4hrend hier eine lokale innerhalb jeder Datei basierend auf einem bestimmten Offset verwendet wird. Dies liegt an den unterschiedlichen zu l\u00f6senden Aufgaben: Hier m\u00fcssen wir gro\u00dfe Dateien von vollst\u00e4ndigen Backups kopieren, und unseren Untersuchungen zufolge liefert dieser Deduplication-Algorithmus auch \u00fcber lange Zeitr\u00e4ume hinweg die besten Ergebnisse.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam v10 wurde?\" src=\"\/wp-content\/uploads\/2020\/06\/1db1a696e289187ae02bd84d9edd6f66.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAber mehr Indizes f\u00fcr den Gott der Indizes! Es gibt auch einen Index zur Wiederherstellung von Daten! Wenn wir die Wiederherstellung einer Maschine, die sich im Capacity Tier befindet, 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 v10 wurde?\" src=\"\/wp-content\/uploads\/2020\/06\/257593c39e63bfb6f7e13d228bcebbae.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>So ist es geworden<\/h1>\n<p>\nDas w\u00e4re alles zur Einleitung. Sie ist recht detailliert, aber wie bereits erw\u00e4hnt, ohne diese Details l\u00e4sst sich nicht erkl\u00e4ren, wie die neuen Funktionen arbeiten. Daher kommen wir ohne weitere Umschweife zum ersten Punkt.<\/p>\n<h3>Copy-Modus<\/h3>\n<p>\nBasiert gr\u00f6\u00dftenteils auf bestehenden Technologien, verfolgt jedoch eine v\u00f6llig andere Logik der Nutzung.\u00a0<\/p>\n<p>Ziel dieses Modus ist es, sicherzustellen, dass alle Daten, die sich auf dem lokalen Extent befinden, eine Kopie im Capacity Tier haben.<\/p>\n<p>Wenn man die Modi Move und Copy direkt vergleicht, ergibt sich Folgendes:<\/p>\n<ul>\n<li>Verschieben kann man nur eine versiegelte Kette. Im Copy-Modus wird alles transportiert, unabh\u00e4ngig davon, was in dem Backup-Job geschieht.<\/li>\n<li>Das Verschieben tritt in Kraft, wenn Dateien die Grenzen des operativen Backup-Fensters \u00fcberschreiten, w\u00e4hrend das Kopieren sofort erfolgt, sobald die Backup-Datei verf\u00fcgbar ist.<\/li>\n<li>Die \u00dcberwachung neuer Daten zum Kopieren erfolgt kontinuierlich, w\u00e4hrend das Verschieben alle 4 Stunden aktiviert wird.<\/li>\n<\/ul>\n<p>\nBei der Betrachtung des neuen Modus schlage ich vor, von einfachen Beispielen zu komplexen \u00fcberzugehen.<\/p>\n<p>Im einfachsten Fall erscheinen einfach neue Dateien mit Inkrementen, und wir kopieren sie einfach ins Capacity Tier. Unabh\u00e4ngig davon, welcher Modus im Backup-Job verwendet wird, ob er zur versiegelten Kette geh\u00f6rt oder nicht, und unabh\u00e4ngig davon, ob unser operatives Fenster abgelaufen ist. Wir haben sie einfach genommen und kopiert.<\/p>\n<p>Der Prozess dahinter ist nach wie vor die Dehydrierung, wie oben beschrieben. Im Kopiermodus wird auch darauf geachtet, dass wir keine Bl\u00f6cke kopieren, die bereits in unserem Speicher vorhanden sind. Der einzige Unterschied besteht darin, dass wir im Move-Modus die echten Dateien durch Platzhalter ersetzt haben, w\u00e4hrend wir hier nichts \u00e4ndern und alles so belassen, wie es ist. Ansonsten handelt es sich um denselben Dehydrierungsindex, der sorgf\u00e4ltig darauf abzielt, Ihre Kosten und Zeit zu sparen.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam 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 kombinierter Modus funktionieren?<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam v10 wurde?\" src=\"\/wp-content\/uploads\/2020\/06\/12f658765a05e120dc5068920886edb5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLassen Sie uns das kl\u00e4ren.<\/p>\n<p>Der Anfang ist Standard: Eine Sicherungsdatei wird erstellt und sofort kopiert. Dazu wird ein Inkrement erstellt und ebenfalls kopiert. Dies geschieht, bis wir verstehen, dass die Dateien aus unserem Betriebsfenster herausgefallen sind und eine versiegelte Kette aufgetreten ist. In diesem Moment f\u00fchren wir den Dehydrierungsprozess durch und ersetzen diese Dateien durch Platzhalter. Selbstverst\u00e4ndlich kopieren wir keine Daten erneut in die Kapazit\u00e4tstabelle.<\/p>\n<p>F\u00fcr diese spannende Logik ist lediglich ein H\u00e4kchen in der Benutzeroberfl\u00e4che verantwortlich: 'Sicherungen sofort bei ihrer Erstellung in den Objektspeicher kopieren.'<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam 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 ist 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 Datenwiederherstellung. Wenn wir eine vollst\u00e4ndige Kopie der lokalen Daten im Objektspeicher 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>Deshalb lassen Sie uns die m\u00f6glichen Szenarien von den einfachsten bis zu den komplexesten durchgehen.<\/p>\n<p>Die einfachste Bedrohung, die uns treffen kann, ist die Nichtverf\u00fcgbarkeit einer der Dateien in der Backup-Kette.<\/p>\n<p>Eine traurigere Geschichte ist, dass einer der Extents unseres SOBR-Repositorys defekt ist.<\/p>\n<p>Es wird noch schlimmer, wenn das gesamte SOBR-Repository nicht mehr verf\u00fcgbar ist, aber das Kapazit\u00e4tstier noch funktioniert.<br \/>\nUnd es wird richtig schlimm, wenn der Backup-Server ausf\u00e4llt und dein erster Wunsch ist, in zehn Minuten zur kanadischen Grenze zu rennen.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam v10 wurde?\" src=\"\/wp-content\/uploads\/2020\/06\/868d71412901ed362956e1e2157ed895.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJetzt lassen Sie uns jede Situation einzeln betrachten.<\/p>\n<p>Wenn wir eine (auch mehrere) Backup-Dateien verloren haben, reicht es aus, den Rescan-Prozess des Repositories zu starten, und die verlorene Datei wird durch eine Dummy-Datei ersetzt. Mithilfe des Regenerationsprozesses (der zu Beginn des Artikels behandelt wurde) kann der Benutzer die Daten aus dem Kapazit\u00e4tstier in den lokalen Speicher herunterladen.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam v10 wurde?\" src=\"\/wp-content\/uploads\/2020\/06\/5066a21cbd17565569891f8e23cac4fd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJetzt wird die Situation komplizierter. Angenommen, unser SOBR besteht aus zwei Extents, die im Performance-Modus arbeiten, was bedeutet, dass unsere .vbk und .vib relativ ungleichm\u00e4\u00dfig verteilt sind. Und zu einem bestimmten Zeitpunkt wird eines der Extents nicht verf\u00fcgbar, w\u00e4hrend der Benutzer dringend die Maschine wiederherstellen muss, deren Daten sich genau auf diesem Extent befinden. <\/p>\n<p>Der Benutzer startet den Wiederherstellungsassistenten, w\u00e4hlt den Punkt aus, auf den er wiederherstellen m\u00f6chte, und der Assistent erkennt w\u00e4hrend des Vorgangs, dass ihm alle notwendigen Daten zur Wiederherstellung lokal nicht zur Verf\u00fcgung stehen, und dass sie daher aus dem Kapazit\u00e4tstier heruntergeladen werden m\u00fcssen. Dabei werden die Bl\u00f6cke, die im lokalen Speicher verbleiben, nicht aus der Cloud heruntergeladen. Gepriesen sei das Restore-Index (ja, auch dar\u00fcber wurde zu Beginn des Artikels gesprochen).<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam v10 wurde?\" src=\"\/wp-content\/uploads\/2020\/06\/88b38ddf122d20a3e41a0afcba544749.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEine Unterart dieses Falls ist, dass das gesamte SOBR-Repository nicht mehr verf\u00fcgbar ist. In diesem Fall haben wir nichts von lokalen Speichern zu kopieren, und alle Bl\u00f6cke werden aus der Cloud heruntergeladen.<\/p>\n<p>Die interessanteste Situation ist, dass der Backup-Server ausgefallen ist. Hier gibt es zwei Varianten: der Admin hat gute Arbeit geleistet und konfigurationsbezogene Backups erstellt, oder der Admin ist selbst schuld und hat kein konfigurationsbezogenes Backup gemacht.<\/p>\n<p>Im ersten Fall reicht es aus, irgendwo eine saubere Installation von VBR bereitzustellen und die Datenbank aus dem Backup mit den standardm\u00e4\u00dfigen Mitteln wiederherzustellen. Am Ende dieses Prozesses wird alles wieder seinen gewohnten Gang nehmen. Alternativ kann es nach einem der oben genannten Szenarien wiederhergestellt werden.<\/p>\n<p>Aber wenn der Administrator sich selbst schadet oder auch das Backup der Konfiguration einen mythologischen Fehlschlag erlitten hat, dann lassen wir ihn auch hier nicht im Stich. F\u00fcr diesen Fall haben wir ein neues Verfahren eingef\u00fchrt, das Import Object Storage genannt wird. Es erm\u00f6glicht, den manuellen Wiederherstellungsprozess des SOBR-Repositorys und das Anh\u00e4ngen von Kapazit\u00e4ts-Tiers mit nachfolgendem Rescan zu \u00fcberspringen, und einfach Object Storage in die Vima-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 zur Eingabe eines Passworts, falls Ihre Backups verschl\u00fcsselt sind.<\/p>\n<p>Das war es mit dem Copy Mode, und wir kommen jetzt zu<\/p>\n<h3>Sealed Mode<\/h3>\n<p>\nDie Grundidee ist, dass im ausgew\u00e4hlten Extent des SOBR-Repositorys keine neuen Backups erscheinen d\u00fcrfen. Bis v10 hatten wir nur den Maintenance Mode, bei dem jegliche Arbeit mit dem Repository vollst\u00e4ndig untersagt war. Ein sozusagen hardcore Modus zur Auslagerung des Speichers, bei dem nur die Schaltfl\u00e4che Evacuate verf\u00fcgbar ist, die einmalig Backups auf einen anderen Extent verlegt.<\/p>\n<p>Ein Versiegelter Modus ist eine Art \u201esanfte\u201c Variante: Wir verbieten das Erstellen neuer Backups und entfernen schrittweise alte gem\u00e4\u00df dem gew\u00e4hlten Retentionszeitraum, verlieren dabei jedoch nicht die M\u00f6glichkeit, aus den gespeicherten Punkten wiederherzustellen. Dies ist \u00e4u\u00dferst n\u00fctzlich, wenn unsere Hardware entweder das Ende ihrer Lebensdauer erreicht und ersetzt werden muss oder einfach f\u00fcr etwas Wichtigeres freigegeben werden muss, und es keinen Ort gibt, um alles auf einmal zu verschieben. Oder es kann nicht gel\u00f6scht werden. <\/p>\n<p>Das Prinzip funktioniert entsprechend ganz einfach: Man muss alle Schreiboperationen (das Erscheinen neuer Daten) verbieten und die Lese- (Wiederherstellungen) sowie L\u00f6schoperationen (Retentionszeitraum) erlauben.<\/p>\n<p>Beide Modi k\u00f6nnen gleichzeitig verwendet werden, wobei jedoch zu beachten ist, dass die Wartung Vorrang hat.<\/p>\n<p>Als Beispiel betrachten wir 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. Dies f\u00fchrt dazu, dass wir die Erstellung eines neuen aktiven Fulls auf dem zweiten verf\u00fcgbaren Extent initiieren. Wenn unsere Retention vier betr\u00e4gt, dann wird die gesamte Kette, die sich auf dem versiegelten Extent befindet, ohne Bedenken gel\u00f6scht, sobald sie dessen Grenzen \u00fcberschreitet.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam 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 bei der Forward Incremental-Backups mit periodischen Full-Backups. Wenn in den ersten beiden Tagen vollst\u00e4ndige Backups erstellt wurden und wir am Donnerstag entscheiden, das Repository zu versiegeln, wird am Freitag, wenn ein neues Full-Backup erstellt wird, die Datei vom Montag gel\u00f6scht, da es zu diesem Punkt keine Abh\u00e4ngigkeiten gibt. Und der Punkt selbst 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 v10 wurde?\" src=\"\/wp-content\/uploads\/2020\/06\/c6cc452f98336803731163dfd794f828.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDie Sache ist einfacher mit Reverse Incremental. Bei dieser Methode sind die \u00e4ltesten Punkte von nichts abh\u00e4ngig und k\u00f6nnen problemlos gel\u00f6scht werden. Daher werden, sobald ein neues .vbk im neuen Extent erstellt wurde, die alten .vrb nacheinander gel\u00f6scht.<\/p>\n<p>\u00dcbrigens, warum wir jedes Mal ein neues .vbk erstellen: Wenn wir es nicht erstellen und die alte Inkrementenkette fortsetzen w\u00fcrden, w\u00fcrde das alte .vbk in jedem Modus ewig h\u00e4ngen bleiben, was seine L\u00f6schung verhindern w\u00fcrde. Daher wurde beschlossen, dass jedes Mal, wenn der Extent versiegelt wird, ein vollst\u00e4ndiges Backup im freien Extent erstellt wird.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam v10 wurde?\" src=\"\/wp-content\/uploads\/2020\/06\/3757fae46ad76d64cdddfb941309d557.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDie Angelegenheit wird schwieriger mit dem Capacity Tier. <\/p>\n<p>Zuerst betrachten wir den Copy-Modus. Nehmen wir an, dass wir vier Tage lang aktiv Backups erstellt haben, und dann wurde der Capacity Tier versiegelt. Wir l\u00f6schen nichts und halten geduldig die Retention ein, bevor wir die Daten im Capacity Tier l\u00f6schen.<\/p>\n<p>\u00c4hnliches passiert im Move-Modus \u2014 wir warten die Retention ab, l\u00f6schen die alten Daten im lokalen Speicher und entfernen die in der Object Storage gespeicherten Daten.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam v10 wurde?\" src=\"\/wp-content\/uploads\/2020\/06\/391d3b231c7de5da1d13e19c31bd6b7c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEin interessantes Beispiel f\u00fcr Forever Forward Incremental. Wir stellen die Retention auf drei Punkte ein und beginnen am Montag mit der Erstellung von Backups, die zuverl\u00e4ssig in die Cloud kopiert werden. Nachdem der Speicher versiegelt wurde, werden weiterhin Backups erstellt, die die drei Punkte einhalten, jedoch bleiben die im Capacity Tier gespeicherten Daten abh\u00e4ngig und k\u00f6nnen nicht gel\u00f6scht werden. Daher warten wir bis Donnerstag, wenn unser .vbk die Retention \u00fcberschreitet, und erst dann l\u00f6schen wir die gesamte gespeicherte Kette.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam v10 wurde?\" src=\"\/wp-content\/uploads\/2020\/06\/617a42452060210b58148e1fe942a540.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUnd eine kleine Anmerkung: Alle Beispiele hier zeigen eine Maschine. Wenn Sie mehrere im Backup haben, wird die Retention bei ihnen unterschiedlich sein, je nachdem, ob ein Active Full durchgef\u00fchrt wurde oder nicht.<\/p>\n<p>Das w\u00e4re im Prinzip alles. Lass uns also zur extremsten Funktion \u00fcbergehen \u2014 <\/p>\n<h3>Immutability <\/h3>\n<p>\nWie bei den vorherigen Punkten beginnt alles mit der Frage, welches Problem diese Funktion l\u00f6st. Sobald wir unsere Backups irgendwo zur Speicherung exportieren, entsteht der dringende Wunsch, deren Sicherheit zu gew\u00e4hrleisten, also physisch ihr L\u00f6schen und jede Modifikation w\u00e4hrend der festgelegten Aufbewahrungsfrist zu verbieten. Dazu geh\u00f6rt auch der Zugriff durch Admins mit ihren Root-Konten. Dies sch\u00fctzt vor versehentlicher oder absichtlicher Besch\u00e4digung. Wer mit AWS arbeitet, k\u00f6nnte eine \u00e4hnliche Funktion unter dem Namen Object Lock getroffen haben.<\/p>\n<p>Lassen Sie uns zun\u00e4chst den Modus allgemein betrachten und dann in die Details eintauchen. In unserem Beispiel wird die Unver\u00e4nderlichkeit f\u00fcr unseren Kapazit\u00e4tstyp mit einer Aufbewahrungsfrist von vier Tagen aktiviert. Im Backup ist der Modus Kopie aktiviert.<\/p>\n<p>Die Unver\u00e4nderlichkeit hat keinen Einfluss auf die allgemeine Aufbewahrungsfrist. Zum Beispiel f\u00fcgt sie keine zus\u00e4tzlichen Punkte hinzu oder \u00e4hnliches. F\u00fcr vier Tage kann niemand die Dateien der Backups 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 v10 wurde?\" src=\"\/wp-content\/uploads\/2020\/06\/131e50058c1a015ec78089ed4d038bfc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAlle zuvor erl\u00e4uterten Konzepte der Dehydrierung, Indizes und Metadaten funktionieren weiterhin genau so. Mit einer Ausnahme: Der Block wird nicht nur f\u00fcr Daten, sondern auch f\u00fcr Metadaten festgelegt. Dies geschieht f\u00fcr den Fall, dass ein hinterh\u00e4ltiger Angreifer beschlie\u00dft, unsere Metadatenbank zu l\u00f6schen, damit die Datenbl\u00f6cke nicht in eine nutzlose bin\u00e4re Masse verwandelt werden.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam v10 wurde?\" src=\"\/wp-content\/uploads\/2020\/06\/edfe5c04a082594cf5d67f4bafeccb3a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJetzt ist ein gro\u00dfartiger Moment, um unsere Technologie zur Blockgenerierung zu erkl\u00e4ren. Oder block generation. Lassen Sie uns daf\u00fcr eine Situation betrachten, die zu ihrer Entstehung gef\u00fchrt hat.<\/p>\n<p>Nehmen wir eine Zeitspanne von sechs Tagen und markieren wir von unten die erwartete Zeit des Ablaufs der Unver\u00e4nderlichkeit. Am ersten Tag erstellen wir eine Datei, die aus Block a und seinen Metadaten besteht. Wenn die Unver\u00e4nderlichkeit auf drei Tage gesetzt ist, ist es logisch anzunehmen, dass am vierten Tag die Daten entsperrt und gel\u00f6scht werden. Am zweiten Tag f\u00fcgen wir eine neue Datei file2 hinzu, die aus Block b mit denselben Einstellungen besteht. Block a sollte am vierten Tag immer noch gel\u00f6scht werden. Aber am dritten Tag passiert das Unfassbare \u2013 eine Datei File3 wird erstellt, die aus dem neuen Block d und einem Verweis auf den alten Block a besteht. Das bedeutet, dass das Unver\u00e4nderlichkeitsflag f\u00fcr Block a auf einen neuen Zeitraum zur\u00fcckgesetzt werden muss, der auf den sechsten Tag verschoben wird. Und hier tritt das Problem auf \u2013 in realen Backups solcher Bl\u00f6cke gibt es eine immense Menge. Um deren Unver\u00e4nderlichkeitszeitraum zu verl\u00e4ngern, m\u00fcssen st\u00e4ndig eine gro\u00dfe Anzahl von Anfragen gestellt werden. Und tats\u00e4chlich wird dies ein fast endloser t\u00e4glicher Prozess sein, da wir mit hoher Wahrscheinlichkeit bei jedem Kopiervorgang riesige Mengen deduplizierter Bl\u00f6cke finden werden. Was bedeutet eine gro\u00dfe Anzahl von Anfragen bei Anbietern von Objektspeichern? Richtig! Eine hohe Rechnung am Monatsende.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam v10 wurde?\" src=\"\/wp-content\/uploads\/2020\/06\/ce9c5d0da67f99019b00c4a666302fee.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUm zu verhindern, dass wir unseren gesch\u00e4tzten Kunden unverh\u00e4ltnism\u00e4\u00dfig hohe Betr\u00e4ge in Rechnung stellen, wurde der Mechanismus der Blockgenerierung eingef\u00fchrt. Dabei handelt es sich um einen zus\u00e4tzlichen Zeitraum, den wir dem festgelegten Unver\u00e4nderlichkeitszeitraum hinzuf\u00fcgen. Im folgenden Beispiel betr\u00e4gt dieser Zeitraum zwei Tage. Dies dient jedoch nur als Beispiel. In der Realit\u00e4t wird eine eigene Formel verwendet, die bei einer monatlichen Sperre etwa zehn zus\u00e4tzliche Tage ergibt. <\/p>\n<p>Lassen Sie uns die gleiche Situation, jedoch mit der Blockerzeugung, weiter betrachten. Am ersten Tag erstellen wir file1 aus Block a und Metadaten. Wir addieren die Generationenperiode und Immutabilit\u00e4t \u2014 das bedeutet, dass die M\u00f6glichkeit, die Datei zu l\u00f6schen, am sechsten Tag besteht. Wenn wir am zweiten Tag File2 erstellen, das aus Block b und einem Verweis auf Block a besteht, \u00e4ndert sich das voraussichtliche L\u00f6schdatum nicht. Es bleibt am sechsten Tag stehen. Damit versuchen wir, die Kosten f\u00fcr die Anzahl der Anfragen zu sparen. Die einzige Situation, in der sich der Zeitraum verschieben kann, ist, wenn die Generationenperiode abgelaufen ist. Das hei\u00dft, wenn am dritten Tag File3 einen Verweis auf Block a enth\u00e4lt, wird Generation 2 hinzugef\u00fcgt, da Gen1 bereits abgelaufen ist. Das voraussichtliche L\u00f6schdatum von Block a verschiebt sich dann auf den achten Tag. Dadurch k\u00f6nnen wir die Anzahl der Anfragen zur Verl\u00e4ngerung der Lebensdauer deduplizierter Bl\u00f6cke erheblich reduzieren, was unseren Kunden eine Menge Geld spart.<\/p>\n<p><img decoding=\"async\" alt=\"Was hat sich im Capacity Tier ge\u00e4ndert, als Veeam v10 wurde?\" src=\"\/wp-content\/uploads\/2020\/06\/2056d0c15e4e7fcdd67a56b11f973119.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDie Technologie ist f\u00fcr Benutzer von S3 und S3-kompatibler Hardware verf\u00fcgbar, deren Hersteller garantieren, dass ihre Implementierung der von Amazon entspricht. Daraus ergibt sich die legitime Frage, warum Azure nicht unterst\u00fctzt wird \u2013 sie haben eine \u00e4hnliche Funktion, die jedoch auf Container-Ebene und nicht auf separaten Objekten arbeitet. \u00dcbrigens gibt es bei Amazon Object Lock in zwei Modi: Compliance und Governance. Im zweiten Fall bleibt die M\u00f6glichkeit bestehen, dass der gr\u00f6\u00dfte Admin unter den Admins und der Root unter den Roots, trotz des Object Locks, dennoch Daten gel\u00f6scht. Im Compliance-Modus sind alle Daten fest verankert, und Backups k\u00f6nnen von niemandem gel\u00f6scht werden, selbst nicht von Amazon-Administratoren (laut ihren offiziellen Aussagen). Wir unterst\u00fctzen diesen Modus.<\/p>\n<p>\nUnd traditionell, hier sind einige 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\">Blockgenerierung<\/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>e <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/capacity_tier.html?ver=100\">Capacity Tier<\/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 4.9.10 - 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. \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\" \/>\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) 4.9.10\" \/>\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. \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\" \/>\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 im Capacity Tier ge\u00e4ndert, als Veeam v10 wurde | ProHoster","description":"Die Capacity Tier (oder wie wir intern sagen \u2014 KapTier) wurde erstmals mit Veeam Backup und Replication 9.5 Update 4 unter dem Namen Archive Tier eingef\u00fchrt. Die grundliegende Idee ist es, Backups, die aus dem sogenannten operativen Wiederherstellungsfenster gefallen sind, in Objektspeicher zu verschieben. Dies half, den Speicherplatz freizugeben f\u00fcr den","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. \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","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"},"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}]}}