2026 Proxmox Backup Server 4.2: Datastore voll – erst bereinigen oder erweitern?

Der PBS-Datastore meldet zu wenig freien Speicher, obwohl alte Backups gelöscht wurden.

Schnellste sichere Vorgehensweise: Prüfen Sie zuerst, ob Prune und Garbage Collection (GC) wie vorgesehen gelaufen sind, und vergleichen Sie danach die PBS-Anzeige mit dem Dateisystem beziehungsweise dem tatsächlich verwendeten Speicher-Backend. Leiten Sie aus der Snapshot-Liste oder einem Deduplizierungswert keine Löschentscheidung ab und entfernen Sie niemals manuell Dateien aus .chunks. Reicht der Platz tatsächlich nicht mehr oder kann GC nicht ausgeführt werden, klären Sie zuerst Backend, Datenrisiko und Wiederherstellungsweg; erst dann bereinigen Sie nach dokumentiertem Verfahren oder erweitern den Speicher.

Dieser Artikel richtet sich an Administratoren, die einen eigenen PBS betreiben und anhaltendes Wachstum im Datastore feststellen.
MSPs können damit Kundenaufgaben, Aufbewahrungsregeln und Kapazitätsalarme getrennt prüfen, statt vorschnell gemeinsam genutzte Sicherungsdaten zu verändern.
Technische Verantwortliche kleiner Rechenzentren finden eine Entscheidungshilfe für mehrere Mandanten und unabhängige Sicherungsziele.

Aktuellen Stand und Fehlerbild getrennt erfassen

Proxmox Backup Server 4.2 wurde laut offizieller Veröffentlichung vom 29.04.2026 freigegeben. Die offizielle PBS-4.2-Dokumentation beschreibt Datastores und unterstützte Speicherfunktionen; für die konkrete Bedienung und Wartung sind jedoch die Dokumentation und die Konfiguration Ihrer Installation maßgeblich. Letzte Aktualisierung: 28.10.2026; geprüft anhand der PBS-4.2-Veröffentlichung sowie der offiziellen Speicher-, Wartungs- und Befehlsdokumentation.

Ein voller Datastore ist zunächst ein Symptom, keine Diagnose. Trennen Sie mindestens diese Ursachen:

• Prune wurde nicht ausgeführt: Der geplante Auftrag fehlt, ist deaktiviert, wurde nicht gestartet oder endete mit einem Fehler. Dann können alte Snapshot-Referenzen erhalten bleiben.
• Prune lief, GC jedoch nicht: Das Entfernen nicht mehr benötigter Referenzen und das tatsächliche Freigeben nicht mehr verwendeter Chunks sind unterschiedliche Wartungsschritte. Ein erfolgreicher Prune-Lauf beweist daher nicht, dass das Dateisystem bereits Speicher zurückgewonnen hat.
• Die Aufbewahrungsregel entspricht nicht dem Bedarf: Ein technisch erfolgreicher Auftrag kann mehr Sicherungspunkte behalten als geplant oder fachlich erforderlich. Eine Änderung der Regel wirkt nicht rückwirkend als sofortige Speicherfreigabe.
• Der PBS-Wert und der Speicherverbrauch weichen voneinander ab: Der Datastore-Überblick, deduplizierte Datenwerte und der freie Platz des Dateisystems beschreiben nicht dasselbe. Zusätzlich können Backend-Eigenschaften die Sicht auf belegten Speicher beeinflussen.
• Der Speicher ist tatsächlich erschöpft: Ein zu knappes Dateisystem, ein ZFS-Pool ohne ausreichend nutzbaren Platz oder ein Backend, das seine Grenze erreicht hat, kann die Wartung selbst behindern.

