[SOLVED] File Restore Dateien defekt

[fabian]

Andere Frage/Idee: Könnte ich das Backup per

proxmox-backup-client map <snapshot> <archive-name> [OPTIONS]

einbinden und das an eine bestehende Windows VM mit aktiviertem Dedup hängen um einzelne Dateien wiederherzustellen?

ja, sowas in der art koennte funktionieren (so aehnliche ansaetze haben user hier im forum ja auch schon ausprobiert bevor es file-restore support in PVE gab )

 

[Falk R.]

Aber immer drauf achten, mindestens die gleiche oder neuere OS Version. Wenn du ein 2022 Filer hast und das Restore über ein 2019 machst, hast du auch korrupte daten.

 

[cfuchs]

ja, sowas in der art koennte funktionieren (so aehnliche ansaetze haben user hier im forum ja auch schon ausprobiert bevor es file-restore support in PVE gab )

Das funktioniert. Ich mache gleich eine Anleitung fertig.

 

[cfuchs]

Aber immer drauf achten, mindestens die gleiche oder neuere OS Version. Wenn du ein 2022 Filer hast und das Restore über ein 2019 machst, hast du auch korrupte daten.

Sowieso. Der Einfachheit halber wird der Snapshot an den selben Server gehängt. Natürlich an eine Restore-VM, sonst muss man das Produktivsystem ja neu starten.

 

[cfuchs]

Leider lassen sich (derzeit) keine einzelne Dateien von Windows Servern wiederherstellen, auf denen die Windows Deduplizierung aktiviert ist.

Über folgenden Weg gelingt es doch:

Ausgangssituation:
PVE 7.1-12
PBS 2.1-5
VM Windows Server 2022 mit aktivierter Deduplikation (VMID 117 (in diesem Beispiel))
- vorhande Festplatten:
sata0 mit dem Betriebssystem
virtio1 als Datenfestplatte


Wir benötigen eine "Restore-VM" mit der gleichen Windows Version, wie der produktive Server auf dem die Daten fehlen sowie installiertem Deduplikation-Feature.

Anschließend suchen wir uns einen Snapshot des produktiven Servers, in dem die fehlenden Daten möglicherweise noch vorhanden sind:

proxmox-backup-client snapshot list --repository root@pam@pbs.lan.home:zfs01

├─────────────────────────────┼─────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ vm/117/2022-04-15T16:54:04Z │ 102.004 GiB │ client.log drive-efidisk0.img drive-sata0.img drive-tpmstate0-backup.img drive-virtio1.img index.json qemu-server.conf │
├─────────────────────────────┼─────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ vm/117/2022-04-18T09:14:16Z │ 102.004 GiB │ client.log drive-efidisk0.img drive-sata0.img drive-tpmstate0-backup.img drive-virtio1.img index.json qemu-server.conf │
├─────────────────────────────┼─────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤

Da wir wissen, dass die Datenfestplatte virtio1 ist, mounten wir den letzten Snapshot mit folgendem Befehl:

proxmox-backup-client map vm/117/2022-04-18T09:14:16Z drive-virtio1.img --repository root@pam@pbs.lan.home:zfs01

Ausgabe: Image 'root@pam@pbs.lan.home:8007:zfs01:vm/117/2022-04-18T09:14:16Z/drive-virtio1.img' mapped on /dev/loop0

Disclaimer: Natürlich legt Ihr Euch auf dem PBS einen Benutzer an, der auf die Snapshots zugreifen darf. Ich habe "root" nur der Einfachheit halber genommen.

Von Device /dev/loop0 müssen wir (in diesem Fall) die erste und einzige Partition als zusätzliche Festplatte in der Konfiguration der Restore-VM hinterlegen:

Konfiguration Restore-VM (VMID 999) unter /etc/pve/qemu-server/999.conf

