Capacity Tier (oder wie wir es in Vim nennen – captir) erschien bereits in den Tagen von Veeam Backup and Replication 9.5 Update 4 unter dem Namen Archive Tier. Die Idee dahinter ist, es zu ermöglichen, Backups, die aus dem sogenannten Operational-Restore-Fenster gefallen sind, in den Objektspeicher zu verschieben. Dies trug dazu bei, Speicherplatz für diejenigen Benutzer freizugeben, die nur wenig davon hatten. Und diese Option wurde Bewegungsmodus genannt.

Um diese (wie es scheint) einfache Aktion auszuführen, reichte es aus, zwei Bedingungen zu erfüllen: Alle Punkte aus dem verschobenen Backup müssen außerhalb der Grenzen des oben genannten operativen Wiederherstellungsfensters liegen, das explizit in der Benutzeroberfläche festgelegt wird. Und zweitens: Die Kette muss in der sogenannten „versiegelten Form“ vorliegen (sealed Backup Chain oder Inactive Backup Chain). Das heißt, in dieser Kette treten im Laufe der Zeit keine Änderungen auf.

Aber in VBR v10 wurde das Konzept um neue Funktionen ergänzt – Copy Mode, Sealed Mode und etwas mit dem schwer auszusprechenden Namen Immutability erschien.

Das sind die faszinierenden Dinge, über die wir heute sprechen werden. Zunächst zur Funktionsweise in VBR9.5u4 und dann zu den Änderungen in der zehnten Version.

Und mögen mir die Verfechter der reinen Sprache verzeihen, aber es gibt zu viele Begriffe, die nicht übersetzt werden können.
Es wird hier also eine Menge Anglizismen geben.
Und viele GIFs.
Und Bilder.

• Ohne das geringste Bedauern. Autor des Artikels.

Wie war

Beginnen wir mit der Analyse des operativen Wiederherstellungsfensters und des versiegelten Backups (oder wie sie in der Dokumentation zur inaktiven Backup-Kette genannt werden). Ohne ihr Verständnis wird eine weitere Erklärung nicht möglich sein.

Wie wir im Bild sehen, haben wir eine Art Backup-Kette mit Datenblöcken, die sich auf dem Performance-Tier SOBR des Repositorys befindet, mit dem der Capacity-Tier verbunden ist. Unser operatives Backup-Fenster beträgt drei Tage.

Demnach versiegelt die am Montag erstellte .vbk die bisherige Kette, deren Zeitfenster auf drei Tage festgelegt ist. Und das bedeutet, dass Sie bedenkenlos damit beginnen können, alles, was älter als diese drei Tage ist, zum Schießstand zu transportieren.

Aber was genau war mit einer versiegelten Kette gemeint und was konnte in Update 4 an den Kapazitäts-Schießstand geschickt werden?

Bei Forward Incremental ist die Erstellung eines neuen vollständigen Backups ein Zeichen für die Versiegelung der Kette. Dabei spielt es keine Rolle, wie dieses Voll-Backup zustande kommt: Es werden sowohl synthetische Voll-Backups als auch aktive Voll-Backups berücksichtigt.

Bei Reverse sind das alle Dateien, die nicht in das Betriebsfenster fallen.

Im Fall der Vorwärtsinkrementierung mit Rollbacks sind dies alle Rollbacks und .vbk, wenn es auf dem Leistungsumfang eine weitere .vbk gibt

Betrachten wir nun die Möglichkeit, mit Sicherungskopieketten zu arbeiten. Hier wurden ausschließlich Gegenstände transportiert, die unter die GFS-Aufbewahrung fallen. Denn alles, was in neueren Backup-Kopierketten gespeichert ist, kann auf die eine oder andere Weise geändert werden.