Die PBS-Wartungsdokumentation erklärt die Aufgaben von Prune und Garbage Collection. Prüfen Sie außerdem, welche Datastore-Konfiguration und Speicherart auf Ihrem System tatsächlich verwendet wird: Die PBS-Speicherdokumentation ist dafür die maßgebliche Referenz. Ein einzelner Community-Beitrag, etwa die Diskussion zu einem gemeldeten Fall mit fehlendem Speicherplatz, ist ein Fallbericht und kein Nachweis für eine allgemeine Ursache in PBS 4.2.

Warum wird nach dem Löschen von Backups kein Speicher frei?

Ein gelöschter Snapshot und eine freigegebene Datenmenge sind nicht gleichzusetzen. PBS kann Datenblöcke gemeinsam nutzen: Ein Chunk darf erst dann als nicht mehr benötigt gelten, wenn keine verbliebenen Sicherungen mehr darauf verweisen. Selbst wenn eine Aufbewahrungsregel Snapshot-Einträge entfernt, muss die Garbage Collection anschließend prüfen, welche Chunks noch gebraucht werden und welche tatsächlich freigegeben werden dürfen. Der zeitliche Abstand zwischen diesen Vorgängen ist deshalb nicht automatisch ein Fehler.

Auch die Größe eines einzelnen Sicherungspunkts ist kein verlässlicher Wert für den Speicher, der nach seinem Entfernen frei werden müsste. Deduplizierung, gemeinsam genutzte Chunks und die verbleibenden Sicherungen beeinflussen das Ergebnis. Ein hoher Deduplizierungswert ist weder eine Prognose für sofort verfügbaren Speicher noch eine Freigabe zur manuellen Bereinigung. Prüfen Sie die ausgeführten Aufgaben und das Backend, bevor Sie die weitere Kapazität planen.

Was unterscheidet Prune und GC?

Prune setzt die Aufbewahrungsregeln um und entfernt Sicherungspunkte, die nach dieser Regel nicht mehr behalten werden sollen. GC ermittelt anschließend, welche Datenblöcke von keiner verbleibenden Sicherung mehr benötigt werden. Beide Aufgaben lösen damit unterschiedliche Teile der Bereinigung: Prune ändert, welche Sicherungen gültig sind; GC bearbeitet die daraus entstehende Speicherbereinigung. Details zu verfügbaren Wartungsfunktionen und ihrem Ablauf finden Sie in der offiziellen PBS-Wartungsdokumentation.

Wenn Prune regelmäßig läuft, aber die GC-Aufgabe ausbleibt, liegt der nächste Prüfschritt nicht in einer manuellen Löschung. Kontrollieren Sie Zeitplan, letzte Ausführung, Ergebnis und Protokoll der betroffenen Aufgabe. Eine GC-Ausführung, die noch läuft oder mit einem Fehler beendet wurde, muss anders behandelt werden als eine GC, die gar nicht eingeplant ist. Prüfen Sie außerdem, ob gerade eine andere Wartungsaufgabe oder ein Zugriff auf den Datastore läuft, bevor Sie Änderungen an Aufgaben oder Speicher vornehmen.

Zuständigkeit nach Betriebssituation festlegen

Für den einzelnen PBS-Administrator

Wenn Sie eine einzelne PBS-Instanz verwalten, sichern Sie zuerst den Befund: Datastore, verwendetes Backend, betroffene Aufgabe, Zeitpunkt und vollständiges Aufgabenprotokoll. Vergleichen Sie dann den Datastore-Status mit der freien Kapazität des tatsächlich darunterliegenden Speicherorts. Unter Linux können beispielsweise findmnt -T /PFAD/ZUM/DATASTORE und df -hT /PFAD/ZUM/DATASTORE helfen, den eingehängten Speicher und die Dateisystembelegung zu identifizieren. Verwenden Sie dabei den in Ihrer Installation konfigurierten Pfad; ein beliebiger Beispielpfad wäre keine verlässliche Diagnose.

