Komischer deduplication factor

[TErxleben]

Sollte der o.g. Faktor auch bei initialer Befüllung nicht über 1 liegen?
Wenn man dann eine zweite Sicherung hinterherdonnert, bleibt es immer noch bei 1.
Wie wird der Wert eigentlich ermittelt?
Schön wäre die korrekt Ausgabe dieses Faktors für einzelne Sicherungen in der Content-Übersicht um Problembären auf die Spur zu kommen..

 

[UdoB]

Gute Frage. Der PBS ist ganz frisch? Ich würde nach dem zweiten Backup mal wenigstens 24h warten, eventuell wird das immer erst beim täglichen Aufräumen neu ermittelt. (GC + Prune sind bei auf "daily" eingerichtet.)

Ich liege hier im Homelab bei Werten zwischen 20 und 40 - etliche VMs ändern sich bei mir gar nicht, weil sie "aus" sind ;-)

 

[Falk R.]

Sollte der o.g. Faktor auch bei initialer Befüllung nicht über 1 liegen?
Wenn man dann eine zweite Sicherung hinterherdonnert, bleibt es immer noch bei 1.
Wie wird der Wert eigentlich ermittelt?
Schön wäre die korrekt Ausgabe dieses Faktors für einzelne Sicherungen in der Content-Übersicht um Problembären auf die Spur zu kommen..

Hi, der Wert wird immer bei der Garbage Collection ermittelt. Wenn die noch nicht gelaufen ist, muss da noch 1 stehen.
Steht so aber auch in der Doku.

 

[TErxleben]

Hi, der Wert wird immer bei der Garbage Collection ermittelt.

Danke. Habe ich nun auch sogar bei Fr. Google gefunden. Nach einer GC wird tatsächlich ein plausiblerer Wert angezeigt. Es wäre aber verständlicher vor einer GC "zu wenig Daten" anzuzeigen, wie es estimated full tut.
Nach einer GC zeigt der PBS einen Faktor von 2,47. Nach einer zweiten Sicherung mit nur minimale Änderungen bleibt es bei 2.47 Estimated behauptet 5 Tage und voll. Nach einem dritten Durchlauf werden 2,90 angegeben.
Da erwarte ich eher Faktor 90, der kontinuierlich sinkt.

Darum würde ich ja auch gerne die schlimmen Finger per Liste identifizieren,

Die Werte wirken m.E. eher geraten.

P.S.: Zumal die Speicherbelegung Zuwächse anzeigt, die im Kopf überschlagen auf ganz andere estimated-Werte kommen muss.
Hoffentlich pendelt sich das ein.

P.P.S; Ich habe hier ein 320GB OMV als zentrales NAS. Da liegen zu 98% viele kaum komprimierbare Mediendaten. die bei Erstsicherung natürlich ein Schluck aus der Pulle sind. Auch an verbleibenden 2% passiert kaum etwas. Ändern tut sich da also so gut wie nichts.
Darum nochmal mein Wunsch nach einer Übersichtsliste, welche Sicherung wieviele Neudaten mitbringt und in die Suppe spuckt..
Es handelt sich übrigens über einen frischen PBS 4.0.14, der von PVEs 9.0.5 befüllt wird.

 

[Falk R.]

Danke. Habe ich nun auch sogar bei Fr. Google gefunden. Nach einer GC wird tatsächlich ein plausiblerer Wert angezeigt. Es wäre aber verständlicher vor einer GC "zu wenig Daten" anzuzeigen, wie es estimated full tut.
Nach einer GC zeigt der PBS einen Faktor von 2,47. Nach einer zweiten Sicherung mit nur minimale Änderungen bleibt es bei 2.47 Estimated behauptet 5 Tage und voll. Nach einem dritten Durchlauf werden 2,90 angegeben.

1:2,9 ist doch ganz OK

Da erwarte ich eher Faktor 90, der kontinuierlich sinkt.

1:90 habe ich noch nie gesehen, ich habe zuhause 1:56 und das ist schon Top.

Darum würde ich ja auch gerne die schlimmen Finger per Liste identifizieren,

Die Werte wirken m.E. eher geraten.

P.S.: Zumal die Speicherbelegung Zuwächse anzeigt, die im Kopf überschlagen auf ganz andere estimated-Werte kommen muss.
Hoffentlich pendelt sich das ein.

P.P.S; Ich habe hier ein 320GB OMV als zentrales NAS. Da liegen zu 98% viele kaum komprimierbare Mediendaten. die bei Erstsicherung natürlich ein Schluck aus der Pulle sind. Auch an verbleibenden 2% passiert kaum etwas. Ändern tut sich da also so gut wie nichts.
Darum nochmal mein Wunsch nach einer Übersichtsliste, welche Sicherung wieviele Neudaten mitbringt und in die Suppe spuckt..
Es handelt sich übrigens über einen frischen PBS 4.0.14, der von PVEs 9.0.5 befüllt wird.

