SOP Übersicht und Anhänge

SOP-Metadaten

SOP-Nummer: SOP 1007
Priorität: Prio 2
Dauer: 10 Minuten
Status: Aktuell

Download:

Beschreibung der Aufgabe / des Problems

Ein Proxmox-Backup liegt als Datei vzdump-qemu-00-00-00-00.vma.zst auf dem Produktiv-Server (192.168.178.100).
Dieses Backup soll sauber, reproduzierbar und ohne Root-SSH auf den Backup-Proxmox (192.168.178.200) übertragen werden.
Anschließend wird ein Restore-Test durchgeführt, um das Backup wirklich zu validieren.
Problemtypisch: Direkter rsync nach /var/lib/vz/dump scheitert ohne Root-Rechte auf dem Ziel (Permission denied, rsync code 23).

Ziel / Endergebnis

• Die Datei vzdump-qemu-00-00-00-00.vma.zst liegt korrekt auf dem Backup-Server in /var/lib/vz/dump/.
• Root-SSH bleibt deaktiviert (Login nur als andre).
• andre darf auf dem Backup-Server ausschließlich rsync als root ausführen (minimale Rechte).
• Restore-Test ist erfolgreich: VM wird wiederhergestellt und startet.
• Optionaler Fix für alte Hardware: CPU-Kompatibilität (z. B. kvm64) ist bekannt.

Voraussetzungen

1. Netzwerk

• Produktiv-Proxmox: 192.168.178.100 erreichbar
• Backup-Proxmox: 192.168.178.200 erreichbar

2. Benutzer / Rechte

• SSH Login ist nur als Benutzer andre erlaubt
• andre hat sudo-Rechte auf beiden Systemen
• Root-SSH ist deaktiviert (gewollt)

3. Tools / Pfade

• Backup-Datei liegt auf Produktiv in /var/lib/vz/dump/
• Zielverzeichnis auf Backup: /var/lib/vz/dump/
• rsync ist installiert (Standard in Proxmox)
• qmrestore ist verfügbar (Proxmox-Node, nicht PBS)

4. Beispielwerte

• Backup-Dateiname: vzdump-qemu-00-00-00-00.vma.zst
• Produktiv: 192.168.178.100
• Backup: 192.168.178.200
• Test-VMID (Beispiel): 905

Video-Anleitung

folgt auf YouTube Link:

Text-Anleitung

Schritt 1: Backup-Ordner und Rechte auf dem Backup-Server vorbereiten (einmalig)

Auf dem Backup-Proxmox (192.168.178.200) als andre anmelden.

Code: ssh andre@192.168.178.200

Prüfen, ob /var/lib/vz/dump existiert und Root gehört.

Code: ls -ld /var/lib/vz/dump

Falls der Ordner fehlt oder Rechte unklar sind, neu setzen.

Code: sudo mkdir -p /var/lib/vz/dump
 sudo chown root:root /var/lib/vz/dump
 sudo chmod 755 /var/lib/vz/dump

Erklärung:

• mkdir -p erstellt den Ordner, falls er nicht existiert.
• chown root:root setzt Besitzer und Gruppe auf root, passend für Proxmox-Dumps.
• chmod 755 erlaubt Lesen/Betreten für alle, Schreiben nur für root.

Schritt 2: andre darf rsync als root ausführen (einmalig, minimal und sicher)

Auf dem Backup-Proxmox (192.168.178.200) wird eine gezielte sudo-Regel gesetzt:
 andre darf nur rsync als root ausführen – ohne Passwort.

Code: sudo visudo

Am Ende folgende Zeile hinzufügen:

Code: andre ALL=(root) NOPASSWD:/usr/bin/rsync

Erklärung:

• visudo bearbeitet sudoers sicher (Syntaxprüfung, verhindert Lockouts).
• Diese Regel erlaubt andre exakt einen privilegierten Befehl:
• nur /usr/bin/rsync
• als root
• ohne Passwort (wichtig für automatisierbare Transfers)
• Root-SSH bleibt weiterhin deaktiviert.

Optional prüfen, ob rsync wirklich hier liegt:

Code: which rsync

Wenn der Pfad abweicht, muss der Pfad in der sudo-Regel entsprechend angepasst werden.

Schritt 3: Backup-Datei auf Produktiv-Server prüfen