Prüfen Sie im PBS-Verwaltungsbereich die geplanten Prune- und GC-Aufgaben, ihre letzten Ergebnisse und die dazugehörigen Protokolle. Bei Bedarf können Sie die für Ihre Installation verfügbaren Verwaltungsbefehle in der PBS-Befehlsreferenz nachschlagen. Führen Sie keinen Befehl aus, dessen Ziel-Datastore oder Wirkung Sie nicht geprüft haben. Halten Sie vor Änderungen am Zeitplan, an Aufbewahrungsregeln oder am Backend fest, wie Sie den vorherigen Zustand wiederherstellen.

Für MSPs mit mehreren Kundenumgebungen

In einer MSP-Umgebung ist die erste Aufgabe nicht, Speicher „freizuräumen“, sondern Fehlerdiagnose und Kundenänderung voneinander zu trennen. Ein fehlgeschlagener GC-Lauf auf einem Kundensystem ist ein anderer Vorgang als eine genehmigte Änderung der Aufbewahrungsfrist. Verknüpfen Sie jeden Befund mit dem richtigen Kunden, Datastore und Auftrag; übernehmen Sie nicht versehentlich eine Aufbewahrungsregel aus einer anderen Umgebung.

Bewahren Sie Aufgabenprotokolle, Alarmmeldungen und Änderungen an Prune- oder GC-Zeitplänen auf. Dokumentieren Sie, wer die Änderung freigegeben hat und welche Sicherungspunkte davon betroffen sein können. Bei personenbezogenen oder anderweitig vertraulichen Sicherungsdaten müssen Sie außerdem die vertraglichen und internen Vorgaben zur Aufbewahrung berücksichtigen. Ein kurzfristig freier Speicherplatz ist kein ausreichender Grund, Sicherungen zu entfernen, deren Aufbewahrung noch erforderlich ist.

Für kleine Rechenzentren mit mehreren Mandanten

Bei mehreren Mandanten müssen Sie die Grenze des betroffenen Datastores und die des darunterliegenden Speichers eindeutig bestimmen. Prüfen Sie, ob die Belegung zu einem Dateisystem wie ext4 oder XFS, zu einem ZFS-Pool oder zu einem anderen dokumentierten Backend gehört. Für jedes Backend können andere Verwaltungsanzeigen und Kapazitätsgrenzen relevant sein. Übertragen Sie nicht einfach eine für ein normales Dateisystem passende Prüf- oder Reparaturmaßnahme auf einen Pool oder einen Objektspeicher.

Verwenden Sie bei einem S3-basierten Speicher nur die für Ihre tatsächliche PBS-Version und Integration dokumentierte Betriebsweise. Dateisystembefehle wie df zeigen dort nicht automatisch die für Sie entscheidende Kapazität. Prüfen Sie stattdessen die dokumentierte Ansicht und die Meldungen des konkret eingesetzten Backends. Die PBS-Speicherdokumentation beschreibt den PBS-seitigen Rahmen; sie ersetzt nicht die produktspezifische Dokumentation eines externen Speicherdienstes.

Prüfablauf für eine sichere Diagnose

Arbeiten Sie die folgenden Punkte in dieser Reihenfolge ab. Wenn ein Schritt zeigt, dass der Speicherbackend-Zustand nicht eindeutig ist, halten Sie vor Änderungen an und klären Sie zuerst dessen Konfiguration.

