Ein nie wiederhergestelltes Backup ist keins

Dem Titel stimmen alle zu. Fast kein Dashboard bildet ihn ab.

Der Grund ist nicht Faulheit. Es liegt daran, dass drei wirklich verschiedene Belege durch dasselbe Rohr ankommen, in benachbarten Spalten landen und am Ende als ein grüner Haken dargestellt werden. Sobald sie ein Haken sind, borgt sich die stärkste Aussage der Gruppe stillschweigend die Glaubwürdigkeit der billigsten, und ein Kunde liest „geschützt“, während in Wahrheit ein Auftrag mit null geendet hat.

Wir haben eine Runde damit verbracht, diese drei in unserem eigenen Schema auseinanderzunehmen, und eine zweite damit, einen echten Proxmox Backup Server zu vermessen, um herauszufinden, welchen davon er uns tatsächlich geben kann. Das ist dabei herausgekommen.

Drei Nachweise, und sie sind nicht austauschbar

Der erste ist der billigste und der, den jedes Produkt zeigt. Er ist genau das wert, was er sagt: Ein Vorgang ist fertig geworden. Bei dem, was die vzdump-Modi von Proxmox garantieren, geht es darum, was dieser Vorgang über den Zustand des Gastes zusichern konnte und was nicht, und keine dieser Zusicherungen überlebt danach die Begegnung mit einem beschädigten Chunk-Speicher.

Der zweite ist ein echter Beleg, und er lässt sich leicht überinterpretieren. Dazu weiter unten mehr.

Der dritte ist der einzige, der die Frage beantwortet, die ein Kunde tatsächlich stellt, und er ist der einzige, der verlangt, dass Sie etwas bauen, statt etwas zu lesen. Diese Asymmetrie ist der Grund, warum er meistens fehlt.

Was ein grünes Verify wirklich behauptet

Der Proxmox Backup Server kann einen Snapshot verifizieren: Er liest die Chunks erneut und prüft sie gegen das Manifest. Ist das geschehen, trägt die Snapshot-Auflistung ein verification-Objekt mit einem Zustand darin.

Das ist etwas wirklich Nützliches, und es ist enger, als es sich anfühlt. Es sagt, dass die Bytes auf diesem Datastore die Bytes sind, die geschrieben wurden. Es sagt nicht, dass die Maschine starten wird. Es sagt nicht, dass die Anwendung darin anlaufen wird. Es sagt nicht, dass die Datenbank im Moment des Snapshots in einem konsistenten Zustand war. Und wenn das Backup clientseitig verschlüsselt ist, sagt es nicht, dass irgendjemand den Schlüssel noch hat: Eine Integritätsprüfung auf Geheimtext geht bestens durch, wenn der Schlüssel weg ist.

Der Zustand lebt deshalb in einer eigenen Spalte in unserem Schema, und im Code ist dokumentiert, dass er zu Nachweis zwei gehört und nie mit einer nachgewiesenen Wiederherstellung vermischt werden darf. Nachweis drei bekommt seine eigene Tabelle an dem Tag, an dem ihn jemand baut. Einen vierten Wert zu einer bestehenden Aufzählung hinzuzufügen wäre ein halber Tag Arbeit gewesen und eine dauerhafte Quelle der Verwirrung.

Ein fehlendes Feld ist kein Fehlschlag

Unsere Spalte hat drei Werte: ok, fehlgeschlagen und unbekannt. Der mittlere ist nicht der interessante.

Gemessen gegen einen laufenden Proxmox Backup Server 4.2 mit echten Snapshots darauf: Ein Snapshot, der nie durch einen Verify-Task gelaufen ist, hat schlicht keinen verification-Schlüssel. Das Feld fehlt. Das ist etwas anderes als ein Verify, der gelaufen und fehlgeschlagen ist, und beides zusammenzuwerfen kostet Sie in beide Richtungen. Setzen Sie den Standard auf ok, und jeder ungeprüfte Snapshot wird zu einem geprüften. Setzen Sie ihn auf fehlgeschlagen, und jeder historische Snapshot in Ihrer Datenbank steht plötzlich in Flammen. Der dritte Wert existiert, um das einzig Wahre zu sagen: Es ist nichts bekannt.

