2TB Virtual HDD Restore - Failed to Mount Virtual HDD - File Restore Function

G

gsusr1

New Member
Proxmox Subscriber
Jul 3, 2026
9
0
1
Hallo,

wir nutzen Proxmox VE und Proxmox Backup Server mit einem Abonnement.

Ich habe folgendes Problem: Wir führen regelmäßig Wiederherstellungstests durch. In einer Windows-Server-VM befinden sich drei virtuelle Festplatten (alle mit NTFS-Dateisystem). Wenn ich versuche, eine dieser drei virtuellen Festplatten über die GUI einzubinden (mounten), um einen einzelnen Ordner oder eine Datei wiederherzustellen, schlägt dies fehl.

Ich habe bereits „Checkdisk“ innerhalb des Windows-Servers ausgeführt, um die virtuelle Festplatte auf Fehler zu prüfen; Windows hat dabei keine Fehler gefunden. Zudem handelt es sich bei der Festplatte innerhalb von Windows nicht um einen dynamischen Datenträger.

Ich habe einen Screenshot der Fehlermeldung angehängt: `mounting drive-scsi1.img.fidx/part/2 failed: all mounts failed or no supported file system(400)`. Die virtuelle Maschine verfügt über vier Festplatten, von denen sich nur eine nicht einbinden lässt – ausgerechnet diejenige, die die wichtigsten Dateien enthält (Größe: 1,85 TiB, siehe Screenshot). Die Proxmox-Version ist 9.2.2.

Was kann ich tun, um eine Datei über die GUI wiederherzustellen? Wir müssen diese Tests über die GUI durchführen können, um die Funktionsfähigkeit der Backups zu überprüfen oder bei Bedarf einzelne Dateien wiederherzustellen.
 
Hat denn die Wiederherstellung aus einer NTFS-Platte schon mal funktioniert?

