Recovery - ein Conclusio

[showiproute]

Ich durfte gestern, nachdem sich einer meiner ZFS Pools selbstverschuldet verabschiedet hat, ein Backup machen - soweit so gut.
Im Zuge dessen, wären mir einige Verbesserungsvorschläge untergekommen:

Recovery von einzelnen VM Disks
Wenn zB nur ein ZFS Pool betroffen ist, die VM Daten aber auch auf anderne Pools liegen hat, muss ich dennoch immer die komplette VM wiederherstellen. Sprich die "guten" Daten werden dennoch überschrieben.

Thin provision wird zu thick provision
Meine Disks sind generell thin provision eingestellt. Ich weiß nicht, ob PBS das auch so erkennt oder nicht - meiner Meinung nach erkennt er jedenfalls, dass auf der VM Disk keine Daten liegen.
Mache ich jedenfalls ein Recovery, dann schreibt er auch die ganzen 0-Daten auf die Platte, dass einerseits den Recovery Prozess unnötig in die Länge zieht und andererseits Storage belegt.


Und last but not least: Wenn es eine Möglichkeit gäbe, nach einem PVE-VM-Neustart den initalen Einleseprozess zu beschleunigen, so dass es wieder nur dieses "dirty"-Delta gibt, wäre das ein Traum.
Ich habe viele Daten auf "old rust" liegen und diese immer wieder einzulesen und mit den Chunks zu vergleichen dauert sehr lange. Dadurch entsteht am Server ein generelles IO-Problem, wodurch andere VMs, die nur auf SSDs liegen, auch Probleme bekommen.
Die meisten Daten hier sind einfach nur statische Daten, die sich so gut wie nicht verändern. Wenn die Maschine knapp 20 TB an Daten durchackern muss, dauert das einige Tage.

 

[Falk R.]

Also zu Punkt 1, das gibts derzeit nur per CLI. Da kannst du sagen, dass du nur mit einer Disk restoren willst.
Das Thin Problem ist mir noch nicht aufgefallen, hast du auf dem Zielpool Thin aktiviert?
Das dritte Thema ist etwas komplexer. Qemu hält die DirtyMap nur im RAM. Ich hätte es auch gern wenn man den Zustand beim herunterfahren einfach mitspeichert, notfalls in ner kleinen Disk wie die EFI.

 

[showiproute]

Also zu Punkt 1, das gibts derzeit nur per CLI. Da kannst du sagen, dass du nur mit einer Disk restoren willst.
Das Thin Problem ist mir noch nicht aufgefallen, hast du auf dem Zielpool Thin aktiviert?
Das dritte Thema ist etwas komplexer. Qemu hält die DirtyMap nur im RAM. Ich hätte es auch gern wenn man den Zustand beim herunterfahren einfach mitspeichert, notfalls in ner kleinen Disk wie die EFI.

Könntest du mir verraten, wo ich die "Single-Volume-Recovery" Commands finde?
Ich habe bisher nur die Optionen gefunden, die ich kenne: Ganze VM oder File Recovery.

Zu Thin Provision: Ja, ich stelle meine Pools direkt nach der Erstellung auf Thin um.
Ich habe bei der VM beispielsweise eine 2 TB VM-Disk (thin), wo ich in der VM nur 1 TB belegt habe. Nun sehe ich aber in der PVE-GUI (via CLI ebenso), dass der Pool belegt ist, wobei `refreservation = none` bei den VM-Disks steht.

Punkt 3 wäre wirklich Spitze. Ich bin momentan am Überlegen, ob ich statt dem offiziellen PVE/PBS-Weg lieber den von send & receive (für manche Daten) gehe, da der vermutlich einfacher wäre.

 

[Falk R.]

Könntest du mir verraten, wo ich die "Single-Volume-Recovery" Commands finde?
Ich habe bisher nur die Optionen gefunden, die ich kenne: Ganze VM oder File Recovery.

igentlich steht im Wiki alles beschrieben:
https://pbs.proxmox.com/docs/backup-client.html
Sonst hilft die Forumssuche.

Zu Thin Provision: Ja, ich stelle meine Pools direkt nach der Erstellung auf Thin um.
Ich habe bei der VM beispielsweise eine 2 TB VM-Disk (thin), wo ich in der VM nur 1 TB belegt habe. Nun sehe ich aber in der PVE-GUI (via CLI ebenso), dass der Pool belegt ist, wobei `refreservation = none` bei den VM-Disks steht.

Zu dem Thema kann sich eventuell mal jemand anderes äußern. Ich mache selten ZFS.

Punkt 3 wäre wirklich Spitze. Ich bin momentan am Überlegen, ob ich statt dem offiziellen PVE/PBS-Weg lieber den von send & receive (für manche Daten) gehe, da der vermutlich einfacher wäre.

Ich glaube da gibt es auch schon einen Case im Bugzilla dazu.

 