Schauen wir nun unter die Haube. Dort findet ein Prozess namens Dehydrierung statt, bei dem leere Sicherungsdateien auf dem Extent zurückbleiben und Blöcke aus diesen Dateien in den Kapazitätsschießstand gezogen werden. Um diesen Prozess zu optimieren, wird der sogenannte Dehydrationsindex verwendet, der es ermöglicht, das Kopieren bereits kopierter Blöcke in den Kapazitätsschießstand zu vermeiden.

Sehen wir uns anhand eines Beispiels an, wie das aussieht: Nehmen wir an, wir haben eine .vbk, die aus dem Transaktionsfenster kam und zu einer versiegelten Kette gehört. Das bedeutet, dass wir das Recht haben, es auf den Kapazitätsschießstand zu verlegen. Beim Verschieben wird im Kapazitätsstrich und in den Blöcken der übertragenen Datei eine Metadatendatei erstellt. Die Metadatendatei auf Linkebene beschreibt, aus welchen Blöcken unsere Datei besteht. Im Fall im Bild besteht unsere erste Datei aus den Blöcken a, b, c und die Metadaten enthalten Links zu diesen Blöcken. Wenn wir eine zweite .vbk-Datei haben, die zum Verschieben bereit ist und aus den Blöcken a, b und d besteht, verstehen wir bei der Analyse des Dehydrierungsindex, dass nur Block d übertragen werden muss. Und seine Metadatendatei enthält Links zu zwei vorherigen Blöcken und einem neuen.

Dementsprechend wird der Vorgang, diese leeren Räume wieder mit Daten zu füllen, als Rehydrierung bezeichnet. Es verwendet bereits einen eigenen Rehydrierungsindex, der auf der ältesten .vbk-Datei auf dem lokalen Leistungsumfang basiert. Das heißt, wenn der Benutzer eine Datei aus dem Kapazitätsschießstand zurückgeben möchte, erstellen wir zunächst einen Index der Blöcke der ältesten Vollsicherung und übertragen nur die fehlenden Blöcke aus dem Kapazitätsschießstand. Im im Bild dargestellten Fall benötigen wir zur Rehydrierung von FullBackup1.vbk gemäß dem Rehydrierungsindex nur Block C, den wir aus dem Kapazitätsschießstand entnehmen. Wenn ein Speicher-Cloud-Objekt als Kapazitäts-Schießstand dient, können Sie dadurch enorm viel Geld sparen.

Hier mag es scheinen, dass diese Technologie mit der in WAN-Beschleunigern verwendeten identisch ist, aber es scheint nur so. Bei Beschleunigern ist die Deduplizierung global; hier wird die lokale Deduplizierung innerhalb jeder Datei an einem bestimmten Offset verwendet. Dies geschieht aufgrund der unterschiedlichen Aufgaben, die gelöst werden müssen: Hier müssen wir große Vollsicherungsdateien kopieren, und unseren Untersuchungen zufolge liefert dieser Deduplizierungsalgorithmus das beste Ergebnis, selbst wenn zwischen ihnen eine lange Zeitspanne vergeht.

Aber noch mehr Indizes für den Gott der Indizes! Es gibt auch einen Index zur Datenwiederherstellung! Wenn wir mit der Wiederherstellung einer Maschine beginnen, die sich im Kapazitäts-Dashboard befindet, lesen wir nur eindeutige Datenblöcke, die nicht im Leistungs-Dashboard enthalten sind.

Wie es wurde

Das ist alles für den Einführungsteil. Es ist recht detailliert, aber wie oben erwähnt, ist es ohne diese Details nicht möglich, die Funktionsweise der neuen Funktionen zu erklären. Kommen wir also ohne weitere Umschweife zum ersten Punkt.

Kopiermodus

Es basiert weitgehend auf bestehenden Technologien, trägt jedoch eine völlig andere Nutzungslogik. 

Der Zweck dieses Modus besteht darin, sicherzustellen, dass alle Daten, die sich auf dem lokalen Extent befinden, eine Kopie im Kapazitäts-Dash haben.

