Hallo zusammen,
beim File-Restore eines Windows-Server-2019-Fileservers lässt sich das große Datenvolume nicht mounten, das Systemlaufwerk derselben VM dagegen schon.
Umgebung
Symptom
Dasselbe Kommando auf
Vergleich beider Volumes
Bereits ausgeschlossen
Reproduktion außerhalb von proxmox-file-restore
Um an die Kernel-Meldungen zu kommen, habe ich die Restore-VM manuell gestartet. Damit meine ich: QEMU direkt aufgerufen, mit demselben Kernel und demselben
initramfs bauen:
VM starten –
In der Shell:
Ergebnis
Der Treiber wird aber erreicht – mit einer ungültigen Option antwortet er:
Gegenprobe im selben Aufbau
Identischer Start, nur
Geometrie und Datenintegrität geprüft
Bytes/Sektor 512, Sektoren/Cluster 8, hidden_sectors 32768 (passt zum Partitionsstart), Gesamtsektoren 18874331135, MFT-Start-LCN 0xC0000, Volume-Seriennummer 3e8ca3f28ca3a33f – identisch mit
MFT liegt an der erwarteten Position. Lesezugriffe über die gesamte Volumelänge funktionieren: bei 2 TiB liegen Daten, bei 8 TB Nullen (unbelegter Bereich).
Speicher scheidet als Ursache aus, der Mount scheitert auch mit 4 GB RAM.
Frage
Gibt es eine bekannte Grenze von
beim File-Restore eines Windows-Server-2019-Fileservers lässt sich das große Datenvolume nicht mounten, das Systemlaufwerk derselben VM dagegen schon.
Umgebung
- PVE 9.2.4, proxmox-backup-file-restore 4.2.3-1, proxmox-backup-restore-image 1.0.0
- Host-Kernel: 7.0.14-5-pve
- Restore-Kernel 6.14.6-pbs-restore
- Gast: Windows Server 2019, UEFI, virtio-scsi
Symptom
Code:
proxmox-file-restore list vm/<VMID>/<SNAPSHOT> drive-scsi1.img.fidx/part/2 ...
Error: mounting 'drive-scsi1.img.fidx/part/2' failed: all mounts failed or no supported file systemDasselbe Kommando auf
drive-scsi0.img.fidx/part/4 (C:, 100 GB NTFS) liefert korrekt den Verzeichnisinhalt.Vergleich beider Volumes
Code:
C: (geht) D: (geht nicht)
Größe 100 GB 9 TB
NTFS-Version 3.1 3.1
Bytes/Cluster 4096 4096
Bytes/Sektor 512 512
MFT 476 MB 9,8 GBBereits ausgeschlossen
- Kein Dirty Flag (
fsutil dirty query D:meldet sauber) - Windows-Deduplizierung nicht installiert
- 15 Snapshots aus verschiedenen Zeiträumen geprüft, alle identisch fehlschlagend
- Partitionstabelle wird korrekt gelesen:
listaufdrive-scsi1.img.fidx/partzeigt1(16 MB MSR) und2(9663657541632 Bytes), letzteres stimmt exakt mit der Windows-Datenträgerverwaltung überein PBS_FILE_RESTORE_MEM_HOTPLUG_ALLOWundPBS_FILE_RESTORE_MEM_HOTPLUG_SIZE_MBzeigen keine Wirkung, die Restore-VM startet unverändert mit-m 256M,slots=1,maxmem=768M
Reproduktion außerhalb von proxmox-file-restore
Um an die Kernel-Meldungen zu kommen, habe ich die Restore-VM manuell gestartet. Damit meine ich: QEMU direkt aufgerufen, mit demselben Kernel und demselben
pbs-Blockdev wie proxmox-file-restore es tut, aber mit einem eigenen initramfs, das in eine Busybox-Shell bootet statt in den Restore-Daemon. So lässt sich der Mount von Hand absetzen und dmesg auslesen.initramfs bauen:
Code:
mkdir -p /tmp/shim && cd /tmp/shim
cpio -idmv < /usr/lib/x86_64-linux-gnu/proxmox-backup/file-restore/initramfs.img
cp /usr/lib/x86_64-linux-gnu/proxmox-backup/file-restore/proxmox-restore-daemon .
ln -sf busybox bin/sh
mv init init.orig
find . | cpio -o -H newc > /tmp/initramfs-manual.imgVM starten –
/init ist entfernt, der Kernel fällt auf /bin/sh zurück, das ist hier gewollt:
Code:
export PBS_PASSWORD='...'
export PBS_FINGERPRINT='...'
qemu-system-x86_64 \
-serial mon:stdio -vnc none -enable-kvm \
-kernel /usr/lib/x86_64-linux-gnu/proxmox-backup/file-restore/bzImage \
-initrd /tmp/initramfs-manual.img \
-append 'console=ttyS0 loglevel=7' \
-m 4096M \
-blockdev driver=pbs,repository=<USER>@<REALM>@<PBS-IP>:8007:<DATASTORE>,namespace=<NS>,snapshot=vm/<VMID>/<SNAPSHOT>,archive=drive-scsi1.img.fidx,read-only=on,node-name=drive1 \
-device pci-bridge,id=bridge2,chassis_nr=2 \
-device virtio-blk-pci,drive=drive1,serial=drive-scsi1,bus=bridge2 \
-nographicIn der Shell:
Code:
export PATH=/bin:/sbin:/usr/bin:/usr/sbin
/bin/busybox --install -s /bin
mkdir -p /proc /dev /sys /tmp/m
mount -t proc proc /proc
mount -t devtmpfs dev /dev
mount -t sysfs sys /sys
mount -t ntfs3 -o ro /dev/vda2 /tmp/m ; echo "exit=$?"Ergebnis
Code:
mount: mounting /dev/vda2 on /tmp/m failed: No such file or directory
exit=255dmesg enthält dazu keinerlei Eintrag. Dasselbe mit -o ro,nohidden und -o ro,prealloc.Der Treiber wird aber erreicht – mit einer ungültigen Option antwortet er:
Code:
ntfs3: Unknown parameter 'nols'Gegenprobe im selben Aufbau
Identischer Start, nur
archive=drive-scsi0.img.fidx, dann mount -t ntfs3 -o ro /dev/vda4 /tmp/m: funktioniert, Verzeichnisinhalt von C: wird angezeigt. Die Testumgebung ist also tauglich.Geometrie und Datenintegrität geprüft
Code:
# cat /sys/block/vda/vda2/start /sys/block/vda/vda2/size
32768
18874331136
Code:
# dd if=/dev/vda2 bs=512 count=1 | hexdump -C | head -6
00000000 eb 52 90 4e 54 46 53 20 20 20 20 00 02 08 00 00 |.R.NTFS .....|
00000010 00 00 00 00 00 f8 00 00 3f 00 ff 00 00 80 00 00 |........?.......|
00000020 00 00 00 00 80 00 80 00 ff 6f ff 64 04 00 00 00 |.........o.d....|
00000030 00 00 0c 00 00 00 00 00 02 00 00 00 00 00 00 00 |................|
00000040 f6 00 00 00 01 00 00 00 3f a3 a3 8c f2 a3 8c 3e |........?......>|
00000050 00 00 00 00 fa 33 c0 8e d0 bc 00 7c fb 68 c0 07 |.....3.....|.h..|Bytes/Sektor 512, Sektoren/Cluster 8, hidden_sectors 32768 (passt zum Partitionsstart), Gesamtsektoren 18874331135, MFT-Start-LCN 0xC0000, Volume-Seriennummer 3e8ca3f28ca3a33f – identisch mit
fsutil fsinfo ntfsinfo D: unter Windows.
Code:
# dd if=/dev/vda2 bs=4096 skip=786432 count=1 | hexdump -C | head -3
00000000 46 49 4c 45 30 00 03 00 17 fe 6e d8 04 00 00 00 |FILE0.....n.....|MFT liegt an der erwarteten Position. Lesezugriffe über die gesamte Volumelänge funktionieren: bei 2 TiB liegen Daten, bei 8 TB Nullen (unbelegter Bereich).
Speicher scheidet als Ursache aus, der Mount scheitert auch mit 4 GB RAM.
Frage
Gibt es eine bekannte Grenze von
ntfs3 bei großen Volumes bzw. großer MFT? Und ist der stille ENOENT-Pfad im Treiber bekannt? Über Hinweise zur weiteren Eingrenzung würde ich mich freuen.