Ein einfacher Proxmox-Speicher füllt die Spalte überhaupt nie, denn seine Inhaltsauflistung kennt kein Verifikationskonzept. Das ist keine Lücke in unserer Integration. Das ist die Antwort.

Noch ein ehrliches Detail, denn es ist von der Sorte, die gern weggerundet wird. Das verification-Objekt, das wir gemessen haben, trägt einen Zustand und eine Task-Kennung, und keinen Zeitstempel. Der Zeitpunkt, den wir als verifiziert festhalten, ist deshalb der Moment, in dem wir diesen Zustand zuerst gesehen haben, und das ist eine andere Frage als die, wann der Speicher das verifiziert hat. Er beantwortet: seit wann wissen wir das. Legt eine künftige Version die echte Zeit offen, sollte die Spalte anfangen, sie zu tragen, und der Kommentar, der all das erklärt, sollte gelöscht werden.

Leer muss leer bedeuten

Hier kommt die schärfste Regel des ganzen Gebiets, und sie hat mit Verifikation nichts zu tun.

Jedes System, das Wiederherstellungspunkte regelmäßig auflistet, leitet am Ende etwas aus der Abwesenheit eines Snapshots ab: Er war letzte Woche da, er ist jetzt nicht da, also wurde er ausgedünnt oder gelöscht. Dieser Schluss trägt Last, und er ist nur dann gültig, wenn eine erfolgreiche leere Auflistung wirklich leer ist.

Wir haben deshalb gemessen, was ein Backup-Server tatsächlich antwortet, wenn eine Auflistung schiefgeht, denn ein leeres Feld und ein Fehler, der wie ein leeres Feld aussieht, müssen unterscheidbar sein. Vier Fälle, alle gegen dieselbe laufende 4.2-Instanz gemessen:

• ein leerer Namespace antwortet mit 200 und einem leeren Feld;
• ein Namespace, den es nicht gibt, antwortet mit 400 und einem Nicht-gefunden-Fehler, nicht mit einer leeren Liste;
• ein Datastore, den der Token nicht auditieren darf, antwortet mit 403;
• ein ungültiger Token antwortet mit 401.

Drei dieser vier müssen zu bestimmten Fehlern werden statt zu Ergebnissen. Wenn einer von ihnen Ihre Abgleichslogik als „die Auflistung war erfolgreich und dort ist nichts“ erreichen darf, dann markiert ein Tippfehler in einem Namespace-Namen die gesamte Backup-Historie eines Kunden als verschwunden. Der Fehlerfall ist kein Ausfall. Es ist ein Bildschirm, der still aufhört zu erwähnen, dass es Backups gibt.

Das ist dieselbe Klasse von Falle wie ein Hypervisor, der mit 200 antwortet, bevor die Arbeit begonnen hat: Der Antwortcode ist in Ordnung, und er ist nicht die Antwort auf Ihre Frage.

Die Zugangsdaten sollten nichts kaputt machen können

Die nützlichste Sicherheitsentscheidung hier ist zugleich die langweiligste.

Der Token, den ein Kunde für ein Backup-Ziel anlegt, muss Snapshots und den Zustand des Datastores lesen können. Er muss nicht löschen, vergessen, ausdünnen oder verifizieren können. Das sind eigene Vorgänge, die demjenigen gehören, dem der Speicher gehört, nach seinem eigenen Zeitplan, mit seiner eigenen Identität.

Wir haben die Integration ganz ohne schreibenden Befehl gebaut, was die Aussage strukturell statt anstrebenswert macht, und haben es dann von der anderen Seite geprüft: Mit einem Token, der nur Auditrechte hält, antwortet ein Löschvorgang auf einem Snapshot mit 403. Das ist die Form, die anzustreben ist. Eine nur lesende Integration, deren Zugangsdaten ausdünnen können, ist genau so lange eine nur lesende Integration, bis jemand eine Schleife mit einem Zählfehler darin schreibt.

Es gibt eine Folgerung, die Hosting-Anbieter in die andere Richtung falsch machen. Wenn Ihre Plattform einen Server löscht, ist die Frage der Aufbewahrung eine Entscheidung, die der Kunde treffen muss, und kein Standard, den Ihr Code wählt. Die letzte verbliebene Kopie der Daten von jemandem als Nebenwirkung des Aufräumens einer Zeile zu entfernen ist etwas, das echten Unternehmen schon passiert ist.

