Backup-Size increases too fast

[F.Horn]

Good morning guys,

We usw 2 Proxmox Clusters with about 50 VMs, linux and Windows
They Backup to a PBS, splittet in two datastores.
PBS-Version 2.2-3





We are running Prune and GC.

Here is the GC Protocoll for datastore GHH:
Datastore: GHH01
Task ID: UPID:GHH-PVE04:00000FA8:000012AD:000012AF:6323A060:garbage_collection:GHH01:root@pam:
Index file count: 1284

Removed garbage: 0 B
Removed chunks: 0
Removed bad chunks: 0

Leftover bad chunks: 0
Pending removals: 286.362 GiB (in 170440 chunks)

Original Data usage: 1.822 PiB
On-Disk usage: 38.939 TiB (2.09%)
On-Disk chunks: 15504577

Deduplication Factor: 47.91

And the GC Protocoll for datastore GHW:

Datastore: GHW01
Task ID: UPID:GHW-PBS01:0000166A:0000032B:000000F1:6323B050:garbage_collection:GHW01:root@pam:
Index file count: 369

Removed garbage: 0 B
Removed chunks: 0
Removed bad chunks: 0

Leftover bad chunks: 0
Pending removals: 0 B (in 0 chunks)

Original Data usage: 880.367 TiB
On-Disk usage: 14.379 TiB (1.63%)
On-Disk chunks: 6114822

Deduplication Factor: 61.23

Garbage collection successful.

This is our Prune-Job configuration:



Datastore GHW01 is the same Configuration.

The Backups in GHW01 are running for about 1 year now. There 34 versions of each machine.

Most in GHH01 are running for about 6 weeks now.

The onDisk Usage over all in Cluster 2 is about 22TB HDD + 6,5TB SSD (28,5TB)
The onDisk Usage over all in Cluster 1 is about 14TB HDD + 1,3TB SSD (15,3TB)
So on Disk it's about 44 TB.

it is continiusly increasing the last month, but GC shoud have cleand up.



So, is it possible, that GC is not cleaning up all chunks?


Thanks for any help

greetz
Frank

 

[sterzy]

it is continiusly increasing the last month, but GC shoud have cleand up.

Why do you assume that GC should have cleaned up more chunks? From what I can tell from your post, you want to keep up to ten years of possible backups. GC will keep all distinct chunks that haven't been pruned. So in your case, so far at least all distinct chunks from the last 14 days, all 12 monthly and up to ten yearly backups that are still kept.

I'd expect there to be more distinct chunks the longer the time-frame between the earliest and latest backup, that has been kept, is. That's just because the VM state now is probably closer to that a day ago than to that a year ago. So if you need to store 40 backups from the last 40 days, I'd expect more de-duplication than 40 backups from the (ten) year(s).

 

[F.Horn]

So my prune configuration doesn't make sense?

 

[sterzy]

So my prune configuration doesn't make sense?

No, I am not saying that. I am just saying that from what you provided, I can't tell why you'd expect the GC to remove more chunks. Whether the setting makes sense, depends on your use-case.

The GC will first mark and then remove all chunks that are not used by any backup index. This seems to be working fine on your machine. I should mention that the on-disk storage usage on the PVE and PBS is only tangentially related. That is due to how the deduplication works. It will split the VM backup into chunks, then hash those chunks and only store chunks that have a unique hash. That means the more the data between backups and VMs matches, the less data will be store. Take the following examples:

1. Ten VMs with the same disk images, one backup each: Likely less data than even one backup needs to actually be stored as one backup will likely contain the same chunk more than once (e.g: two copies of a large file etc.)
2. One VM with ten backups over a time-frame with many reads and writes: This will likely consume more data than one VM backup (but less than ten whole backups) as lots of data has changed between the ten backups.

So in the case of 1) on the PVE side you will see the VMs take up the sum of all the space needed for all ten VMs, while the backups on the PBS side will need less than the space of a single full backup to be stored. In the case of 2) on the PVE side you will see on-disk usage of exactly that one VM, whereas on the PBS side it could be multiples of the size of one backup as the backups can't be deduplicated as efficiently.

I hope that makes sense. One thing, you could check if you see any backups that should have been pruned, though. The prune simulator may help with that [1].

If you prefer, we can switch to German by the way.

[1]: https://pbs.proxmox.com/docs/prune-simulator/

 

[F.Horn]

Guter Plan Stefan

Ich denke, das hab ich schon soweit verstanden.
Bin gerade nochmal durchgegangen was auf den Maschinen passiert.
Es gibt einen File-Server, auf den Backups von anderen Maschinen im Netz geschrieben werden. Das sind 130GB die sich wöchentlich ändern
Außerdem werden von einer Datenbank mit knapp 100 GB auf einer VM ein lokales Dump geschrieben, welches dann nochmal auf einen anderen Fileserver kopiert wird.
Also die Datei wird an zwei Windows-VMs täglich neu geschrieben. In wie fern sich das auf die Blocks auswirkt weiß ich nicht.