Grundsätzlich zu beachten: Der file-restore aus VMS funktioniert nur von ProxmoxVE, bei Containern oder dateibasierten Backups auch aus den ProxmoxBackupServer. Der Hintergrund ist, dass für den Restore einer Datei aus VM-Laufwerken im Hintergrund selbst eine spezielle VM gestartet wird (siehe https://pve.proxmox.com/pve-docs/chapter-vzdump.html#_single_file_restore ), laut deren Changelog ( https://pve.proxmox.com/pve-docs/chapter-vzdump.html#_single_file_restore/changelog.gz ) sollte die ab Version 0.7.0 auch mit ntfs klar kommen. Aber: Da es eben eine VM ist, ist das nur innerhalb von ProxmoxVE selbst möglich (bei der VM in der ProxmoxVE Oberfläche zu den Backups navigieren, dort dann "file-restore" auswählen, dort dann das Diskimage und aus dessen Dateibaum die passende Partition und Datei (gerade getestet):
1783107726705.png

Habt ihr schon versucht die VM als ganzes unter einer anderen ID und Hostname wiederherzustellen (mit live-restore startet die VM dann direkt und kann auch (wenn auch langsamer) benutzt werden)? Sonst könnte es auch noch einen Versuch wert sein, die VM wiederherzustellen und die fragliche Plate an eine andere laufende VM anzuhängen, um dann von dort an die Platten zu kommen.
 
  • Like
Reactions: news and UdoB
Hallo, Vielen Dank erstmal für den Lösungsvorschlag.

Grundsätzlich hat die VM 3 verschiedene NTFS Platten, davon kann ich in Proxmox VE alle problemlos mounten per File Restore und einzelne Dateien runterladen, was nur nicht bei der einen 2TB Festplatte funktioniert, dort erscheint die genannte Fehlermeldung, dass das Laufwerk nicht gemountet werden kann. Was geht ist die ganze VM inkl. aller Disks zeitaufwendig wiederherzustellen und dann innerhalb der VM auf die Daten zuzugreifen, dies ist jedoch nicht Sinn der File Restore Funktion, diese wollen wir jedoch unbedingt nutzen, da alles andere viel zu zeitaufwendig ist, gibt es eine Lösung, um die NTFS Festplatte via GUI zu mounten? Ist dies ein Bug? Hat dies was damit zu tun, dass die Festplatte größer gleich 2Terrabyte ist? Hat dies jemand mal ausprobiert?
 
gsusr1 said:
Hallo, Vielen Dank erstmal für den Lösungsvorschlag.

Grundsätzlich hat die VM 3 verschiedene NTFS Platten, davon kann ich in Proxmox VE alle problemlos mounten per File Restore und einzelne Dateien runterladen, was nur nicht bei der einen 2TB Festplatte funktioniert, dort erscheint die genannte Fehlermeldung, dass das Laufwerk nicht gemountet werden kann. Was geht ist die ganze VM inkl. aller Disks zeitaufwendig wiederherzustellen und dann innerhalb der VM auf die Daten zuzugreifen, dies ist jedoch nicht Sinn der File Restore Funktion, diese wollen wir jedoch unbedingt nutzen, da alles andere viel zu zeitaufwendig ist, gibt es eine Lösung, um die NTFS Festplatte via GUI zu mounten? Ist dies ein Bug? Hat dies was damit zu tun, dass die Festplatte größer gleich 2Terrabyte ist? Hat dies jemand mal ausprobiert?
Click to expand...
Ist da zufällig Windows Deduplizierung aktiv?
 
  • Like
Reactions: Johannes S
Hallo, die Deduplizierung ist bei dem Laufwerk nicht aktiviert, sowie auf dem gesamten Server bzw. VMaschine nicht aktiv, auch ist der Dedeuplizierungsdienst ebenfalls nicht installiert als Feature / Rolle.
 
OK, das wäre sonst eine Simple Ursache.
Kannst du mal checken mit welcher Blocksize das NTFS formatiert wurde. Eventuell gibts da Probleme.

Geht per: fsutil fsinfo ntfsinfo D: für Laufwerk D
 
Last edited:
  • Like
Reactions: Johannes S
Also 4096 Bytes pro Cluster, das ist der Standard, anbei alle Daten:

NTFS-Version : 3.1
LFS-Version : 2.0
Anzahl der Sektoren : 0x000000004aff6fff
Gesamtzahl Cluster : 0x00000000095fedff
Freie Cluster : 0x0000000001447e98
Insgesamt reserviert : 0x0000000000000400
Bytes pro Sektor : 512
Bytes pro physischem Sektor : 512
Bytes pro Cluster : 4096
Bytes pro Dateidatensatzsegment : 1024
Cluster pro Dateidatensatzsegment: 0
Gültige MFT-Datenlänge : 0x0000000015fc0000
MFT-Start-LCN : 0x00000000000c0000
MFT2-Start-LCN : 0x0000000000000002
MFT-Zonenstart : 0x00000000017a36e0
MFT-Zonenende : 0x00000000017af2e0
Max. Erweiterungsanzahl für Gerätekürzung : 255
Max. Byteanzahl für Gerätekürzung: 0x40000000
Max. Erweiterungsanzahl für Volumekürzung : 62
Max. Byteanzahl für Volumekürzung: 0x40000000
 
Da die mit 4K Standard formatiert ist, kann das auch nicht das Problem sein.

Als Workaround nutze ich auch gern den Live Restore, und dann muss man nicht auf den kompletten Restore warten.
Die Ursache rauszufinden wird nicht so einfach. Manchmal sind es auch irgendwelche liegengebliebenen Metadaten.

Ich würde mal die ganzen Logs in eine KI kippen, das Analysieren der Logs können die LLM viel schneller als jeder Mensch. Eventuell kommt man so schneller zum Ziel.
 
Das ist ja das Problem, es gibt in den Logs keine genauen Fehler IDs oder Meldungen worauf meine Suche basiert sein kann, das Laufwerk kann nicht gemountet werden, das wars.

Das Laufwerk wurde auch auf Fehler in der VM selbst geprüft, Windows konnte keine Fehlerhaften Sektoren finden und das Laufwerk ist gemäß Windows einwandfrei.
 
gsusr1 said:
Das ist ja das Problem, es gibt in den Logs keine genauen Fehler IDs oder Meldungen worauf meine Suche basiert sein kann, das Laufwerk kann nicht gemountet werden, das wars.

Das Laufwerk wurde auch auf Fehler in der VM selbst geprüft, Windows konnte keine Fehlerhaften Sektoren finden und das Laufwerk ist gemäß Windows einwandfrei.
Click to expand...
Und der NTFS Treiber im PVE bringt keine Fehlermeldungen?
 
Ich habe mir die Logs angeschaut und folgendes ist zu sehen:

[2026-07-08T10:34:41.137Z WARN proxmox_restore_daemon::proxmox_restore_daemon::disk] mount error on '/dev/vdc2' (ntfs3) - ENOENT: No such file or directory
ufs: ufs_fill_super(): bad magic number
befs: (vdc2): invalid magic header
F2FS-fs (vdc2): Can't find valid F2FS filesystem in 1th superblock
F2FS-fs (vdc2): Can't find valid F2FS filesystem in 2th superblock
bcachefs (/dev/vdc2): error reading default superblock: Not a bcachefs superblock (got magic a8006661-901f-0706-1e66-6067807b0800)
bcachefs (/dev/vdc2): error reading superblock: Not a bcachefs superblock layout
bcachefs: bch2_fs_get_tree() error: invalid_sb_layout
[2026-07-08T10:34:41.160Z ERROR proxmox_rest_server::rest] GET /api2/json/list?path=sdf43sdfg234y: 400 Bad Request: [client 0.0.0.0:807] mounting 'drive-scsi1.img.fidx/part/2' failed: all mounts failed or no supported file system
 
Wenn du das als Codeblock postest, kann man das viel besser lesen.
Der findet im Superblock keine Information, was für ein Dateisystem drauf ist. Ich weiß, dass man diese Informationen fixen kann, aber ich habe das auch noch nicht gemacht.

Also ein ganz simpler Fehler. Es gibt keine Validen Infos und er weiß nicht welches Dateisystem vorhanden ist.
Microsoft ignoriert das, die gehen immer davon aus, dass NTFS oder ReFS kommt und lesen einfach weiter.
 
  • Like
Reactions: Johannes S
Kann man dies selbst lösen oder auf den Patch von Proxmox warten? Ich habe gelesen dass im Linux Kernel 7.2 massive NTFS Verbesserungen kommen inkl. neuem NTFS Kerneltreiber, der viele Fehler behebt und bessere Kompatibilität hat.
 
Das musst du selbst beheben. Linux geht immer davon aus, dass der Header korrekt beschrieben wurde und da die Information zum verwendeten Dateisystem steht.
Wenn die Info fehlt, dann wird das Fehlerbild unter allen nicht Windows Systemen bleiben.
 
Die KI spuckt sofort folgendes aus, was auch plausibel ist:
parted /dev/sdb print Ausführen. Wenn das Feld Dateisystem leer ist, kommt es zu dem verhalten. (Wenn die Disk als sdb erkannt wird)
Die korrekte Info setzt du mit:
parted /dev/sdb set 1 msftdata on
 
Die VMs sind alle per ZFS formatiert, die Backups laufen über Proxmox Backup Server, ich verstehe nicht was die parted /dev/sdb print auswirken soll, wenn das laufwerk doch garnicht erst gemountet werden kann, dies muss irgendwie doch beim mount befehl mitgeteilt werden können, dass es sich um ntfs handelt und weitere parameter oder habe ich hierbei etwas nicht verstanden?
 
Wenn du Windows VMs hast, dann hast du sehr wahrscheinlich kein ZFS Dateisystem.
Womit die Backups gemacht werden ist vollkommen egal.
Entweder du hängst die betroffene Disk temporär an eine Linux VM oder bootest eine Live CD, da kannst du das easy mit parted checken und modifizieren.
Theoretisch kannst du das auch mit Diskpart im Windows machen, aber das ist deutlich komplizierter.
Da suche dir einen Blog wo schon mal jemand das mit Diskpart gemacht hat oder frag die KI deiner Wahl.

Wenn, warum auch immer, die Partitionsinformationen nicht korrekt geschrieben wurden, ist das Windows zwar egal aber alle anderen Betriebssysteme erwarten korrekte Metadaten.
 
  • Like
Reactions: Johannes S
You must log in or register to reply here.
Top Bottom
Back