File Restore aus Proxmox Backup Server

[sub2o5]

Hab das Problem bei einem Kunden auch.
Eine VM mit 3 Drives: 250G System, 6TB Daten und nochmal 2TB Daten.
die 6TB-Partition läßt sich weder mittels Filerestore öffnen, noch mittels Map mounten.
Nun muß ich das Drive komplett zurückspielen, damit ich es in eine laufende VM einhängen kann. :-/

5490283.315897] ntfs: driver 2.1.32 [Flags: R/O MODULE].
[5490283.342505] __ntfs_error: 13 callbacks suppressed
[5490283.342509] ntfs: (device loop0p2): ntfs_attr_find(): Inode is corrupt. Run chkdsk.
[5490283.343479] ntfs: (device loop0p2): ntfs_read_inode_mount(): Failed to lookup $MFT/$DATA attribute extent. $MFT is corrupt. Run chkdsk.
[5490283.344264] ntfs: (device loop0p2): ntfs_read_inode_mount(): Failed. Marking inode as bad.
[5490283.344671] ntfs: (device loop0p2): ntfs_fill_super(): Failed to load essential metadata.

Getestet unter verschiedenen Proxmox-Versionen (alles 8er). Könnte nun spaßeshalber noch einen 7er irgendwo aufsetzen, denn mit dem ging damals der Filerestore definitiv.

Bericht kommt in Kürze!

 

[Falk R.]

Ist auf dem Windows zufällig Dedup aktiv?
Ich würde einen Liverestore machen und wenn du die Datei hast, den Liverestore abbrechen.
Ok, hatte ich schon mal gefragt. Sorry.

 

[Falk R.]

Ich habe mir noch einmal alles durchgelesen. Hängt die virtuelle Disk an einem virtuellen SATA Controller?
Sonst mal bootrec.exe /fixmbr ausführen, ob das zufällig zum Ziel führt.

 

[sub2o5]

File-Restore klappt mit 7.4 problemlos! Ist also ein Bug der mit der 8er Release eingeführt wurde!
Ich tippe stark auf den verwendeten Kernel, da beim händischen map und mount der Fehler ja ebenfalls auftritt.

 

[sub2o5]

Ich habe mir noch einmal alles durchgelesen. Hängt die virtuelle Disk an einem virtuellen SATA Controller?
Sonst mal bootrec.exe /fixmbr ausführen, ob das zufällig zum Ziel führt.

Die Backups sind korrekt und haben keine Fehler. Das Problem scheint im NTFS-Treiber der Kernel in der 8er Proxmox-Releases zu stecken.
(Oder in einer Änderung im Blockdevice-Handling zwischen PBS und PVE - was ich aber für eher unwahrscheinlich halte)

Edit: Aktuell läuft bei mir noch 8.0 mit 6.2er Kernel, ich setze gleich mal eine VM mit 8.1/6.5 auf und schaue, was passiert!

 

[sub2o5]

Problem besteht in aktueller 8.1 mit Kernel 6.5 ebenfalls:

mounting 'drive-scsi1.img.fidx/part/2' failed: all mounts failed or no supported file system (400)

 

[Falk R.]

versuche mal den fixmbr.
Das Backup ist in Ordnung wenn es den Originaldaten entspricht, wenn da schon ein Fehler auf der Disk ist, wird dir der Verify nicht helfen.

 

[sub2o5]

Welcher Verify? Ich sprach zu keinem Zeitpunkt davon!

Disk hängt auch nicht an SATA, regulärer VirtIO-SCSI.

Die Maschine ist völlig in Ordnung, es gibt kein Problem mit den Partitionen!
Lediglich mit Versionen >=8.0 von Proxmox ist kein Filerestore mehr möglich, was augenscheinlich an der Kernelversion liegt.

Ich lasse aber später spaßeshalber mal einen Dateisystemcheck laufen.

 

[Falk R.]

Es muss ja ein Problem geben, warum er das NTFS nicht erkennt. Bei mir funktioniert die Erkennung von NTFS auch unter PVE8.

 

[sub2o5]

Ja, bei mir funktioniert NTFS auch bei 99,9% der Backups auch unter PVE8. Eben nur nicht bei dieser einen Maschine, und das Fehlerbild ist exakt jenes vom OP hier, weshalb ich auch via Googlesuche auf diesen Thread aufmerksam wurde. Und - Zufall - er nutzt ebenfalls eine 3er-Version von PBS (somit liegt die Vermutung nahe, dass er ebenfalls eine 8er PVE nutzt!)

