Restore von Proxmox Backup Server sehr langsam ZFS

[heppi75]

Hallo,

ich habe bei Hetzner 2 Root Server.

Server PVE Host (Falkenstein): 2x3,84 TB NVMe SSD Datacenter Edition, konfiguriert als ZFS Pool
Server PBS Host (Helsinki): 2x6 TB Enterprise HDD, konfiguriert als ZFS Pool

Fio Tests:

fio --rw=readwrite --name=test --size=100M --direct=1 --bs=1024k

ZFS / NVME SSD
READ: bw=5750MiB/s (6029MB/s), 5750MiB/s-5750MiB/s (6029MB/s-6029MB/s), io=46.0MiB (48.2MB), run=8-8msec
WRITE: bw=6750MiB/s (7078MB/s), 6750MiB/s-6750MiB/s (7078MB/s-7078MB/s), io=54.0MiB (56.6MB), run=8-8msec

PBS / SATA HDD
READ: bw=4600MiB/s (4823MB/s), 4600MiB/s-4600MiB/s (4823MB/s-4823MB/s), io=46.0MiB (48.2MB), run=10-10msec
WRITE: bw=5400MiB/s (5662MB/s), 5400MiB/s-5400MiB/s (5662MB/s-5662MB/s), io=54.0MiB (56.6MB), run=10-10msec

Ich habe am PVE nun eine größere VM mit ca. 1 TB die ich regelmäßig auf den PBS sichere. Die erste initale Sicherung dieser VM hat ca. 2h 39m gedauert, was für mich absolut akzeptabel ist.

Nun habe ich aber gestern den Restore vom PBS auf den PVE zurück ausprobiert. Schaut dann in etwa wie folgt aus:

new volume ID is 'local-zfs:vm-100-disk-0'
download and verify backup index
progress 1% (read 10737418240 bytes, zeroes = 1% (130023424 bytes), duration 363 sec)
progress 2% (read 21474836480 bytes, zeroes = 1% (276824064 bytes), duration 780 sec)

Wenn ich den Fortschritt hochrechne (habe es dann abgebrochen) komme ich auf eine Restore Zeit von über 11 Stunden. Das ist natürlich im Bedarfsfall vollkommen unakzeptabel. Auch das Risiko, daß während dieser langen Zeit irgendein Abbruch stattfinden kann, ist natürlich sehr hoch.

Mich würde daher interessieren was die Profis hier in der Community dazu sagen. Mache ich da was falsch? Habe ich da irgendwo was falsch konfiguriert.

Bin für jeden Tipp dankbar.

 

[Dunuin]

Auszug aus Manual:

Recommended Server System Requirements​

...​

• Backup storage:
  • Use only SSDs, for best results
  • If HDDs are used: Using a metadata cache is highly recommended, for example, add a ZFS special device mirror.

Von HDDs ist abzuraten da halt sehr langsam. Nicht vergessen, dass da PVE alles als Chunks von max 4MB Größe (in der Praxis eher um die 2MB) speichert und wegen Deduplikation diese auch nicht rein sequentiell gelesen/geschrieben werden können. Ein Restore von 1TB muss also rund 500.000x 2MB Dateien öffnen die quer über die Platten verstreut sind.

Und deine fio Ergebisse messen nur Cache. 5,4 GiB/s können 2 HDDs ja nicht realistisch schaffen.

 

[heppi75]

Hi Dunuin, danke für deine Info. Ich werde mal ein Setup mit SSDs auf dem PBS ausprobieren. Irgendwie habe ich immer nur von ZFS auf dem PBS gelesen, das es wirklich mit HDDs so schlecht funktioniert, habe ich scheinbar immer übersehen.

 

[Dunuin]

Hi Dunuin, danke für deine Info. Ich werde mal ein Setup mit SSDs auf dem PBS ausprobieren. Irgendwie habe ich immer nur von ZFS auf dem PBS gelesen, das es wirklich mit HDDs so schlecht funktioniert, habe ich scheinbar immer übersehen.

ZFS aber auch vorallem (neben Bit Rot Protection), weil du deine HDDs mit SSDs unterstützen solltest, wenn man schon HDDs verwenden will. Dass da dann die SSDs als "Special Devices" arbeiten und alles an Metadaten rein auf den SSDs gespeichert wird, dass da die HDDs von weniger kleinem Random IO getroffen werden. Hilft besonders beim GC Task, aber auch sonst generell bei jeglichen Workloads.

 

[heppi75]

