Datenvolumes mit LVM-Snapshots offline zurücksetzen

Ein Anwendungsupgrade ersetzt nicht nur Programmdateien. Es kann auch Indizes, Ressourcendateien und Datenformate verändern. Das alte Installationspaket aufzubewahren reicht deshalb nicht aus, um ein Datenvolume zuverlässig zurücksetzen zu können. Auf einem Dedicated Server, der bereits LVM (Logical Volume Management) verwendet, lässt sich nach dem Stoppen aller Schreibzugriffe ein kurzfristiger Snapshot anlegen. Durch ein anschließendes Offline-Zusammenführen kann der Zustand vor dem Upgrade wiederhergestellt werden. Entscheidend ist nicht allein, ob der Snapshot-Befehl erfolgreich war, sondern ob die Grenzen der Schreibzugriffe, die verbleibende Kapazität und die Prüfung der Wiederherstellung vollständig berücksichtigt wurden.

1. Zielvolume und Grenzen des Rollbacks klären

Dieser Ablauf verwendet Debian 13, ein ext4-Dateisystem und ein klassisches LVM-Datenvolume als Beispiel. Root-Dateisysteme, Boot-Volumes und Thin Pools sind nicht Gegenstand dieses Artikels. Zur Standardausstattung von CloudUDP gehören zwei direkt angebundene NVMe-Laufwerke mit jeweils 1TB, ohne Hardware-RAID. Daraus folgt jedoch nicht, dass das System bereits LVM nutzt: Das tatsächliche Speicherlayout muss auf dem jeweiligen Server geprüft werden.

Erfassen Sie zunächst die Mount-Quelle, den Dateisystemtyp, die Eigenschaften der logischen Volumes und den freien Platz in der Volume-Gruppe:

findmnt -T /srv/appdata -o SOURCE,TARGET,FSTYPE,OPTIONS
sudo lvs -a -o vg_name,lv_name,lv_attr,segtype,origin,data_percent
sudo vgs -o vg_name,vg_size,vg_free
sudo lsblk -f

Handelt es sich beim Ziel lediglich um eine gewöhnliche Partition, dürfen Sie diesen Ablauf nicht weiter anwenden. Formatieren Sie keine vorhandenen Daten, nur um Snapshots nutzen zu können. Zeigt die Ausgabe Thin Volumes, eine Cache-Schicht oder andere komplexe Speicherlayouts, ist das Verfahren für die jeweilige Speicherlösung erforderlich.

Im Folgenden wird angenommen, dass das Datenvolume vgdata/appdata heißt, unter /srv/appdata eingehängt ist und zum Dienst app.service gehört. Ersetzen Sie diese Namen durch die tatsächlichen Werte Ihrer Umgebung. Prüfen Sie außerdem, dass weder verschachtelte Mounts noch weitere schreibende Prozesse vorhanden sind. Führen Sie die Befehle abschnittsweise aus; kopieren Sie nicht den gesamten Artikel zur Ausführung in ein Terminal.

Ein Snapshot ist kein Backup

Ein klassischer Snapshot bewahrt per Copy-on-Write die Datenblöcke des Ursprungsvolumes auf, bevor diese überschrieben werden. Er ist damit weiterhin vom Ursprungsvolume und dem darunterliegenden Speicher abhängig. Er schützt weder vor Laufwerksausfällen noch erfasst er Konfigurationen, Programme oder entfernte Daten außerhalb des Volumes.

Das Zusammenführen eines Snapshots macht sämtliche Schreibvorgänge innerhalb des Volumes seit der Snapshot-Erstellung rückgängig. Hat die Anwendung nach dem Upgrade bereits produktive Anfragen verarbeitet, müssen Sie zunächst alle neuen Daten exportieren, die erhalten bleiben sollen, und deren Kompatibilität mit der alten Programmversion prüfen. Ein unmittelbarer Rollback ist dann nicht zulässig.

2. Nach dem Stoppen der Dienste einen konsistenten Wiederherstellungspunkt erstellen

Bereiten Sie vor dem Upgrade ein unabhängiges Backup vor und dokumentieren Sie die Programmversion, eine Zusammenfassung der Konfiguration sowie den Gesundheitszustand der Anwendung. Ein Snapshot sichert lediglich den Blockzustand des ausgewählten Volumes. Sind mehrere Volumes oder externe Datenbanken beteiligt, muss weiterhin eine komponentenübergreifende Konsistenzgrenze festgelegt werden.

