Inkrementelles Backup

[fabian]

ergaenzend zum post von @Dunuin (das zu 99% stimmt):

der client fragt nicht beim server nach, ob ein chunk schon existiert (das waere sonst ein ziemliches einfallstor fuer information leaks ). stattdessen passiert folgendes:

1. client startet backup session
2. server legt neuen snapshot an
3. server locked vorherigen snapshot in der gruppe (falls vorhanden)
4. client holt sich manifest und indizes des vorherigen snapshots (falls vorhanden)
5. client kann nun selbst feststellen, ob ein chunk vom vorherigen snapshot referenziert wird - falls ja, muss nur die info in welchem index and welcher stelle der chunk benoetigt wird geschickt werden, falls nein, der chunk + die info
6. server macht dann den gegencheck, falls der chunk nicht mitgeschickt worden ist, um sicherzustellen das nicht durch einen bug ein chunk eingetragen wird der nicht (mehr?) existiert
7. server spart sich den write, falls ein hochgeladener chunk schon existiert und passt

punkt 3 stellt sicher, dass die infos welche chunks schon existieren nicht waehrend des backups ungueltig werden kann (das lock verhindert ein loeschen des snapshots, und solange der snapshot existiert raeumt eine garbage collection die darin referenzierten chunks natuerlich nicht auf!)

die dirty bitmap bei VMs hilft bei punkt 5 - wenn die bitmap sagt das ein gewisser bereicht der VM disk nicht geaendert worden ist, muss der client nichtmal lesen und hashen um zu wissen, dass der chunk schon existiert, daher gehts dann noch flotter ("fast incremental mode").

der schritt 7 ist quasi noch ein server-seitiges deduplizieren und I/O optimierung, falls ein chunk in mehreren gruppen referenziert wird (z.b., wenn gaeste von ein und demselben template instanziert worden sind) oder im letzten snapshot nicht enthalten war, aber davor schon.

 

[Dunuin]

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.

Bei mir hier merke ich das leider schon deutlich. Gerade der olle Thin-Client mit der 7 Jahre alten 6.5W TDP Atom CPU. Der hat nur 4 Threads und ein PBS Backup bringt das Load Average dann von 2 auf 8. Sprich die CPU ist komplett von ZFS und PBS überfordert und nicht mal die SATA SSDs können ihre volle Performance ausschöpfen (so 420MiB/s Reads im ZFS Mirror).

Beispiel 162 GiB Nextcloud VM, die quasi leer ist, mit 3 Backups direkt nacheinander.

Einmal mit Stop-Mode:

INFO: backup is sparse: 144.82 GiB (89%) total zero data
INFO: backup was done incrementally, reused 161.64 GiB (99%)
INFO: transferred 162.00 GiB in 629 seconds (263.7 MiB/s)

Einmal mit Snapshot-Mode:

INFO: using fast incremental mode (dirty-bitmap), 220.0 MiB dirty of 162.0 GiB total
INFO: backup was done incrementally, reused 161.79 GiB (99%)
INFO: transferred 220.00 MiB in 7 seconds (31.4 MiB/s)

7 vs 629 Sekunden sind da schon ein ordentlicher Unterschied.
Eine NAS VM als Cold Storage mit 40 TB Zvol auf einem HDD Pool würde ich da nicht mit einem Stop-Mode Backup sichern wollen.

 

[Falk R.]

Eine NAS VM als Cold Storage mit 40 TB Zvol auf einem HDD Pool würde ich da nicht mit einem Stop-Mode Backup sichern wollen.

Zuhause ist das eh nicht so kritisch und Produktive PVE habe ich seit 2022 nur noch NVMe only Systeme verbaut. Davor war es auch zu 99% all SSD.
Da merkt man das bei einem 30TB Fileserver schon, aber das Backup ist trotzdem zeitnah Nachts durch.

 

[beta]

Wow, danke für die ausführlichen Antworten.
Ich hätte echt nicht gedacht, dass die Kombi PVE & PBS so schlau zusammenarbeiten.
Das mit den Chunks hatte ich doch schon wieder glatt vergessen.
Also spare ich nicht nur Speicherplatz durch inkrementelles Backups sondern auch Traffic.
Meine VM Backups laufen tatsächlich aber nur einmal die Woche.
Wann macht ein GC denn zeitlich Sinn?
Nach dem Backup, oder ist das prinzipiell egal?

 

[fabian]

die uebliche abfolge waere backup (oder pull), danach prune, danach GC und in regelmaessigen abstaenden verification. je nachdem wieviel luft/reserve bzgl. speicherplatz da ist, kann die GC (die wesentlich teurer ist als pruning) seltener laufen, also z.b. prune taeglich, GC woechentlich. oder prune taeglich, verification woechentlich mit monatlicher "reverification", GC monatlich. haengt von vielen faktoren ab.

 

[Dunuin]