Möchte das Thema nochmal aufgreifen. Habe mir gestern noch einen PBS mit NVMe's eingerichtet und ein Backup der 1 TB VM darauf abgespeichert. Die Backups zum PBS laufen generell (HDD bzw. SSD) sehr schnell und gut.

Hier nun der Restore - beide Server, PVE und PBS, haben jetzt NVMe's verbaut.

progress 1% (read 10737418240 bytes, zeroes = 1% (130023424 bytes), duration 142 sec)
progress 2% (read 21474836480 bytes, zeroes = 1% (276824064 bytes), duration 292 sec)
progress 3% (read 32212254720 bytes, zeroes = 1% (423624704 bytes), duration 468 sec)
progress 4% (read 42949672960 bytes, zeroes = 1% (570425344 bytes), duration 656 sec)

Man sieht natürlich schon einen deutlichen Unterschied zum vorherigen Setup. Dennoch dauert so ein Restore, meiner Meinung nach, immer noch zu lange. Habe heute einen vzdump (1 TB) von einem anderen Proxmox Server (ebenfalls HDD) von Hetzner zum o. g. PVE (NVMe, freigegebener NFS Share) gemacht. Das ging mit einer Zeit von ca. 2h 51m viel schneller als das ich das vom PBS retour bekomme (5h 26m). Auch mit dem neuen Setup dauert das ja viel länger.

So ganz schlau bin ich aus dieser Lösung immer noch nicht geworden?

 

[mafel.o0]

Hallo, es ist schon ein wenig älter der Thread, dennoch aktuell ... ich bin leider auch in die Falle getappt wie der Kollege, der hier den Post getätigt hat

immer schön backups gemacht allerdings auf hdd
Nun kam ich in die Situation eine größere VM wierherstellen zu müssen

nach meinen Berechnungen dürfte es ungefähr einen Monat dauern ....
Gibt es mglw. einen Workaround, dass ich die Maschine wieder schneller herstellen kann? Bspw. mit direken kopieren eines gesamten Images oder ähnl.? Würde meine nextcloud gerne wieder in Betrieb wissen ...

oder wäre mglw. ein Klonen des pbs nebst backup auf eine ssd als workaround möglich?
Ich bitte um Unterstützung, bin für alle Ideen offen

download and verify backup index
progress 1% (read 21474836480 bytes, zeroes = 1% (293601280 bytes), duration 11109 sec)
progress 2% (read 42949672960 bytes, zeroes = 1% (587202560 bytes), duration 24990 sec)
progress 3% (read 64424509440 bytes, zeroes = 1% (1115684864 bytes), duration 37182 sec)

 

[news]

Nein es gibt kein Workout es gibt auch keine Tipps das zu verbessern außer man macht es neu und richtig. Nicht betreibe mein proxx Backup Server virtualisiert auf ZFS basierend mit mehreren SSDs und HDDs im Verbund. Und erreiche so für meine Verhältnisse maximale IOPs. Auf dem SSDs liegen im Allgemeinen die Metadaten, das sind die Verwaltungsdaten die blockspeicherplätze und Eigenschaften eines zfs datasets unter anderem. Durch die Methode der Parallelisierung, hier über zfs als mirror mit N devices, erhöre ich so die Reaktionsfähigkeit meines Pools. Gleiches gilt natürlich dann auch bei den realen Durchsatz, die auf HDDs zu liegen kommen. Einem Parallelisierung ist hier auch im Lesezugriff möglich, indem man N lass Festplatten mit 7200 rpm verwendet. Dir IOPS der Festplatten verdoppelt oder dreifach sich mit der Anzahl der Festplatten. So erhält man insgesamt einen Zugriff auf die Daten, der nur durch die bei IOPs der Festplatten begrenzt ist. Bei den handelt es sich natürlich hier um random 4k Zugriffe und nicht um lineares Lesen von großen Datenblöcken. All das bedeutet natürlich man muss Geld in die Hand nehmen, mehr Platz haben für Festplatten und SSDs, das Wissen wie man ZFS Pools korrekt aufbaut und konfiguriert.
ich sehe hier mehr Wissensprobleme, dass man über Monate und Jahre beseitigen könnte. Vom Geldeinsatz würde ich mal so von 1000 € ausgehen.

 

[UdoB]

oder wäre mglw. ein Klonen des pbs nebst backup auf eine ssd als workaround möglich?

Naja, du könntest theoretisch den vollständigen ".chunks"-Ordner auf eine SSD kopieren und dann den neuen Ordner "über" den original HDD-Ordner mounten (oder linken). Diese vorbereitende Kopieraktion ist aber nicht viel schneller als dein langsames Restore.