Außerdem gab es bei der Inbetriebnahme nochmal einen Datenumzug.
Auf FS01 waren ca. 10 TB daten, die später auf FS03 umgezogen wurden.
Von beiden sind von beginn an Backups gelaufen.

Kann ich von den beiden Geräten die ältesten Backups mal manuell löschen und bringt mir das dann einen Speichergewinn, ohne dass irgendwas zerbröselt?


Grüße
Frank

 

[sterzy]

Kann ich von den beiden Geräten die ältesten Backups mal manuell löschen und bringt mir das dann einen Speichergewinn, ohne dass irgendwas zerbröselt?

Vermutlich: ja. Also PBS sollte dann nur die Chunks dieses Backups löschen (nachdem die GC fertig gelaufen ist, kann ein bisschen dauern, GC gibt Chunks eine "Grace Period" siehe Manual [1]). Alle anderen Backups sollten also ganz normal weiter funktionieren. Prune Jobs sollte das auch egal sein, die löschen nur die Indices von Backups, die nicht mehr behalten werden sollen, ob eines da sein sollte oder nicht ist dabei egal.

Wie groß der Speichergewinn ist, lässt sich aber schwer sagen, dazu müsste ich im Prinzip das tun, was die GC macht: schauen, welche Chunks nach dem Löschen der Indices von keinem Backup mehr referenziert werden.

[1]: https://pbs.proxmox.com/docs/backup-client.html#garbage-collection

 

[sterzy]

Ein Kollege meinte gerade das ein Datastore + Namespaces würde mehr De-duplizierung und somit weniger Speicherverbrauch bedeuten. Das wäre also auch eine Möglichkeit. Dafür müssten die beiden Datastores aber zuerst konsoldiert werden, was etwas kompliziert sein könnte je nachdem wie der Storage genau eingebunden ist. Wenn Sie das versuchen wollen kann ich Ihnen aber gerne mal die Schritte dafür zusammen schreiben

 

[F.Horn]

Sorry für meine späte Antwort. War leider in anderen Themen gebunden.
Tatsächlich würde ich die beiden Datastores gerne zusammenfassen und in Namespaces aufteilen. Die notwendigen Schritte hierfür würden mich interessieren, danke
Storage: Das ist ein ZFS-Pool aus lokalen HDDs.
Wobei: Ob das so gerade wo viel Sinn macht weiß ich nicht. Aktuell ist das ein Pool aus 18TB HDDs. Da es aber knapp 50VMs sind hab ich Angst vor dem Restore.
Da in dem Server nicht mehr genügend Einschübe frei sind plane ich einen weiteren PBS aufzusetzen, der SSD only hat und dann die Masse an kleinen VMs beherbergt und auf dem PBS mit den HDDs nur die großen liegen. Dann verschiebt sich eh alles nochmal.


GC zählt die Chunks für das gesamte Datastore. Habe ich eine Möglichkeit die Anzahl der Chunks die zu einer VM gehören herauszufinden?
Ich habe tatsächlich 2-3 große VMs auf denen viel Datenänderung passiert, würde aber gerne herausfinden wie sich das genau auf die Backupgröße auswirkt und was Dedup da hinkriegt.

Wenn ich die entsprechenden VMs so eingrenzen kann, würde ich diese in einen eigenen NS werfen und nen prune mit kürzerer Aufbewahrung einrichten.

 

[fabian]

Sorry für meine späte Antwort. War leider in anderen Themen gebunden.
Tatsächlich würde ich die beiden Datastores gerne zusammenfassen und in Namespaces aufteilen. Die notwendigen Schritte hierfür würden mich interessieren, danke

wenn du den platz hast um temporaer backups doppelt abzulegen ist ein "sync" am einfachsten:
- remote fuer den lokalen PBS anlegen
- namespace(s) am ziel datastore anlegen (und entsprechende berechtigungen vergeben falls notwendig)
- sync job anlegen der quelle in ziel datastore + namespace synced (gegebenfalls wiederholen, falls mehrere verschiebungen oder in der zwischenzeit neue backups dazugekommen sind)

wenn alles gesynced ist, backup quelle/jobs auf neues ziel umstellen. wenn sicher alles passt, alten, nicht mehr gebrauchten datastore loeschen

Storage: Das ist ein ZFS-Pool aus lokalen HDDs.
Wobei: Ob das so gerade wo viel Sinn macht weiß ich nicht. Aktuell ist das ein Pool aus 18TB HDDs. Da es aber knapp 50VMs sind hab ich Angst vor dem Restore.
Da in dem Server nicht mehr genügend Einschübe frei sind plane ich einen weiteren PBS aufzusetzen, der SSD only hat und dann die Masse an kleinen VMs beherbergt und auf dem PBS mit den HDDs nur die großen liegen. Dann verschiebt sich eh alles nochmal.