Pausieren Sie vor dem Stoppen des Dienstes eingehende Anfragen, Queue-Consumer und geplante Aufgaben. So verhindern Sie, dass andere Prozesse nach dem Dienststopp weiterhin Daten verändern. Der folgende Ablauf betrachtet das erfolgreiche Aushängen als Nachweis dafür, dass das Volume nicht mehr genutzt wird. Er verwendet weder erzwungenes Aushängen noch Lazy Unmount:

sudo systemctl stop app.service
sudo fuser -vm /srv/appdata
sudo sync
sudo umount /srv/appdata

Meldet das Aushängen, dass das Volume noch verwendet wird, prüfen Sie aktuelle Arbeitsverzeichnisse, offene Dateien und andere Dienste. Fahren Sie erst fort, wenn alle schreibenden Prozesse ausgeschlossen sind. Erstellen Sie anschließend den Snapshot:

sudo lvcreate --snapshot --size 20G \
  --name preupgrade /dev/vgdata/appdata
sudo lvs -o lv_name,lv_attr,origin,data_percent vgdata
sudo mount /srv/appdata

Die hier angegebenen 20G sind eine beispielhafte Snapshot-Kapazität, keine Produktkonfiguration und keine allgemeingültige Empfehlung. Prüfen Sie vor der Ausführung, dass die Volume-Gruppe ausreichend freien Platz hat und preupgrade noch nicht existiert. Bemessen Sie die Snapshot-Kapazität anhand der Datenblöcke, die während des vorgesehenen Rollback-Beobachtungszeitraums voraussichtlich überschrieben werden, statt pauschal einen Prozentsatz der Gesamtgröße des Ursprungsvolumes anzusetzen.

Legen Sie nach dem erneuten Einhängen des Ursprungsvolumes zunächst eine kleine Prüfdatei an und führen Sie dann das Upgrade kontrolliert durch. Produktive Schreibzugriffe sollten weiterhin blockiert bleiben. Andernfalls sind bei einem späteren Rollback zusätzliche Schritte zur Datenübergabe erforderlich.

3. Snapshot schreibgeschützt prüfen und Belegung überwachen

Nach erfolgreicher Erstellung müssen Sie prüfen, ob sich der Inhalt des Snapshots lesen lässt. Die folgenden Optionen gelten ausschließlich für das ext4-Beispiel in diesem Artikel: ro steht für schreibgeschützten Zugriff, noload verhindert die Wiedergabe des Journals beim Einhängen. Diese Optionen dürfen nicht unverändert auf andere Dateisysteme übertragen werden.

sudo mkdir -p /mnt/app-preupgrade
sudo mount -t ext4 -o ro,noload \
  /dev/vgdata/preupgrade /mnt/app-preupgrade
sudo sha256sum /mnt/app-preupgrade/manifest.json \
  | sudo tee /root/app-preupgrade.sha256
sudo umount /mnt/app-preupgrade

manifest.json steht hier für eine tatsächlich ausgewählte, inhaltlich stabile Anwendungsdatei. Prüfen Sie vorab, dass sie vorhanden ist und sich sinnvoll zur Abnahme eignet. Die Prüfsummenliste wird außerhalb des Zielvolumes gespeichert. Vergleichen Sie nach dem Rollback nur das Feld mit der Dateiprüfsumme, nicht den Mount-Pfad.

Risiken anhand des Änderungsvolumens beurteilen

sudo lvs -a -o lv_name,lv_attr,origin,data_percent vgdata
sudo vgs -o vg_name,vg_free

Data% gibt den belegten Anteil des klassischen Snapshot-Speichers an, nicht die Dateisystembelegung des Ursprungsvolumes. Erfassen Sie diesen Wert vor und nach dem Upgrade fortlaufend und beobachten Sie, wie schnell er steigt. Vorgänge wie der massenhafte Neuaufbau von Indizes oder das Überschreiben großer Dateien können den verfügbaren Platz rasch aufbrauchen.

Nähert sich die Belegung der vorab festgelegten Warnschwelle, pausieren Sie weitere Schreibzugriffe und prüfen Sie eine Kapazitätserweiterung. Wenn die Volume-Gruppe noch freien Platz bietet und der Snapshot gültig ist, können Sie seine Kapazität entsprechend Ihrer Einschätzung erhöhen:

sudo lvextend -L +10G /dev/vgdata/preupgrade

Mehr Speicherplatz verlängert nicht den betrieblich zulässigen Rollback-Zeitraum. Ist der Snapshot bereits ungültig, stellt eine Erweiterung keine Reparatur dar. Wechseln Sie dann zum Wiederherstellungsverfahren mit dem unabhängigen Backup. Snapshot-Monitoring ohne einen festgelegten Weg für den Empfang und die Bearbeitung von Warnungen bietet keinen zuverlässigen Schutz.