Wenn Sie die Modi „Verschieben“ und „Kopieren“ direkt vergleichen, sieht es so aus:

• Nur die versiegelte Kette kann bewegt werden. Im Falle eines Kopiermodus wird absolut alles übertragen, unabhängig davon, was im Backup-Job passiert.
• Das Verschieben wird ausgelöst, wenn die Dateien die Grenzen des operativen Sicherungsfensters überschreiten, und das Kopieren wird ausgelöst, sobald die Sicherungsdatei erscheint.
• Die Überwachung neuer Daten zum Kopieren erfolgt ständig und zum Verschieben wurde sie alle 4 Stunden ausgelöst.

Bei der Betrachtung des neuen Modus schlage ich vor, von einfachen Beispielen zu komplexen Beispielen überzugehen.

Im häufigsten Fall haben wir einfach neue Dateien mit Inkrementen und kopieren sie einfach auf den Kapazitätsschießstand. Unabhängig davon, welcher Modus im Backup-Auftrag verwendet wird, unabhängig davon, ob er zum versiegelten Teil der Kette gehört oder nicht, unabhängig davon, ob unser Betriebsfenster abgelaufen ist. Sie haben es einfach genommen und kopiert.

Der Prozess dahinter ist immer noch die oben beschriebene Dehydrierung. Im Kopiermodus wird außerdem sichergestellt, dass wir keine Blöcke kopieren, die sich bereits auf unserem Speicher befinden. Der einzige Unterschied besteht darin, dass wir, wenn wir im Filmmodus echte Dateien durch Dummy-Dateien ersetzt haben, sie hier in keiner Weise berühren und alles so lassen, wie es ist. Ansonsten handelt es sich um genau den gleichen Dehydrationsindex, der sorgfältig versucht, Geld und Zeit zu sparen.

Es stellt sich die Frage: Wenn Sie sich die Benutzeroberfläche ansehen, besteht die Möglichkeit, beide Optionen gleichzeitig auszuwählen. Wie wird ein solcher kombinierter Modus funktionieren?

Lass uns verstehen.

Der Anfang ist Standard: Eine Backup-Datei wird erstellt und sofort kopiert. Dazu wird ein Inkrement erstellt und ebenfalls kopiert. Dies geschieht so lange, bis wir feststellen, dass die Dateien unser Arbeitsfenster verlassen haben und eine versiegelte Kette entstanden ist. An diesem Punkt führen wir einen Dehydrierungsvorgang durch und ersetzen diese Dateien durch Dummy-Dateien. Dem Kapazitätsschießstand kopieren wir natürlich nichts mehr nach.

Für all diese faszinierende Logik ist nur ein Kontrollkästchen in der Benutzeroberfläche verantwortlich: Backups in den Objektspeicher kopieren, sobald sie erstellt werden.

Warum brauchen wir diesen Kopiermodus?

Noch besser wäre es, die Frage so umzuformulieren: Vor welchen Risiken werden wir mit ihrer Hilfe geschützt? Welches Problem hilft es uns zu lösen?

Die Antwort liegt auf der Hand: Natürlich handelt es sich hier um Datenwiederherstellung. Wenn wir über eine vollständige Kopie der lokalen Daten im Objektspeicher verfügen, können wir unabhängig davon, was mit unserem Produkt passiert, jederzeit Daten aus Dateien wiederherstellen, die sich im bedingten Amazon befinden.

Gehen wir also die möglichen Szenarien durch, vom einfachsten bis zum komplexeren.

Das einfachste Unglück, das uns passieren kann, ist die Unzugänglichkeit einer der Dateien in der Backup-Kette.

Eine traurigere Geschichte ist, dass einer der Bereiche unseres SOBR-Repositorys kaputt ging.