1. Betroffenen Datastore abgrenzen. Notieren Sie den Namen, den Speicherpfad beziehungsweise das Backend und die betroffenen Mandanten. Prüfen Sie, ob mehrere Datastores denselben physischen Pool oder dieselbe Speichergrenze teilen.
2. Aufgabenstatus prüfen. Kontrollieren Sie, ob die Prune- und GC-Aufträge eingerichtet sind, wann sie zuletzt liefen und ob sie erfolgreich beendet wurden. Öffnen Sie die Protokolle, statt sich nur auf eine Statusübersicht zu verlassen.
3. Aufbewahrungsregel kontrollieren. Vergleichen Sie die tatsächlich konfigurierte Regel mit der freigegebenen Aufbewahrung. Ändern Sie sie nicht allein deshalb, weil der Datastore voll ist; berücksichtigen Sie, welche Sicherungspunkte dadurch entfallen würden.
4. PBS- und Backend-Anzeige gegenüberstellen. Prüfen Sie den Datastore-Status und die Kapazität des darunterliegenden Speicherorts. Bei einem Dateisystem helfen passende Systemanzeigen; bei ZFS, S3 oder einem anderen Backend verwenden Sie die dafür vorgesehene Dokumentation und Verwaltungsansicht.
5. Fehlerursache festhalten. Ordnen Sie den Befund einer nicht ausgeführten Aufgabe, einem fehlgeschlagenen Lauf, einer unerwarteten Aufbewahrungsregel oder einer tatsächlichen Speichergrenze zu. Sichern Sie Protokolle und Zeitpunkt, bevor Sie Änderungen vornehmen.
6. Maßnahme genehmigen und absichern. Legen Sie Wartungsfenster, Freigabe, Wiederherstellungsweg und Rückfallplan fest. Für riskante Speicheränderungen reicht ein erfolgreicher früherer Backup-Lauf allein nicht als Wiederherstellungsnachweis.
7. Nach der Änderung erneut prüfen. Kontrollieren Sie Aufgabenprotokolle, Datastore-Zustand und Backend-Belegung. Bestätigen Sie anschließend, dass neue Sicherungen nach Plan abgeschlossen werden und GC nicht lediglich erneut aufgeschoben wurde.

Entscheidung nach Fehlerzustand

Erst bereinigen oder erweitern?

Eine Bereinigung ist nur dann der nächste Schritt, wenn Sie eine nachvollziehbare Ursache haben: etwa eine fehlende GC-Ausführung, eine bestätigte fehlerhafte Aufgabenplanung oder eine abgestimmte Änderung an der Aufbewahrung. Eine Erweiterung ist zu prüfen, wenn der Speicherbedarf bei korrektem Betrieb und passender Aufbewahrung dauerhaft höher ist als der nutzbare Platz. Werden beide Fragen vermischt, besteht das Risiko, Daten ohne Freigabe zu entfernen oder zusätzliche Kapazität zu kaufen, obwohl ein Wartungsauftrag lediglich nicht ausgeführt wurde.

Was tun, wenn GC wegen einer vollen Platte nicht startet?

Gehen Sie nicht davon aus, dass eine manuelle Löschung von Chunks die GC wieder lauffähig macht. Erfassen Sie zuerst die genaue Fehlermeldung und stellen Sie fest, ob PBS tatsächlich keinen freien Platz mehr melden kann, ein Backend- oder Mount-Problem vorliegt oder der Auftrag aus einem anderen Grund fehlschlägt. Prüfen Sie die dazu passenden Hinweise in der Wartungs- und Speicherreferenz. Falls das Backend eine sichere, dokumentierte Möglichkeit zum Freimachen oder Vergrößern von Speicher bietet, klären Sie vorher, welche Daten betroffen sind und wie Sie den Zustand wiederherstellen.

Kapazität nach der Behebung neu bewerten

Nach einer erfolgreichen Bereinigung ist die Kapazitätsfrage nicht automatisch erledigt. Prüfen Sie, ob Prune und GC wieder planmäßig laufen, ob der Datastore-Status mit dem Backend übereinstimmt und ob die nachfolgenden Sicherungen fehlerfrei abgeschlossen werden. Ein einzelner erfolgreicher Lauf zeigt nicht, dass die bisherige Kapazität langfristig ausreicht.

