Bevor eine produktive VM ein Major-Upgrade bekommt, will man ein verlässliches Backup haben – und zwar ohne die laufende Maschine herunterfahren zu müssen. In meinem Fall: ein WordPress-Blog in einer Debian-Bookworm-VM unter QEMU/libvirt, das auf Debian Trixie soll. Hier der komplette Ablauf in zwei Teilen: erst die laufende qcow2 sichern, dann das Upgrade.
Teil 1: Laufende qcow2-VM sichern
Wichtig vorweg: Eine qcow2 im Betrieb einfach mit cp zu kopieren, führt zu einem inkonsistenten Abbild – laufende I/O und Schreibcache sind nicht synchron. Der saubere Weg führt über einen externen Snapshot.
1. Externen Snapshot anlegen
Die VM läuft dabei weiter (Downtime = 0). libvirt friert die Basis-qcow2 read-only ein und leitet alle weiteren Schreibvorgänge in eine Overlay-Datei um.
virsh snapshot-create-as --domain meine-vm backup-snap \
--diskspec vda,file=/var/lib/libvirt/images/meine-vm-overlay.qcow2 \
--disk-only --atomic --no-metadata--no-metadata sorgt dafür, dass libvirt den Snapshot nicht dauerhaft in der Domain-Definition trackt – wir wollen ja nur kurz einen Schreibstopp auf der Basisdatei, keine permanente Snapshot-Kette.
2. Die Basis-qcow2 kopieren – mit rsync statt cp
Die Basisdatei ist jetzt eingefroren und damit sicher kopierbar. Ich habe hier eine 250-GB-Datei, das dauert das eine Weile. Und genau hier spielt rsync seinen Vorteil aus: Es zeigt einen Fortschrittsbalken und ist resume-fähig. Reißt das Terminal oder die SSH-Session ab, setzt ein erneuter Aufruf nahtlos fort, statt von vorne zu beginnen.
rsync --progress /var/lib/libvirt/images/meine-vm.qcow2 \
/backup/meine-vm-pre-trixie-$(date +%F).qcow2Liegt das Ziel auf einem Netzlaufwerk, lohnt zusätzlich --inplace, um doppelten Speicherbedarf während des Kopierens zu vermeiden. Praktisch ist auch, das Backup auf ein anderes physisches Volume zu legen als das Original.
3. Overlay zurückspielen (blockcommit)
Nach dem Kopieren wird die Overlay-Datei wieder in die Basis gemergt, damit die VM ohne Snapshot-Altlasten weiterläuft. --pivot schaltet die laufende VM anschließend zurück auf die Basisdatei.
virsh blockcommit meine-vm vda --active --pivotWichtig zu verstehen: Die laufende VM verliert dabei nichts. Was im Backup-File fehlt, ist nur alles, was nach dem Snapshot-Zeitpunkt geschrieben wurde (bei mir waren es zufälligerweise nur Logdaten der Kopierzeit – unkritisch).
4. Sauberkeit prüfen, dann Overlay löschen
Vor dem Aufräumen kurz verifizieren, dass der Pivot vollständig war:
# Aktive Disk-Quelle prüfen -> sollte wieder die Original-qcow2 sein
virsh domblklist meine-vm
# Snapshot-Liste sollte leer sein
virsh snapshot-list meine-vm
# Backing-Chain der Basisdatei prüfen
qemu-img info -U /var/lib/libvirt/images/meine-vm.qcow2Das -U (force-share) ist nötig, weil die laufende VM einen Schreib-Lock auf die Datei hält – ohne das Flag meldet qemu-img info nur „failed to get shared write lock“. Fehlt in der Ausgabe die Zeile backing file:, ist die Overlay-Datei verwaist und kann weg:
rm /var/lib/libvirt/images/meine-vm-overlay.qcow2Bonus: Die Backup-Kopie lässt sich als eigene Test-VM einbinden (Domain-XML mit neuem Namen, neuer UUID und neuer MAC-Adresse), um das Upgrade gefahrlos zu proben, bevor man es in Produktion fährt.
Teil 2: Upgrade von Bookworm auf Trixie
Debian unterstützt nur den Sprung von der direkten Vorversion – also Bookworm (12) → Trixie (13). Vorher das bestehende System komplett aktuell ziehen.
1. Paketquellen von bookworm auf trixie umstellen
sed -i 's/bookworm/trixie/g' \
/etc/apt/sources.list /etc/apt/sources.list.d/*.listWer das neuere deb822-Format nutzt, passt entsprechend die *.sources-Dateien an. Und: Auch Drittquellen wie das Sury-Repo (PHP) müssen auf trixie zeigen, sonst blockieren sie das Upgrade.
2. Zweistufiges Upgrade
Erst ein minimales Upgrade mit --without-new-pkgs (hält Pakete zurück, die neue Abhängigkeiten reinziehen würden – senkt das Konfliktrisiko), dann das volle Upgrade:
apt update
apt upgrade --without-new-pkgs # minimales Upgrade
apt full-upgrade # volles UpgradeDie Meldung „Packages have been kept back“ nach dem ersten Schritt ist normal – der full-upgrade räumt das auf. Bei Konfigurationsdatei-Prompts im Zweifel die eigene Version behalten und hinterher gezielt mergen. Danach Reboot und prüfen:
cat /etc/os-release # -> trixie / VERSION 13
uname -r # -> 6.12.x
systemctl --failed # keine fehlgeschlagenen Dienste
apt autoremove --purgeDie eigentliche Stolperfalle: PHP 8.2 → 8.4
Der größte Risikofaktor beim Upgrade ist nicht Debian selbst, sondern der PHP-Sprung: Bookworm liefert standardmäßig PHP 8.2, Trixie bringt PHP 8.4 mit – also gleich zwei Major-Versionen auf einmal.
Für ein WordPress-Setup heißt das zum Beispiel:
- WordPress selbst ist in aktuellen Versionen meist gut auf neue PHP-Versionen vorbereitet – der unsichere Faktor ist der Plugin- und Theme-Stack.
- Ältere, lange nicht gepflegte Plugins oder Themes können unter PHP 8.4 Fatal Errors werfen, die unter 8.2 noch stillschweigend durchliefen (z. B. „deprecated dynamic properties“, die jetzt strenger behandelt werden).
- PHP 8.4 ist generell restriktiver bei Systeminteraktionen – relevant für Plugins mit Shell-Exec oder direkten Datei-Schreibzugriffen.
- Debian installiert teils Extensions bei einem major-upgrade nicht automatisch, wenn es keine klare Abhängigkeit gibt. In meinem Fall lief der Upload in die Mediathek anschließend nicht mehr,
PHP fatal error .... Class "DOMDocument" not found
Lösung war ganz einfach:apt install php-xml && systemctl restart apache2
Mein Rat: Den Stack vorher in einer Test-VM (siehe Teil 1) gegen PHP 8.4 prüfen – oder zumindest PHP 8.4 testweise via Sury-Repo schon in der Bookworm-Kopie installieren, bevor man das ganze OS-Upgrade in Produktion fährt. Bei mir lief am Ende alles sauber durch – aber das ist beim Plugin-Stack keine Garantie, sondern Glückssache, wenn man es nicht vorher testet.
Fazit
Snapshot → rsync → blockcommit → prüfen gibt ein konsistentes Backup ohne Downtime. Das Trixie-Upgrade selbst ist mit dem zweistufigen apt-Verfahren unspektakulär – die Aufmerksamkeit gehört dem PHP-8.4-Sprung und dem WordPress-Plugin-Stack.