Das Capacity Tier (oder wie wir es intern nennen – KapTier) wurde bereits zur Zeit von Veeam Backup and Replication 9.5 Update 4 unter dem Namen Archive Tier eingeführt. Die zugrunde liegende Idee ist es, die Möglichkeit zu schaffen, Backups, die das sogenannte operational restore window überschreiten, in Objektspeicher zu verschieben. Dies half Benutzern, die über wenig Speicherplatz verfügten, Speicherplatz freizugeben. Diese Option wurde Move Mode genannt.

Um diese recht einfache (wie es scheint) Aktion durchzuführen, mussten zwei Bedingungen erfüllt sein: Alle Punkte des verschobenen Backups müssen außerhalb 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 Änderungen ergeben.

In VBR v10 wurde das Konzept jedoch um neue Funktionen ergänzt — Copy Mode, Sealed Mode und eine Sache mit dem kompliziert auszusprechenden Namen Immutability wurden eingeführt.

Darüber werden wir heute sprechen. Zuerst darüber, wie das in VBR9.5u4 funktionierte, und dann über die Änderungen in der zehnten Version.

Und mögen mir die Verfechter einer reinen Sprache verzeihen, aber zu viele Begriffe lassen sich nicht übersetzen.
Deshalb wird es hier eine Menge Anglizismen geben.
Und viele GIFs.
Und Bilder.

Ohne jede Reue. Der Autor des Artikels.

Wie zuvor

Nun, lassen Sie uns mit der Analyse des operational restore window und der sealed backup (oder wie sie in der Dokumentation heißen: Inactive Backup Chain) beginnen. Ohne das Verständnis dieser Konzepte kann die weitere Erklärung nicht erfolgen.

Wie wir im Bild sehen, haben wir eine Backup-Kette mit Datenblöcken, die sich im Performance tier eines SOBR-Repositories befindet, zu dem das Capacity Tier angeschlossen ist. Unser operatives Backup-Fenster beträgt drei Tage.

Daher versiegelt das am Montag erstellte .vbk die vorherige Kette, deren Fenster auf drei Tage eingestellt ist. Und somit kann alles, was älter als diese drei Tage ist, problemlos ins Capacity Tier verschoben werden.

Was genau wurde jedoch unter einer versiegelten Kette verstanden und was konnte in Update 4 ins Capacity Tier verschoben werden?

Für 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ählen.

Im Falle von Reverse sind es alle Dateien, die nicht im operativen Fenster liegen.

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.

Betrachten wir nun die Arbeitsweise mit Backup Copy-Ketten. Hier wurde nur das abgegeben, was unter die GFS-Aufbewahrung fällt. Denn alles, was in neueren Backup Copy-Ketten gespeichert ist, kann auf die eine oder andere Weise geändert werden.

Lassen Sie uns nun unter die Haube schauen. Dort findet ein Prozess statt, der Dehydratisierung genannt wird – das Beibehalten leerer Backup-Dateien auf dem Extent und das Verschieben von Blöcken aus diesen Dateien in das Capacity Tier. Zur Optimierung dieses Prozesses wird der sogenannte Dehydratisierungsindex verwendet, der es ermöglicht, Blöcke, die bereits in das Capacity Tier kopiert wurden, nicht nochmals zu kopieren.

Betrachten wir, wie dies am Beispiel aussieht: Angenommen, wir haben eine .vbk, die aus dem Betriebszeitfenster herausgefallen ist und zu einer versiegelten Kette gehört. 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öcke der verschobenen Datei. In der Metadaten-Datei werden auf der Verlinkungsebene beschrieben, aus welchen Blöcken unsere Datei besteht. Im Bild besteht unsere erste Datei aus den Blöcken a, b, c, und in den Metadaten befinden sich Links zu diesen Blöcken. Wenn wir eine zweite .vbk-Datei haben, die bereit ist, umgezogen zu werden und aus den Blöcken 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öcken und einem neuen enthalten.