Da der PBS nur das Datengrab ist, hat er die Informationen nicht. Da musst du dir die Daten der einzelnen Jobs anschauen.

 

[TErxleben]

90 war nur eine Beispielzahl.
Der PBS ist alles andere als ein Datengrab.
Der führt Buch über resultierende Chunks aus den eingelieferten Daten, erzeugt neue und löscht ggf. alte. Wer soll denn sonst den Hut aufhaben?
Im Gegensatz zu vzdump, welches lediglich komprimiert und den immer gleichen Scheiß erneut speichert.
Da nur schwindelige Bezeichnungen innerhalb von PVE erzeugt werden, kannst du rsync noch nicht einmal im Nachgang elegant einsetzen.
Wie wäre es mit einem Alias dump-latest? Dann könnte man wenigstens diese gröbsten Schnitzer ohne riesen Geraffel per CLI und rsync abfideln. Besser wäre natürlich eine Integration in die WebGUI.

• Bei der initialen Sicherung erwarte ich einen Faktor, der Brutto zu sichern vs, Netto verbraucht wiederspiegelt => Deduplizierung. Schon das es eine GC braucht um von 1 abweichende Werte zu erzeugen ist sehr seltsam, es sollte einfach nicht an die GC gebastelte werden, sondern beim Sichern generiert werden.
• In weiteren Sicherungsläufen muss man nur noch gelesen vs geschrieben protokollieren.
• Dieses wird im Tasklog ja sogar immer angezeigt.
• Nach einem prune senkt man einfach die verbrauchte Menge um x-chunks*Größe,
• Ist doch keine Raketentechnologie, sondern nur mangelhaft umgesetzt.
• Ich bekomme es schwer auf den Zettel, warum in den sonst wirklich tollen Produkten solche Kindergeburtstagsnummern stecken.
• Eine Übersichtsinfo wie viele chunks ein Einzelbackup belegt, wäre auch nicht kontraproduktiv.

 

[Falk R.]

90 war nur eine Beispielzahl.
Der PBS ist alles andere als ein Datengrab.
Der führt Buch über resultierende Chunks aus den eingelieferten Daten, erzeugt neue und löscht ggf. alte. Wer soll denn sonst den Hut aufhaben?
Im Gegensatz zu vzdump, welches lediglich komprimiert und den immer gleichen Scheiß erneut speichert.
Da nur schwindelige Bezeichnungen innerhalb von PVE erzeugt werden, kannst du rsync noch nicht einmal im Nachgang elegant einsetzen.
Wie wäre es mit einem Alias dump-latest? Dann könnte man wenigstens diese gröbsten Schnitzer ohne riesen Geraffel per CLI und rsync abfideln. Besser wäre natürlich eine Integration in die WebGUI.

• Bei der initialen Sicherung erwarte ich einen Faktor, der Brutto zu sichern vs, Netto verbraucht wiederspiegelt => Deduplizierung. Schon das es eine GC braucht um von 1 abweichende Werte zu erzeugen ist sehr seltsam, es sollte einfach nicht an die GC gebastelte werden, sondern beim Sichern generiert werden.

Wer genau soll denn die daten deiner Meinung nach prüfen? Der Wert lässt sich nur ermitteln, wenn man die Bruttodaten und die Nettodaten vergleicht.
Das während dem Backup zu tun würde unnötige Last erzeugen, da ein GC ja sowieso im Nachgang gemacht werden muss zum aufräumen.

• In weiteren Sicherungsläufen muss man nur noch gelesen vs geschrieben protokollieren.

Nicht wirklich. Das ist ein wenig Komplexer.

• Dieses wird im Tasklog ja sogar immer angezeigt.
• Nach einem prune senkt man einfach die verbrauchte Menge um x-chunks*Größe,

Ein Prune macht gar nix mit den Chunks, ein Prune löscht höchstens Zeiger auf Chunks und der GC schaut dann ob es noch Zeiger zu den Chunks gibt und wenn nicht wird der Chunk gelöscht.

• Ist doch keine Raketentechnologie, sondern nur mangelhaft umgesetzt.

Ich glaube eher falsch verstanden. Umgesetzt ist das eigentlich super Sauber und Simple.

• Ich bekomme es schwer auf den Zettel, warum in den sonst wirklich tollen Produkten solche Kindergeburtstagsnummern stecken.
• Eine Übersichtsinfo wie viele chunks ein Einzelbackup belegt, wäre auch nicht kontraproduktiv.

Ja was nützt dir das? Dann willst du noch wissen wie viele Zeiger auf einen Chunk verweisen. Was nützt dir das ganze? Du könntest damit unendliche Tabellen füllen und theoretische Werte aller Art errechnen, welche aber niemanden weiter bringen.
Eventuell liest du dich mal in Deduptechniken ein und wenn du das verstanden hast, verstehst du auch warum der PBS so arbeitet. Übrigens wie jedes Kommerzielle Dedupsystem.