Repo-Inhaltsanzeige nur mit Originalgröße der Daten. Was in Planung?

[floh8]

ich glaube, es schon mal gelesen zu haben und ich bemerkte es jetzt auch bei meinen Tests, dass die Archivgröße nur die kumulierte Originalgröße der Daten im originalen Dateisystem angibt, aber nicht die kompr. Archivgröße vor der Versendung zum Server. Die Archivgröße wäre aber interessant, wenn ich das Archiv vom Remoteserver über das VPN zu mir entpacken möchte. ich weiß, dass man auf dem Datastore nicht diese Größe auslesen kann, da ja im Archiv dedupliziert wird und der Datastore mit zfs dedupliziert auch noch mal, wenn ich es konfiguriert habe.

Beispiel:

Beim sichern sagt er:

had to backup 16.50 MiB of 16.50 MiB (compressed 378.98 KiB) in 0.24s

und im Webportal steht nur die Originalgröße:



Wird das noch erweitert und die komprimierte Größe des Archivs angezeigt?
Gerade bei einem Desaster-Restore, wo ich einige Daten übertragen werde, ist das sehr relevant für die Zeitkalkulation.

 

[dcsapak]

nur ums gesagt zu haben, 'compressed' ist hier auch dedupliziert,
also wäre das leider auch keine sinvolle angabe, da, wenn beim hochladen alle chunks schon existieren, wir das auch nicht wissen bzw ausrechnen können...

die 'raw' nicht deduplizierte Größe ist die einzige die wir verlässlich und ohne overhead haben können (leider). alles andere würde entweder
unnötigerweise Daten lesen/komprimieren/verschlüsseln/etc.. und um die Backup-Geschwindigkeit so gut wie möglich zu machen, wollen wir das grundsätzlich vermeiden...

 

[floh8]

Ok. Verständnisfrage: Macht ihr eine Source-Deduplizierung?

 

[dcsapak]

Macht ihr eine Source-Deduplizierung

was ist damit genau gemeint?

es werden chunks generiert und die werden dedupliziert. verschlüsselt/komprimiert wird nachdem der chunk digest berechnet wird
bei vm disks gibt es eine fixe chunk size von 4MiB, bei file basierten backups (host/ct) wird zuerst (on-the-fly) ein pxar archiv[0] erstellt, über das dann ein buzhash läuft um die chunk-grenzen zu generieren
mehr details hier: https://pbs.proxmox.com/docs/technical-overview.html

0: https://pbs.proxmox.com/docs/file-formats.html#proxmox-file-archive-format-pxar

 

[floh8]

Damit meine ich: Wird die Deduplizierung auf dem Quellsystem durchgeführt, z.B. dem PVE-Host oder dem Linux-Host oder wird auf dem Backupserver nach der Übertragung kontrolliert, ob der Chunk im Repository bereits gespeichert ist und dann nur verlinkt?

 

[dcsapak]

der backup prozess bekommt eine chunkliste des letzten backups in der gleichen gruppe (also bei der vm 100, vom letzten snapshot der gruppe vm/100)
der client rechnet dann die digests aus, und verschickt nur die chunks die nicht in der liste sind. der server speichert dann nur die chunks die es noch nicht gab

dh. es kann passieren das chunks zum server geschickt werden die er eh nicht gebraucht hätte

 

[floh8]

ok. ihr seid ja fortschrittlich. D.h. für mich jetzt, ihr macht sowohl eine Quell- als auch eine Ziel-Deduplizierung. Die Quell-Deduplizierung vollführt ihr anhand der Liste, die zu Beginn vom Backup-Prozess an den Client gesendet wird und sich erstmal nur auf die Gruppe bezieht, sprich das Backupobjekt (VM,Host,CT). Dann werden die chunks versendet, die nicht in der Liste sind. Der Serverprozess überprüft dann, welche der chunks bereits im Repository vorhanden sind. Die werden dann nicht 2-mal im Repository gespeichert (Ziel-Deduplizierung).
Wenn es so ist, dann könnt ihr den Wert natürlich nicht direkt im Proztess angeben. Die Reihenfolge erst Deduplizierung, dann Kompression ist auch logisch gewählt. Wenn ihr diesen Wert angeben würdet, müßtet ihr auf dem PBS einen Task anbieten, der den Speicherplatz aller chunks für ein Fullrestore addiert. Richtig? Vielleicht schreibt ihr das mit auf die Agenda. Das muss ja kein automatischer Job sein. Nur ein Task, den man manuell starten kann. PBS macht ja pro VM/CT ein snapshot? Oder? Du sprichst ja von Gruppe, also dann einen Task, der sich auf die Gruppe bezieht.

 

[dcsapak]

Wenn ihr diesen Wert angeben würdet, müßtet ihr auf dem PBS einen Task anbieten, der den Speicherplatz aller chunks für ein Fullrestore addiert. Richtig?