Dementsprechend wird der Prozess des Rückfüllens dieser Leerblöcke mit Daten Reghydratisierung genannt. Hierbei wird bereits der eigene Reghydratisierungsindex verwendet, der sich auf die älteste .vbk-Datei auf dem lokalen Performance-Extent stützt. Das bedeutet, wenn der Benutzer eine Datei aus dem Capacity Tier zurückholen möchte, erstellen wir zunächst den Blockindex des ältesten vollständigen Backups und übertragen nur die fehlenden Blöcke aus dem Capacity Tier. Im dargestellten Beispiel fehlt uns für die Reghydratisierung von FullBackup1.vbk gemäß dem Reghydratisierungsindex nur der Block C, den wir aus dem Capacity Tier holen. Wenn das Capacity Tier objektbasierter Cloud-Speicher ist, ermöglicht dies enorme Einsparungen.

Hier mag es scheinen, als wäre 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ösenden Aufgaben: Hier müssen wir große Dateien aus vollständigen Backups kopieren, und nach unseren Untersuchungen liefert ein solcher Deduplikationsalgorithmus selbst dann bessere Ergebnisse, wenn zwischen ihnen ein großer Zeitraum verstrichen ist.

Aber 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öcke, die im Performance-Tier nicht vorhanden sind.

Wie es geworden ist

Damit sind wir am Ende des einführenden Teils. Dieser ist recht detailliert, wie bereits erwähnt, aber ohne diese Details lässt sich nicht erklären, wie die neuen Funktionen funktionieren. Daher ohne weitere Vorrede kommen wir zum Ersten.

Kopiermodus

Baut stark auf bestehenden Technologien auf, trägt jedoch eine völlig andere Nutzungslogik in sich.

Ziel dieses Modus ist es, sicherzustellen, dass alle Daten, die sich im lokalen Extent befinden, eine Kopie im Capacity-Tier haben.

Wenn wir Move- und Copy-Modi direkt vergleichen, ergibt sich Folgendes:

Bewege nur die versiegelte Kette. Im Copy-Modus wird absolut alles transportiert, unabhängig davon, was in der Backup-Job geschieht.
Verschieben tritt in Kraft, wenn Dateien das Zeitfenster des operativen Backups überschreiten, während das Kopieren sofort erfolgt, sobald die Backup-Datei verfügbar ist.
Die Verfolgung neuer Daten zum Kopieren erfolgt kontinuierlich, während das Verschieben alle 4 Stunden aktiv war.

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

Im einfachsten Fall erscheinen einfach neue Dateien mit Inkrementen, und wir kopieren sie einfach in das Capacity-Tier. Unabhängig davon, welcher Modus in der Backup-Job verwendet wird, ob sie zur versiegelten Kette gehört oder nicht, unabhängig davon, ob unser operatives Fenster abgelaufen ist oder nicht. Einfach genommen und kopiert.

Der Prozess, der dahintersteht, ist nach wie vor die Dehydrierung, wie oben beschrieben. Im Kopiermodus sorgt er auch dafür, dass wir keine bereits vorhandenen Blöcke in unserem Objekt Speicher kopieren. Der einzige Unterschied besteht darin, dass wir im Bewegungsmodus die echten Dateien durch Platzhalterdateien ersetzt haben; hier berühren wir sie nicht und lassen alles so, wie es ist. Ansonsten ist es genau dasselbe Dehydrierungs-Index, der sorgfältig versucht, Ihr Geld und Ihre Zeit zu sparen.

Es stellt sich die Frage: Wenn man sich die Benutzeroberfläche ansieht, gibt es die Möglichkeit, beide Optionen gleichzeitig auszuwählen. Wie wird ein solcher Kombinationsmodus funktionieren?

Lass uns das klären.

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ühren wir die Dehydrierungsoperation durch und ersetzen diese Dateien durch Platzhalter. Natürlich kopieren wir erneut nichts auf das Kapazitäts-Tier.

Für all diese faszinierende Logik ist nur ein Häkchen in der Benutzeroberfläche verantwortlich: Copy backups to object storage as soon as they are created.

Warum brauchen wir diesen Kopiermodus?

Es wäre sogar besser, die Frage so umzuformulieren: Vor welchen Risiken schützen wir uns damit? Welches Problem hilft es uns zu lösen?

