Der Kapazitätstier (oder wie wir intern sagen — kaptir) wurde noch zu Zeiten von Veeam Backup and Replication 9.5 Update 4 unter dem Namen Archivtier eingeführt. Die zugrunde liegende Idee ist es, die Möglichkeit zu geben, Backups, die aus dem sogenannten operational restore window gefallen sind, in Objektspeicher zu verschieben. Dies half, den Speicherplatz für Benutzer zu räumen, die nur wenig davon hatten. Diese Option wurde als Move Mode bezeichnet.

Um diese scheinbar einfache (wie es aussieht) Aktion auszuführen, mussten zwei Bedingungen erfüllt sein: Alle Punkte aus dem zu verschiebenden Backup mussten außerhalb des genannten operational restore window liegen, das im UI explizit festgelegt wird. Und zweitens: Die Kette musste in sogenannter „versiegelter Form“ (sealed backup chain oder Inactive Backup Chain) vorliegen. Das bedeutet, dass es im Laufe der Zeit in dieser Kette keine Änderungen gibt.

In VBR v10 wurde das Konzept jedoch um neue Funktionen erweitert — es kam der Copy Mode, Sealed Mode und ein schwer auszusprechender Begriff namens Immutability hinzu.

Heute werden wir über diese aufregenden Dinge sprechen. Zuerst darüber, wie es in VBR9.5u4 funktionierte, und dann über die Veränderungen in der zehnten Version.

Und mögen mir die Verfechter der reinen Sprache vergeben, aber zu viele Begriffe sind unmöglich zu übersetzen.
Es wird also eine Flut von Anglizismen geben.
Und viele GIFs.
Und Bilder.

Ohne jegliche Reue. Der Autor des Artikels.

Wie bereits erwähnt

Nun, fangen wir mit der Analyse des operational restore window und sealed backup (oder wie sie in der Dokumentation Inactive Backup Chain heißen) an. Ohne ihr Verständnis kann ich nichts weiter erklären.

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

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 älter als drei Tage ist, in die Capacity Tier zu verschieben.

Aber was genau war mit der sealed Kette gemeint und was konnte in der Capacity Tier im Update 4 geschickt werden?

Für Forward Incremental ist das Zeichen für 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ählen.

Im Falle von Reverse sind das alle Dateien, die nicht im Betriebsfenster liegen.

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.

Schauen 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önnte auf die eine oder andere Weise verändert werden.

Werfen wir nun einen Blick unter dieHaube. Dort findet ein Prozess statt, der als Dehydrierung bezeichnet wird — das Hinterlassen von leeren Backup-Dateien auf dem Extent und das Verschieben von Blöcken aus diesen Dateien in das Capacity Tier. Zur Optimierung dieses Prozesses wird ein sogenannter Dehydrierungsindex verwendet, der es ermöglicht, Blöcke nicht zu kopieren, die bereits in das Capacity Tier kopiert wurden.

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ört. 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öcke der zu verschiebenden Datei. In der Metadaten-Datei auf der Verlinkungsebene wird beschrieben, aus welchen Blöcken unsere Datei besteht. In dem Bild besteht unsere erste Datei aus den Blöcken a, b, c, und in den Metadaten sind die Links zu diesen Blöcken platziert. Wenn wir eine zweite .vbk Datei haben, die bereit zur Verschiebung ist und aus den Blöcken 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öcken und einem neuen enthalten.

Der Prozess, diese Platzhalter mit Daten zu füllen, wird als Rehydrierung bezeichnet. Dabei wird bereits der spezifische Rehydrierungsindex verwendet, der auf der ältesten .vbk-Datei im lokalen Performance-Extent basiert. Das bedeutet, wenn der Nutzer eine Datei aus dem Capacity-Tier wiederherstellen möchte, erstellen wir zunächst einen Blockindex des ältesten vollständigen Backups und übertragen nur die fehlenden Blöcke aus dem Capacity-Tier. Im dargestellten Beispiel müssen wir, um FullBackup1.vbk gemäß 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öglicht das enorme Kosteneinsparungen.

Hier mag es den Anschein erwecken, dass diese Technologie der in WAN-Beschleunigern verwendeten ähnelt, aber das ist nur eine Täuschung. In den Beschleunigern erfolgt die globale Deduplication, während hier eine lokale innerhalb jeder Datei basierend auf einem bestimmten Offset verwendet wird. Dies liegt an den unterschiedlichen zu lösenden Aufgaben: Hier müssen wir große Dateien von vollständigen Backups kopieren, und unseren Untersuchungen zufolge liefert dieser Deduplication-Algorithmus auch über lange Zeiträume hinweg die besten Ergebnisse.

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

So ist es geworden

