# Damit arbeiten

++enter++ auf einer Maschine in der Übersicht öffnet die Detailansicht. Das ist
der Bildschirm, auf dem man im Ernstfall die meiste Zeit verbringt:

![Die Detailansicht](../bilder/recovery-detail.svg)

| Taste | |
|---|---|
| ++s++ | starten |
| ++h++ | [herunterfahren](#herunterfahren) |
| ++e++ | [Austauschlaufwerk auswerfen / einklinken](transfer.md#im-laufenden-betrieb-wechseln) |
| ++v++ | [Austauschlaufwerke verwalten](transfer.md) |
| ++p++ | [SPICE und USB](dongle.md#nachtraglich-umstellen) |
| ++f++ | [vom Quell-Snapshot lösen](loesen.md) |
| ++x++ | [verwerfen](verwerfen.md) |
| ++q++ | zurück |

---

## An die Konsole kommen

In der Detailansicht steht die fertige Adresse:

```
https://10.20.0.11:8006/?console=kvm&novnc=1&vmid=9101&node=pve1&resize=off&cmd=
```

Dasselbe liefert `pvesnap-recovery console 9101`. Es ist die ganz normale
noVNC-Konsole von Proxmox — die Maschine taucht auch in der Weboberfläche auf,
markiert mit dem Tag `pvesnap-recovery`.

Bei Containern geht zusätzlich `pct enter 9101` auf dem Host.

!!! info "Warum eine IP-Adresse und kein Name?"

    Vorne steht bewusst die **IP** des Nodes, nicht sein Name: Auf dem
    Proxmox-Host löst der Name auf, am Arbeitsplatz meist nicht. Sie kommt aus
    `/etc/pve/.members`.

    Der Node hinter `node=` bleibt der Name — so erwartet Proxmox ihn.

Für SPICE und USB-Weiterleitung siehe [Dongle und USB](dongle.md).

---

## Was man drinnen tut

Die Maschine ist voll beschreibbar. Alles, was man an einer echten Maschine
täte, geht auch hier — nur eben ohne Netz.

Der typische Ablauf für eine Datenbank:

<div class="ablauf" markdown>

**1.** Im Gast prüfen, ob der Dienst läuft — mit geladenem Arbeitsspeicher ist
er bereits offen

**2.** Dump schreiben, auf das [Austauschlaufwerk](transfer.md):
`pg_dump -Fc kunden > /media/DUMPS/kunden.dump`

**3.** Im Gast aushängen (`umount`, unter Windows „Auswerfen")

**4.** In pvesnap ++e++ — Laufwerk auswerfen

**5.** ++v++ ++enter++ — Commander auf das Laufwerk, Dump abholen

**6.** ++x++ — Maschine verwerfen

</div>

Schritt 3 ist der, den man vergisst. Mehr dazu unter
[Austauschlaufwerke](transfer.md#im-laufenden-betrieb-wechseln).

---

## Herunterfahren

Taste ++h++ fährt **sauber** herunter — und schaltet nicht von selbst hart ab.

Weigert sich der Gast, kommt eine Wahl:

| | |
|---|---|
| **Im Gast selbst herunterfahren** | pvesnap wartet und meldet, wenn sie aus ist |
| **Hart ausschalten** | wie Stecker ziehen, mit ausdrücklicher Bestätigung |
| **Abbrechen** | läuft weiter |

!!! quote "Warum nicht einfach nach 60 Sekunden abschalten?"

    Weil ein stilles Abschalten nach Zeitablauf ein Stromausfall mit Ansage
    wäre — und genau der Grund, warum ein Dateisystem hinterher unsauber ist.

    Wenn man gerade dabei ist, aus einer Maschine konsistente Daten zu holen,
    ist das die falsche Voreinstellung.

Beim Warten zeigt pvesnap, was zu tun ist, und verfolgt den Zustand:

```
Bitte jetzt IM GAST herunterfahren.

  Windows   Start -> Ein/Aus -> Herunterfahren
  Linux     poweroff   bzw.   shutdown -h now

Zustand: running     seit 1:23
```

++q++ bricht das Warten ab — die Maschine läuft dann weiter.

---

## Neu starten

Ein Neustart wird nötig, wenn sich die [Grafikkarte ändert](dongle.md) — also
beim Ein- oder Ausschalten von SPICE. Dann kommt dieselbe Wahl:

![Wie soll die Maschine neu starten?](../bilder/recovery-neustartwahl.svg)

| | |
|---|---|
| **Ich fahre im Gast herunter** | pvesnap wartet, startet danach selbst wieder — **der verlässliche Weg** |
| **Proxmox herunterfahren lassen (ACPI)** | klappt bei Linux, bei Windows oft nicht |
| **Gar nicht** | später selbst; die Änderung greift beim nächsten Start |

!!! warning "ACPI und Windows"

    Bei Linux funktioniert der ACPI-Aus-Knopf zuverlässig. Windows blockt ihn
    gern: Dort hält eine Anwendung den Vorgang auf, oder der Shutdown Event
    Tracker fragt nach einem Grund und wartet auf eine Eingabe, die nie kommt.

    Wer im Gast selbst herunterfährt, umgeht das. Deshalb steht dieser Weg an
    erster Stelle.

!!! danger "Ein Neustart *im* Gast hilft nicht"

    Dabei setzt sich nur die Maschine zurück — der QEMU-Prozess läuft weiter,
    mit der alten Grafikkarte. Es braucht wirklich den Umweg über „aus und
    wieder an".

### Der geladene Arbeitsspeicher ist danach weg

!!! danger "Endgültig"

    Proxmox gibt den kopierten Arbeitsspeicher schon beim **ersten** Start
    wieder frei. Ein zweiter Start bootet also kalt — offene Programme und
    ungespeicherte Daten sind dann verloren.

    pvesnap warnt vorher ausdrücklich, wenn eine Maschine mit geladenem
    Arbeitsspeicher neu starten soll:

![Warnung vor dem Neustart](../bilder/recovery-neustart.svg)

Wer den warmen Zustand braucht, erledigt seine Arbeit also **vor** dem ersten
Neustart — oder verzichtet gleich mit `--no-resume` darauf und bootet kalt.

---

## Starten und Stoppen von außen

```bash
pvesnap-recovery start 9101
pvesnap-recovery stop 9101
pvesnap-recovery list
pvesnap-recovery console 9101
```

`list` zeigt dieselbe Tabelle wie die Übersicht:

```
Maschine   Zustand   Node    Herkunft                              Modus
VM 9101    running   pve1    VM 101 @ auto-stuendlich-20260809-…    live
VM 9102    stopped   pve2    VM 105 @ auto-taeglich-20260809-02…    recover
```

Steht in der Spalte **Zustand** ein `weg`, wurde die Maschine außerhalb von
pvesnap entfernt — dann hilft [`cleanup`](verwerfen.md#cleanup).