[Dunuin]

Ich glaube da gibt es auch schon einen Case im Bugzilla dazu.

Ja, aber das Problem dabei ist, dass wenn QEMU nicht mehr läuft ein manipulieren der vDisk von außen nicht mehr getrackt werden kann. Würde die Dirty Bitmap persistent sein und man würde die VM runterfahren, dann z.B. mit dd die vDisk manipulieren und dann wieder die VM starten, dann wären die Backups nicht mehr konsistent. Also eher eine Maßnahme um User-Error vorzubeugen.

 

[showiproute]

Ja, aber das Problem dabei ist, dass wenn QEMU nicht mehr läuft ein manipulieren der vDisk von außen nicht mehr getrackt werden kann. Würde die Dirty Bitmap persistent sein und man würde die VM runterfahren, dann z.B. mit dd die vDisk manipulieren und dann wieder die VM starten, dann wären die Backups nicht mehr konsistent. Also eher eine Maßnahme um User-Error vorzubeugen.

Man könnte ja den User entscheiden lassen, wie er Backuppen möchte.

 

[showiproute]

igentlich steht im Wiki alles beschrieben:
https://pbs.proxmox.com/docs/backup-client.html
Sonst hilft die Forumssuche.

Mein Fehler - ich war nur im regulären PVE Handbuch unterwegs und hätte hierzu nichts gefunden.
An eine Forensuche hatte ich damals auch nicht gedacht.

 

[Falk R.]

Ja, aber das Problem dabei ist, dass wenn QEMU nicht mehr läuft ein manipulieren der vDisk von außen nicht mehr getrackt werden kann. Würde die Dirty Bitmap persistent sein und man würde die VM runterfahren, dann z.B. mit dd die vDisk manipulieren und dann wieder die VM starten, dann wären die Backups nicht mehr konsistent. Also eher eine Maßnahme um User-Error vorzubeugen.

Also wenn du mit dd deine Disks manipulierst, legst du auch keinen Wert auf Konsistente Daten.
Mir geht es hauptsächlich um Realworld Szenarien. Ich habe bei Kunden, VMs mit mehreren TB Disks angehängt. Die werden zum Glück selten heruntergefahren, aber wenn z.B. die DB mehr Performance braucht und muss dann mal abschalten um Kerne hinzuzufügen, läuft dann das Backup wieder ewig. Gerade bei DBs, nicht so schön.

 

[showiproute]

Also wenn du mit dd deine Disks manipulierst, legst du auch keinen Wert auf Konsistente Daten.
Mir geht es hauptsächlich um Realworld Szenarien. Ich habe bei Kunden, VMs mit mehreren TB Disks angehängt. Die werden zum Glück selten heruntergefahren, aber wenn z.B. die DB mehr Performance braucht und muss dann mal abschalten um Kerne hinzuzufügen, läuft dann das Backup wieder ewig. Gerade bei DBs, nicht so schön.

Ganz genau, das ist mein Thema. Die Gesamtperformance im IO-Kontext sinkt dadurch teils extrem(st).
Ich hatte phasenweise bis zu 70 % IO-Delay.

 

[Dunuin]

Bin ich ja auch der Meinung, dass es da einen Switch geben sollte womit man diese Sicherheitsmaßnahme deaktivieren kann, wenn man denn möchte.
Hab da nur existierende Threads dazu aus meiner Erinnerung zusammengefasst und da schien der PBS Staff aus genannten Gründen nicht so begeistert von zu sein.

 

[Falk R.]

Ganz genau, das ist mein Thema. Die Gesamtperformance im IO-Kontext sinkt dadurch teils extrem(st).
Ich hatte phasenweise bis zu 70 % IO-Delay.

70% IO-Delay ist aber auch nicht richtig. Bei den produktiven Systemen haben wir nur bis zu 5% Delay aber das ist schon spürbar und die Backups dauern dann natürlich viel länger.

 

[showiproute]

70% IO-Delay ist aber auch nicht richtig. Bei den produktiven Systemen haben wir nur bis zu 5% Delay aber das ist schon spürbar und die Backups dauern dann natürlich viel länger.

Das war damals auf einer SATA-Platte, die an einer Windows Server VM (Fileserver) angehängt war.
Hauptsächlich Bilder/Fotos und Musik.

Ich hatte da auch das Thema, dass ich die Platte in der VM defragmentieren wollte und musste dafür 64 GB RAM zuweisen.
Keine Ahnung, warum eine VM, die normalerweise mit 8 GB RAM auslangen findet, für eine Defragmentierung zu viel benötigt...

 

[Falk R.]

Defragmentierung solltest du in einer VM eh nie machen, außer du hast nativ eine HDD durchgereicht.

 

[showiproute]

Danach ging der Backup Prozess jedoch um einiges schneller - keine Ahnung warum.