Noch schlimmer wird es, wenn das gesamte SOBR-Repository nicht mehr zugänglich ist, der Kapazitätsschießstand aber funktioniert.
Und alles ist wirklich schlimm – dann stirbt der Backup-Server und Ihr erster Wunsch besteht darin, in zehn Minuten zu versuchen, zur kanadischen Grenze zu fliehen.

Schauen wir uns nun jede Situation einzeln an.

Wenn wir eine (oder sogar mehrere) Sicherungsdateien verloren haben, müssen wir nur noch den Vorgang zum erneuten Scannen des Repositorys starten und die verlorene Datei wird durch eine Dummy-Datei ersetzt. Und mithilfe des Rehydrierungsprozesses (der am Anfang des Artikels besprochen wurde) kann der Benutzer Daten vom Kapazitätsschießstand in den lokalen Speicher herunterladen.

Jetzt ist die Situation komplizierter. Nehmen wir an, dass unser SOBR aus zwei Extents besteht, die im Leistungsmodus ausgeführt werden, was bedeutet, dass unsere .vbk und .vib in einer ziemlich ungleichmäßigen Schicht über sie verteilt sind. Und irgendwann ist einer der Extents nicht mehr verfügbar und der Benutzer muss dringend die Maschine wiederherstellen, deren Daten sich teilweise genau auf diesem Extent befinden.

Der Benutzer startet den Wiederherstellungsassistenten, wählt den Punkt aus, an dem er wiederherstellen möchte, und der Assistent stellt während der Arbeit fest, dass er nicht über alle für die Wiederherstellung erforderlichen Daten lokal verfügt und daher von der Kapazitätsaufnahme heruntergeladen werden muss Galerie. Gleichzeitig werden Blöcke, die im lokalen Speicher verbleiben, nicht aus der Cloud heruntergeladen. Ehre sei dem Wiederherstellungsindex (ja, er wurde auch am Anfang des Artikels erwähnt).

Ein Untertyp dieses Falles besteht darin, dass auf das gesamte SOBR-Repository nicht mehr zugegriffen werden kann. In diesem Fall müssen wir nichts aus dem lokalen Speicher kopieren und alle Blöcke werden aus der Cloud heruntergeladen.

Und die interessanteste Situation ist, dass der Backup-Server gestorben ist. Hier gibt es zwei Möglichkeiten: Der Admin ist großartig und hat Konfigurations-Backups gemacht, und der Admin ist selbst ein böser Pinocchio und hat keine Konfigurations-Backups gemacht.

Im ersten Fall reicht es aus, einfach irgendwo eine Neuinstallation von VBR bereitzustellen und die Datenbank mit Standardmitteln aus einem Backup wiederherzustellen. Am Ende dieses Prozesses wird sich alles wieder normalisieren. Oder es wird gemäß einem der oben genannten Szenarien wiederhergestellt.

Aber wenn der Administrator entweder sein eigener Feind ist oder auch das Konfigurations-Backup einen epischen Fehler erlitten hat, dann werden wir ihn auch hier nicht dem Schicksal überlassen. Für diesen Fall haben wir ein neues Verfahren namens „Import Object Storage“ eingeführt. Damit können Sie den Prozess der manuellen Neuerstellung eines SOBR-Repositorys und des Anhängens eines Kapazitätsschießstands daran mit anschließendem erneuten Scannen überspringen und einfach ein Speicherobjekt zur Vim-Schnittstelle hinzufügen und den Vorgang „Speicher-Repository importieren“ ausführen. Das Einzige, was zwischen Ihnen und Ihren Backups im Weg stehen kann, ist eine Aufforderung zur Eingabe eines Passworts, wenn Ihre Backups verschlüsselt waren.

Hier dreht sich wahrscheinlich alles um den Kopiermodus und wir machen weiter

Versiegelter Modus

