Das eingebaute Austauschlaufwerk faellt weg

Es tat dasselbe wie die Transfer-Laufwerke, nur schlechter: namenlos, nicht
vorher befuellbar, nicht wiederverwendbar, und es starb mit der Maschine. Zwei
Mechanismen fuer dieselbe Sache sind schlechter als einer.

Entfernt: --exchange, --exchange-storage, --exchange-fs, --exchange-dir, die
Unterbefehle pull und release, das Formatieren und Einhaengen auf dem Host
samt Mount-Merkliste. Was davon gebraucht wurde, steckt jetzt in transfer.py -
dort aber benannt, dauerhaft und im laufenden Betrieb wechselbar.

Aeltere Eintraege in der Merkliste stoeren nicht: ihr Austauschlaufwerk ist
ein gewoehnliches Volume der Maschine und wird beim Verwerfen ohnehin von
Proxmox mitgeloescht.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

README.md

@@ -770,7 +770,7 @@ passen. `pvesnap-recovery` sorgt selbst dafür:
 * `runningmachine` und `runningcpu` aus dem Snapshot werden übernommen
 * die Netzwerkkarte bleibt **vorhanden**, wird aber abgeklemmt (`link_down=1`)
   statt entfernt — herausnehmen würde den Zustand unbrauchbar machen
-* das Austauschlaufwerk wird erst **nach** dem Fortsetzen angesteckt (Hotplug),
+* Transfer-Laufwerke werden erst **nach** dem Fortsetzen angesteckt (Hotplug),
   weil der Gast in einem Zustand aufwacht, in dem es die Platte noch nicht gab
 
 Ein Detail, das Proxmox nicht selbst meldet: Schlägt das Laden des
@@ -781,49 +781,67 @@ gebootet wurde.
 
 Mit `--no-resume` lässt sich der Arbeitsspeicher bewusst weglassen.
 
-### Daten aus einer Maschine ohne Netzwerk holen
+### Daten hinein und wieder heraus — Transfer-Laufwerke
 
-Ohne Netz kommt nichts heraus — dafür gibt es das **Austauschlaufwerk**.
+Ein wiederhergestellter Snapshot hat kein Netzwerk. Dafür gibt es
+**Transfer-Laufwerke**: benannte Abbilddateien unter
+`/var/lib/pvesnap/transfer/`, die du **in Ruhe vorher** anlegst und befüllst
+und im Notfall nur noch aus einer Liste auswählst.
 