Schätzen Sie den Bedarf anhand Ihrer eigenen Sicherungen und Aufbewahrungsregeln. Erfassen Sie, wie viel Speicher über einen repräsentativen Betriebszeitraum hinzugekommen ist, welche Daten gemeinsam genutzt werden und welche Sicherungspunkte aus betrieblichen oder vertraglichen Gründen erhalten bleiben müssen. Nutzen Sie dafür reale Verlaufsmessungen Ihres Systems, nicht Zahlen aus einem einzelnen Forenfall. Wenn Sie noch keine belastbare Verlaufsmessung haben, planen Sie zunächst eine Beobachtungsphase und halten Sie währenddessen Belegung, Aufgabenstatus und Fehler fest.

Bei einer Erweiterung müssen Sie außerdem die Speichergrenze des konkreten Backends, die Ausfallsicherheit und eine unabhängige Kopie berücksichtigen. Mehr nutzbarer Platz im Datastore ist nicht dasselbe wie eine redundante oder externe Sicherung. Ein Speicherziel, das nur die Kapazität erhöht, aber keinen passenden Schutz vor Ausfall bietet, löst nicht automatisch das Risiko des Ausgangssystems.

Unabhängiges Sicherungsziel passend planen

Wenn die bestehende Umgebung dauerhaft keinen angemessenen Spielraum bietet, kann ein unabhängiger Server als separates Sicherungsziel in die Planung einbezogen werden. Vergleichen Sie dabei nicht nur die nominelle Datenträgerkapazität. Entscheidend sind die tatsächlich nutzbare Kapazität nach der gewählten Redundanz, die Zahl der Laufwerke, das erwartete Wachstum, die Verbindungsgeschwindigkeit sowie ein zusätzlicher, vom Server getrennter Sicherungsweg. Auch die Wiederherstellung muss in Ihre Planung passen: Ein Ziel, das zwar Daten aufnimmt, aber im Ausfallfall nicht rechtzeitig erreichbar ist, erfüllt Ihre betrieblichen Anforderungen möglicherweise nicht.

Prüfen Sie außerdem, ob Sie langfristig einen dedizierten AMD-Server benötigen oder ob die bestehende gemeinsam genutzte Umgebung für Ihren Bedarf ausreicht. Eine gemeinsam genutzte VM kann für geringe oder vorübergehende Last sinnvoll sein, bringt aber weniger Kontrolle über die zugrunde liegenden Ressourcen und kann bei dauerhaftem Wachstum die Kapazitätsplanung erschweren. Ein dedizierter physischer Server ist dagegen dann eine passendere Option, wenn Sie unabhängig zugewiesene Ressourcen und eine dauerhaft betriebene eigene Sicherungsinfrastruktur benötigen. Er ersetzt jedoch weder PBS-Wartung noch Redundanzplanung oder externe Sicherungen.

Für die Auswahl eines unabhängigen Ziels sollten Sie zunächst Ihren gemessenen Bedarf, die gewünschte Redundanz und die Backend-Anforderungen festhalten. Die Informationen zur Serverkonfiguration von OVN Cloud können Sie anschließend mit diesen Anforderungen abgleichen; konkrete Hardware- und Speicheroptionen sollten Sie ausschließlich anhand der dort aktuell ausgewiesenen Angaben bewerten. Wenn Sie die laufende finanzielle Planung einbeziehen, vergleichen Sie die Angaben zu den monatlichen Abrechnungsoptionen mit Ihrer vorgesehenen Betriebsdauer.

Wenn Ihr PBS-Datastore nur wegen eines nicht ausgeführten Auftrags voll wirkt, beginnen Sie mit dessen Fehlerbehebung und verschieben Sie die Erweiterungsentscheidung, bis die Backend-Belegung geklärt ist. Ist der Speicher dagegen bei korrektem Prune- und GC-Betrieb dauerhaft zu knapp, vergleichen Sie die Anforderungen an Kapazität, Redundanz und externe Sicherung mit einem dedizierten AMD-Server von OVN Cloud. So entscheiden Sie anhand Ihres tatsächlichen Sicherungswachstums und der aktuell verfügbaren Serveroptionen, statt aus einer einzelnen Fehlermeldung oder einem Community-Fall auf den allgemeinen Bedarf zu schließen.