Der Grundgedanke besteht darin, dass auf dem ausgewählten SOBR-Bereich des Repositorys keine neuen Backups erscheinen können. Vor v10 hatten wir nur den Wartungsmodus, in dem jegliche Arbeit mit dem Repository komplett verboten war. Eine Art Hardcore-Modus zum Herunterfahren des Speichers, bei dem nur die Evakuieren-Taste verfügbar ist, die Backups einmalig an einen anderen Ort transportiert.

Und der versiegelte Modus ist eine Art „weiche“ Option: Wir verbieten die Erstellung neuer Backups und löschen nach und nach alte Backups entsprechend der gewählten Aufbewahrungsfrist, verlieren dabei aber nicht die Möglichkeit, von gespeicherten Punkten wiederherzustellen. Eine sehr nützliche Sache, wenn wir entweder ein Stück Hardware haben, das sich dem Ende seiner Lebensdauer nähert und es ersetzen muss, oder wir es einfach für etwas Wichtigeres freigeben müssen, es aber nirgendwo hinnehmen und alles auf einmal transportieren können. Oder es kann nicht gelöscht werden.

Dementsprechend ist das Funktionsprinzip recht einfach: Es ist notwendig, alle Schreibvorgänge (das Erscheinen neuer Daten), das Lesen (Wiederherstellung) und das Löschen (Aufbewahrung) zu verbieten.

Beide Modi können gleichzeitig verwendet werden. Beachten Sie jedoch, dass die Wartung eine höhere Priorität hat.

Betrachten Sie als Beispiel eine SOBR, die aus zwei Extents besteht. Nehmen wir an, dass wir in den ersten vier Tagen Backups im Modus „Forward Forever Increatal“ erstellt haben und dann den Extent versiegeln. Dies führt dazu, dass wir die Erstellung eines neuen aktiven Vollzugriffs auf dem zweiten verfügbaren Extent initiieren. Wenn unsere Aufbewahrung vier beträgt, wird die gesamte auf dem versiegelten Bereich befindliche Kette, wenn sie ihre Grenzen überschreitet, guten Gewissens gelöscht.

Es gibt Situationen, in denen die Löschung früher erfolgt. Dies ist beispielsweise eine Vorwärtsinkrementierung mit periodischen Vollabläufen. Wenn wir in den ersten beiden Tagen vollständige Backups erstellt haben und am Donnerstag beschließen, das Repository zu versiegeln, wird am Freitag, wenn ein neues Backup erstellt wird, die Datei für Montag gelöscht, weil Bisher bestehen keine Abhängigkeiten. Und der Punkt selbst hängt von niemandem ab. Dann warten wir, bis vier Punkte auf der verfügbaren Ausdehnung erstellt wurden und löschen die restlichen drei, die nicht unabhängig voneinander gelöscht werden können.

Mit Reverse Incremental ist die Sache einfacher. Darin hängen die ältesten Punkte von nichts ab und können sicher gelöscht werden. Sobald daher eine neue .vbk-Datei auf einem neuen Extent erstellt wird, werden die alten .vrbs-Dateien nacheinander gelöscht.

Übrigens, warum erstellen wir jedes Mal eine neue .vbk-Datei: Wenn wir sie nicht erstellen, sondern die alte Inkrementierungskette fortsetzen würden, würde die alte .vbk-Datei in jedem Modus für unendlich lange Zeit einfrieren und so ihre Löschung verhindern. Daher wurde entschieden, dass wir, sobald der Extent versiegelt ist, ein vollständiges Backup auf dem freien Extent erstellen.

Komplizierter wird es beim Kapazitätsschießstand.

Schauen wir uns zunächst den Kopiermodus an. Nehmen wir an, dass wir vier Tage lang aktiv Backups erstellt haben und dann der Kapazitäts-Schießstand versiegelt wurde. Wir löschen nichts, ertragen aber demütig die Aufbewahrung und löschen anschließend die Daten aus dem Kapazitätsschießstand.

Im Verschiebemodus passiert ungefähr das Gleiche: Wir warten auf die Retusche, löschen die alte im lokalen Speicher und löschen die im Objektspeicher gespeicherte.