-**Bei virtuellen Maschinen** wird eine leere, formatierte Zusatzplatte angelegt
-(Bezeichnung `PVESNAP`, mit einer kurzen `LIESMICH.txt` darauf):
-
-```bash
-# Snapshot abgeschottet starten, mit 20 GB Austauschplatte
-pvesnap-recovery live 802 --exchange 20G
-
-# im Gast (über die noVNC-Konsole):
-mount /dev/disk/by-label/PVESNAP /mnt
-mysqldump --all-databases > /mnt/dump.sql
-umount /mnt && poweroff
-
-# auf dem Host:
-pvesnap-recovery pull 9802        # gibt den Pfad aus, z. B. /run/pvesnap/exchange/9802
-pvesnap-recovery release 9802     # wieder lösen
-pvesnap-recovery destroy 9802     # alles verwerfen
+```
+pvesnap-recovery
+  v            Übersicht der Laufwerke
+  n            "dumps", 20G                    ← einmalig
+  Enter        Commander: Werkzeuge hineinkopieren
+  q q
+  n            Wiederherstellung, Snapshot wählen
+               Transfer-Laufwerke: [dumps]     ← Leertaste
+  F10          läuft
+  ...arbeiten...  im Gast: Datenträger DUMPS
+  e            auswerfen, am Host auslesen, wieder einklinken
+  h            herunterfahren
+  v Enter      Commander: Ergebnis abholen
 ```
 
-**Bei Containern** ist es einfacher: Ein Host-Verzeichnis wird direkt
-durchgereicht und erscheint im Container unter `/mnt/pvesnap`. Was der Container
-hineinschreibt, liegt sofort auf dem Host — kein Ein- und Aushängen nötig.
+Kein einziger Parameter. Auf der Kommandozeile ginge es auch:
+`--transfer dumps`, mehrfach möglich.
 
-```bash
-pvesnap-recovery live 100 --exchange ja
-pct exec 9100 -- sh -c 'pg_dumpall > /mnt/pvesnap/dump.sql'
-ls /var/lib/pvesnap/exchange/9100/
+| Eigenschaft | |
+|---|---|
+| Dateisystem | **exFAT** — Windows und Linux nativ, keine 4-GB-Grenze je Datei |
+| Partition | GPT mit `msftdata`, damit Windows sofort einen Laufwerksbuchstaben vergibt |
+| Bezeichnung | der Name in Großbuchstaben, z. B. `DUMPS` (max. 11 Zeichen) |
+| Lebensdauer | überlebt jede Wiederherstellung — auch das Löschen der VM in der Weboberfläche |
+
+**Warum eine Datei und kein Proxmox-Volume?** Ein Volume würde beim Entfernen
+der Maschine mitgelöscht, auch aus der Weboberfläche heraus — die mühsam
+vorbereitete Werkzeugsammlung wäre weg. Pfade überspringt PVE beim Zerstören
+ausdrücklich (`return if $volid =~ m|^/|`). Angehängt wird über ein
+Loop-Gerät, weil Proxmox als Pfad nur `/dev/…` akzeptiert.
+
+**Host oder Gast, nie beides.** Zwei unabhängige Einhängungen desselben
+Blockgeräts zerlegen das Dateisystem. Die Verwaltung lässt das nicht zu:
+Anhängen wird abgelehnt, solange der Host es hält; Aushängen, solange ein Gast
+darauf arbeitet; Löschen, solange es überhaupt in Benutzung ist.
+
+**Bei Containern** ist es kein Blockgerät, sondern ein durchgereichtes
+Verzeichnis. Host und Container sehen dieselben Dateien **gleichzeitig** —
+dort gibt es nichts auszuwerfen und nichts zu warten.
+
+### 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 und befüllen
+einklinken   → zurück in denselben Steckplatz, VM läuft durchgehend
 ```
 
-Und hier passt auch die Idee mit dem **Netzlaufwerk**: Ist auf dem Host ohnehin
-schon eine NFS- oder CIFS-Freigabe eingehängt, lässt sie sich direkt
-durchreichen — der Container schreibt dann quasi aufs Netzlaufwerk, obwohl er
-selbst kein Netzwerk hat:
-
-```bash
-pvesnap-recovery live 100 --exchange-dir /mnt/nfs/dumps
-```
-
-Bei virtuellen Maschinen geht das nicht: Ein Host-Verzeichnis lässt sich nicht in
-eine VM hineinreichen. Dort bleibt es bei der Austauschplatte.
+> **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.
 
 ### An die Konsole kommen
 
@@ -871,10 +889,7 @@ Karte erst zuschalten, wenn klar ist, dass die Luft rein ist.
 | `--node <name>` | auf welchem Node sie laufen soll |
 | `--net none\|down\|on` | keine Karte / Karte ohne Leitung / voll am Netz |
 | `--resume` / `--no-resume` | Arbeitsspeicher laden bzw. bewusst kalt starten |
-| `--exchange <größe>` | Austauschplatte, z. B. `20G` (Container: `ja` genügt) |
-| `--exchange-storage <name>` | Storage dafür (Vorgabe: wie die erste Platte) |
-| `--exchange-fs <fs>` | `ext4` (Vorgabe), `ext3`, `xfs`, `vfat`, `exfat` |
-| `--exchange-dir <pfad>` | nur Container: dieses Host-Verzeichnis durchreichen |
+| `--transfer <name>` | vorbereitetes Transfer-Laufwerk anhängen (mehrfach möglich) |
 | `--memory <MB>`, `--cores <n>` | abweichende Ausstattung (nicht mit `--resume`) |
 | `--name <name>` | Name der neuen Maschine |
 | `--keep-binds` | durchgereichte Host-Verzeichnisse des Originals übernehmen |
@@ -888,8 +903,6 @@ Karte erst zuschalten, wenn klar ist, dass die Luft rein ist.
 | `list` | vorhandene Wiederherstellungen anzeigen |
 | `start` / `stop` | hoch- bzw. herunterfahren |
 | `console <VMID>` | noVNC-Adresse ausgeben |
-| `pull <VMID>` | Austauschlaufwerk auf den Host holen |
-| `release <VMID>` | es wieder lösen |
 | `flatten <VMID>` | vom Quell-Snapshot lösen (für den Dauerbetrieb) |
 | `cleanup` | Klone entfernen, zu denen es keinen Gast mehr gibt |
 | `destroy <VMID>` | restlos verwerfen |
@@ -932,6 +945,8 @@ pvesnap/
   explorer.py     Zwei-Fenster-Explorer im Terminal
   recovery.py     Snapshot als Maschine starten (Klone, Konfiguration, Aufräumen)
   recovery_ui.py  ncurses-Oberfläche und Kommandozeile dazu
+  transfer.py     Transfer-Laufwerke: anlegen, ein-/aushängen, Verriegelung
+  transfer_ui.py  deren Bildschirm, auch aus dem Explorer erreichbar
   web/            Web-Oberfläche zum Herunterladen
     server.py     HTTP-Server, ZIP im Strom, Zugangsschlüssel
     assets.py     Stylesheet und HTML-Gerüst