Inkrementelles Backup

Whit23

New Member
Feb 1, 2023
8
0
1
Hi,

Wie stelle ich die Inkrementelles Backup ein? Bei mir sieht es so aus als würde er immer voll Backups machen.

Hab das bei Container, bei den möchte er immer volle Backups machen.
 
Last edited:
PBS sichert standardmäßig nur die Änderungen an CT/VM/Host.

pbs.png

Zu erkennen am Deduplizierungsfaktor.
 
Hab das bei Container, bei den möchte er immer volle Backups machen.

Bitte spezifizieren, wie du darauf kommst.

LXCs haben keine Dirty Bitmap und müssen daher bei jedem Backup komplett gelesen werden. Geschrieben auf den PBS werden aber nur die Änderungen.
Also das Lesen nicht mit dem Schreiben verwechseln...
 
Also bei mir steht Deduplizierungsfaktor 1.
Er scheint also immer ein Vollbackup zu machen.
Ich weiß aktuell aber nicht warum, weil ich nirgends was dazu beim Backup selbst einstellen kann?
Ist das Filesystemabhängig?
 
Also bei mir steht Deduplizierungsfaktor 1.
Er scheint also immer ein Vollbackup zu machen.
Ich weiß aktuell aber nicht warum, weil ich nirgends was dazu beim Backup selbst einstellen kann?
Ist das Filesystemabhängig?
Wenn bei dir Dedup 1 stehen bleibt, hast du kein Garbage Collection scheduled und auch noch nie ausgeführt.
Bitte immer Prune und GC konfigurieren.
 
So ... einen Prune Job hatte ich bereits angelegt, aber der ist ja nur für das Löschen zuständig?
Ein klick auf "Start Garbage Collection" hat geholfen.
Ich gehe davon aus, dass man das direkt am Besten nach dem Backup scheduled?
Was ich aber nicht verstehe: Was genau macht die Garbage Collection?
Dient die nur zur richtigen Anzeige der Backups?
Oder enstehen dabei erst die inkrementellen Backups?
Falls ja, würde ja trotzdem immer erst das komplette Image übers Netz gebackupped.
 
Die Garbage Collection scannt welche Blöcke nicht mehr Referenziert sind und nicht mehr benötigt werden. Dabei wird auch der Dedupfaktor berechnet.
 
Also wird im Prinzip doch immer ein Full-Backup gemacht und erst durch die Garbage Collection entsteht ein inkrementelles Backup?
 
Nein, es wird immer incremental gespeichert. Wenn du einen Prune machst und alte Restorepunkte löschst, sind meistens auch Blöcke nicht mehr in Nutzung. Diese werden bei der GC ermittelt und tatsächlich aus dem Speicher gelöscht. Dabei wird der Dedupfaktor berechnet, weil sich die genutzte Speichermenge ändert.
 
Sorry, ich habe mich da glaube ich missverständlich ausgedrückt.
Dazu muss aber doch jeweils das komplette PVE-Backup übers Netzt geschickt werden und PBS macht daraus quasi ein inkrementelles?
 
Bei VMs wird nur das Inkrement gelesen und bei LXC die Daten komplett gelesen. Der Backupclient überträgt aber nur die Änderungen zum PVE.
 
Ich bin verwirrt.
Gelesen?
Bei PBS untereinander kann man ja pullen, aber beim PBS vom PVE geht das doch nicht?
Also muss ich vom PVE zum PBS pushen?
Also es geht mir um eine PVE Backup zum PBS, wofür er ja gedacht ist.
Und da gehe ich von aus, dass PVE immer das komplette Image schickt?
Oder Teilt PBS dem PVE mit, was neu ist oder noch fehlt?
Kann ich mir nicht vorstellen.
 
Last edited:
Der Backupclient läuft auf dem PVE und pusht die Daten.
Der PBS ist quasi nur das Datengrab.
 
Genau, aber woher soll PVE wissen was inkrementell gebackupped werden soll?
Theoretisch müsste PBS dem PVE dann ja genau mitteilen, was dem bereits erstellten Backup noch fehlt.
Das kann ich mir nicht vorstellen, dass das geht.
Deshalb hat PBS ja ohne GC auch die vollen Backups angezeigt, weil es immer volle Backups waren bis zu dem Zeitpunkt wo PBS mit GC ein inkrementelles Backups daraus erstellt hat.
 
Die Anzeige im PBS spiegelt nur die Konfigurierte Speichermenge der VM oder LXC wieder. Der PBS kann keinen tatsächlichen Speicherbedarf anzeigen, da durch Dedup viele Blöcke mehrfach genutzt sind. Die Anzeige ist nur dafür da, dass man beim Restore weiß, wieviel Platz man vorhalten sollte.
 
