Einleitung

Der Proxmox Backup Server (PBS) ist die Standard-Backup-Lösung für Proxmox VE. In der Praxis stoßen Administratoren immer wieder auf dieselben Fehlermeldungen. Dieser Artikel behandelt die acht häufigsten Probleme, ihre Ursachen und die jeweilige Lösung.

1. Fingerprint-Mismatch

Ursache

Das TLS-Zertifikat des PBS hat sich geändert – etwa durch Erneuerung, Neuinstallation oder Hostnamenwechsel. PVE vertraut dem alten Fingerprint nicht mehr.

Lösung

In PVE unter Datacenter → Storage den PBS-Eintrag bearbeiten, das Fingerprint-Feld leeren und den aktuellen Fingerprint neu abrufen und bestätigen. Den neuen Fingerprint außerband prüfen, bevor er vertraut wird – diese Fehlermeldung ist genau das, was ein Man-in-the-Middle erzeugen würde.

2. Verbindung verweigert auf Port 8007

Ursache

PVE erreicht die PBS-API nicht. Mögliche Schichten: Dienst, Firewall, NAT.

Lösung

systemctl status proxmox-backup-proxy
# von der PVE-Node:
nc -zv  8007

Ist der TCP-Connect erfolgreich, liegt das Problem bei Dienst oder Authentifizierung; scheitert er, bei Netzwerk oder Firewall. PBS-Firewall muss TCP 8007 von der PVE-Node erlauben.

3. Authentifizierung fehlgeschlagen

Ursache

Drei typische Gründe: falsche API-Token-Syntax, fehlende Berechtigungen, Zeitabweichung.

Lösung

  • Token-Benutzername ist user@realm!tokenname – der Ausrufezeichen-Teil gehört zum Benutzernamen, das Secret ins Passwortfeld.
  • Token oder Benutzer benötigt DatastoreBackup (oder höher) auf /datastore/<name>.
  • NTP auf beiden Seiten prüfen – PBS-Tickets sind zeitkritisch.

4. Datastore voll (ENOSPC)

Ursache

Kein Speicherplatz mehr im Datastore.

Lösung

proxmox-backup-manager prune  --keep-daily 7 --keep-weekly 4
proxmox-backup-manager garbage-collection run 

Erst Prune, dann Garbage Collection. Bei hartem Vollstand einen alten Snapshot manuell entfernen, um Arbeitsraum zu schaffen. Langfristig bei 80 % Auslastung alarmieren.

5. Garbage Collection gibt keinen Speicher frei

Ursache

GC entfernt nur Chunks, auf die keine Snapshot mehr verweist. Außerdem gilt ein Zeitfenster von 24 Stunden 5 Minuten: Chunks mit neuerem atime werden nicht gelöscht.

Lösung

Zuerst Prune durchführen, einen Tag warten, dann GC erneut starten. Bei anhaltendem Problem andere Namespaces auf vergessene Snapshot-Gruppen prüfen und sicherstellen, dass das Datastore-Dateisystem atime nicht vollständig deaktiviert hat.

6. Verifikation fehlgeschlagen

Ursache

Ein Chunk besteht seine Checksumme nicht mehr – die Daten auf der Platte stimmen nicht mehr mit den geschriebenen überein.

Lösung

Den fehlgeschlagenen Snapshot nicht löschen, solange kein neuerer verifizierter existiert. Die nächste Sicherung des Gastes lädt die betroffenen Chunks neu und heilt die Gruppe oft selbst. Bei Mustern über mehrere Snapshots: SMART der Datastore-Disks prüfen, bei ZFS einen Scrub durchführen und zpool status lesen.

7. Backup-Gruppe gesperrt

Ursache

Zwei Tasks greifen gleichzeitig auf dieselbe Backup-Gruppe zu – etwa überlappende Backup- und Prune-Jobs oder ein abgestürzter Task mit hinterlassener Sperre.

Lösung

Laufende Tasks auf PBS prüfen und echte Tasks beenden lassen. Ist kein Task aktiv, löst sich die Sperre von selbst oder durch Neustart von proxmox-backup-proxy. Wiederkehrende Kollisionen: Zeitpläne versetzen.

8. Dirty-Bitmap wird bei jedem Backup neu erstellt

Ursache

Kein Fehler im eigentlichen Sinn, aber ein Performance-Flag: die inkrementelle Tracking-Bitmap lebt im QEMU-Speicher und geht bei VM-Stopp, Migration oder Node-Reboot verloren. Ständige Neuerstellung bedeutet: irgendetwas startet die VM zwischen den Backups neu.

Lösung

Ursache für die Neustarts finden – nächtliche Reboots im Gast, HA-Migrationen, Memory-Ballooning – und abstellen. Danach kehrt die inkrementelle Geschwindigkeit zurück.

FAQ

Wie prüfe ich die PBS-Erreichbarkeit schnell?

Von der PVE-Node: curl -k https://<pbs-host>:8007/api2/json/version. Antwortet die API, ist der Dienst erreichbar und die Authentifizierung der nächste Prüfpunkt.

Wann sollte ich alarmieren?

Bei 80 % Datastore-Auslastung, bei fehlgeschlagener Verifikation und bei wiederkehrenden Sperr-Kollisionen – nicht erst beim Ausfall.

Quellen

Hinweis: Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz (KI) erstellt.

Category
Tags

No responses yet

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert