FUSE - selektiver Restore

May 4, 2021
79
1
13
42
Hallo liebes Proxmox-Forum

Es geht um folgendes: Im Moment nutzen wir den Backup-Server um VMs zwischen verschiedenen Clustern umherzuziehen. Das funktioniert auch hervorragend, allerdings ist die Wiederherstellungsgeschwindigkeit recht langsam.

Jetzt haben wir das Problem, daß wir ein aktiv genutzes Kundensystem, Größe circa 2,7TB umziehen möchten. Wir haben das getestet und Restore gibt am Schluß als Zusammenfassung folgendes aus : restore image complete (bytes=2899102924800, duration=22830.83s, speed=121.10MB/s (etwa 380 min). Das ist, selbst wenn ich eine Nachtschicht am Wochenende schiebe, ein wenig lang. Mein Kollege hat gefragt ob es nicht die Möglichkeit eines selektiven Restores gebe. Ich kenne nur die Möglichkeit Dateien aus dem Archiv über das Webinterface herunterzuladen, aber das will ich natürlich nicht, ich sitze hier an einer 50Mbits-Leitung und der Backup-Server und die VM befinden sich beide im selben Rechenzentrum und sind mit 10Gbits angebunden. Vor ein paar Jahren habe habe ich versucht einen selektiven Restore über die Kommandozeile zu machen, habe aber irgendwann erfolglos aufgegeben und einen Workaround für das Problem gefunden.

Für mich optimal wäre es optimal erst das vollständige Backup in einer Nacht wiederherzustellen und dann in der nächsten Nacht das Backup von der ursprünglichen Quelle zu aktualisieren, dann das Image auf der VM via FUSE zu mounten und die veränderten Dateien via rsync an ihr Ziel zu bringen.

Ist das so wie ich mir das vorgestellt habe möglich?

Ich tue mich auf jeden Fall noch etwas schwer mit dem richtigen Kommandozeilenparameter, will sagen ich habe alle möglichen Befehle und Kombinationen ausprobiert aber keinen funktionierenden Mount hinbekommen. Kann mir hier jemand auf die Sprünge helfen? Beispiel: PBS-Server ist subdomain.foo.de. Darauf sind verschiedene logisches Volume, auf den jeweils ein Datatore sitzt. Dieser Datastore hat den namen "bar". Wenn ich ich diesen im Webinterface browse sehe ich einen "Root Namespace", in dem Backups wie üblich in Gruppen (Beispiel vm/100/) aufgeteilt sind. Ich habe diesen Teil der Doku gelesen, aber keine Erleuchtung gefunden.

Nutzt jemand der hier Mitlesenden die FUSE Funktionalität und könnte mir ein - natürlich anonymisiertes - funktionierendes Beispiel eines FUSE-Mounts von einem Client aus zeigen? Idealerweise wirklich alle Schritte, bei denen man potentiell etwas falsch machen könnte, also auch das korrekte Einloggen auf dem Server etc.

Vielen Dank im voraus
Stefan

PS: Das hatte ich im März 2022 gefragt bzw. als Feature vorgeschlagen.
 
Last edited:
auf PVE seite sollte ansonsten "proxmox-backup map" (XXX.img ausm backup als block device exposen) und anschliessend mounten (je nach dem wie die platte ausschaut ;)) und restore funktionieren. bzw. geht das auf jedem system wo du proxmox-backup-client installieren kannst und zugriff auf den PBS server hast. es werden dann nur die chunks dynamisch geladen die fuer das lesen vom block device notwendig sind.

es gibt sonst auch noch die "live-restore" option, wo du die VM schon waehrend des restores starten kannst und im hintergrund die chunks die aktiv von der VM angefasst werden zuerst restored werden. birgt natuerlich ein gewisses risiko (wenn dir die VM dann z.b. abstuerzt bevor der rerstore fertig ist, sind die writes die in der zwischenzeit passiert sind und daher nicht im backup waren futsch).

aber hoert sich tatsaechlich so an, als waere remote migration eher das was ihr sucht ;)
 
Hallo liebe Proxmox-Community

Ich habe gestern qm remote-migrate ausprobiert. Nachdem ich mich durch die Syntax gekämpft hatte lief das ganze mit einer Kopie unseres Wikis sehr problemlos. Nur der Lock auf der Ursprungs-VM musste noch manuell mit qm gelöst werden. Geschwindigkeitsmässig sind wir aber bei der Hälfte geblieben, die unser PBS hergibt. Das ist bei 32GB egal, bei 2700GB aber sehr wohl relevant. Aber auf jeden Fall ein sehr praktisches Feature, jetzt fehlt nur noch die Geschwindigkeit. Aber es ist ja experimentell, ich bin gespannt auf das fertige Produkt.
 
Hi, eigentlich sollte das vernünftig schnell gehen. Check mal das Netzwerk und wenn du die Migration über ein eigenes Netz geht, setz das mal auf insecure. Die Singlecore Performance des Prozessors ist oft der limitierende Faktor.
 
Hi, eigentlich sollte das vernünftig schnell gehen. Check mal das Netzwerk und wenn du die Migration über ein eigenes Netz geht, setz das mal auf insecure. Die Singlecore Performance des Prozessors ist oft der limitierende Faktor.
insecure geht bei der remote migration derzeit noch nicht, der traffic geht immer ueber einen websocket tunnel, und wie du richtig sagst - dabei ist single-thread CPU performance bei schnellem storage der bottle neck. hier gibts aber sicher noch optimierungspotenzial (derzeit wird die websocket connection vom API server auf remote seite gehandelt), und auch eine "plain-TCP" remote migration (z.b. ueber dark fiber, oder direkt auf link ebene z.b. mit wireguard abgesichert) ist sicher implementierbar.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!