Ich habe nun schon alles quergetestet, der Fehler tritt erst ab PVE 8.XX respektive Kernel >=6.2 auf.

FS-Check ist durch auf der VM. Wie erwartet keine Fehler.

Fehler ist mit PVE 8.1.3 und Kernel 6.5 ebenfalls noch präsent.

Daher: Eindeutig ein Bug im NTFS-Treiber von Kernel >=6.2

Und nein, ich werde an einer funktionierenden VM, bei der die windowseigene Dateisystemprüfung sagt, alles ist ok, keine Experimente machen!

Edlin: Beide anderen Partitionen (NTFS) lassen sich absolut problemlos öffnen. Setze ich ein PVE7.4 in einer VM auf und gebe ihm Zugriff auf den PBS funktioniert File Restore ebenfalls.

 

[Falk R.]

Ich würde das gerne mal nachstellen. Welche Blocksize nutzt ihr bei eurem NTFS und wie groß sind die Disks wo das Problem auftritt? Ganz wichtig, sind die MBR oder GPT?

 

[sub2o5]

Ich würde das gerne mal nachstellen. Welche Blocksize nutzt ihr bei eurem NTFS und wie groß sind die Disks wo das Problem auftritt? Ganz wichtig, sind die MBR oder GPT?

Alles 4k. MBR. Ich sehe halt keinen offensichtlichen Unterschied. Volume 2 + 4 sind ähnlich alt (seit Erstinstallation), 5+6 kamen später hinzu.
Volume 4 ist das, was Probleme macht.

Besonders merkwürdig ist, dass ich gestern die changelogs vom ntfs-treiber (read only) gesichtet habe und seit 2017 keine Änderungen mehr vorgenommen wurden. Mysteriös.

Ich kann wiegesagt zu 100% nachstellen, dass Filerestore mit einer beliebigen 7.4er geht, ab 8 nicht mehr.
Ich könnte jetzt noch spaßeshalber eine 7.4er mit Kernel 6.2 booten oder einen 8.0er mit 5.15.
Aber ich denke, da in der Mini-VM vom Filerestore auch der zur Proxmox-Release passende Kernel verwendet wird, ist das Ergebnis davon schon von vornherein klar.

PBS-Version scheint keine Rolle zu spielen, der ist ebenfalls auf die Neueste hochgezogen worden.
Backups sind btw auf 2 PBSen an unterschiedlichen Standorten und mit völlig unterschiedlicher Historie, Hardware und Infrastruktur. Weshalb auch hier keinerlei Übereinstimmung erkennbar ist.
Zum Restore habe ich 3 "echte" Installationen (2 bei meinem Kunden, 1 bei mir) und eine VM bei mir mit jeweils dem gleichen Datenbestand (ich synce seinen PBS zu mir) probiert.

Und eben per bash den Kram gemappt und gemerkt, dass dort eben der MFT-Fehler angezeigt wird.

Ich hatte vor 1-2 Jahren schon einen Bug im Filerestore gefunden, lag aber damals an einer großen Partition (knapp 40T) und dem dadurch fehlenden Arbeitsspeicher der VM. Wurde zwischenzeitlich gefixt.

Ich könnte theoretisch mal versuchen, die Filerestore-Mini-VM einer 7.4er in meinen 8er zu frickeln und zu schauen, ob es dann geht. Aber dazu komme ich heute leider nichtmehr.

DISKPART> lis vol

  Volume ###  Bst  Bezeichnung  DS     Typ         Größe    Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     F                       CD              0 B  Kein Medi
  Volume 1         System-rese  NTFS   Partition    100 MB  Fehlerfre  System
  Volume 2     C                NTFS   Partition    119 GB  Fehlerfre  Startpar
  Volume 3                      NTFS   Partition    570 MB  Fehlerfre  Versteck
  Volume 4     D   Volume       NTFS   Partition   6143 GB  Fehlerfre
  Volume 5     E   Profileback  NTFS   Partition   2047 GB  Fehlerfre
  Volume 6     G   Volume       NTFS   Partition    999 GB  Fehlerfre

DISKPART> sel vol 2
DISKPART> filesystems

  Typ                  : NTFS
  Größe der Zuordnungseinheit : 4096

DISKPART> sel vol 4
DISKPART> filesystems

  Typ                  : NTFS
  Größe der Zuordnungseinheit : 4096
  Kennzeichen : 00000000

DISKPART> sel vol 3
DISKPART> filesystems

  Typ                  : NTFS
  Größe der Zuordnungseinheit : 4096
  Kennzeichen : 00000000

 

[Falk R.]

Falls du es hinbekommen hast eine MBR Partition auf 6TB zu erweitern, dann haben wir ja schon die Quelle des Übels.
Kannst du das bitte noch einmal checken und falls das tatsächlich so ist, verrate mir mal den Trick wie man das hinbekommt.

 

[sub2o5]

Argh, nein. Natürlich nicht. War ne kurze Nacht.

Das erste Volume liegt auf MBR und wird auch entsprechend nicht per UEFI gebootet.
Die anderen Partitionen liegen alle auf GPT.

Ich kann dir gerne das Layout mal auslesen.

Disk /dev/hdd-epyc01/vm-147-disk-1: 6 TiB, 6597069766656 bytes, 12884901888 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 8192 bytes
I/O size (minimum/optimal): 8192 bytes / 8192 bytes
Disklabel type: gpt
Disk identifier: 227724EA-9ED9-4C8C-9335-9602B958EC16

Device                           Start         End     Sectors  Size Type
/dev/hdd-epyc01/vm-147-disk-1p1     34      262177      262144  128M Microsoft reserved
/dev/hdd-epyc01/vm-147-disk-1p2 264192 12884897791 12884633600    6T Microsoft basic data

 

[Falk R.]

Ich teste das morgen mal.

 

[Falk R.]

Ich habe jetzt an meinem Server2022 eine 6TB Disk, ganz identisch angehängt, einige Daten drauf geschaufelt und zwei Backups durchgeführt.
Der Filerestore funktioniert mit aktuellem PVE 8.1 und PBS 3.0 sauber.
Das einzige was mir am Layout auffällt, Server2022 reserviert nur noch 16MB statt wie bei dir 128MB.
Irgend etwas muss an der Disk noch anders sein. Ich habe einen Kunden mit ner 8TB Disk, wo ich selbst schon unter PVE8 einen Filerestore gemacht habe und einige Kunden haben auch noch größere Disks im Einsatz. Da habe ich aber noch keinen Filerestore getestet, aber es hat sich bisher auch noch keiner gemeldet, dass etwas nicht funktioniert.

 

[Falk R.]

P.S. das dritte Backup läuft gerade, ich bleibe mal dran.

 

[sub2o5]

Ich muß mich nochmals korrigieren:
Beim 7.4er kommt mit "proxmox-backup-client map" und einem anschließenden "mount" ebenfalls der gleiche Fehler.
Lediglich File-Restore im Browser funktioniert einwandfrei.

Spaßeshalber habe ich die Files vom filerestore (/usr/lib/x86_64-linux-gnu/proxmox-backup/file-restore/*) vom 7.4er auf meien 8.1er gepackt und es funktioniert damit!

Jetzt müßte ich mal schauen, welche Änderungen im file-restore-image seitdem geschehen sind.

 

[sub2o5]

Mir kommen die Start/End-Sektoren auch sonderbar vor, zumal fdisk von Linux über schräge Boundaries meckert.

Ach ja: Auf dem Livesystem habe ich 512/8192 (zeigt fdisk an), beim loopback 512/512:

Disk /dev/loop0: 6 TiB, 6597069766656 bytes, 12884901888 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 227724EA-9ED9-4C8C-9335-9602B958EC16

Device        Start         End     Sectors  Size Type
/dev/loop0p1     34      262177      262144  128M Microsoft reserved
/dev/loop0p2 264192 12884897791 12884633600    6T Microsoft basic data

 

[Falk R.]

Mir kommen die Start/End-Sektoren auch sonderbar vor, zumal fdisk von Linux über schräge Boundaries meckert.

Ach ja: Auf dem Livesystem habe ich 512/8192 (zeigt fdisk an), beim loopback 512/512:

bei mir steht überall 512/512. Eventuell ist da irgendwo die Ursache. Ich wüsste jetzt auch nicht wie ich die 512/8192 nachstellen soll.