Die Antwort ist offensichtlich: Es geht um die Wiederherstellung von Daten. Wenn wir im Objekt Speicher eine vollständige Kopie unserer lokalen Daten haben, spielt es keine Rolle, was mit unserem Produkt passiert, wir können die Daten immer von den in einem hypothetischen Amazon gespeicherten Dateien wiederherstellen.

Lass uns daher die möglichen Szenarien von dem einfachsten zum komplexeren durchgehen.

Das einfachste Unglück, das uns widerfahren kann, ist die Nichterreichbarkeit einer der Dateien in der Sicherungskette.

Eine traurigere Geschichte ist, dass einer der Extents unseres SOBR-Repositorys kaputt gegangen ist.

Es wird noch schlimmer, wenn das gesamte SOBR-Repository nicht mehr verfügbar ist, aber das Kapazitäts-Tier weiter funktioniert.
Und alles ist ganz schlecht, wenn der Backup-Server ausfällt und dein erster Wunsch ist, zu versuchen, in zehn Minuten zur kanadischen Grenze zu gelangen.

Und jetzt lassen Sie uns jede Situation einzeln betrachten.

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über haben wir zu Beginn des Artikels gesprochen) kann der Benutzer die Daten aus dem Capacity-Tier in den lokalen Speicher herunterladen.

Jetzt 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äßig über sie verteilt sind. Und irgendwann wird einer der Extents unzugänglich, während der Benutzer dringend eine Maschine wiederherstellen muss, deren Daten sich genau auf diesem Extent befinden.

Der Benutzer startet den Wiederherstellungsassistenten, wählt den Zeitpunkt aus, auf den er wiederherstellen möchte, und der Assistent kommt im Verlauf seiner Arbeit zu dem Ergebnis, dass er nicht alle für die Wiederherstellung benötigten Daten lokal hat, und deshalb müssen diese aus dem Capacity-Tier heruntergeladen werden. Die Blöcke, die sich im lokalen Speicher befinden, werden nicht aus der Cloud heruntergeladen. Ruhm dem Restore-Index (ja, auch darüber haben wir zu Beginn des Artikels gesprochen).

Eine Unterart dieses Falls — das gesamte SOBR-Repository ist unzugänglich geworden. In diesem Fall haben wir nichts von den lokalen Speichern zu kopieren, und alle Blöcke werden aus der Cloud heruntergeladen.

Und die interessanteste Situation — der Backup-Server ist ausgefallen. Hier gibt es zwei Möglichkeiten: 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.

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.

Aber wenn der Administrator sich selbst schadet oder auch das Backup der Konfiguration ein mythisches Missgeschick erleidet, werden wir ihn hier nicht dem Schicksal überlassen. Für diesen Fall haben wir ein neues Verfahren eingeführt, das Import Object Storage genannt wird. Es ermöglicht, den manuellen Prozess der Wiederherstellung des SOBR-Repositories und das Anfügen des Kapazitätstiers mit anschließendem Rescan zu überspringen und einfach den Object Storage in die WIMA-Oberfläche hinzuzufügen 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üsselt waren.

Damit sind wir bei Copy Mode wohl am Ende und gehen weiter zu

Sealed Mode

Die Grundidee ist, dass auf dem ausgewählten Extent des SOBR-Repositories keine neuen Backups erstellt werden können. Bis zur Version v10 hatten wir nur den Wartungsmodus, bei dem jegliche Arbeiten am Repository vollständig verboten waren. Eine Art Hardcore-Modus, um den Speicher aus dem Betrieb zu nehmen, in dem nur die Schaltfläche Evacuate zur Verfügung steht, die einmalig Backups auf einen anderen Extent verschob.

Der Sealed Mode ist eine Art „sanfte“ Variante: Wir verbieten die Erstellung neuer Backups und entfernen die alten schrittweise gemäß der gewählten Aufbewahrungsrichtlinie, verlieren aber dabei nicht die Möglichkeit, aus den gespeicherten Punkten wiederherzustellen. Sehr nützlich, wenn entweder die Lebensdauer des Geräts dem Ende zugeht und es ersetzt werden muss oder es einfach für etwas Wichtigeres freigegeben werden muss, ohne alles auf einmal verschieben zu können. Oder es kann nicht gelöscht werden.

