Inkrementelles Backup
- Thread starter Whit23
- Start date
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...
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.
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.
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.
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.
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:
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.
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.
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.
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.
Ich empfehle generell vor einer Inbetriebnahme das sehr gute Proxmox-Wiki durchzulesen, denn da steht ja eh alles drinn 