Ein Objektspeicher wird oft erst dann bemerkt, wenn eine Anwendung ihre Sicherung nicht mehr ablegen oder eine Datei nicht mehr lesen kann. Beim Upgrade wollten wir deshalb mehr sehen als einen gestarteten Container: Der Speicher sollte seinen vorhandenen Zustand erkennen und über die gewohnten Werkzeuge tatsächlich nutzbar sein.
Unser Wechsel von Garage 2.4.1 auf 2.5.0 verband eine vorbereitete Sicherung mit mehreren getrennten Kontrollen. Dieser Beitrag beschreibt den Ablauf und die daraus gewonnenen Erfahrungen. Interne Speicherzuordnungen, Zugänge und Konfigurationswerte gehören nicht zu den Beispielen.
Den allgemeinen Einsatz von Objektspeicher für Sicherungen haben wir im Beitrag S3-Backups beschrieben. Hier geht es um die Wartung des Speicherdienstes selbst.
Bei einem Speicherdienst zählt auch der Zustand
Ein Containerimage enthält die Software. Der gespeicherte Zustand liegt unabhängig davon vor und muss nach dem Wechsel weiterhin zur Software passen.
Die Upgradeanleitung von Garage unterscheidet Upgradearten und verlangt die Beachtung der jeweiligen Änderungshinweise. Sie behandelt auch den Umgang mit Metadaten während einer Sicherung. Insbesondere ist eine gewöhnliche Dateikopie laufender Metadaten kein Ersatz für ein dafür geeignetes Sicherungsverfahren.
Für die Vorbereitung ergeben sich daraus konkrete Fragen: Welche Ausgangs- und Zielversionen sind beteiligt? Welche Bestandteile gehören zur Sicherung? Wie wird ein konsistenter Zustand hergestellt? Und welche Hinweise gelten für genau diesen Versionswechsel?
Ein vorhandenes altes Image beantwortet diese Fragen nicht. Es ersetzt weder gesicherte Daten noch die Prüfung, ob ein Rückwechsel mit einem veränderten Datenbestand unterstützt ist.
Einen konsistenten Vorzustand sichern
Wir verwendeten vor dem Upgrade eine kalte Sicherung. Dafür wurde der Dienst kontrolliert gestoppt, bevor der zusammengehörige Bestand aus Konfiguration, Metadaten und Objektdaten kopiert wurde. Auch die bisherige Softwareversion gehörte zur Vorbereitung.
Das ist ein bewusst gewählter Ablauf mit einer Unterbrechung. Welche Methode sich eignet, hängt vom konkreten Aufbau und den unterstützten Sicherungswegen ab. Eine Beschreibung aus einer anderen Umgebung sollte deshalb nicht ungeprüft als Betriebsanweisung übernommen werden.
Zusätzlich legten wir eine zweite Kopie der Sicherung an einem getrennten Ablageort ab. Für die Sicherungsarchive prüften wir die SHA256-Prüfsummen und kontrollierten die Archivverzeichnisse.
Damit konnten wir bestätigen, dass die geprüften Kopien mit den erwarteten Archivdaten übereinstimmten. Diese Kontrolle hat einen klaren Zweck: Übertragungsfehler oder beschädigte Kopien sollen vor einer Wiederherstellung auffallen. Eine erfolgreiche Wiederherstellungsprobe untersucht darüber hinaus, ob sich daraus ein funktionsfähiger Dienst aufbauen lässt.
Das Zielimage vor dem eigentlichen Wechsel ansehen
Vor dem Deployment prüften wir die Versionsausgabe des vorgesehenen Zielimages in einem getrennten Aufruf ohne Zugriff auf die produktiven Daten und ohne Netzwerkverbindung.
Das lieferte eine erste Antwort auf eine einfache Frage: Enthält das vorbereitete Image die erwartete Garage-Version? Dafür musste die neue Software den gespeicherten Bestand noch nicht öffnen.
Danach erfolgte die eigentliche Aktualisierung über den bestehenden Stack. Wir behielten Vorbereitung und Deployment als getrennte Schritte bei. So blieb erkennbar, welche Prüfung bereits vor dem Eingriff abgeschlossen war.
Nach dem Start mehrere Signale zusammen lesen
Nach dem Upgrade bestätigte die Versionsausgabe den Zielstand. Der Dienst erkannte seine bisherige Identität wieder, meldete einen gesunden Knotenzustand und eine leere Resynchronisationswarteschlange. Die vorliegenden Startmeldungen zeigten das Öffnen der vorhandenen Metadaten und den Start der Schnittstellen ohne ERROR-Einträge.
Diese Beobachtungen ergänzen sich. Die Versionsausgabe beschreibt die Software. Der Zustand zeigt, wie Garage sich selbst beurteilt. Die Startmeldungen helfen beim Erkennen von Problemen während der Initialisierung.
Keines dieser Signale allein belegt bereits einen vollständigen Anwendungsvorgang. Eine leere Warteschlange bedeutet beispielsweise, dass dort aktuell keine entsprechende Arbeit ansteht. Sie bescheinigt keine universelle Integritätsprüfung sämtlicher gespeicherter Objekte.
Lesen und Schreiben tatsächlich ausführen
Für die praktische Abnahme nutzten wir zwei unterschiedliche Vorgänge. Ein vorhandenes Objekt wurde mit Mountain Duck heruntergeladen. Zusätzlich wurde eine neue verschlüsselte Portainer-Sicherung geschrieben; das neue Objekt war danach mit passendem Zeitstempel und einer Dateigrösse im Speicher sichtbar.
Damit waren ein tatsächlicher Lesezugriff und ein neuer Sicherungsschreibvorgang bestätigt. Ein lediglich erreichbarer Endpunkt hätte diese beiden Ergebnisse nicht geliefert.
Die Unterscheidung ist auch bei anderen Speicherlösungen hilfreich:
Softwareversion und Dienstzustand prüfen
-> vorhandenes Objekt herunterladen
-> neues Objekt über einen vorgesehenen Arbeitsablauf schreiben
-> Ergebnis im Speicher kontrollierenFür einen ausführlicheren Inhaltstest kann ein eigens dafür bestimmtes Testobjekt vor und nach der Übertragung per Prüfsumme verglichen werden. Bei verschlüsselten Sicherungen gehören die Entschlüsselung und die Wiederherstellung der Anwendung in einen eigenen Testablauf. Ein gespeichertes Objekt und eine wiederhergestellte Anwendung beantworten verschiedene Fragen.
Den Abschluss so genau wie die Prüfung beschreiben
Unser dokumentiertes Ergebnis umfasst das Upgrade, die Zustandskontrollen und die tatsächlichen Lese- und Schreibvorgänge. Diese einzelnen Nachweise machen den Wartungsschritt verständlicher als die pauschale Aussage, dass der neue Container läuft.
Für den Betrieb ist gerade diese Genauigkeit nützlich. Beim nächsten Upgrade lassen sich dieselben Prüfziele wieder aufnehmen und um neue Anforderungen ergänzen. Der Ablauf bleibt überschaubar: Vorzustand sichern, Ziel prüfen, kontrolliert wechseln und danach die Vorgänge ausführen, auf die sich die nutzenden Anwendungen verlassen.