ReFS File Restore

[Falk R.]

Ich bin gerade beim Testen über ReFS gestolpert.
Ist der Support von Filerestores mit MS ReFS geplant? Beim Filerestore kommt "no supported file system (500)".

Viele Grüße,
Falk

 

[dcsapak]

nein, wir unterstützen nur Filesysteme die auch in unserem Linux kernel verfügbar sind. da gibt es leider keinen ReFS support.
(es gibt zwar einen kommerziellen ReFS Treiber für den Linux kernel, den können wir aber nicht integrieren. https://www.paragon-software.com/business/refs-linux/)

 

[Falk R.]

Vielen Dank für den Tip. Kann ich denn dann eine virtuelle Disk aus dem Backup an eine andere VM hängen zum draufschauen?

 

[dcsapak]

Kann ich denn dann eine virtuelle Disk aus dem Backup an eine andere VM hängen zum draufschauen?

momentan noch nicht direkt, aber ein paar workarounds:

1. die disk in einen order, restoren und an eine bestehende vm dranhängen:

proxmox-backup-client restore <snapshot> <archiv> <target>
qm set ID -scsiX <path-to-disk>

2. 'map' kommando verwenden:

proxmox-backup-client map <snapshot> <archiv> # wird zu /dev/loopX  gemappt
qm set ID -scsiX /dev/loopX

3. qmp/hmp kommandos verwenden
im qemu monitor kann man mittels hmp/qmp direkt drives/devices hotpluggen:

drive_add <slot> if=none,id=some-id,file=pbs:repository:<repository>,,snapshot=<snapshot>,,archive=<archiv>,,password=<password>,,fingerprint=<fingerprint>
device_add virtio-blk-pci,drive=some-id,id=some-id

(wobei hier auch ein anderer disk-treiber statt 'virtio-blk-pci' gewählt werden kann, zb scsi-hd)

 

[kura]

Die Möglichkeit einen Snapshot aus dem Backup in eine Windows VM zu hängen fände ich auch für NTFS intressant, da mir im Moment die Möglichkeit fehlt Windows Dateirechte beim Wiederherzustellen einzelner Ordner zurückzusichern. Und der Umweg des Rücksichern in dem man kompletten Disk wiederherstellt (wie in Workaround 1) und dann einhängt ist recht zeitintensiv bei größeren Disks.

Ich habe das mit dem map Kommando in Workaround 2 ausprobiert, aber das scheint daran zu scheitern, dass /dev/loopX schreibgeschützt ist. Es wäre sehr hilfreich und zeitsparend wenn ich das Einhängen über das Mapping zum Laufen bekäme.

 

[dcsapak]

Ich habe das mit dem map Kommando in Workaround 2 ausprobiert, aber das scheint daran zu scheitern, dass /dev/loopX schreibgeschützt ist. Es wäre sehr hilfreich und zeitsparend wenn ich das Einhängen über das Mapping zum Laufen bekäme.

ah, klar. im moment kann man das mittels der option 'snapshot=1' lösen, zB:

qm set ID -scsi5 /dev/loopX,snapshot=1

VORSICHT: das legt ein temporäres file unter /var/tmp an, wohin die writes gehen. Dieses file kann so groß wie das ursprüngliche disk image werden wenn man alle daten überschreibt.