# 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](einrichten.md#die-optionsmaske) und aus der [Detailansicht](arbeiten.md): ![Übersicht der Austauschlaufwerke](../bilder/transfer-uebersicht.svg) | 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/` | | `in Benutzung von 9101` | gelb | steckt in dieser Maschine | --- ## Ein Laufwerk anlegen Taste ++n++, dann drei Fragen: ![Ein neues Laufwerk anlegen](../bilder/transfer-neu.svg) | 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: 1. Abbilddatei anlegen (dünn besetzt — sie belegt anfangs nichts) 2. GPT-Partitionstabelle mit einer Partition, Typ `msftdata` 3. exFAT-Dateisystem, Bezeichnung = Name in Großbuchstaben 4. Rechte `0777` und eine `LIESMICH.txt` hineinlegen !!! 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](../holen/explorer.md) darauf: ![Der Commander auf einem Austauschlaufwerk](../bilder/transfer-commander.svg) 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](arbeiten.md) 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 ```bash 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](../holen/explorer.md#laufwerk-wahlen) | --- ## 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).