# Daten zurückholen

Ein Snapshot ist kein Verzeichnis. Er liegt als Blockgerät oder als Eintrag im
qcow2-Kopf im Storage, und dort kann man nicht einfach hineinsehen.

pvesnap nimmt einem das ab: Der Snapshot wird **schreibgeschützt** eingebunden
und gemountet, und danach ist er ein ganz gewöhnlicher Pfad.

---

## Drei Wege hinein

| | wofür |
|---|---|
| [**Der Explorer**](explorer.md) | Auf dem Host, im Terminal. Zwei Fenster wie im Midnight Commander. Der schnellste Weg, wenn man ohnehin per SSH angemeldet ist. |
| [**Die Web-Oberfläche**](web.md) | Im Browser, auch vom Arbeitsplatz. Anmeldung mit den Proxmox-Benutzern. Verzeichnisse kommen als ZIP. |
| [**Als Maschine starten**](../wiederherstellen/index.md) | Wenn Dateien nicht reichen — eine Datenbank etwa wird erst brauchbar, wenn ihr Server läuft und selbst einen Dump schreibt. |

Die ersten beiden lesen nur. Sie können nichts kaputt machen.

---

## Was dabei im Hintergrund passiert

Je nach Storage geht es unterschiedlich hinein:

| Storage | Weg |
|---|---|
| `rbd` (Ceph) | `rbd map pool/image@snap`; bei nicht unterstützten Image-Features über `rbd-nbd` |
| `zfspool` | Container direkt über `.zfs/snapshot/…`, VMs über einen temporären Klon |
| `lvmthin`, `lvm` | die Snapshot-LV `snap_<volume>_<snapname>` aktivieren |
| `dir`, `nfs`, `cifs` | `qemu-nbd --load-snapshot` — nur bei qcow2 |

Danach werden die Partitionen erkannt und gemountet, und zwar mit
`ro,noload` bzw. `ro,norecovery,nouuid`.

!!! info "Warum diese Optionen wichtig sind"

    Der Snapshot einer **laufenden** Maschine hat fast immer ein unsauberes
    Journal — die VM war ja mitten in der Arbeit. Ohne `noload` bzw.
    `norecovery` würde der Kernel das Journal abspielen wollen, also
    **schreiben**. In einen Snapshot, der schreibgeschützt sein soll.

    Deshalb wird bewusst darauf verzichtet. Die Folge: Die letzten Sekunden vor
    dem Snapshot können in den Dateien fehlen, auch wenn sie im Journal stünden.
    Für eine Datenbank ist das der Grund, den Weg über
    [`pvesnap-recovery`](../wiederherstellen/index.md) zu nehmen — dort startet
    der Datenbankserver und räumt selbst auf.

---

## Aufräumen

Beim Beenden wird alles wieder ausgehängt — automatisch, auch beim Verlassen
über ++q++ oder ++ctrl+c++.

Bleibt nach einem Absturz etwas hängen:

```bash
pvesnap-explorer --cleanup
pvesnap-web --cleanup
```

Beide räumen dieselben Reste weg: Einbindungen unter `/run/pvesnap/`,
`rbd`-Zuordnungen, NBD-Geräte, temporäre ZFS-Klone.

Nachsehen, ob wirklich nichts mehr liegt:

```bash
findmnt | grep pvesnap
rbd showmapped
losetup -a
ls /run/pvesnap/
```

---

## Was nicht geht

!!! warning "Schreiben"

    In einen Snapshot hinein geht nichts. Kein Kopieren, kein Löschen, kein
    Umbenennen. Das ist keine Vorsichtsmaßnahme, sondern eine Eigenschaft der
    Sache: Ein Snapshot ist ein festgehaltener Stand.

    Wer einen Stand **ändern** will, um daraus weiterzuarbeiten, braucht
    [`pvesnap-recovery`](../wiederherstellen/index.md) — dort entsteht ein Klon,
    der voll beschreibbar ist.

!!! warning "Verschlüsselte Dateisysteme"

    LUKS, BitLocker oder eine verschlüsselte Datenbankpartition bleiben auch im
    Snapshot verschlüsselt. Es gibt keinen Weg daran vorbei — die Daten müssen
    im laufenden Gast entschlüsselt werden. Auch das ist ein Fall für
    `pvesnap-recovery`.