Dateien eines Gasts

Eine Wiederherstellung eines Gasts legt einen ganzen neuen Gast an, siehe Restore. Oft brauchen Sie weniger: eine Konfigurationsdatei, einen Ordner, ein Dokument, das jemand gelöscht hat. Dafür lassen sich die Sicherungsstände eines Gasts wie die Sicherungsstände eines Rechners durchsuchen, und Dateien und Ordner laden Sie als ein ZIP herunter.

Wo Sie es finden

Server & Clients → Datei-Restore. Jeder Container mit einem Sicherungsstand steht in der Gruppe Proxmox-VE-Container, jede VM mit einem Sicherungsstand in der Gruppe Proxmox-VE-VMs, die mit Vorschau gekennzeichnet ist. Die Gruppen stehen neben den Rechnern. Wählen Sie einen Gast, dann einen Sicherungsstand auf der Zeitleiste und durchsuchen Sie seine Ordner. Ein Sicherungsstand zählt, ob ihn ein Job erzeugt hat oder jemand die Sicherung von Hand gestartet hat, aus Restow oder aus Proxmox VE.
Die Seite des Gasts, geöffnet aus VMs & Container oder dem Inventar: Jeder Sicherungsstand hat Dateien durchsuchen, das Datei-Restore mit diesem Gast öffnet. Die Seite bietet es für Sicherungsstände an, die sich durchsuchen lassen (ein VM-Sicherungsstand, der nur die EFI-Variablen und den TPM-Zustand enthält, hat nichts zu durchsuchen).

Kreuzen Sie Dateien und Ordner an und wählen Sie Als ZIP herunterladen. Ein angekreuzter Ordner schließt alles darin ein. Restow bereitet das ZIP vor, und Ihr Browser startet den Download.

Die Seite sagt, was ein Sicherungsstand enthält. Bei einem Container ist das der ganze Container (/) und jeder Volume-Mountpunkt, den vzdump einschließt, und die Pfade sind die des Containers selbst: /opt/paperless/... im Browser ist /opt/paperless/... im Container. Bind-Mounts und Geräte-Mounts gehören nicht zu einer vzdump-Sicherung, sie fehlen also.

Dateien einer VM (Preview)

Die Ordner auf oberster Ebene eines VM-Sicherungsstands sind die lesbaren Dateisysteme der Festplatten der VM, jeder benannt nach seiner Lage:

Ordner	Was es ist
`scsi0`	Eine Festplatte ohne Partitionstabelle.
`scsi0-p2`	Partition 2 der Festplatte `scsi0` (GPT oder MBR, auch logische Partitionen).
`vg0-root`	Das logische Volume `root` der LVM-Volume-Gruppe `vg0`, zusammengesetzt aus den Festplatten der VM.

Die Festplatten für die EFI-Variablen und den TPM-Zustand bleiben außen vor. Was der Server nicht lesen kann, steht mit dem Grund auf der Seite (zum Beispiel BitLocker, Swap, ein logisches RAID- oder Thin-Volume oder kein bekanntes Dateisystem).

Lesbar	Nicht lesbar
Partitionen von GPT- und MBR-Festplatten und lineare logische LVM-Volumes.	btrfs, ZFS, ReFS.
ext2, ext3 und ext4, mit im Speicher nachgespieltem Journal.	LVM thin, RAID, gestreifte, Cache- und Snapshot-Volumes.
XFS.	BitLocker und LUKS.
NTFS und FAT12/16/32 (die EFI-Partition).	NTFS-komprimierte Dateien und EFS-Dateien. Deduplizierte Dateien und andere Reparse Points werden aufgelistet und nie verfolgt, ebenso symbolische Links.

Eine Datei, die sich nicht lesen lässt, hält den Download nicht auf. Sie steht mit dem Grund in _not-restored.txt im ZIP.

Wie die Dateien gelesen werden

Der Restow-Server liest die Dateien. Dafür läuft nichts auf dem Proxmox-VE-Knoten, und nichts wird eingehängt, weder auf dem Server noch auf dem Knoten.

Ein Container. Der Server öffnet das restic-Repository des Containers, pve-guests/<Gast-ID>/, mit dem Passwort, das er dafür verwahrt. Das Passwort erreicht Ihren Browser nie. Das ZIP wird gestreamt und nicht im Speicher oder auf der Platte gehalten.
Eine VM. Der Server liest die Festplatten des Sicherungsstands aus seinen Blockkarten im Chunk-Speicher des Mandanten, prüft jeden 4-MiB-Block gegen seine SHA-256 und reicht die Bytes an einen Leser in einem kurzlebigen, eingeschränkten Kindprozess. Der Leser wertet Partitionstabellen, LVM, ext, XFS, NTFS und FAT im User-Space aus. Es gibt einen Kindprozess je Ordnerseite oder Download, und er wird danach beendet. Er hat keine Schlüssel, keine Datenbankadresse und keine Speicher-Zugangsdaten, darf keine anderen Prozesse starten und hat begrenzten Arbeitsspeicher, begrenzte Zeit (60 Sekunden je Schritt) und eine begrenzte Menge an Festplatte, die er lesen darf. Daten eines Gasts erreichen nie einen Dateisystemtreiber des Kernels, denn ein präpariertes Dateisystem ist ein bekannter Weg, einen anzugreifen.