Auf dem Produktiv-Proxmox (192.168.178.100) als andre anmelden.

Code: ssh andre@192.168.178.100

Prüfen, ob die Datei existiert und Größe plausibel ist.

Code: ls -lh /var/lib/vz/dump/vzdump-qemu-00-00-00-00.vma.zst

Erklärung:

• ls -lh zeigt lesbare Größen (MB/GB), gut für Plausibilitätscheck.
• Wenn die Datei nicht existiert, ist der Pfad oder Dateiname falsch.

Schritt 4: Transfer in einem Schritt (sauber, ohne Root-SSH)

Der Transfer wird vom Produktiv-Server (192.168.178.100) gestartet.
 Wichtig ist, dass rsync auf dem Ziel (Backup-Server) per sudo läuft.

Code: rsync -avh –progress –rsync-path=“sudo rsync“ /var/lib/vz/dump/vzdump-qemu-00-00-00-00.vma.zst andre@192.168.178.200:/var/lib/vz/dump/

Erklärung der Parameter:

• rsync synchronisiert Dateien zuverlässig über SSH.
• -a (archive) übernimmt Struktur, Zeiten, Rechte (robuster Transfer).
• -v zeigt mehr Ausgaben (gut im Video).
• -h menschenlesbare Größen.
• –progress zeigt Fortschritt während der Übertragung (perfekt für große Dateien).
• –rsync-path=“sudo rsync“ ist der Kern:
• SSH meldet sich weiterhin als andre an
• auf dem Ziel wird rsync aber als root ausgeführt
• dadurch darf rsync in /var/lib/vz/dump schreiben
• Zielpfad /var/lib/vz/dump/ ist Proxmox-konform.

Schritt 5: Transfer-Ergebnis auf dem Backup-Server prüfen

Auf dem Backup-Proxmox (192.168.178.200) prüfen, ob die Datei angekommen ist.

Code: ssh andre@192.168.178.200

Code: ls -lh /var/lib/vz/dump/vzdump-qemu-00-00-00-00.vma.zst

Erklärung:

• Die Datei muss existieren und die Größe muss plausibel sein.
• Bei Abweichungen Transfer erneut starten.

Optional (Integritätscheck des ZST-Containers):

Code: zstd -t /var/lib/vz/dump/vzdump-qemu-00-00-00-00.vma.zst

Erklärung:

• zstd -t testet, ob das komprimierte Archiv strukturell intakt ist.

Schritt 6: Restore-Test durchführen (qmrestore)

Restore wird auf dem Backup-Proxmox (192.168.178.200) durchgeführt.
 Als Test-VMID wird in dieser SOP 905 verwendet (anpassbar).

Code: sudo qmrestore /var/lib/vz/dump/vzdump-qemu-00-00-00-00.vma.zst 905

Erklärung:

• qmrestore stellt eine VM aus dem vzdump-Backup wieder her.
• sudo ist notwendig, weil Proxmox VM-Konfigurationen und Disks anlegt.
• 905 ist die neue VMID für den Restore-Test.

Danach prüfen, ob die VM existiert:

Code: sudo qm list

Konfiguration ansehen:

Code: sudo qm config 905

VM starten:

Code: sudo qm start 905

Schritt 7: Spezialfall bei alter Hardware (CPU-Feature fehlt, z. B. AES)

Wenn die VM beim Start meldet, dass ein CPU-Feature fehlt, liegt es daran, dass die VM-Konfiguration CPU-Flags erwartet, die der Backup-PC nicht liefern kann.

Lösung: CPU-Profil auf kompatibel umstellen.

Code: sudo qm set 905 –cpu kvm64

Danach neu starten:

Code: sudo qm start 905

Erklärung:

Das ist ideal für Restore-Tests auf älterer Hardware.

–cpu kvm64 setzt ein generisches, kompatibles CPU-Modell.

Besonderheiten

Root-SSH bleibt deaktiviert: Sicherheit bleibt hoch.

Die sudo-Regel ist minimal: andre darf ausschließlich /usr/bin/rsync als root ohne Passwort.

rsync braucht Schreibrechte auf dem Zielordner, weil es temporäre Dateien anlegt (mkstemp).
Ohne --rsync-path="sudo rsync" scheitert der Transfer nach /var/lib/vz/dump.