4. Offline zusammenführen und Wiederherstellung prüfen

Wenn Sie sich für einen Rollback entscheiden, sperren Sie zunächst den Zugang für produktive Anfragen. Sichern Sie Nachweise zum Fehler und alle neuen Daten, die erhalten bleiben müssen. Auch Programme und Konfigurationen außerhalb des Volumes müssen auf den passenden Versionsstand zurückgebracht werden. Nur das Datenvolume wiederherzustellen kann zu einer fehlerhaften Kombination aus alten Daten und neuer Software führen.

Prüfen Sie, dass der Snapshot gültig und sein Mount-Punkt ausgehängt ist. Stoppen Sie anschließend sämtliche zugehörigen Dienste und hängen Sie das Ursprungsvolume aus. Die folgenden Operationen verändern Daten; kontrollieren Sie deshalb vor der Ausführung erneut die Volume-Namen:

sudo systemctl stop app.service
sudo umount /srv/appdata
sudo lvchange -an /dev/vgdata/appdata
sudo lvconvert --merge /dev/vgdata/preupgrade
sudo lvchange -ay /dev/vgdata/appdata
sudo lvs -a -o lv_name,lv_attr,origin,data_percent vgdata

Wird die Zusammenführung für die nächste Aktivierung vorgemerkt, beobachten Sie den Status, bis sie abgeschlossen ist. Starten Sie den Produktivbetrieb nicht allein deshalb, weil der Befehl erfolgreich zurückgekehrt ist. Nach erfolgreicher Zusammenführung verschwindet das Snapshot-Volume. Hängen Sie dann das Ursprungsvolume wieder ein und prüfen Sie es:

sudo mount /srv/appdata
sudo sha256sum /srv/appdata/manifest.json
sudo cat /root/app-preupgrade.sha256

Die Dateiprüfsumme muss mit dem Referenzwert übereinstimmen. Die nach der Snapshot-Erstellung angelegte Prüfdatei muss verschwunden sein. Diese Prüfungen belegen allerdings nur, dass die ausgewählten Dateien zurückgesetzt wurden, nicht, dass die Anwendung korrekt funktioniert. Prüfen Sie zusätzlich die Programmversion, die Anzahl wichtiger Datensätze und die Ergebnisse von Lesezugriffen. Führen Sie außerdem einen kontrollierten Schreibvorgang durch, bevor Sie den Dienst starten und die Logs kontrollieren.

5. Aus dem Probelauf eine Upgrade-Checkliste erstellen

Erproben Sie den gesamten Ablauf zunächst auf einem Datenvolume ohne Produktivdaten. Dokumentieren Sie die Snapshot-Erstellung, die zunehmende Belegung, den Status der Zusammenführung und die Ergebnisse der Anwendungsprüfungen. Vor einem produktiven Upgrade müssen mindestens die folgenden Punkte bestätigt sein:

• Das Ziel ist ein bereits vorhandenes klassisches LVM-Datenvolume; Mount-Quelle und Volume-Name passen zusammen.
• Alle schreibenden Prozesse lassen sich stoppen, das Ursprungsvolume lässt sich regulär aushängen und das unabhängige Backup wurde geprüft.
• Die Snapshot-Kapazität basiert auf dem erwarteten Änderungsvolumen, und die Volume-Gruppe bietet Reserven für eine Erweiterung.
• Die alte Programmversion, Konfigurationen außerhalb des Volumes und die Wiederherstellungscheckliste sind verfügbar.
• Es ist festgelegt, wie neue Schreibdaten erhalten bleiben und unter welchen Bedingungen der Produktivbetrieb wieder aufgenommen wird.

Sobald das Upgrade die Abnahme bestanden hat und der Rollback-Beobachtungszeitraum beendet ist, prüfen Sie, dass der Snapshot nicht eingehängt ist. Entfernen Sie einen noch vorhandenen Snapshot anschließend mit lvremove /dev/vgdata/preupgrade. Ein bereits zusammengeführter Snapshot muss nicht erneut gelöscht werden.

Als abschließendes Ergebnis sollte ein Betriebsprotokoll vorliegen, das Volume-Layout, Wiederherstellungspunkt, Kapazitätsaufzeichnungen und Ergebnisse der fachlichen Abnahme enthält. Ein Snapshot ist lediglich ein Werkzeug für kurzfristige Rollbacks. Zuverlässigkeit entsteht durch einen wiederholbar ausführbaren Wiederherstellungsprozess, nicht durch einen zusätzlich aufbewahrten Volume-Namen.

Häufig gestellte Fragen