Die Seite eines Containers kann „Die Sicherungsdaten sind gerade belegt“ melden: Der Server liest ein Container-Repository nicht, solange die Aufbewahrung oder die wöchentliche Prüfung am selben arbeitet. Versuchen Sie es gleich noch einmal. Eine laufende Sicherung blockiert es nicht.

Wer es darf und was protokolliert wird

Administratoren des Mandanten und Restore-Operatoren (die Rolle „Restore“) durchsuchen und laden herunter. Ein Restore-Operator liest die Proxmox-VE-Übersicht und die Sicherungsstände eines Gasts und darf Dateien aus Container- und VM-Sicherungsständen durchsuchen und herunterladen. Ein Restore-Operator darf nicht einen ganzen Gast wiederherstellen, eine Startprüfung auslösen, sichern, Jobs oder Knoten ändern oder das Repository-Passwort lesen. Siehe Team und Rollen.
Jede gelesene Ordnerseite und jeder gestartete Download steht im Audit-Log, mit der Person als Akteur: pve.snapshot.browsed und pve.snapshot.downloaded. VMs nutzen dieselben zwei Aktionen wie Container. Das Audit-Log formuliert sie für Container („Dateien eines Sicherungsstands des Containers durchsucht“); der Eintrag einer VM trägt kind: "vm" in seinen Details.
Ein vorbereiteter Download lässt sich einmal starten, innerhalb von zehn Minuten, von der Person, die ihn vorbereitet hat. Die Adresse allein öffnet nichts. Ist er abgelaufen oder benutzt, bereiten Sie das ZIP neu vor.

Was es nicht tut

Es legt keine Dateien in den laufenden Gast zurück (0.4.7). Dateien laden Sie als ZIP herunter. Um einen ganzen Gast zurückzuholen, stellen Sie ihn als neuen Gast wieder her oder kopieren Sie die Dateien selbst aus dem ZIP.
Es ersetzt keinen Restore-Test. Eine durchsuchte Datei zeigt, dass sie sich aus dem Sicherungsstand lesen ließ. Ob ein Gast startet, sagt Ihnen eine Startprüfung.
Es liest nichts, was nicht im Backup ist. Eine Container-Sicherung enthält, was vzdump einschließt. Eine VM-Sicherung enthält die Festplatten, die Teil der Sicherung sind.

Was getestet wurde

Die Release Notes von 0.4.0 führen das Datei-Restore von VMs als nur gegen simulierte Dienste getestet auf, noch nicht gegen einen echten Proxmox-VE-Cluster. Dazu gehören die Leser für ext, XFS, NTFS, FAT, Partitionstabellen und LVM, die die Testsuite mit kleinen, dafür angelegten Dateisystem-Abbildern prüft. Kein Release bis 0.4.2 meldet einen Test auf einem Proxmox-VE-Host. Deshalb tragen VMs die Kennzeichnung Vorschau. Probieren Sie es an einem Testgast aus und vergleichen Sie Dateien mit den Originalen, bevor Sie sich darauf verlassen.

Wenn es nicht funktioniert

Symptom	Ursache und Abhilfe
Der Gast steht nicht in der Liste.	Nur Gäste mit einem Sicherungsstand stehen in der Liste, und nur Administratoren und Restore-Operatoren des Mandanten sehen die Seite. Prüfen Sie die Sicherungsstände auf der Seite des Gasts.
Die Sicherungsdaten sind gerade belegt	Die Aufbewahrung oder die wöchentliche Prüfung arbeitet am Repository dieses Containers. Versuchen Sie es gleich noch einmal.
Ein Ordner einer VM fehlt auf oberster Ebene.	Das Dateisystem ist nicht lesbar, oder es liegt auf einer Festplatte, die die Seite auslässt. Die Seite listet mit dem Grund, was sie nicht lesen konnte.
Eine Datei fehlt im ZIP.	Sie steht mit dem Grund in `_not-restored.txt`.
Der Download startet nicht.	Ein vorbereitetes ZIP startet einmal und zehn Minuten lang. Bereiten Sie es neu vor.

Siehe auch Fehlerbehebung.

Weiter

Restore: einen ganzen Gast als neuen Gast zurückholen.
Startprüfungen: nachweisen, dass ein Sicherungsstand startet.
Inventar, Gäste und Sicherungsstände