duffyduckandClaude Opus 5
d9d9345d03
Zwei Luecken, die seit dem Umbau offenstanden.
1. Transfer-Laufwerke waren aus dem Explorer nicht erreichbar
F2 zeigte nur die Dateisysteme des Snapshots. Jetzt stehen die
Transfer-Laufwerke in derselben Liste - aus Sicht des Bedieners ist es
dieselbe Frage ("wo soll ich hinschauen?"), und der Weg ueber
pvesnap-recovery entfaellt.
Das gewaehlte Laufwerk landet im rechten Fenster, links bleibt der
Snapshot. Damit laesst sich direkt aus einem Snapshot auf das
Austauschmedium kopieren, das anschliessend in die wiederhergestellte
Maschine wandert - ohne Zwischenlager auf dem Host.
Ausgehaengt wird beim Verlassen, und zwar nur, was wir selbst eingehaengt
haben: ein Laufwerk, das schon vorher am Host hing, gehoert jemand
anderem. Das finally faengt auch Absturz und Strg-C ab - bliebe es
eingehaengt, gaelte es spaeter als belegt.
2. cleanup fand geschuetzte Snapshots ohne Klon nicht
Loescht jemand eine Wiederherstellung in der Proxmox-Oberflaeche, raeumt
Proxmox den Klon durchaus mit ab - aber nicht den Schutz seines
Quell-Snapshots (rbd snap protect, den setzt es beim Klonen selbst).
Zurueck bleibt ein geschuetzter Snapshot ohne Klon: die Vorhaltezeit
scheitert an ihm jede Nacht mit "snapshot is protected", und
find_orphans() findet prinzipiell nichts, weil es den Datentraeger, nach
dem es sucht, wirklich nicht mehr gibt. Dasselbe entsteht nach einem von
Hand ausgefuehrten rbd flatten.
find_stale_protections() sucht deshalb direkt nach der Ursache: jeder
geschuetzte Snapshot, an dem kein Klon haengt. Ein solcher Schutz hat
keinen Zweck - er existiert einzig dafuer, dass ein Klon seine Grundlage
behaelt. Geloest wird nur der Schutz, geloescht wird nichts. Vor jedem
Loesen wird ein zweites Mal nachgesehen, ob inzwischen doch ein Klon
daran haengt.
cleanup laeuft damit in zwei Durchgaengen und liegt neu auch in der
Oberflaeche auf Taste c - man sucht sonst lange nach einem Befehl, den
man nur im Notfall braucht.
Getestet gegen die Kulisse der Handbuch-Werkstatt: die rbd-Attrappe
kennt jetzt snap ls und children und enthaelt beide Zustaende
nebeneinander - ein geschuetzter Snapshot mit Klon (muss in Ruhe
gelassen werden) und einer ohne (muss gefunden werden).
Handbuch und README nachgezogen, zwei Bildschirmfotos dazu.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
8.1 KiB
Austauschlaufwerke
Eine abgeschottete Wiederherstellung hat kein Netzwerk. Kein SCP, kein Netzlaufwerk, kein Cloud-Speicher. Wie kommt der Datenbank-Dump dann heraus?
Über ein Austauschlaufwerk: eine benannte Abbilddatei unter
/var/lib/pvesnap/transfer/, die sich am Host ganz normal einhängen lässt und
einem Gast als zusätzliche Platte angehängt wird.
/var/lib/pvesnap/transfer/dumps.img 20G "Datenbank-Dumps und Exporte"
/var/lib/pvesnap/transfer/werkzeuge.img 4G "Skripte, Treiber, Installer"
!!! success "Der eigentliche Sinn: vorher, nicht mittendrin"
Ein Austauschlaufwerk gehört zu keiner Maschine und überlebt jede
Wiederherstellung. Man legt es **einmal in Ruhe an**, packt hinein, was man
im Notfall braucht — und wählt es im Ernstfall nur noch aus einer Liste aus.
Im Notfall ist keine Zeit, sich Werkzeuge zusammenzusuchen. Und die
Maschine, in der man sie bräuchte, kommt nicht ins Netz.
Die Übersicht
Taste ++v++ — erreichbar aus der Übersicht, aus der Optionsmaske und aus der Detailansicht:
| Taste | |
|---|---|
| ++enter++ | am Host einhängen und im Commander öffnen |
| ++n++ | neues Laufwerk anlegen |
| ++u++ | am Host aushängen |
| ++l++ | löschen |
| ++r++ | neu einlesen |
| ++q++ | zurück |
Die Spalte Zustand ist die wichtigste. Sie kennt drei Werte:
| Zustand | Farbe | bedeutet |
|---|---|---|
frei |
— | gehört niemandem, kann angehängt oder eingehängt werden |
am Host eingehängt |
grün | liegt gerade unter /run/pvesnap/transfer/<name> |
in Benutzung von 9101 |
gelb | steckt in dieser Maschine |
Ein Laufwerk anlegen
Taste ++n++, dann drei Fragen:
| Frage | |
|---|---|
| Name | kurz, klein geschrieben, z. B. dumps. Wird zur Bezeichnung im Gast (DUMPS). |
| Größe | 20G, 500M, 2T |
| Wofür | freier Text, taucht in der Übersicht auf |
Dabei passiert:
- Abbilddatei anlegen (dünn besetzt — sie belegt anfangs nichts)
- GPT-Partitionstabelle mit einer Partition, Typ
msftdata - exFAT-Dateisystem, Bezeichnung = Name in Großbuchstaben
- Rechte
0777und eineLIESMICH.txthineinlegen
!!! note "Die Größe ist eine Obergrenze, keine Reservierung"
Die Datei ist dünn besetzt: Ein 20-GB-Laufwerk mit 3 GB Inhalt belegt 3 GB
auf dem Host. In der Übersicht stehen beide Zahlen nebeneinander —
**Größe** und **belegt**.
Befüllen und auslesen
++enter++ hängt das Laufwerk am Host ein und öffnet den Commander darauf:
Links das Laufwerk, rechts der Host. Beide Seiten sind beschreibbar — anders als beim Snapshot-Explorer, wo links Schreibschutz herrscht. Kopiert wird mit ++f5++ in beide Richtungen.
Beim Verlassen mit ++q++ wird das Laufwerk automatisch wieder ausgehängt.
!!! tip "Auch direkt aus dem Explorer erreichbar"
Im [`pvesnap-explorer`](../holen/explorer.md#laufwerk-wahlen) öffnet ++f2++
dieselbe Auswahl. Das Laufwerk landet dann im rechten Fenster, links steht
weiter der Snapshot — damit lässt sich **direkt aus einem Snapshot auf das
Austauschmedium kopieren**, ohne Umweg über den Host.
!!! tip "Was hineingehört"
Alles, was man im Gast bräuchte und dort nicht herunterladen kann:
* ein passendes `pg_dump` / `mysqldump` in der richtigen Version
* ein Packprogramm (`7z.exe` für Windows-Gäste)
* eigene Auswerteskripte
* bei Windows die virtio-Treiber, falls die Maschine sie braucht
* ein leeres Verzeichnis `ausgang/` für das, was herauskommen soll
Host oder Gast, nie beides
Zwei unabhängige Einhängungen desselben Blockgeräts zerlegen das Dateisystem. Nicht „vielleicht" — zuverlässig, weil beide Seiten Puffer halten, von denen die andere nichts weiß.
Die Verwaltung lässt das deshalb nicht zu:
| Versuch | |
|---|---|
| Anhängen, während der Host es hält | abgelehnt |
| Aushängen, während ein Gast darauf arbeitet | abgelehnt |
| Löschen, solange es überhaupt in Benutzung ist | abgelehnt |
Woher sie das weiß: Sie liest die Gast-Konfigurationen unter
/etc/pve/nodes/*/. Dort steht der Eintrag auch dann, wenn die Maschine gerade
nicht läuft — was die Wahrheit besser trifft als jede Merkliste.
!!! info "Bei Containern ist es anders"
Dort ist es kein Blockgerät, sondern ein durchgereichtes Verzeichnis
(Bind-Mount). Host und Container sehen dieselben Dateien **gleichzeitig** —
es ist dasselbe Dateisystem, nicht zweimal eingehängt.
Dort gibt es also nichts auszuwerfen und nichts abzuwarten.
Im laufenden Betrieb wechseln
Taste ++e++ in der Detailansicht zieht das Laufwerk bei laufender Maschine ab und gibt es wieder hinein — beliebig oft:
auswerfen → gehört wieder dem Host: einhängen, auslesen, neu befüllen
einklinken → zurück in denselben Steckplatz, die VM läuft durchgehend
Das ist der Weg, ohne die Maschine anzufassen an Zwischenergebnisse zu kommen — Dump ziehen, abholen, weitermachen.
!!! warning "Im Gast vorher aushängen"
Unter Linux `umount`, unter Windows „Auswerfen" im Explorer.
Proxmox meldet das Gerät zwar ordentlich ab, aber ein Dateisystem, auf das
gerade geschrieben wird, nimmt das übel. Hält der Gast es fest, schlägt das
Auswerfen mit einer entsprechenden Meldung fehl — dann erst im Gast
aushängen und noch einmal.
Die Detailansicht zeigt jederzeit, was steckt:
Transfer-Laufwerke:
dumps eingesteckt als scsi1
e = auswerfen / einklinken, im laufenden Betrieb
Warum exFAT
| Windows und Linux lesen und schreiben es von Haus aus | kein Treiber, keine Nachinstallation im Gast |
| Keine 4-GB-Grenze je Datei | ein 30-GB-Dump passt |
| Keine Besitzrechte auf der Platte | keine Rechteprobleme zwischen Host und Gast, keine chown-Runden |
Die Bezeichnung darf höchstens 11 Zeichen haben — daher der Rat, den Namen
kurz zu halten. Eingehängt wird mit umask=0000, damit auch ein
unprivilegierter Container hineinschreiben kann (dessen root ist auf dem Host
die UID 100000).
Warum eine Datei und kein Proxmox-Volume?
!!! danger "Ein Volume würde mitgelöscht"
Beim Entfernen der Maschine — auch aus der Proxmox-Weboberfläche heraus.
Die mühsam vorbereitete Werkzeugsammlung wäre weg, und zwar genau in dem
Moment, in dem jemand aufräumt.
Pfade überspringt PVE beim Zerstören ausdrücklich:
`return if $volid =~ m|^/|`. Deshalb eine Datei.
Angehängt wird über ein Loop-Gerät, weil Proxmox als Pfad nur /dev/…
akzeptiert — eine Abbilddatei direkt einzutragen lehnt es ab
(unable to associate path to any storage).
Die GPT-Partition trägt bewusst den Typ msftdata. Ohne diese Angabe vergibt
parted den Typ „Linux filesystem", und Windows gibt dem Laufwerk dann keinen
Buchstaben.
Auf der Kommandozeile
pvesnap-recovery live 101 --transfer werkzeuge --transfer dumps
Mehrfach möglich. Die Laufwerke müssen frei sein, sonst bricht das Anlegen mit einer Meldung ab.
Angelegt und verwaltet werden sie nur über die Oberfläche — dafür gibt es bewusst keine Parameter. Das ist eine Vorbereitungsaufgabe, keine, die man unter Zeitdruck tippt.
Erreichbar ist die Verwaltung von vier Stellen aus:
pvesnap-recovery, Übersicht |
++v++ |
| … Optionsmaske beim Anlegen | ++v++ |
| … Detailansicht einer Maschine | ++v++ |
pvesnap-explorer |
++f2++ — Laufwerk wählen |
Wo sie liegen
/var/lib/pvesnap/transfer/index.json Verzeichnis der Laufwerke
/var/lib/pvesnap/transfer/dumps.img die Abbilddatei
/run/pvesnap/transfer/dumps Einhängepunkt am Host
!!! warning "uninstall.sh --purge nimmt sie mit"
Ohne `--purge` bleibt alles liegen. Mit `--purge` ist auch der Inhalt der
Austauschlaufwerke weg. Siehe [Installation](../installation.md#deinstallation).