duffyduckandClaude Opus 5
59e7224297
26 Kapitel in vier Teilen, in der Reihenfolge, in der man sie braucht: erst sichern, dann Dateien holen, dann ganze Maschinen wiederherstellen, dahinter der Nachschlagteil. Gebaut wird mit MkDocs + Material. Bewusst ohne Netzabhaengigkeiten: keine Schriften vom CDN (font: false), Volltextsuche mit deutschem Stemming liegt neben den Seiten. Im Notfall steht vielleicht das halbe Netz - dann nuetzt eine Doku im Internet nichts. handbuch/bauen.sh baut handbuch/site/ handbuch/bauen.sh ansehen Vorschau auf 127.0.0.1:8000 install.sh nimmt das gebaute Handbuch mit nach /usr/share/doc/pvesnap/handbuch/ - falls es vorliegt. Auf dem Host selbst wird nichts gebaut, mkdocs gehoert nicht auf einen Hypervisor. Die 28 Bildschirmfotos sind nicht abfotografiert, sondern erzeugt: Der echte Programmcode laeuft in einem Pseudo-Terminal gegen einen erfundenen Proxmox-Host (Attrappen fuer pvesh, perl und rbd), pyte baut den Bildschirm nach, heraus faellt ein SVG. Damit stimmen sie garantiert mit dem Programm ueberein, sind reproduzierbar und enthalten keine echten Daten. Die Werkstatt dafuer liegt unter handbuch/werkstatt/ samt LIESMICH.md. Nebenbei: die Schlussmeldung von install.sh warb noch mit --exchange, das mit dem eingebauten Austauschlaufwerk weggefallen ist. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
7.5 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 "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.
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).