[SOLVED] Komisches Restore-Verhalten.

[TErxleben]

Vorweg: Es handelt sich um eine virtualisierten PBS. Die VM hat 16GB RAM und liegt auf einer einzelnen SSD. Es handelt sich im Host nur um SSD/NVMe.
Spiele ich eine 300GB Sicherung der SSD auf eine NVMe zurück, dann ist der Drops in 4,5min gelutscht.
Spiele ich eine 1.2TB Sicherung zurück, dauert es um den Faktor 20 länger.
Dieses ist schon in den ersten 5% der Rücksicherung ableitbar. Wärmeproblem kann es also nicht sein.
Wo könnte der Karussell-Bremser zu finden sein?
Die Restorezeit sollte meines Erachtens linear steigen.
Rechnerisch sollten rohe 1.2TB maximal in ca. 40min. statt 2,5h kopiert sein. Die CPU bummelte i.ü. auch nur rum.

 

[UdoB]

Ohne Beleg aus der Hüfte geschossen: ist das Schreib-Ziel ein preiswertes Device oder "Enterprise Class"?

Preiswertere SSD/NVMe haben oft einen dedizierten Single-Level-Cell Bereich, in den ankommende Daten schnell geschrieben werden können. Erst später werden die Daten an die finalen Speicherorte verschoben. Natürlich ist der SLC-Bereich relativ klein und kann von "einige GB" bis "einige hundert GB" gehen.

Falls also dieser schnelle Platz möglicherweise 500 GB groß ist, kannst du 500 GB schnell schreiben. Die nächsten 500 GB müssen dann aber erst auf das Freiräumen des schnellen Bereiches warten... (oder werden vielleicht auch direkt an die finale Stelle geschrieben, das weiß ich nicht.)

 

[Bu66as]

Das passt mir nicht mit dem SLC-Cache, weil der Einbruch schon in den ersten 5% sichtbar ist. Das wären bei 1,2TB grob 60GB, und die sollten noch locker in den Cache passen. Ich würd eher schauen, wie viel echte Daten in den beiden Sicherungen drin sind. Leere Bereiche oder Zero-Chunks gehen beim Restore extrem schnell durch. Wenn die 300GB-VM zum Großteil leer ist und die 1,2TB-Disk richtig voll, dann ist der Vergleich halt schief. Linear geht da nicht. Was zeigt denn der Task-Log beim Restore als tatsächlich gelesene Datenmenge und Durchsatz?

Außerdem würd ich während des langsamen Restores mal iostat -x 2 in der PBS-VM und parallel auf dem Ziel-Host laufen lassen. Dann sieht man direkt, ob das Lesen der Chunks von der einzelnen SSD bremst (hohes await/util im PBS) oder das Schreiben aufs Ziel. Liegen beide Restores auf demselben Ziel-Storage, und was für einer ist das (ZFS, LVM-thin, ...)?

 

[TErxleben]

Sauberer Schuss ins eigene Knie. Ich habe beim Zurückspielen einfach die Defaultangabe "Gleicher Storage wie in der Sicherung" übernommen.
Das war nun leider das Ziel auf dem auch die PBS-VM liegt. Also Restore-Quelle = Ziel-Storage. Bei der anderen Sicherung war das Ziel aber korrekt (local-lvm)
Mit der gedachten und nun gewählten Einstellung SSD=>NVMe ist ein Restore in erwarteten 40min erledigt.
Um solche Blödfehler zu vermeiden sollte die GUI vielleicht gleich ein Zielstorage anzeigen. Vielleicht mit einer eckigen Klammer drumherum um anzuzeigen, dass es sich um die Sicherungsvorgabe handelt.

 

[TErxleben]

Das passt mir nicht mit dem SLC-Cache, weil der Einbruch schon in den ersten 5% sichtbar ist. Das wären bei 1,2TB grob 60GB, und die sollten noch locker in den Cache passen. Ich würd eher schauen, wie viel echte Daten in den beiden Sicherungen drin sind. Leere Bereiche oder Zero-Chunks gehen beim Restore extrem schnell durch. Wenn die 300GB-VM zum Großteil leer ist und die 1,2TB-Disk richtig voll, dann ist der Vergleich halt schief. Linear geht da nicht. Was zeigt denn der Task-Log beim Restore als tatsächlich gelesene Datenmenge und Durchsatz?

Außerdem würd ich während des langsamen Restores mal iostat -x 2 in der PBS-VM und parallel auf dem Ziel-Host laufen lassen. Dann sieht man direkt, ob das Lesen der Chunks von der einzelnen SSD bremst (hohes await/util im PBS) oder das Schreiben aufs Ziel. Liegen beide Restores auf demselben Ziel-Storage, und was für einer ist das (ZFS, LVM-thin, ...)?

Das hatte ich auch in Verdacht, denn tatsächlich ist die kleinere VM nur zu 50% ausgelastet und die 1.2TB VM zu 85%.
Scheint aber nach Wahl des richtigen Zielstorages kaum eine Rolle zu spielen, da die erwarteten relativen Zahlen dann ziemlich exakt stimmen.
Allerdings weiß ich nicht, ob gelöschte Bereiche unter Debian (hier im speziellen OMV) zwecks besserer Deduplizierung automatisch genullt werden. Unter Windows muss man immer sdelete bemühen.