Ein interessantes Beispiel mit Forever Forward Inkremental. Wir installieren die Aufbewahrung an drei Stellen und beginnen am Montag mit der Erstellung von Backups, die regelmäßig in die Cloud kopiert werden. Nach der Versiegelung des Speichers werden unter Beibehaltung von drei Punkten weiterhin Backups erstellt, die im Kapazitätsstrich gespeicherten Daten bleiben jedoch abhängig und können nicht gelöscht werden. Daher warten wir bis Donnerstag, wenn unsere .vbk-Datei die Aufbewahrungsdauer überschreitet, und löschen erst dann in aller Ruhe die gesamte gespeicherte Kette.

Und ein kleiner Haftungsausschluss: Alle Beispiele hier werden mit einer Maschine gezeigt. Wenn Sie mehrere davon in Ihrem Backup haben, unterscheidet sich ihre Retusche, je nachdem, ob Active Full erstellt wurde oder nicht.

Das ist im Grunde alles, was dazu gehört. Kommen wir also zum härtesten Feature –

Unveränderlichkeit

Wie bei den vorherigen Punkten geht es zunächst darum, welches Problem diese Funktion löst. Sobald wir unsere Backups irgendwo zur Speicherung hochladen, besteht ein starker Wunsch, ihre Sicherheit zu gewährleisten, das heißt, ihre Löschung und jegliche Änderung während einer bestimmten Aufbewahrungszeit physisch zu verbieten. Einschließlich Administratoren, auch unter ihren Root-Konten. Dadurch können Sie sie vor unbeabsichtigter oder vorsätzlicher Beschädigung schützen. Jeder, der mit AWS arbeitet, ist möglicherweise auf eine ähnliche Funktion namens Object Lock gestoßen.

Schauen wir uns den Modus nun allgemein an und gehen dann auf die Details ein. In unserem Beispiel wird die Unveränderlichkeit für unseren Kapazitätsschießstand mit einer Aufbewahrung von vier Tagen aktiviert. Und der Kopiermodus ist im Backup aktiviert.

Unveränderlichkeit hat keinerlei Wechselwirkung mit der allgemeinen Aufbewahrung. Es werden zum Beispiel keine Extrapunkte oder ähnliches hinzugefügt. Es ist nur so, dass eine Person Backup-Dateien nicht innerhalb von vier Tagen löschen kann. Wenn Sie am Montag ein Backup erstellen, können Sie die Datei erst am Freitag löschen.

Alle zuvor erläuterten Konzepte von Dehydrierung, Indizes und Metadaten funktionieren weiterhin genau gleich. Allerdings mit einer Bedingung: Die Sperre wird nicht nur für Daten, sondern auch für Metadaten gesetzt. Dies geschieht für den Fall, dass ein gerissener Angreifer beschließt, unsere Metadatendatenbank zu löschen und zu verhindern, dass Datenblöcke zu nutzlosem Binärbrei werden.

Jetzt ist ein guter Zeitpunkt, unsere Blockgenerierungstechnologie zu erklären. Oder Blockgenerierung. Berücksichtigen Sie dazu die Situation, die zu seinem Auftreten geführt hat.