das verschieben laesst sich dann wieder mit einem sync job (dieses mal mit "remote" remote ) erledigen - ggf. einen group filter setzen um nur bestimmte VMs zu syncen statt alle.

GC zählt die Chunks für das gesamte Datastore. Habe ich eine Möglichkeit die Anzahl der Chunks die zu einer VM gehören herauszufinden?

nicht direkt. es gibt das proxmox-backup-debug tool mit dem direkt am PBS server files angeschaut werden koennen - wenn du dem kommando inspect file den pfad zu einem .fidx index file (index zum backup einer einzelnen VM disk) gibst, dann kriegst du eine liste an chunks (in der reihenfolge wie sie das raw image ergeben). das kannst du fuer disks aus unterschiedlichen snapshots machen und entsprechend auswerten. ein chunk entspricht bei VM backups immer 4MB an unkompromierten original daten (ausser der letzte, der darf kleiner sein) - am PBS wird er aber komprimiert und optional verschluesselt abgelegt, der tatsaechliche speicherverbrauch pro chunk wird also anders sein.

also z.b.:

proxmox-backup-debug inspect file /pool/backup/vm/104/2022-06-09T15:12:05Z/drive-scsi0.img.fidx
size: 34359738368
creation time: Thu Jun  9 17:12:05 2022
chunks:
  "d43ff6509a45ac7a59c70935206fd5fbccafaf931afda9ac4643b7b9930bf78a"
  "f11af7f7c33b705513580a953e453023030aba60c8693a975d2645f75dc16e6a"
  "9dc6a66ba36bc8652488f78efae0d64c4a9e5814b905df3ddf2f2c36bfb6d153"
  "1d65970f575663d7e0c471707309b9e2fd90755f0673d5ae0766a61ba2ecee5c"
  "9701f040c72a69dda774c1bfdc1aa8a6a8274d1389acdb208955f2b7702edf17"
  "8a0b3323009507c8ea138598fb548521f368e3b855b056ef8efab832c5301d18"
  "ac7314bcfb97a703214b8860fe68c543dbd756fad0f89a84fd1ddfabe453eff2"
[...]

size ist dabei die gesamtgroesse, creation time eh klar und chunks die liste an chunks.

Ich habe tatsächlich 2-3 große VMs auf denen viel Datenänderung passiert, würde aber gerne herausfinden wie sich das genau auf die Backupgröße auswirkt und was Dedup da hinkriegt.

Wenn ich die entsprechenden VMs so eingrenzen kann, würde ich diese in einen eigenen NS werfen und nen prune mit kürzerer Aufbewahrung einrichten.

s.o.

 

[F.Horn]

Danke für die Infos.

Hab mal ein bisschen gespielt.

root@GHH-PVE04:/# proxmox-backup-debug inspect file /GHH-zpool1/GHH01/ns/Alte-Backups/vm/207/2022-07-21T23:31:57Z/drive-scsi0.img.fidx | grep ^\ \ \" | wc -l
10135
root@GHH-PVE04:/# proxmox-backup-debug inspect file /GHH-zpool1/GHH01/ns/Alte-Backups/vm/207/2022-07-21T00:10:54Z/drive-scsi0.img.fidx | grep ^\ \ \" | wc -l
10145
root@GHH-PVE04:/# proxmox-backup-debug inspect file /GHH-zpool1/GHH01/ns/Alte-Backups/vm/207/2022-07-20T01:22:06Z/drive-scsi0.img.fidx | grep ^\ \ \" | wc -l
10121

Die Disk hat eine Roh-Größe von 50 GB.
Insgesamt 30401 chunks
Im GC hab ich gesehen, dass die durchschnittliche Chunk-size 2.636 MiB ist.
Also 30401 * 2,636 = 80137,036 MiB ~ 84 GB

Hab ich das Prinzip soweit richtig verstanden?
Halt ich zwar für bisserl unrealistisch. Die Maschine hat ne Disk Usage von 13 GB.

Ich werde mal ein Script basteln und damit auf die anderen Backups losgehen und mal schauen, was da raus kommt.

 

[fabian]