Das wäre alles zur Einleitung. Sie ist recht detailliert, aber wie bereits erwähnt, ohne diese Details lässt sich nicht erklären, wie die neuen Funktionen arbeiten. Daher kommen wir ohne weitere Umschweife zum ersten Punkt.

Copy-Modus

Basiert größtenteils auf bestehenden Technologien, verfolgt jedoch eine völlig andere Logik der Nutzung.

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

Wenn man die Modi Move und Copy direkt vergleicht, ergibt sich Folgendes:

Verschieben kann man nur eine versiegelte Kette. Im Copy-Modus wird alles transportiert, unabhängig davon, was in dem Backup-Job geschieht.
Das Verschieben tritt in Kraft, wenn Dateien die Grenzen des operativen Backup-Fensters überschreiten, während das Kopieren sofort erfolgt, sobald die Backup-Datei verfügbar ist.
Die Überwachung neuer Daten zum Kopieren erfolgt kontinuierlich, während das Verschieben alle 4 Stunden aktiviert wird.

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

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

Der Prozess dahinter ist nach wie vor die Dehydrierung, wie oben beschrieben. Im Kopiermodus wird auch darauf geachtet, dass wir keine Blöcke 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ährend wir hier nichts ändern und alles so belassen, wie es ist. Ansonsten handelt es sich um denselben Dehydrierungsindex, der sorgfältig darauf abzielt, Ihre Kosten und 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 kombinierter Modus funktionieren?

Lassen Sie uns das klären.

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ühren wir den Dehydrierungsprozess durch und ersetzen diese Dateien durch Platzhalter. Selbstverständlich kopieren wir keine Daten erneut in die Kapazitätstabelle.

Für diese spannende Logik ist lediglich ein Häkchen in der Benutzeroberfläche verantwortlich: 'Sicherungen sofort bei ihrer Erstellung in den Objektspeicher kopieren.'

Warum brauchen wir diesen Kopiermodus?

Es ist 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 Datenwiederherstellung. Wenn wir eine vollständige Kopie der lokalen Daten im Objektspeicher 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.

Deshalb lassen Sie uns die möglichen Szenarien von den einfachsten bis zu den komplexesten durchgehen.

Die einfachste Bedrohung, die uns treffen kann, ist die Nichtverfügbarkeit einer der Dateien in der Backup-Kette.

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

Es wird noch schlimmer, wenn das gesamte SOBR-Repository nicht mehr verfügbar ist, aber das Kapazitätstier noch funktioniert.
Und es wird richtig schlimm, wenn der Backup-Server ausfällt und dein erster Wunsch ist, in zehn Minuten zur kanadischen Grenze zu rennen.

Jetzt lassen Sie uns jede Situation einzeln betrachten.

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ätstier in den lokalen Speicher herunterladen.

Jetzt 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äßig verteilt sind. Und zu einem bestimmten Zeitpunkt wird eines der Extents nicht verfügbar, während der Benutzer dringend die Maschine wiederherstellen muss, deren Daten sich genau auf diesem Extent befinden.

Der Benutzer startet den Wiederherstellungsassistenten, wählt den Punkt aus, auf den er wiederherstellen möchte, und der Assistent erkennt während des Vorgangs, dass ihm alle notwendigen Daten zur Wiederherstellung lokal nicht zur Verfügung stehen, und dass sie daher aus dem Kapazitätstier heruntergeladen werden müssen. Dabei werden die Blöcke, die im lokalen Speicher verbleiben, nicht aus der Cloud heruntergeladen. Gepriesen sei das Restore-Index (ja, auch darüber wurde zu Beginn des Artikels gesprochen).

Eine Unterart dieses Falls ist, dass das gesamte SOBR-Repository nicht mehr verfügbar ist. In diesem Fall haben wir nichts von lokalen Speichern zu kopieren, und alle Blöcke werden aus der Cloud heruntergeladen.

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.

Im ersten Fall reicht es aus, irgendwo eine saubere Installation von VBR bereitzustellen und die Datenbank aus dem Backup mit den standardmäßigen Mitteln wiederherzustellen. Am Ende dieses Prozesses wird alles wieder seinen gewohnten Gang nehmen. Alternativ kann es nach einem der oben genannten Szenarien wiederhergestellt werden.

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ür diesen Fall haben wir ein neues Verfahren eingeführt, das Import Object Storage genannt wird. Es ermöglicht, den manuellen Wiederherstellungsprozess des SOBR-Repositorys und das Anhängen von Kapazitäts-Tiers mit nachfolgendem Rescan zu überspringen, und einfach Object Storage in die Vima-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 zur Eingabe eines Passworts, falls Ihre Backups verschlüsselt sind.