Nehmen wir eine Zeitskala von sechs Tagen und markieren unten den Zeitpunkt des erwarteten Ablaufs der Unveränderlichkeit. Am ersten Tag erstellen wir eine Datei, die aus dem Datenblock a und seinen Metadaten besteht. Wenn die Unveränderlichkeit auf drei Tage eingestellt ist, ist es logisch, davon auszugehen, dass die Daten am vierten Tag entsperrt und gelöscht werden. Am zweiten Tag werden wir eine neue Datei2 hinzufügen, bestehend aus Block b mit den gleichen Einstellungen. Block a muss am vierten Tag noch entfernt werden. Doch am dritten Tag passiert etwas Schreckliches – eine File3-Datei wird erstellt, bestehend aus einem neuen Block d und einem Link zum alten Block a. Das bedeutet, dass für einen Block und seine Unveränderlichkeitsflagge auf ein neues Datum zurückgesetzt werden muss, das auf den sechsten Tag verschoben wird. Und hier entsteht ein Problem: In echten Backups gibt es eine große Anzahl solcher Blöcke. Und um den Zeitraum ihrer Unveränderlichkeit zu verlängern, müssen Sie jedes Mal eine große Anzahl von Anfragen stellen. Und tatsächlich wird dies ein fast endloser täglicher Prozess sein, da wir mit hoher Wahrscheinlichkeit bei jeder Kopie große Stapel deduplizierter Blöcke vorfinden werden. Was bedeutet eine große Anzahl an Anfragen von Objektspeicheranbietern? Rechts! Riesige Rechnung am Monatsende.

Und um Ihre Lieblingskunden nicht aus heiterem Himmel für viel Geld bloßzustellen, wurde der Blockgenerierungsmechanismus erfunden. Dies ist ein zusätzlicher Zeitraum, den wir zum festgelegten Unveränderlichkeitszeitraum hinzufügen. Im Beispiel unten beträgt dieser Zeitraum zwei Tage. Aber das ist nur ein Beispiel. In Wirklichkeit verwenden sie eine eigene Formel, die während einer monatlichen Sperre etwa zehn zusätzliche Tage ergibt.

Betrachten wir weiterhin die gleiche Situation, jedoch mit der Blockgenerierung. Am ersten Tag erstellen wir Datei1 aus Block a und Metadaten. Wir addieren den Generierungszeitraum und die Unveränderlichkeit – das bedeutet, dass die Möglichkeit zum Löschen der Datei am sechsten Tag besteht. Wenn wir am zweiten Tag Datei2 erstellen, bestehend aus Block b und einem Link zu Block a, dann passiert mit dem erwarteten Löschdatum nichts. Sie stand da wie am sechsten Tag. Und so versuchen wir, bei der Anzahl der Anfragen Geld zu sparen. Eine Fristverschiebung ist nur dann möglich, wenn der Generierungszeitraum abgelaufen ist. Das heißt, wenn am dritten Tag die neue Datei3 einen Link zu Block a enthält, wird Generation 2 hinzugefügt, da Gen1 bereits abgelaufen ist. Und das voraussichtliche Datum für die Löschung von Block a verschiebt sich auf den achten Tag. Dadurch können wir die Anzahl der Anfragen drastisch reduzieren, um die Lebensdauer deduplizierter Blöcke zu verlängern, was Kunden eine Menge Geld spart.

Die Technologie selbst steht Nutzern von S3- und S3-kompatibler Hardware zur Verfügung, deren Hersteller garantieren, dass sich ihre Implementierung nicht von der von Amazon unterscheidet. Daher die Antwort auf die berechtigte Frage, warum Azure nicht unterstützt wird: Sie verfügen über eine ähnliche Funktion, funktionieren jedoch auf der Ebene von Containern und nicht auf der Ebene einzelner Objekte. Übrigens verfügt Amazon selbst über eine Objektsperre in zwei Modi: Compliance und Governance. Im zweiten Fall bleibt die Möglichkeit bestehen, dass der größte Admin über Admins und Root über Roots trotz Objektsperre die Daten trotzdem löscht. Im Compliance-Fall ist alles unter Kontrolle und niemand kann die Backups löschen. Sogar Amazon-Administratoren (nach ihren offiziellen Aussagen). Dies ist der Modus, den wir unterstützen.

Und wie immer einige nützliche Links:

• Про Blockgenerierung in jedem Detail.
• Alle Informationen zu Veeam Backup & Replication 10 von seiner besten Seite
• О Kapazitätsstufe im Detail

Source: habr.com