PBS Vollgelaufen....

proxifoxi

Member
Aug 17, 2021
201
16
23
und die Sicherung ist nicht auf dem PBS sichtbar das ich sie löschen könnte.

Einen wunderschönen guten Morgen, ich habe da mal erneut ein klitzekleines Problemchen...

Also ich habe vorgestern Abend mal auf einem meiner 2 ProxmoxHosts ein Vollbackup angeworfen. (mit den folgenden befehl)

Code:
proxmox-backup-client backup pve_sda.img:/dev/sda --repository pbs.home.net:zpool01 --backup-type host --crypt-mode none

gestern habe ich festgestellt das der PBS zu 100% vollgelaufen ist, und habe daraufhin das Backup abgebrochen auf dem Host.
Leider habe ich auf dem PBS keine Host Sicherung gefunden, aber das System ist trotzdem zu 100% belegt :(
Ich habe dann einmal auf dem PBS --> Datastore --> zpool01 --> Prune & GC --> "Garbage Collection" gestartet, in der Hoffnung das damit die abgebrochenen Sicherung gelöscht wird...nunja, jetzt nach ca. 16 Stunden zeigt mir der Task das folgende an.

proxmox.png
Er scheint ja noch zu laufen, aber bringt das wirklich wieder freien speicher ?, also wird damit das abgebrochene Host-Backup entfernt und der Speicher wieder frei gegeben ?
Ansonsten bin ich für Vorschläge offen


Grüße
Foxi
 
die GC schlaegt erst fuer chunks an, die aelter als 24h sind. ausserdem ist die GC vermutlich nicht sehr schnell (oder schlaegt sogar fehl) wenn der datastore 100% voll ist. sofern du nicht irgendwie mehr platz schaffen kannst (z.b. drunter liegende disk vergroessern falls virtualisiert, andere daten loeschen falls datastore sich den storage mit anderen dingen teilt), wuerde ich folgendes vorgehen vorschlagen:

  1. sichergehen dass keine neuen backups gemacht werden und keine backup oder sync jobs mehr laufen
  2. datastore/gruppen prunen falls moeglich (das loescht zwar nur metadaten, aber damit wird schon mal ein bisschen platz frei)
  3. find /DATASTORE/.chunks -exec touch {} \; (DATASTORE entsprechend ersetzen, sicherstellen dass punkt 1. wirklich zutrifft!)
  4. GC anwerfen (durch das 'touch' aus schritt 3 werden alle chunks angeschaut)
  5. warten bis GC fertig ist - ab phase 2 werden chunks geloescht dann sollte die usage deutlich sinken
 
supi, vielen vielen Dank für den Tipp.
der find läuft nun erst einmal, mal sehen wie lange er benötigt.
sollte ich auf den 2 Hosts den PBS erst einmal herausnehmen ? nur um ganz sicher zu gehen ?

Grüße
Foxi
 
auf PVE seite den storage disablen ist sicher nicht verkehrt damit keine "unfaelle" passieren ;)
 
  • Like
Reactions: proxifoxi
sorry, aber ich muss nochmal fragen
kann ich den GC schon starten, während der find noch läuft ?
Um 10:50Uhr habe ich den "find" gestartet und jetzt um 12:10 Uhr also nach etwas über 1Std. ist er erst bei Chunk 02f6
somit würde der "find" ja noch zig Stunden laufen bis er bei ffff ankommt :oops::rolleyes:

Grüße
Foxi
 
sorry, aber ich muss nochmal fragen
kann ich den GC schon starten, während der find noch läuft ?
Um 10:50Uhr habe ich den "find" gestartet und jetzt um 12:10 Uhr also nach etwas über 1Std. ist er erst bei Chunk 02f6
somit würde der "find" ja noch zig Stunden laufen bis er bei ffff ankommt :oops::rolleyes:

Grüße
Foxi
Deshalb wird geraten SSDs für PBS zu benutzen. HDDs kommen halt nicht gerade gut mit den Millionen von Chunks klar. Nach meinem Verständnis von Datastores und Chunks sollte Punkt 3 sollte erst ganz durchlaufen müssen, bevor man Punkt 4 starten darf, weil du mit Punkt 3 die Zugriffszeit aller Chunks setzt, damit sie dann auch im viertem Schritt tatsächlich angeguckt werden. Was die GC anguckt und was nicht hängt da von den Zugriffs/Änderungszeiten der Dateiattribute der Chunks ab.
 
Last edited:
  • Like