Das war es mit dem Copy Mode, und wir kommen jetzt zu

Sealed Mode

Die Grundidee ist, dass im ausgewählten Extent des SOBR-Repositorys keine neuen Backups erscheinen dürfen. Bis v10 hatten wir nur den Maintenance Mode, bei dem jegliche Arbeit mit dem Repository vollständig untersagt war. Ein sozusagen hardcore Modus zur Auslagerung des Speichers, bei dem nur die Schaltfläche Evacuate verfügbar ist, die einmalig Backups auf einen anderen Extent verlegt.

Ein Versiegelter Modus ist eine Art „sanfte“ Variante: Wir verbieten das Erstellen neuer Backups und entfernen schrittweise alte gemäß dem gewählten Retentionszeitraum, verlieren dabei jedoch nicht die Möglichkeit, aus den gespeicherten Punkten wiederherzustellen. Dies ist äußerst nützlich, wenn unsere Hardware entweder das Ende ihrer Lebensdauer erreicht und ersetzt werden muss oder einfach für etwas Wichtigeres freigegeben werden muss, und es keinen Ort gibt, um alles auf einmal zu verschieben. Oder es kann nicht gelöscht werden.

Das Prinzip funktioniert entsprechend ganz einfach: Man muss alle Schreiboperationen (das Erscheinen neuer Daten) verbieten und die Lese- (Wiederherstellungen) sowie Löschoperationen (Retentionszeitraum) erlauben.

Beide Modi können gleichzeitig verwendet werden, wobei jedoch zu beachten ist, dass die Wartung Vorrang hat.

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

Es gibt Situationen, in denen die Löschung früher erfolgt. Zum Beispiel bei der Forward Incremental-Backups mit periodischen Full-Backups. Wenn in den ersten beiden Tagen vollständige 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öscht, da es zu diesem Punkt keine Abhängigkeiten gibt. Und der Punkt selbst 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.

Die Sache ist einfacher mit Reverse Incremental. Bei dieser Methode sind die ältesten Punkte von nichts abhängig und können problemlos gelöscht werden. Daher werden, sobald ein neues .vbk im neuen Extent erstellt wurde, die alten .vrb nacheinander gelöscht.

Übrigens, warum wir jedes Mal ein neues .vbk erstellen: Wenn wir es nicht erstellen und die alte Inkrementenkette fortsetzen würden, würde das alte .vbk in jedem Modus ewig hängen bleiben, was seine Löschung verhindern würde. Daher wurde beschlossen, dass jedes Mal, wenn der Extent versiegelt wird, ein vollständiges Backup im freien Extent erstellt wird.

Die Angelegenheit wird schwieriger mit dem Capacity Tier.

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öschen nichts und halten geduldig die Retention ein, bevor wir die Daten im Capacity Tier löschen.

Ähnliches passiert im Move-Modus — wir warten die Retention ab, löschen die alten Daten im lokalen Speicher und entfernen die in der Object Storage gespeicherten Daten.

Ein interessantes Beispiel für Forever Forward Incremental. Wir stellen die Retention auf drei Punkte ein und beginnen am Montag mit der Erstellung von Backups, die zuverlässig 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ängig und können nicht gelöscht werden. Daher warten wir bis Donnerstag, wenn unser .vbk die Retention überschreitet, und erst dann löschen wir die gesamte gespeicherte Kette.

Und 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ührt wurde oder nicht.

Das wäre im Prinzip alles. Lass uns also zur extremsten Funktion übergehen —

Immutability

Wie bei den vorherigen Punkten beginnt alles mit der Frage, welches Problem diese Funktion löst. Sobald wir unsere Backups irgendwo zur Speicherung exportieren, entsteht der dringende Wunsch, deren Sicherheit zu gewährleisten, also physisch ihr Löschen und jede Modifikation während der festgelegten Aufbewahrungsfrist zu verbieten. Dazu gehört auch der Zugriff durch Admins mit ihren Root-Konten. Dies schützt vor versehentlicher oder absichtlicher Beschädigung. Wer mit AWS arbeitet, könnte eine ähnliche Funktion unter dem Namen Object Lock getroffen haben.

Lassen Sie uns zunächst den Modus allgemein betrachten und dann in die Details eintauchen. In unserem Beispiel wird die Unveränderlichkeit für unseren Kapazitätstyp mit einer Aufbewahrungsfrist von vier Tagen aktiviert. Im Backup ist der Modus Kopie aktiviert.

Die Unveränderlichkeit hat keinen Einfluss auf die allgemeine Aufbewahrungsfrist. Zum Beispiel fügt sie keine zusätzlichen Punkte hinzu oder ähnliches. Für vier Tage kann niemand die Dateien der Backups löschen. Wenn am Montag ein Backup erstellt wird, kann die Datei erst am Freitag gelöscht werden.