Restore-Tests auf alter Hardware können CPU-Fehler auslösen (z. B. fehlendes AES).
Das wird durch --cpu kvm64 gelöst.

Für echte Backup-Validierung ist der Restore-Test entscheidend:
Eine Backup-Datei ist erst wertvoll, wenn ein Restore startet und funktioniert.

Meistgesuchte Fragen und Antworten

PROXMOX BACKUP UND PROXMOX BACKUP SERVER
GRUNDLAGEN, UNTERSCHIEDE UND EINORDNUNG

Einordnung des Themas im Proxmox-Umfeld

In Proxmox-Umgebungen existieren zwei unterschiedliche, aber eng miteinander verbundene Konzepte zur Datensicherung. Zum einen gibt es die klassische Backup-Funktion, die direkt im Proxmox-Server integriert ist und häufig verkürzt als „Proxmox Backup“ bezeichnet wird. Zum anderen existiert der Proxmox Backup Server als eigenständiges System, das speziell für die Verwaltung, Speicherung und Optimierung von Backups entwickelt wurde. Beide Ansätze verfolgen unterschiedliche Ziele und sind nicht als Konkurrenz, sondern als komplementäre Werkzeuge zu verstehen. Um eine fundierte Entscheidung treffen zu können, ist es wichtig, die technischen Unterschiede und die jeweiligen Vorteile zu kennen.

Proxmox Backup als integrierte Sicherungsfunktion

Das klassische Proxmox Backup ist unmittelbar Bestandteil eines Proxmox-Servers. Es basiert technisch auf dem Werkzeug vzdump, das virtuelle Maschinen und Container in eine einzelne Backup-Datei sichert. Diese Datei liegt in der Regel im Format .vma.zst vor und enthält sowohl die virtuellen Festplatten als auch die zugehörige Konfiguration der jeweiligen VM. Da es sich um eine normale Datei handelt, ist sie im Dateisystem sichtbar, kopierbar und unabhängig vom ursprünglichen Server nutzbar. Genau diese Transparenz ist ein zentraler Vorteil der integrierten Backup-Funktion. Administratoren behalten jederzeit die volle Kontrolle über ihre Sicherungen und können diese gezielt auf anderen Proxmox-Servern wiederherstellen oder für Restore-Tests verwenden.

Proxmox Backup Server als spezialisiertes Backup-System

Der Proxmox Backup Server ist ein eigenständiges System, das ausschließlich für Backup-Zwecke konzipiert wurde. Er arbeitet blockbasiert, unterstützt vollständige Inkrementalität und nutzt Deduplizierung, um Speicherplatz effizient zu verwenden. Anders als beim klassischen Proxmox Backup entstehen hier keine einzelnen Backup-Dateien, die direkt im Dateisystem liegen, sondern Backups werden in einer speziell entwickelten Datenstruktur gespeichert. Der Backup Server bietet eine zentrale Oberfläche zur Verwaltung, Überwachung und Verifikation von Sicherungen und ist besonders für größere Umgebungen mit vielen virtuellen Maschinen oder häufigen Backup-Zyklen ausgelegt.

Technischer Kernunterschied zwischen beiden Ansätzen

Der wesentliche Unterschied zwischen Proxmox Backup und Proxmox Backup Server liegt im Grad der Abstraktion. Während das klassische Backup sehr direkt arbeitet und für den Administrator vollständig transparent ist, abstrahiert der Proxmox Backup Server viele technische Details zugunsten von Effizienz, Komfort und Skalierbarkeit. Das klassische Backup erzeugt ein greifbares Artefakt in Form einer Datei, die unabhängig existiert und einfach transportiert werden kann. Der Backup Server hingegen optimiert den Sicherungsprozess durch Deduplizierung und inkrementelle Speicherung, verzichtet dafür aber auf die direkte Sichtbarkeit einzelner Backup-Dateien. Beide Konzepte sind technisch valide, sprechen jedoch unterschiedliche Anforderungen an.

Vorteile der Backup-Lösung speziell für Proxmox-Server

