File Restore aus Proxmox Backup Server

[CH.illig]

Das Backup wurde bereits genutzt und auch für den restore,
ich habe nun aber seit neuerem (genauer Zeitpunkt unbekannt)
folgenden Fehler beim File restore:



drive-scsi 1&2 sind beides identische Festplattenkonfigurationen mit NTFS

Diek 2 funktioniert einwandfrei,
bei Disk1 erhalte ich die Fehlermeldung siehe Screenshot


Seitens Backupserver sehen die offenen Tasks dann so aus:


ZFS gibt den pool als Grün und gut an,

Die Serverconfig


Auf dem Backupserver (3.0.2) kann ich den Download der Disk starten (nicht zu ende getestet)

 

[Falk R.]

Hast du zufällig Dedup im Windows aktiviert?

 

[CH.illig]

Falls du das meinst, nein ist nicht installiert

 

[Falk R.]

Du nutzt auf beiden Disks NTFS mit der gleichen Blocksize? Welche Blocksize nutzt du?

 

[CH.illig]

 

[Falk R.]

Das ist ja alles Standard und muss funktionieren. Jetzt könnte die Ursache, beschädigte Daten im Backup sein. Verify läuft regelmäßig? Auch Re-verify gemacht?
Eventuell mal ein Live Restore machen und in der VM gucken ob die Disk sauber lesbar ist.

 

[CH.illig]

"Müsste" ;-)

Ja ein verify und reverify nach 30 Tagen läuft durch, auch das Backup von gestern lief im erneuten verify einwandfrei durch.


ein live restore ist gerade am Booten sieht aber gut aus bis jetzt...

 

[CH.illig]

Der Live restore klappt, ich kann sowohl die VM starten als auch innerhalb der VM mich in die Festplatte bewegen und daten lesen.

 

[Falk R.]

OK, dann sind alle Daten in Ordnung und wir haben hier einen Bug. Mal die Standardfrage, PBS Updates alle drin und nach den Updates neu gestartet?

 

[fabian]

bitte einen file-restore starten, die betroffene partition aufmachen um den fehler zu triggeren und dann den inhalt von /var/log/proxmox-backup/file-restore/qemu.log hier posten!

das backup scheint ja prinzipiell okay zu sein, vermutlich laeufst du in ein problem mit der speziellen file-restore VM (die automatisch im hintergrund gestartet wird). kann aufgrund der groesse moeglicherweise auch nur zuwenig RAM sein, oder fehlender support fuer so grosse NTFS filesysteme im Linux treiber, oder ..!

 

[CH.illig]

OK, dann sind alle Daten in Ordnung und wir haben hier einen Bug. Mal die Standardfrage, PBS Updates alle drin und nach den Updates neu gestartet?

ja ;-) Backupserver (3.0.2)

 

[Falk R.]

ja ;-) Backupserver (3.0.2)

Dann bitte mal Fabians Rat befolgen.

 

[CH.illig]

bitte einen file-restore starten, die betroffene partition aufmachen um den fehler zu triggeren und dann den inhalt von /var/log/proxmox-backup/file-restore/qemu.log hier posten!

das backup scheint ja prinzipiell okay zu sein, vermutlich laeufst du in ein problem mit der speziellen file-restore VM (die automatisch im hintergrund gestartet wird). kann aufgrund der groesse moeglicherweise auch nur zuwenig RAM sein, oder fehlender support fuer so grosse NTFS filesysteme im Linux treiber, oder ..!

EXT4-fs (vdc2): VFS: Can't find ext4 filesystem
EXT4-fs (vdc2): VFS: Can't find ext4 filesystem
EXT2-fs (vdc2): error: can't find an ext2 filesystem on dev vdc2.
FAT-fs (vdc2): bogus number of reserved sectors
FAT-fs (vdc2): bogus number of reserved sectors
VFS: could not find a valid V7 on vdc2.
ntfs: (device vdc2): ntfs_attr_find(): Inode is corrupt.  Run chkdsk.
ntfs: (device vdc2): ntfs_read_inode_mount(): Failed to lookup $MFT/$DATA attribute extent. $MFT is corrupt. Run chkdsk.
ntfs: (device vdc2): ntfs_read_inode_mount(): Failed. Marking inode as bad.
ntfs: (device vdc2): ntfs_fill_super(): Failed to load essential metadata.
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
[2023-09-05T07:42:27.447Z ERROR proxmox_rest_server::rest] GET /api2/json/list?path=ZHJpdmUtc2NzaTEuaW1nLmZpZHgvcGFydC8y: 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

auf seitens PBS

 

[Falk R.]

ntfs: (device vdc2): ntfs_attr_find(): Inode is corrupt.  Run chkdsk.
ntfs: (device vdc2): ntfs_read_inode_mount(): Failed to lookup $MFT/$DATA attribute extent. $MFT is corrupt. Run chkdsk.
ntfs: (device vdc2): ntfs_read_inode_mount(): Failed. Marking inode as bad.
ntfs: (device vdc2): ntfs_fill_super(): Failed to load essential metadata.

sagt ja schon alles aus.
Er erkennt korrupte Inodes und die MFT ist auch korrupt.
Ich würde einmal auf der laufenden VM ein chkdsk ausführen und wenn das ohne Fehler ist im Liverestore ein chkdsk auf die DIsk.
Windows hat den Vorteil, dass eine defekte MFT nicht sofort zu Problemen führt, da einiges im Windows gecached wird. Ist natürlich Sch.... wenn das erst beim nächsten Restore auffällt.

 

[fabian]

das klingt so als waere das backup entweder nicht konsistent (werden die backups mit guest agent und freeze gemacht, oder ohne?), oder als wuerde irgendein edge case im linux treiber triggern.. funktionieren andere backup snapshots, oder zeigen alle das gleiche verhalten?

was sonst eventuell noch einen versuch wert ist - diese disk mappen (mit "proxmox-backup-client map ..") und dann in eine linux VM einhaengen, sh. z.b. https://forum.proxmox.com/threads/einzelne-hdd-aus-pbs-backup.121169/#post-526763 fuer eine kurze anleitung. da koenntest du auch direkt das reparieren mit linux tools probieren bzw. feststellen, ob die ursache vielleicht nur im fehlenden schreibzugriff liegt..

 

[CH.illig]

die anderen Backups dieser Disk zeigen dasselbe (auch die ganz alten die mal funktionierten)
allerdings nur diese Disk ... die anderen disks / vm's funktionieren
bis auf die TMB Disk die immer diese Meldung bringt

 

[CH.illig]

Noch jemand eine Idee?

 

[Falk R.]

Kannst du mal ein neues Backup auf ein neuen Namespace machen und davon einen Restore testen?

 

[CH.illig]

muss ich mal schauen wo ich das hinbiege
reicht dir ein subdirectory im jetzigen namespace oder einen komplett neuen?

 

[Falk R.]

Ich hätte mal einen neuen getestet. Keine Ahnung ob das hilft, aber Versuch macht klug.