agent: 1
bios: ovmf
boot: order=virtio0;ide2;net0;ide0
cores: 2
efidisk0: zfs01:vm-999-disk-0,efitype=4m,pre-enrolled-keys=1,size=1M
ide0: local:iso/virtio-win-0.1.217.iso,media=cdrom,size=519096K
ide2: local:iso/SW_DVD9_Win_Server_STD_CORE_2022_2108.1_64Bit_German_DC_STD_MLF_X22-82989.ISO,media=cdrom,size=4914750K
machine: pc-q35-6.2
memory: 6144
meta: creation-qemu=6.2.0,ctime=1650452727
name: restore-vm
net0: virtio=E2:7C:A7:C5:53:BF,bridge=vmbr0,firewall=1
numa: 0
ostype: win11
scsihw: virtio-scsi-pci
smbios1: uuid=fe458dd8-4fd5-4c3e-b20d-fab892470d95
sockets: 2
tpmstate0: zfs01:vm-999-disk-1,size=4M,version=v2.0
virtio0: local-lvm:vm-999-disk-0,size=32G
virtio1: /dev/loop0p1,ro=1
vmgenid: a580f33b-f9ea-4548-b430-031c8f8f4bed

Leider erkennt der Windows Server die Festplatte erst nachdem man den Server aus- und wieder eingeschaltet hat. Danach kann die Festplatte über den Server Manager online geschaltet werden. Die fehlenden Daten können nun z. B. über eine Freigabe auf den produktiven Server kopiert werden.

2022-04-21 Nachtrag:
Alternativ kann die Festplatte auch über qm set 999 -virtio1 /dev/loop0p1,ro=1 im laufenden Betrieb an die Restore-VM gehängt werden.

Falls der Befehl aus dem Nachtrag nicht funktionieren sollte, dann einfach wie zuerst geschrieben, die Konfiguration ändern. Dann funktioniert es auf jeden Fall.


An dieser Stelle noch einmal Danke für die Anregungen und Hinweise. Danke auch meinen Ex-Kollegen Daniel, mit dem ich abseits des Forums nach einer Möglichkeit gesucht habe. Vielleicht hilft die Anleitung auch denjenigen, die den gleichen "Fehler", wie ich gemacht habe. Und vielleicht gibt es zukünftig eine Möglichkeit Snapshots über die Web-GUI wie beschrieben einzuhängen. ;-)

Ich weiß, dass das nur ein Workaround ist, aber schneller ist als die komplette VM wiederherzustellen.

 

[Falk R.]

Was aber komisch bei dir ist, dass die Disk erst nach Neustart erkannt wird. Bei mir geht das immer im laufenden Betrieb.

 

[cfuchs]

Was aber komisch bei dir ist, dass die Disk erst nach Neustart erkannt wird. Bei mir geht das immer im laufenden Betrieb.

Das kenne ich auch so. In diesem Fall funktionierte es mehrfach nicht. Vielleicht teste ich das noch einmal.

 

[fabian]

hast du die zeile einfach in die config eingetragen? oder mittels API/qm set konfiguriert? weil ersteres kriegt die VM/PVE nicht mit, zweiteres sollte bei laufender VM ein hotplug ausloesen (und falls das nicht klappt, die aenderung als pending change statt direkt in die config schreiben!)

 

[Falk R.]

Mir fällt da gerade noch was zu ein.
Erkennt der die Disk nur nicht, wenn du den Snapshot an die original VM hängst? Das wäre ein normales Verhalten, da die Snapshot Disk, die gleiche ID wie die gemountete Platte hat. Multipath ist ja defaultmässig aus und da wird das Device einfach ausgeblendet.
Also immer an eine Helper VM geben.

 

[cfuchs]

hast du die zeile einfach in die config eingetragen? oder mittels API/qm set konfiguriert? weil ersteres kriegt die VM/PVE nicht mit, zweiteres sollte bei laufender VM ein hotplug ausloesen (und falls das nicht klappt, die aenderung als pending change statt direkt in die config schreiben!)

Beides. Einmal direkt in der Konfig und einmal per qm set 999 -virtio1 /dev/loop0p1,ro=1 und anschließend qm rescan --vmid 999

2022-04-21 18:53
Edit:
Ich habe es gerade erneut getestet. Jetzt hat er den Snapshot direkt als neue Festplatte erkannt.

 

[cfuchs]

Mir fällt da gerade noch was zu ein.
Erkennt der die Disk nur nicht, wenn du den Snapshot an die original VM hängst? Das wäre ein normales Verhalten, da die Snapshot Disk, die gleiche ID wie die gemountete Platte hat. Multipath ist ja defaultmässig aus und da wird das Device einfach ausgeblendet.
Also immer an eine Helper VM geben.

Ne, das war bei beiden Maschinen so.

 

[fabian]

rescan ist nicht notwendig (das ist dazu da, auf storages liegende volumes die derzeit nicht referenziert werden als unused in die config einzutragen )