Alle zuvor erläuterten Konzepte der Dehydrierung, Indizes und Metadaten funktionieren weiterhin genau so. Mit einer Ausnahme: Der Block wird nicht nur für Daten, sondern auch für Metadaten festgelegt. Dies geschieht für den Fall, dass ein hinterhältiger Angreifer beschließt, unsere Metadatenbank zu löschen, damit die Datenblöcke nicht in eine nutzlose binäre Masse verwandelt werden.

Jetzt ist ein großartiger Moment, um unsere Technologie zur Blockgenerierung zu erklären. Oder block generation. Lassen Sie uns dafür eine Situation betrachten, die zu ihrer Entstehung geführt hat.

Nehmen wir eine Zeitspanne von sechs Tagen und markieren wir von unten die erwartete Zeit des Ablaufs der Unveränderlichkeit. Am ersten Tag erstellen wir eine Datei, die aus Block a und seinen Metadaten besteht. Wenn die Unveränderlichkeit auf drei Tage gesetzt ist, ist es logisch anzunehmen, dass am vierten Tag die Daten entsperrt und gelöscht werden. Am zweiten Tag fügen wir eine neue Datei file2 hinzu, die aus Block b mit denselben Einstellungen besteht. Block a sollte am vierten Tag immer noch gelöscht werden. Aber am dritten Tag passiert das Unfassbare – 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änderlichkeitsflag für Block a auf einen neuen Zeitraum zurückgesetzt werden muss, der auf den sechsten Tag verschoben wird. Und hier tritt das Problem auf – in realen Backups solcher Blöcke gibt es eine immense Menge. Um deren Unveränderlichkeitszeitraum zu verlängern, müssen ständig eine große Anzahl von Anfragen gestellt werden. Und tatsächlich wird dies ein fast endloser täglicher Prozess sein, da wir mit hoher Wahrscheinlichkeit bei jedem Kopiervorgang riesige Mengen deduplizierter Blöcke finden werden. Was bedeutet eine große Anzahl von Anfragen bei Anbietern von Objektspeichern? Richtig! Eine hohe Rechnung am Monatsende.

Um zu verhindern, dass wir unseren geschätzten Kunden unverhältnismäßig hohe Beträge in Rechnung stellen, wurde der Mechanismus der Blockgenerierung eingeführt. Dabei handelt es sich um einen zusätzlichen Zeitraum, den wir dem festgelegten Unveränderlichkeitszeitraum hinzufügen. Im folgenden Beispiel beträgt dieser Zeitraum zwei Tage. Dies dient jedoch nur als Beispiel. In der Realität wird eine eigene Formel verwendet, die bei einer monatlichen Sperre etwa zehn zusätzliche Tage ergibt.

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ät — das bedeutet, dass die Möglichkeit, die Datei zu löschen, am sechsten Tag besteht. Wenn wir am zweiten Tag File2 erstellen, das aus Block b und einem Verweis auf Block a besteht, ändert sich das voraussichtliche Löschdatum nicht. Es bleibt am sechsten Tag stehen. Damit versuchen wir, die Kosten für die Anzahl der Anfragen zu sparen. Die einzige Situation, in der sich der Zeitraum verschieben kann, ist, wenn die Generationenperiode abgelaufen ist. Das heißt, wenn am dritten Tag File3 einen Verweis auf Block a enthält, wird Generation 2 hinzugefügt, da Gen1 bereits abgelaufen ist. Das voraussichtliche Löschdatum von Block a verschiebt sich dann auf den achten Tag. Dadurch können wir die Anzahl der Anfragen zur Verlängerung der Lebensdauer deduplizierter Blöcke erheblich reduzieren, was unseren Kunden eine Menge Geld spart.

Die Technologie ist für Benutzer von S3 und S3-kompatibler Hardware verfügbar, deren Hersteller garantieren, dass ihre Implementierung der von Amazon entspricht. Daraus ergibt sich die legitime Frage, warum Azure nicht unterstützt wird – sie haben eine ähnliche Funktion, die jedoch auf Container-Ebene und nicht auf separaten Objekten arbeitet. Übrigens gibt es bei Amazon Object Lock in zwei Modi: Compliance und Governance. Im zweiten Fall bleibt die Möglichkeit bestehen, dass der größte Admin unter den Admins und der Root unter den Roots, trotz des Object Locks, dennoch Daten gelöscht. Im Compliance-Modus sind alle Daten fest verankert, und Backups können von niemandem gelöscht werden, selbst nicht von Amazon-Administratoren (laut ihren offiziellen Aussagen). Wir unterstützen diesen Modus.