Entsprechend ist der Arbeitsprinzip sehr einfach: Alle Schreiboperationen (Erscheinen neuer Daten) müssen verboten werden, während Leseoperationen (Wiederherstellungen) und Löschoperationen (Aufbewahrung) erlaubt sind.

Beide Modi können gleichzeitig verwendet werden, man muss jedoch berücksichtigen, dass der Wartungsmodus Vorrang hat.

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ührt dazu, dass wir die Erstellung eines neuen Aktiv-Full Backups auf dem zweiten verfügbaren Extent initiieren. Wenn unsere Aufbewahrung vier beträgt, dann wird die gesamte Kette, die sich auf dem versiegelten Extent befindet, gelöscht, sobald sie dessen Grenzen überschreitet.

Es gibt Situationen, in denen die Löschung früher erfolgt. Zum Beispiel beim Forward Incremental mit zeitweiligen Full-Backups. Wenn wir an den ersten zwei Tagen vollständige 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öscht, da es bis zu diesem Punkt keine Abhängigkeiten gibt. Und dieser Punkt ist von niemandem abhängig. Danach warten wir, bis vier Punkte im verfügbaren Extent erstellt wurden, und löschen die verbleibenden drei, die nicht unabhängig voneinander gelöscht werden können.

Bei Reverse Incremental verhält es sich einfacher. Hier sind die ältesten Punkte von nichts abhängig und können problemlos gelöscht werden. Sobald ein neues .vbk im neuen Extent erstellt wird, werden die alten .vrb nacheinander gelöscht.

Übrigens, warum erstellen wir jedes Mal ein neues .vbk: Wenn wir es nicht erstellen und die alte Kette der Inkremente fortsetzen würden, würde das alte .vbk für unendlich lange Zeit in jedem Modus hängen bleiben und seine Löschung verhindern. Daher wurde beschlossen, dass sobald der Extent versiegelt ist, wir ein Full Backup im freien Extent erstellen.

Komplizierter ist die Situation mit dem Capacity Tier.

Betrachten wir zuerst den Copy Mode. Angenommen, wir haben vier Tage lang aktiv Backups erstellt und danach wurde der Capacity Tier versiegelt. Wir löschen nichts und warten geduldig auf die Retention, bevor wir die Daten vom Capacity Tier löschen.

Es passiert ungefähr dasselbe im Move Mode – wir warten auf die Retention, löschen das Alte im lokalen Speicher und entfernen das, was im Object Storage gespeichert ist.

Ein 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ässig 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ängig und können nicht gelöscht werden. Daher warten wir bis Donnerstag, wenn unser .vbk die Retention überschreitet, und löschen dann die gesamte gespeicherte Kette.

Und 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.

Das ist im Prinzip alles. Lassen Sie uns also zur härtesten Funktion übergehen –

Immutability

Wie bei den vorherigen Punkten geht es zuerst darum, welches Problem diese Funktion löst. Sobald wir unsere Backups irgendwo zur Speicherung ablegen, entsteht der dringende Wunsch, ihre Integrität zu garantieren, das heißt, ihre Löschung und jede Modifikation während der festgelegten Aufbewahrungsfrist physisch zu verhindern. Auch durch Administratoren oder unter ihren Root-Konten. Dies schützt sie vor versehentlicher oder absichtlicher Beschädigung. Wer mit AWS arbeitet, könnte auf eine ähnliche Funktion mit dem Namen Object Lock gestoßen sein.

Jetzt betrachten wir den Modus in allgemeinen Worten und tauchen dann in die Details ein. In unserem Beispiel wird die Unveränderlichkeit für unser Kapazitätstier mit einer Aufbewahrungsfrist von vier Tagen aktiviert. Im Backup ist der Modus Kopie aktiviert.

Die Unveränderlichkeit hat keinerlei Einfluss auf die allgemeine Aufbewahrungsfrist. Sie fügt keine zusätzlichen Punkte oder ähnliches hinzu. Einfach gesagt kann eine Person die Backup-Dateien während der vier Tage nicht löschen. Wenn am Montag ein Backup erstellt wird, kann die Datei erst am Freitag gelöscht werden.