du musst die gemeinsamen und doppelten chunks ja noch rausrechnen --output-format json hilft vielleicht bei der strukturierten auswertung. jeder chunk wird ja nur einmal gespeichert, egal wie oft er in einem index vorkommt und egal in wievielen indizes er vorkommt. wenn ein chunk nur von einem einzigen index referenziert wird, dann wuerde er wenn der zugehoerige snapshot geloescht wird von einer der naechsten GCs aufgeraeumt werden. wenn ein chunk *ab* einem gewissen snapshot referenziert wird, dann war er in diesem snapshot neu, aber es muessten alle snapshots ab diesem zeitpunkt geloescht werden um den platz freizugeben. wenn ein chunk nur *bis* zu einem gewissen snapshot referenziert wird, dann muessen die snapshots bis inkl. diesem zeitpunkt geloescht werden um den platz freizugeben. im normalfall werden die unterschiede in einer serie an snapshots in alle drei kategorien fallen -> bloecke die sich temporaer geaendert haben und bis zum naechsten backup wieder aendern, bloecke die sich geaendert haben und eine zeit lang mit den neuen daten bleiben, bloecke die eine zeit lang konstante daten hatten aber jetzt nicht mehr.

 

[F.Horn]

Dann komm ich doch ungefähr hin, wenn ich die Chunks in den snapshots (index 1) mit den jeweils vorhergehenden Snapshot (index 0) vergleiche und nur die raus filtere, die im snapshot (index 1) neu sind und dann addiere, oder?

 

[F.Horn]

Hab das mal für eine kleine Maschine laufen lassen. Da gabs drei Backups.
Im ersten sinds 9978 Chunks
Differenz vom 2. zum 1. : 159 neue Chunks
Differenz vom 3. zum 2.: 198 neue Chunks
So 10335 Chunks für diese Kette. Sofern die nicht anderweitig refenziert sind komm ich bei 10335 x 4 MiB auf 41420 MiB.
onDisk Usage immer noch 13 Gb.


So richtig schlau werd ich da noch nicht draus.

Bei nem Windows Domain-Controller (ohne Fileserver und der gleichen) mit ner OnDisk usage von 26 GB über 16 Snapshots komm ich mit der gleichen Rechnung auf ca. 195 Gb an Chunks.

Muss da wohl nochmal nachrechnen...

 

[fabian]

13GB on disk usage korreliert nicht (direkt) mit der anzahl an chunks - die on disk usage ist ja auf file-system ebene (mit viel kleineren bloecken die ueber die ganze disk verteilt sind!), die chunks am PBS sind auf block ebene (d.h. ein chunk besteht aus daten wie sie auf der disk liegen, egal ob das file-system die braucht oder das "unused" space ist). wenn du jetzt in jedem 4MB chunk der disk nur ein bit aenderst muessen trotzdem die ganzen 4MB neu gesichert werden (das ist ein tradeoff - wenn die chunks zu gross sind funktioniert die deduplizierung nicht mehr, wenn die chunks zu klein sind wird zwar mehr dedupliziert, aber der overhead aufgrund der anzahl an chunks wird zu gross).

das erste backup einer VM sagt dir wieviel daten hochgeladen worden sind und wieviel zero-chunks waren, das gibt dir eine baseline wie "gross" dieses backup war von dem du dann die diffs betrachten kannst.

als beispiel
- debian VM mit 4.3G "usage" auf / (ext 4), 8GB disk
- erstes backup:
-- 2.74G komplett Nullen (sparse), d.h. 8-2.74G=5.26G Daten in 1347 Chunks (ein Teil dieser Daten ist "unused" space der sich einen chunk mit "used" space teilt!)
-- server hat 2048 chunks geloggt (8GB/4MB), davon 700 client-seitig dedupliziert (Nullen vermutlich) und 10 serverseitig (mein datastore war nicht leer, das koennten z.b. haeufig zwischen VMs idente bloecke vom bootloader oder aehnliches sein)
-- die 4.3G usage auf file system ebene ergeben 5.26GB input in chunk form ergeben 1.54GB tatsaechlicher verbrauchter Speicher auf PBS seite
- in der VM 10 Dateien mit jeweils 15MB random Daten geschrieben
- nochmal ein Backup gemacht
-- tatsaechlich sind jetzt 328MB als geaendert erkannt worden (10*15MB + overhead um auf chunk boundaries aufzurunden + andere aenderungen die die VM im laufenden betrieb gemacht hat)
-- der PBS server hat 82 hochgeladene chunks geloggt, davon 1 duplicate server-seitig. 82*4MB=328MB
-- tatsaechlicher Verbrauch dieser 82 hochgeladenen chunks auf PBS seite ist allerdings nur 177.44MB (150MB quasi nicht komprimierbare random daten, der rest hat sich scheinbar gut wegkomprimieren lassen )

hoffe dass hilft ein bischen beim verstaendnis. folgendes hab ich verwendet um eine liste an chunk digests in verbrauchten platz umzuwandeln:

cat file_with_chunk_digest | while read c; do dir=${c:0:4}; du --apparent-size /pfad/zum/datastore/.chunks/$dir/$c; done | numsum

numsum ist optional und summiert die einzelnen files auf - wenn du es weglaesst kriegst du die usage von jedem einzelnen chunk.