Reactions: proxifoxi
wenns laenger dauert als bis die 24h seit dem schief gegangenen backup her sind, dann kannst du das find abbrechen, warten bis die 24h um sind, und dann die GC starten. aber die GC macht was aehnliches (touch auf alle noch referenzierten chunks statt ALLE chunks), also wird die auch ne weile brauchen ;)
 
  • Like
Reactions: proxifoxi
ok, gerade den Pool gelöscht und neu gemacht (nicht all zu schade um die Backups), ich stelle mir aber gerade die Frage ob ich irgendwie die Historie zurücksetzen kann ?
Also im Dashboard wird ja sehr übersichtlich der "Task letzten 30 Tage" dargestellt... gibt es da irgendwo eine Möglichkeit diesen zurückzusetzen ?
Da ich ja jetzt quasi frisch / neu anfange ;)

Grüße
Foxi
 
/var/log/proxmox-backup/tasks enthaelt die task logs..
 
Hallo Fabian,
gleiches Problem hier... ein PBS ist voll gelaufen. Recovery läuft noch da ein bissler viele .Chunks.
Idee/Frage: würde es nicht Sinn machen wenn Proxmox in den PBS einbaut das immer pro pool ein dataset "PBS-Recovery-Space" angelegt wird welches eine Reservation von 10gb hat aber dieses Dataset _nie_ benutzt wird? (#zfs set reservation=10gb local_datastore01/pbs-recovery-space) - das würde es doch erlauben 10gb Platz zu haben um einen vollgelaufenen PBS zu "retten" (mit den von Dir oben genannten Schritten). Oder?
Denn man würde auf die Reservation von dem dataset einfach von 10 auf 1 runtersetzen um dann 9gb Platz für die Arbeit mit den .Chunks zu haben.


Grüsse
Stephan
 
Einen ZFS Pool sollte man ja eh nicht mehr als 80% füllen. Ich setze da also immer gleich ein poolweites Quota von 90%, dass man den den Pool garnicht erst ausversehen komplett vollschreiben kann. Pool-Kapazität überwachen und Backups löschen, sobald der Pool 80% überschreitet, sollte man natürlich trotzdem.
Den Pool am Limit zu betreiben ist also so oder so eine schlechte Idee.
 
Last edited:
  • Like
Reactions: fabian
optional zu erlauben, eine quota direkt beim zpool erstellen anzugeben, mit einem hinweis, warum das sinnvoll ist klingt nicht so schlecht.. allerdings muss ein datastore ja nicht zwangslaeufig auf zfs liegen ;) logische quotas auf PBS ebene direkt sind leider nicht ganz trivial zu implementieren - zumindest, wenn sie nicht massiv performance kosten sollen..
 
Hallo zusammen,
ich sehe das hier ausschließlich im Kontext PBS und ZFS.
ein Dataset mit einer reservation wie oben vorgeschlagen anzulegen, scheint mir sinnvoller zu sein als ein Quota. Dies aber nur da ich noch nicht gefunden habe, sofern es möglich ist, ein Quota in % anzugeben. % ist aber wieder uncool da 1% von 50tb mal echt viel sein kann.

generell DANKE!, denn nun habe ich einen Weg gefunden ZFS datasets und pools vor dem volllaufen zu schützen.
wenn das als als Standardvorsichtsmaßnahme in den PBS kommt, dann fände ich das natürlich gut :)

Grüsse
Stephan
 
Dies aber nur da ich noch nicht gefunden habe, sofern es möglich ist, ein Quota in % anzugeben. % ist aber wieder uncool da 1% von 50tb mal echt viel sein kann.
ZFS Quotas kann man soweit ich weiß nur in fixen Größen angeben, also z.B. zfs set quota=10T YourPool.
Wie gesagt sollte man die 20% Verlust gleich beim Dimensionieren einplanen. Das man bei einem 50TB Pool 10TB verliert ist völlig normal und gewollt. Macht man seinen ZFS Pool zu voll, dann wird der lahm und fragmentiert schneller was gerade bei HDDs übel ist, da ZFS ein Copy-on-Write Dateisystem ist und sicher daher nicht defragmentieren lässt. Die einzige Möglichkeit eines Defragmentierens ist es, da alles vom Pool runterzukopieren und dann erneut auf dem leeren Pool zu schreiben, was dann wiederum erfordert, dass man immer einen gleich großen leeren Pool parat hat, wo man dann deutlich mehr Kapazität als die 20% verschwendet.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!