Was ein Wiederherstellungstest sein muss, falls Sie einen bauen

Nachweis drei ist die Stelle, an der die Arbeit liegt, und es lohnt sich, die Randbedingungen aufzuschreiben, bevor der Code geschrieben wird, denn die meisten davon handeln davon, mit dem eigenen Test keinen Zwischenfall auszulösen.

Ein Wiederherstellungstest braucht einen isolierten Ort, in den hinein wiederhergestellt wird: ein Netz ohne Route zur Produktion, vorübergehende Kennungen, vorübergehende Adressen, vorübergehende Hardwareadressen. Nie die Produktionsadresse, und nie die Produktions-Hardwareadresse, denn ein Doppel in einem Livenetz ist ein Ausfall, den Sie selbst verursacht haben, während Sie prüfen, ob Sie sich von einem Ausfall erholen können. Er braucht strenge Kontingente, denn die Wiederherstellung der größten Maschine einer Flotte in einen Testpool ist ein Kapazitätsereignis. Er braucht eine Frist und ein garantiertes Aufräumen, denn die Maschine wird manchmal nicht hochkommen, und irgendetwas muss sie trotzdem entfernen. Und er darf keine Benachrichtigungen senden, denn ein Überwachungsalarm von einer Testkopie, die sich für das echte System ausgibt, weckt jemanden.

Er braucht außerdem eine ausdrückliche Abschlussregel, und hier verdient sich die ganze Sache ihren Namen. Gestartet ist eine Stufe. Erreichbar ist eine andere. Der Gastagent antwortet ist eine andere. Dateisysteme sind eingehängt ist eine andere. Eine Anwendung, die eine vom Kunden festgelegte Gesundheitsprüfung beantwortet, ist die Stufe, die dem entspricht, was ein Kunde mit wiederherstellbar meint. Wählen Sie eine, halten Sie neben dem Ergebnis fest, welche Sie gewählt haben, und lassen Sie nie eine niedrigere Stufe mit dem Etikett einer höheren anzeigen.

Erst dann darf ein Server „Wiederherstellung nachgewiesen“ zeigen, und dann sollte er das Datum tragen, den genauen Wiederherstellungspunkt, die Umgebung, in der er lief, die Prüfungen, die bestanden wurden, und wie lange der Beleg aufbewahrt wird. Alles darunter macht die Formulierung zur Verzierung.

Was wir aufschreiben würden

1. 01Die drei Nachweise im Schema getrennt benennen, bevor Sie alle drei haben. Unsere sind getrennte Spalten und eine Tabelle, die es noch nicht gibt, was sich leichter liest als eine Spalte mit einem entschuldigenden Kommentar.
2. 02„Unbekannt“ als echten Wert speichern. Jeder Standard, der nicht unbekannt lautet, ist eine Lüge über mindestens eine Ihrer Zeilen.
3. 03Eine leere Auflistung beweisen lassen, dass sie leer ist, und jede andere Antwort in einen eigenen Fehler verwandeln, bevor sie irgendetwas erreicht, das abgleicht.
4. 04Der Integration Zugangsdaten geben, die nicht löschen können, und dann von außen prüfen, dass sie es nicht können.
5. 05Aufschreiben, was „Wiederherstellung“ für Sie bedeuten müsste, auf welcher Abschlussstufe, bevor irgendjemand einen grünen Haken danebensetzt.

Unser eigener Stand, schlicht gesagt: Die ersten beiden Nachweise sind gebaut und gemessen, und wir haben keinen Wiederherstellungstest. Die Backup-Funktion sitzt hinter einem Schalter und ist nicht käuflich. Das ist der Unterschied zwischen einem Plan und einer Behauptung, und es ist derselbe Unterschied, um den es in diesem ganzen Artikel geht.

Die Integration hinter diesen Messungen wurde für Provibr gebaut. Die verwandte Frage nach dem Zeitverhalten, was passiert, wenn ein Backup länger dauert als die Frist, die Sie ihm gegeben haben, steht in ein Zeitlimit ist kein Stoppknopf; die Containerseite der Proxmox-Backups steht in VM oder Container auf Proxmox.