Ja ... das hab ich mir schon gedacht.
Ändert aber nichts daran, dass PVE immer alle Daten zum PBS schickt.
Ich dachte, dadurch könnte ich mir auch Traffic sparen. ;)
Aber immerhin spart es Speicherplatz.
Danke für deine Hilfe.
 
Genau, aber woher soll PVE wissen was inkrementell gebackupped werden soll?
Theoretisch müsste PBS dem PVE dann ja genau mitteilen, was dem bereits erstellten Backup noch fehlt.
Das kann ich mir nicht vorstellen, dass das geht.
Deshalb hat PBS ja ohne GC auch die vollen Backups angezeigt, weil es immer volle Backups waren bis zu dem Zeitpunkt wo PBS mit GC ein inkrementelles Backups daraus erstellt hat.
Das läuft so:
Sagen wir du hast ne 100GB virtuelle Disk von einer VM. Beim Backup zerstückelt PVE die 100GB in 25.000x 4MB Chunks und berechnet dann für jeden dieser Chunks die Prüfsumme. Dann fragt PVE den PBS: "Hab hier ein Chunk mit Prüfsumme XYZ. Hast du das schon?". PBS antwortet dann PVE entweder "Ja hab ich schon, brauchst nicht nochmal schicken." oder alternativ "Ne ist mir unbekannt, schick mal rüber, brauch ich noch". Im letzteren fall wird PVE das dann komprimieren und ggf. verschüsseln und dann zum PBS senden. Beim ersten mal muss PVE also alle chunks zum PBS senden, da der ja noch nichts davon hat. Bei allen weiteren Backups der VM wird PVE nur das zum PBS senden, was seit dem letzten Backup neu hinzugekommen ist, da PBS ja alles andere schon gespeichert hat und wegen Deduplizierung nichts doppelt gespeichert werden muss.
Also Senden/Schreiben ist immer "inkrementell" da ja Nichts gesendet werden muss, was schon am PBS existiert. Gelesen werden muss aber trotzdem jedes mal die vollen 100GB, was natürlich ordentlich dauert, da man ja sonst nicht besprechen kann, was noch gesendet werden muss und was nicht.

Um das Lesen am PVE zu beschleunigen gibt es dann aber einen Trick namens Dirty-Bitmapping, was quasi inkrementelles Lesen erlaubt. Damit PVE nicht jedes mal die vollen 100GB erneut einlesen, in 25.000x Chunks zerstückeln und dann die Prüfsummen erneut berechnen muss, kann PVE Dirty-Bitmapping benutzen, was quasi Buch führt, was sich seit dem letzen Backup an der virtuellen Disk geändert hat und was nicht. Dann muss sich PVE nur die Stellen der virtuellen Disk angucken, die seit dem letzen Backup beschrieben/überschrieben wurden und kann alles andere ignorieren, weil es sich ja nicht seit dem letzten Backup verändert haben kann. Das klappt aber auch wirklich nur für VMs und nicht für LXCs. Bei LXCs muss immer die komplette virtuelle Disk erneut eingelesen, zerstückelt und gehasht werden, egal ob die sich verändert hat oder nicht.
Und bei VMs geht die Dirty-Bitmap verloren, sobald du die VM stoppst/neustartest. Nach so einem Stop/Neustart muss auch eine VM wieder die komplette virtuelle disk erneut einlesen. Dirty Bitmapping klappt also nur bei Snapshot-Mode Backups von VMs auf Servern die man nie neustartet.

Nicht von klassischen Backupmodellen verwirren lassen. PBS arbeitet da ganz anders und macht keine differenziellen Backups wie du es sonst wohl kennst. Jedes PBS Backup ist gleichzeitig ein volles Backup und ein inkrementelles Backup, ohne dabei differentiell zu sein. Man hat keinerlei Ketten von Abhängigkeiten da neue Backups nicht auf vorherigen Backups aufbauen.

Pruning löscht die Indexe von Backups. Es löscht aber keine nicht mehr benötigten Chunks. Es wird also keinPlatz wieder freigegeben. Das macht dann erst der GC, der dann endgülig auch die Chunks löscht. Das aber auch nur, wenn der Prune mindestens 24 Stunden her ist.
 
Last edited:
Wieder etwas gelernt! Ich wusste nicht, dass die dirty-bitmap verloren geht beim stoppen.
Habe das gerade mit meiner dicken Windows VM getestet, jetzt hat das Backup 47 Sekunden statt 21 Sekunden gedauert.
Geschrieben hat der maximal 150 MiB/s aber lesen war bis zu 8,7 GB/s. Also bei SSDs fällt das gar nicht so sehr auf. ;)
 
  • Like
Reactions: aaron

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!