Natürlich kannst du auch die komplette Blechplatte auf eine SSD duplizieren. Als Blockdevice, ohne das Dateisystem zu berücksichtigen - das geht wesentlich schneller. Dazu muss die SSD mindestens so groß wie die HDD sein. Mein Tool der Wahl wäre dann "ddrescue", auch wenn es nicht um "retten" von Daten geht:

~# apt show gddrescue

Description: GNU data recovery tool
 The gddrescue tool copies data from one file or block device
 (hard disc, cdrom, etc) to another, trying hard to rescue data
 in case of read errors.

 

[mafel.o0]

Naja, du könntest theoretisch den vollständigen ".chunks"-Ordner auf eine SSD kopieren und dann den neuen Ordner "über" den original HDD-Ordner mounten (oder linken). Diese vorbereitende Kopieraktion ist aber nicht viel schneller als dein langsames Restore.

Natürlich kannst du auch die komplette Blechplatte auf eine SSD duplizieren. Als Blockdevice, ohne das Dateisystem zu berücksichtigen - das geht wesentlich schneller. Dazu muss die SSD mindestens so groß wie die HDD sein. Mein Tool der Wahl wäre dann "ddrescue", auch wenn es nicht um "retten" von Daten geht:

~# apt show gddrescue

Description: GNU data recovery tool
 The gddrescue tool copies data from one file or block device
 (hard disc, cdrom, etc) to another, trying hard to rescue data
 in case of read errors.

Das ist doch mal ein sehr konstruktiver Kommentar, vielen Dank dafür

das werde ich probieren, - die 1:1 block rescue - habe noch eine 4tb ssd rumfliegen, die müsste passen, frage, wie bekomme ich die dann kopfschmerzfrei in den pbs eingebunden? Erkennt er die Daten dann automatisch wenn ich sie angeschlossen & eingebunden habe? Die SSD ID wird dann ja eine andere sein, stellt das ein Problem dar?

 

[UdoB]

frage, wie bekomme ich die dann kopfschmerzfrei in den pbs eingebunden? Erkennt er die Daten dann automatisch wenn ich sie angeschlossen & eingebunden habe? Die SSD ID wird dann ja eine andere sein, stellt das ein Problem dar?

Wie ist denn die Blechplatte eingebunden? Genau so sollte das auch mit der SSD funktionieren.

Was meinst du mit "SSD ID"? Wenn du das Blockdevice duplizierst, bleibt alles identisch. Wenn die SSD den Anschluss der HDD verwendet ist sogar "sdX" gleich. Das gilt allerdings nicht für alle "/dev/disk/by-id/xyz" - die enthalten zum Teil die (unterschiedlichen) Seriennummern.

Ich selber würde vermutlich direkt an der "/etc/proxmox-backup/datastore.cfg" herumbasteln - aber das ist sicher nicht der empfohlene Weg ;-)

Offizelle Doku: https://pbs.proxmox.com/docs/storage.html#datastore

 

[mafel.o0]

die platte ist tatsächlich extern eingebunden an einem usb-c port am mikroserver. bin gerade am klonen, melde mich später mit wie es läuft ^^

 

[Falk R.]

Sonst Live Restore machen. Ist dann langsam aber online.

 

[mafel.o0]

So, long story (im wahrsten Sinne) - short xD
Backup done,
habe nun dank dieser Information von

news

"... Durch die Methode der Parallelisierung, hier über zfs als mirror mit N devices, erhöre ich so die Reaktionsfähigkeit meines Pools. Gleiches gilt natürlich dann auch bei den realen Durchsatz, die auf HDDs zu liegen kommen. Einem Parallelisierung ist hier auch im Lesezugriff möglich, indem man N lass Festplatten mit 7200 rpm verwendet. Dir IOPS der Festplatten verdoppelt oder dreifach sich mit der Anzahl der Festplatten. So erhält man insgesamt einen Zugriff auf die Daten, der nur durch die bei IOPs der Festplatten begrenzt ist. Bei den handelt es sich natürlich hier um random 4k Zugriffe und nicht um lineares Lesen von großen Datenblöcken. ...)

auf eine 4tb ssd umgestellt und werde nun ein kaskadiertes Backup erstellen

heißt
proxmox -> pbs (SSD) -> hdd

wie genau weiß ich noch nicht aber bin erstmal froh das erste Backup auf einer SSD zu haben

Danke an alle und Gruß

hier noch eine kleine Impression eines Zwischenstandes xD