Ein entscheidender Vorteil der Proxmox-Backup-Lösung liegt in ihrer engen Integration in die Virtualisierungsplattform. Proxmox kennt die Struktur seiner virtuellen Maschinen, deren Konfigurationen und Abhängigkeiten und kann diese ohne zusätzliche Agenten sichern. Dadurch entstehen konsistente Backups auf Hypervisor-Ebene, die sowohl virtuelle Festplatten als auch Metadaten zuverlässig erfassen. Zudem können sowohl KVM-VMs als auch LXC-Container mit demselben Mechanismus gesichert werden, was den Betrieb vereinfacht und ein einheitliches Vorgehen ermöglicht. Diese Integration reduziert Komplexität und erhöht die Zuverlässigkeit der Sicherungen.

Restore-Tests als zentrales Qualitätsmerkmal

Ein besonders wichtiger Aspekt der Proxmox-Backup-Strategie ist die einfache Durchführung von Restore-Tests. Beim klassischen Proxmox Backup können Sicherungen auf einen anderen Proxmox-Server kopiert und dort testweise wiederhergestellt werden, selbst auf abweichender oder älterer Hardware. Dabei werden Probleme wie fehlende CPU-Features oder Netzwerkinkonsistenzen sichtbar, bevor sie im Ernstfall kritisch werden. Diese Möglichkeit, Wiederherstellungen realitätsnah zu testen, ist ein entscheidender Vorteil für den operativen Betrieb und die Qualitätssicherung von Backups. Auch beim Proxmox Backup Server sind Restore-Tests möglich, jedoch stärker in die Systemlogik eingebettet und weniger dateibasiert nachvollziehbar.

Einsatzszenarien und Entscheidungshilfe

Das klassische Proxmox Backup eignet sich besonders für kleinere und mittlere Umgebungen, Einzelserver, Test- und Entwicklungsumgebungen sowie für Szenarien, in denen Transparenz und Kontrolle im Vordergrund stehen. Es ist leicht verständlich, gut dokumentierbar und ideal geeignet, um Backup- und Restore-Prozesse als SOP festzuhalten. Der Proxmox Backup Server entfaltet seine Stärken vor allem in größeren Infrastrukturen mit vielen virtuellen Maschinen, häufigen Sicherungen und begrenztem Speicherplatz. Dort sorgen Deduplizierung, Inkrementalität und zentrale Überwachung für Effizienz und Skalierbarkeit. Die Wahl hängt somit weniger von der „Qualität“ des Systems ab, sondern vom konkreten Einsatzszenario.

Bedeutung für Betrieb, Dokumentation und Schulung

Aus betrieblicher Sicht ist das Verständnis des klassischen Proxmox Backups eine wichtige Grundlage, um später mit dem Proxmox Backup Server sinnvoll arbeiten zu können. Wer weiß, wie ein Backup entsteht, wie es übertragen wird und wie ein Restore technisch funktioniert, kann auch komplexere Backup-Systeme fundiert beurteilen und betreiben. Für Schulungen, SOPs und Wissensaufbau ist das klassische Backup daher ein idealer Einstiegspunkt. Der Proxmox Backup Server stellt darauf aufbauend eine professionelle Erweiterung dar, ersetzt jedoch nicht das grundlegende Verständnis von Backup- und Restore-Prozessen.

Zusammenfassende Bewertung

Zusammenfassend lässt sich festhalten, dass Proxmox Backup und Proxmox Backup Server unterschiedliche, aber sich ergänzende Aufgaben erfüllen. Das klassische Proxmox Backup überzeugt durch Transparenz, Einfachheit und sehr gute Restore-Test-Möglichkeiten. Der Proxmox Backup Server bietet Effizienz, Skalierbarkeit und zentrale Verwaltung für anspruchsvollere Umgebungen. Für Proxmox-Server ergibt sich daraus eine flexible Backup-Strategie, bei der das grundlegende Ziel immer gleich bleibt: eine getestete, nachvollziehbare und funktionierende Wiederherstellung im Ernstfall.

Weiterführende Dokumente

Interne Dokumente:
Externe Dokumente:

Was ist eine SOP (Standard Operating Procedure)?

Eine SOP (Standard Operating Procedure) ist eine klar definierte, schriftliche Arbeitsanweisung, die beschreibt, wie ein Prozess Schritt für Schritt korrekt ausgeführt wird. Sie sorgt dafür, dass Aufgaben einheitlich, nachvollziehbar und in gleichbleibender Qualität erledigt werden.