das versteh ich nicht genau, meinst du einen task der alle chunks durchgeht und die unkomprimierte größe ausrechnet ? meiner meinung nach wäre das ein zu zeitintensiver prozess, da ich ja das ganze backup lesen muss..
da kann ich doch auch gleich restoren ?

oder meinst du die komprimierte größe? wäre schneller aber was genau sollte das denn bringen? das wäre halt die größe die es übers netzwerk brauchen würde, aber auch nur ungefähr,
da wir chunks die öfter vorkommen nicht jedesmal neu schicken sondern client-seitig auch nochmal cachen.

PBS macht ja pro VM/CT ein snapshot? Oder? Du sprichst ja von Gruppe, also dann einen Task, der sich auf die Gruppe bezieht.

nur zu klarstellung, pro vm/ct gibt es eine gruppe, zb "vm/100" ist die gruppe der vm mit der id 100. pro backup wird dann ein "snapshot" gemacht, zb: "vm/100/2021-07-01T01:00:00Z"
beim backup wird die liste der chunks vom letzten snapshot der gleichen gruppe geschickt, da dass das backup ist das wahrscheinlich am meisten mit dem aktuellen backup gemeinsam hat

 

[floh8]

Ich habe nochmal die Definition von Group und Snapshot durchgelesen. Eine Gruppe definiert ein objekt. Verstehe.

Du sagst nun, dass ihr auch bei der Wiederherstellung die Source-Deduplizierung berücksichtigt und doppelte chunks nicht nochmals überträgt. Das macht es doch trotzdem nicht so schwierig, denke ich, die zu übertragenden Daten zu kalkulieren. Ihr baut ja die Liste der chunks pro Gruppe. Diese Liste nehmt ihr als Grundlage der Kalkulation. Da ihr diese Liste jedesmal berechnet, wenn ein Backupvorgang startet, kann das ja nicht lange dauern. Jeder Eintrag entspricht 4 MB bei fixed Chunks. Bei dynamic chunks wird's natürlich aufwendiger. Man muss wohl alle anfassen, da die ja unterschiedlich groß sind. Es wäre aber nur notwendig, wenn man es wirklich benötigt. Also nichts, was regelmäßig Rechenzeit in Anspruch nimmt.

 

[ph0x]

Ich verstehe den Sinn dahinter trotzdem nicht so ganz. Die Restore-Geschwindigkeit hängt noch an so viel mehr Faktoren, welche wertvolle Information erhoffst du dir von der Größe des Backups? Es dauert so lang, wie es dauert. Außerdem kannst du inzwischen live restoren, damit wird die Information ja noch unzuverlässiger.

 

[floh8]

du musst auch nicht alles verstehen. es gibt anwendungsfälle, gerade bei Restoreaktionen, da möchte man ungefähr die Zeit kalkulieren. manchmal hat man ja mehrer möglichkeiten und muss nicht unbedingt über das Netzwerk restoren. Auch ein Administrator muss Recoveryzeiten angeben können, um in businesskritischen Situation gute Entscheidungen zu treffen.

 

[ph0x]

Und täglich wächst die Liste ...

 

[dcsapak]

Du sagst nun, dass ihr auch bei der Wiederherstellung die Source-Deduplizierung berücksichtigt und doppelte chunks nicht nochmals überträgt. Das macht es doch trotzdem nicht so schwierig, denke ich, die zu übertragenden Daten zu kalkulieren. Ihr baut ja die Liste der chunks pro Gruppe. Diese Liste nehmt ihr als Grundlage der Kalkulation. Da ihr diese Liste jedesmal berechnet, wenn ein Backupvorgang startet, kann das ja nicht lange dauern. Jeder Eintrag entspricht 4 MB bei fixed Chunks. Bei dynamic chunks wird's natürlich aufwendiger. Man muss wohl alle anfassen, da die ja unterschiedlich groß sind. Es wäre aber nur notwendig, wenn man es wirklich benötigt. Also nichts, was regelmäßig Rechenzeit in Anspruch nimmt.

Ganz so einfach ist es leider immer noch nicht. Wir müssten immer von allen chunks die Größe anschauen (wegen compression). Das ist eine sehr IO intensive operation da potentiell mehrere 10-100 tausende chunks angegriffen werden müssen.
Grundsätzlich wäre so etwas schon möglich, glaube aber nicht dass sich das für viele user lohnt.

Alternativ ist auf der devel liste gerade ein patchset offen [0], das ein 'proxmox-debug' tool inkludiert um ein paar mehr 'low-level' aktionen durchzuführen. Unter anderem soll das tool alle chunk
von einem index file auflisten können. Von da aus ist es dann nur mehr ein bisschen skripten bis man die größe aufsummiert hat.
Vielleicht kann man später sowas ja sogar in das Tool aufnehmen, aber ein eigener api call oder button dafür macht wahrscheinlich weniger sinn.

edit: link vergessen
0: https://lists.proxmox.com/pipermail/pbs-devel/2021-July/003818.html

 

[floh8]

alles klar. danke für response