Alle zuvor erklärten Konzepte der Dehydrierung, Indizes und Metadaten funktionieren weiterhin genau gleich. Mit einer Ausnahme – die Sperre wird nicht nur für die Daten, sondern auch für die Metadaten gesetzt. Dies dient dem Zweck, falls ein hinterhältiger Angreifer unsere Metadatenbank löschen möchte und damit die Daten nicht in eine nutzlose binäre Suppe verwandelt werden.

Und jetzt ist der perfekte Zeitpunkt, um unsere Technologie der Blockerzeugung zu erklären. Oder block generation. Lassen Sie uns dafür die Situation betrachten, die zu ihrer Entstehung führte.

Lassen Sie uns einen Zeitrahmen von sechs Tagen nehmen und von unten die Zeit des erwarteten Ablaufs der Unveränderlichkeit markieren. Am ersten Tag erstellen wir eine Datei, die aus Block a und seinen Metadaten besteht. Wenn die Unveränderlichkeit auf drei Tage festgelegt ist, ist es logisch anzunehmen, dass am vierten Tag die Daten entsperrt und gelöscht werden. Am zweiten Tag fügen wir eine neue file2 hinzu, die aus Block b mit denselben Einstellungen besteht. Block a sollte am vierten Tag immer noch gelöscht werden. Am dritten Tag passiert jedoch etwas Schreckliches – 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änderlichkeitsflag für Block a auf eine neue Frist zurückgesetzt werden muss, die auf den sechsten Tag verschoben wird. Hier entsteht ein Problem – in realen Backups solcher Blöcke gibt es eine riesige Menge. Und um die Unveränderlichkeitsdauer zu verlängern, müssen jedes Mal eine enorme Anzahl von Anfragen gestellt werden. Das wird tatsächlich ein nahezu endloser täglicher Prozess sein, denn mit großer Wahrscheinlichkeit werden wir bei jeder Kopie riesige Mengen deduplizierter Blöcke finden. Und was bedeutet eine große Anzahl von Anfragen bei den Anbietern von Objektspeichern? Richtig! Eine riesige Rechnung am Ende des Monats.

Und um nicht grundlos eine maßgebliche Summe für unsere geschätzten Kunden zu veranschlagen, wurde der Mechanismus der Blockerzeugung erfunden. Das ist ein zusätzlicher Zeitraum, den wir zu dem festgelegten Zeitraum der Unveränderlichkeit hinzufügen. Im folgenden Beispiel beträgt dieser Zeitraum zwei Tage. Aber das ist nur ein Beispiel. In der Realität wird eine eigene Formel verwendet, die etwa zehn zusätzliche Tage bei einer monatlichen Sperre ergibt.

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änderlichkeit – das bedeutet, dass die Möglichkeit, die Datei zu löschen, 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öschdatum 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ßt, wenn am dritten Tag die neue File3 einen Verweis auf Block a enthält, wird die Generation 2 hinzugefügt, da Gen1 bereits abgelaufen ist. Und das erwartete Löschdatum von Block a verschiebt sich auf den achten Tag. Dies ermöglicht es uns, die Anzahl der Anfragen zur Verlängerung der Lebensdauer deduplizierter Blöcke dramatisch zu reduzieren, was unseren Kunden viel Geld spart.

Die Technologie selbst steht den Nutzern von S3 und S3-kompatibler Hardware zur Verfügung, deren Hersteller garantieren, dass ihre Implementierung sich nicht von der von Amazon unterscheidet. Daraus ergibt sich die berechtigte Frage, warum Azure nicht unterstützt wird – sie haben eine ähnliche Funktion, aber diese funktioniert auf Container-Ebene und nicht auf der Ebene einzelner Objekte. Übrigens gibt es bei Amazon selbst Object Lock in zwei Modi: Compliance und Governance. Im zweiten Fall bleibt die Möglichkeit bestehen, dass der größte Admin über den Admins und Root über den Roots, trotz Object Lock, dennoch Daten löschen kann. Im Compliance-Fall ist alles fest verankert, und Backups können von niemandem gelöscht werden. Selbst nicht von den Admins bei Amazon (laut ihren offiziellen Aussagen). Wir unterstützen genau diesen Modus.