PBS Vollgelaufen....

[proxifoxi]

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)

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.


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

 

[fabian]

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

 

[proxifoxi]

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

 

[fabian]

auf PVE seite den storage disablen ist sicher nicht verkehrt damit keine "unfaelle" passieren

 

[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

Grüße
Foxi

 

[Dunuin]

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

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.

 

[fabian]

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

 

[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

 

[fabian]

/var/log/proxmox-backup/tasks enthaelt die task logs..

 

[vongehlens]

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

 

[Dunuin]

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.

 

[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..

 

[vongehlens]

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

 

[Dunuin]

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.

 

[TErxleben]

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..

Lieber Fabian,
wie wäre es denn nur mit einer Warnung in der GC-Notificationmail, wenn die Belegung eines Datastores x% übersteigt?

 

[fabian]

Lieber Fabian,
wie wäre es denn nur mit einer Warnung in der GC-Notificationmail, wenn die Belegung eines Datastores x% übersteigt?

ich glaube so etwas wuerde eher unabhaengig von der GC sinn machen, vielleicht im rahmen von diesem feature hier: https://bugzilla.proxmox.com/show_bug.cgi?id=5108 (kommt zwar derzeit nicht vor, aber laesst sich denk ich gut kombinieren)

 

[TErxleben]

ich glaube so etwas wuerde eher unabhaengig von der GC sinn machen, vielleicht im rahmen von diesem feature hier: https://bugzilla.proxmox.com/show_bug.cgi?id=5108 (kommt zwar derzeit nicht vor, aber laesst sich denk ich gut kombinieren)

Das ist natürlich auch eine gute Idee. Ich habe mir erstmal mit einem Shellscript und crontab innerhalb des PBS geholfen. So prüfe ich täglich die Auslastung und bekomme ab xy% Belegung eine Warnmail.

#!/bin/sh
#Empfaenger der E-Mail
ADMIN="mail@deinedomain.de"

# Auslastung: zeigt an, zu wie viel Prozent die Festplatte belegt ist
Auslastung=$(df /mnt/datastore/pbs | grep / | awk '{ print $5}' | sed 's/%//g')

# Warnung: Wert, ab dem eine E-Mail verschickt werden soll
Warnung=90

# Programmlogik zum Entscheiden, ob eine E-Mail verschickt werden soll
if [ "$Auslastung" -gt "$Warnung" ] ; then
    mail -s 'Belegung von Datastore pbs KRITISCH!' ${ADMIN} << EOF
Der Datastore auf pbs ist zurzeit zu $Auslastung% gefüllt.
EOF
fi

 

[TErxleben]

Noch ein Tipp, ich setze mir für ZFS Pool eine zfs quota auf ca 80% des Gesamtspeicherplatzes des Pools.
So kann ich dann auch das Quota wieder löschen und auto snapshot und andere Dateien löschen.
Auch kann ich durch temporäres erweitern des ZFS Pools um ein Stripe Set als Z.B. Mirror, noch weiteren Platz schaffen.

Von einem Pool kann ich hier nicht sprechen. Ich habe einen PBS stinkend auf Basis von LVM innerhalb eines PVE aufgesetzt (32GB). Danach habe ich auf Vorschlag von Proxmox eine zfs-Partition hinzugefügt. Das Ding platzte dann irgendawann aus äseiner 1.4TB Hose. So habe ich die virtuelle Partition in PVE auf 1.8TB erweitert. Danach wollte ich innerhalb des PBS mit zpool die Partition auf die neue Größe anpassen. Klappt leider nicht für 5 Pfennig.