Wichtig ist halt das zwischen Prune und GC 24 stunden und 5 minuten liegen sollten. Alles was geprunt wurde und nicht so lange her ist wird auch nicht wirklich gelöscht. Wenn du Mo-So um 00:00 den Prune machst und dann nur So um 00:00 den GC, dann wird dir der GC nur den Speicherplatz von letzten So-Fr wieder freigeben aber nicht den von Samstag oder dem aktuellen Sonntag.

Hier daheim mache ich täglichen Prune, wöchentlichen GC, wöchentlichen Sync, wöchentlichen Verify mit Re-Verifyalle 90 Tage.

 

[beta]

Hmm .. wird bei einem Backup nur einmal die Woche schwierig.
Der Backup PC fährt auch nur einmal die Woche hoch und kann also zwischenzeitlich auch nichts machen.
Eingeplant habe ich 2 Stunden für VM Backups und Filebackups.
VMs sind bei mir auch nicht viel.
2 VMs und 2 LXC, komplett nur ca. 60 GB.
Ist die Frage ob ich dafür den PC noch einen anderen Tag extra hochfahren sollte, oder ob ich direkt nach dem Backup erst Prune und dann den GC starten sollte.

 

[Dunuin]

Hmm .. wird bei einem Backup nur einmal die Woche schwierig.
Der Backup PC fährt auch nur einmal die Woche hoch und kann also zwischenzeitlich auch nichts machen.
Eingeplant habe ich 2 Stunden für VM Backups und Filebackups.
VMs sind bei mir auch nicht viel.
2 VMs und 2 LXC, komplett nur ca. 60 GB.
Ist die Frage ob ich dafür den PC noch einen anderen Tag extra hochfahren sollte, oder ob ich direkt nach dem Backup erst Prune und dann den GC starten sollte.

Prune + GC nur an einem Wochentag geht auch. Das GC wird dann aber halt nur den belegten Platz der Backups, von vor 2 wochen, wieder freigeben und nicht den Platz der letzten Woche. Braucht dann also mehr Platz, aber dank Deduplizierung nicht weiter tragisch, solange sich nicht viel bei den VMs geändert hat.

 

[Falk R.]

Hmm .. wird bei einem Backup nur einmal die Woche schwierig.
Der Backup PC fährt auch nur einmal die Woche hoch und kann also zwischenzeitlich auch nichts machen.
Eingeplant habe ich 2 Stunden für VM Backups und Filebackups.
VMs sind bei mir auch nicht viel.
2 VMs und 2 LXC, komplett nur ca. 60 GB.
Ist die Frage ob ich dafür den PC noch einen anderen Tag extra hochfahren sollte, oder ob ich direkt nach dem Backup erst Prune und dann den GC starten sollte.

Wenn eh nur wöchentlich Backups gemacht werden ist die Änderungsrate ja nicht so hoch und die Daten anscheinend nicht so kritisch. Dann sollte das passen, wenn der Speicher nicht extrem knapp ist.

 

[ViennaTux]

ich habe ein seltsames Phänomen: ich habe vor einiger Zeit die Datenplatte eines virtuellen Mailservers vergrößert, das Backup lief dann einige Zeit etwas länger, dann hat es sich wieder auf die üblichen 12 Minuten eingependelt, dirty bitmap so ~ 150MB. Und plötzlich ist die bitmap bei jedem einzelnen Backup 6k bis 8k GB groß und das Backup läuft 20 Stunden, was sowohl die anderen Backups blockiert als auch die PErformance in den Keller schießt.
Irgendwer eine Idee?

 

[Falk R.]

Ist die Dirty Map so groß?
Macht das OS irgendwelche Filesystem reorgs oder defrag?

 

[ViennaTux]

nichts, was sich in den letzten Tagen geändert hätte. Wir haben ein paar Mailboxen restored (~5GB) und dazugehängt, aber nichts in der Dimension. Mittlerweile läuft das Backup mehr als 22 Stunden (und hat natürlich die anderen Backups blockiert).

 

[Falk R.]

Prüfe mal ob da irgend welche Jobs laufen, Defragmentierung oder ähnliches.

 

[ITT]

Trim in der VM aktiv?

 

[mow]

Prune + GC nur an einem Wochentag geht auch. Das GC wird dann aber halt nur den belegten Platz der Backups, von vor 2 wochen, wieder freigeben und nicht den Platz der letzten Woche. Braucht dann also mehr Platz, aber dank Deduplizierung nicht weiter tragisch, solange sich nicht viel bei den VMs geändert hat.

Anmerkung: Prune+GC wird natürlich nur dann etwas freigeben, wenn überhaupt alte Backups gelöscht werden. Ansonsten kann man sich das eigentlich auch ganz sparen.

 

[Udoast]

Wie schön ist das denn beschrieben. Bin begeistert: Falk R.
Jetzt habe ich es verstanden . Danke!