File Restore aus Proxmox Backup Server

Wobei die physical blocksize eigentlich egal sein sollte, die partitionen sind ja immer vielfache der logischen blockgröße.

Die physische dürfte vom darunterliegenden RAID kommen.
 
Ist auf der Disk das Partitionslayout einmal von MBR auf GPT konvertiert worden?
Viel mehr ideen habe ich jetzt nicht, warum der Fehler kommt. Also mit einer frischen Disk und ein paar Backups lässt sich das nicht reproduzieren.
 
Die Kiste wurde vor einiger Zeit frisch aufgesetzt. Konvertiert wurde da nichts.
Die 6TB-Partition fällt demnächst weg, ist natürlich dennoch doof, nicht oder nur umständlich an die Backups zu kommen.
 
Lässt sich aber schwer nachstellen. Ich kenne das Problem auch nicht bei konvertierten VMs. Ich betreue bestimmt in Summe 1000 VMs bei meinen Kunden, aber solche Probleme habe ich noch nicht gesehen. Interessieren tut mich das aber schon, weil ich natürlich vermeiden möchte, dass ein Kunde von mir jemals in einen solchen Fehler läuft.
Meine Server mit der 6 TB testdisk macht weiter fleißig Backups und ich teste regelmäßig die Filerestores.
 
Um mal von meiner Seite her noch paar Informationen nachzulegen..

Ich h habe den Backup Storage nun auf einem 8.0er wo der Fehler auftrat auf ein 8.1 angehoben und habe den Fehler immer noch
den Backupserver von 3.0 auf 3.1.2 ... ebenfalls das Problem bleibt
wenn ich den Backup Storage auf einem PVE 7.4-15 einbinde, kann ich via GUI ganz normal die Partition zum Filerestore öffnen
 
CH.illig said:
Um mal von meiner Seite her noch paar Informationen nachzulegen..

Ich h habe den Backup Storage nun auf einem 8.0er wo der Fehler auftrat auf ein 8.1 angehoben und habe den Fehler immer noch
den Backupserver von 3.0 auf 3.1.2 ... ebenfalls das Problem bleibt
wenn ich den Backup Storage auf einem PVE 7.4-15 einbinde, kann ich via GUI ganz normal die Partition zum Filerestore öffnen
Click to expand...
Same here!
 
CH.illig said:
Um mal von meiner Seite her noch paar Informationen nachzulegen..

Ich h habe den Backup Storage nun auf einem 8.0er wo der Fehler auftrat auf ein 8.1 angehoben und habe den Fehler immer noch
den Backupserver von 3.0 auf 3.1.2 ... ebenfalls das Problem bleibt
wenn ich den Backup Storage auf einem PVE 7.4-15 einbinde, kann ich via GUI ganz normal die Partition zum Filerestore öffnen
Click to expand...
Hast du das bei einen frisch installierten Host auch? Irgendwas muss da ja anders sein. In meiner Testumgebung konnte ich das nicht nachstellen und beim Kunden habe ich Restoretests auf nem 8 TB SQL gemacht. Alles ganz normal.
 
Mit der Partitionsgröße hat das nichts zu tun, ich habe andere Kisten mit teils >30T, da geht der Filerestore auch reibungslos.
 
Aber irgend etwas muss ja anders sein. Eventuell die NTFS Version? Welches Windows ist denn auf der betroffenen VM?
 
C:\Windows\system32>fsutil fsinfo ntfsinfo d:
NTFS Volumeseriennummer: 0x10987da8987d8cca
NTFS Version : 3.1
LFS Version : 2.0
Sektoren insgesamt : 12.884.633.599 ( 6,0 TB)
Cluster insgesamt : 1.610.579.199 ( 6,0 TB)
Freie Cluster : 619.715.561 ( 2,3 TB)
Reservierte Cluster insgesamt: 4.140 (16,2 MB)
Reserviert für Speicherreserve : 0 ( 0,0 KB)
Bytes pro Sektor : 512
Bytes pro physikalischem Sektor : 512
Bytes pro Cluster: 4096 (4 KB)
Bytes pro FileRecord-Segment : 1024
Clusters pro FileRecord-Segment : 0
MFT-gültige Datenlänge: 18,06 GB
MFT-Start-LCN : 0x00000000000c0000
MFT2-Start-LCN : 0x0000000000000002
MFT-Zonenstart : 0x0000000043ee5420
MFT-Zonenende 0x0000000043eee420
MFT-Zonengröße : 144,00 MB
Max. 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
Ressourcen-Manager-Bezeichner: E85C5413-D6C4-11E7-BFAD-002590010AA3

C: sieht genauso aus (Bis auf die Größe), da klappt Filerestore ... seltsam.
 
Alles völlig normal. Dann liegt es schon mal nicht an der Windowsversion.
 
Ich hatte ja vor längerem schonmal ein Problem mit der Restore-Minivm. Damals lag es an der etwas zu engen Speicherplatzzuweisung seitens des Wrappers. Gibt es eine Möglichkeit, die VM mal vernünftig zu debuggen, sprich: Sämtliche Syslogs zu sehen und evtl. eine interaktive Shell aufzurufen, damit man exakt schauen kann, was hakt und evtl. ein paar Workarounds testen kann?

Wie erwähnt klappt das Mounten ja problemlos, wenn man das Blockdevice vom PVE direkt vom PBS mappt und mountet. Der Kernel sollte es "eigentlich" nicht sein, zumindest der NTFS-Treiber ist ja seit Jahren identisch.

Evtl. doch wieder ein Speicherproblem?
 
Bei meiner VM reden wir von einen Server 2016 Datacenter,
die VM-Disk ist ca. 2 Jahre alt... am Anfang hat der file restore auch noch funktioniert, da bereits mehrere Restores gefahren wurden...
Seit dem PVE 8 Upgrade allerdings nicht mehr

H: geht nicht,
G: geht
beide damals in derselben VM zur selben Zeit erstellt ...
Beide jetzt in derselben VM im selben Backup.
Code: 
C:\Windows\system32>fsutil fsinfo ntfsinfo h:
NTFS Volume Serial Number :        0xdef091e8f091c765
NTFS Version   :                   3.1
LFS Version    :                   2.0
Number Sectors :                   0x00000002fffbe7ff
Total Clusters :                   0x000000005fff7cff
Free Clusters  :                   0x000000000c893c54
Total Reserved :                   0x0000000000000400
Bytes Per Sector  :                512
Bytes Per Physical Sector :        512
Bytes Per Cluster :                4096
Bytes Per FileRecord Segment    :  1024
Clusters Per FileRecord Segment :  0
Mft Valid Data Length :            0x00000000f7f00000
Mft Start Lcn  :                   0x00000000000c0000
Mft2 Start Lcn :                   0x0000000000000002
Mft Zone Start :                   0x00000000586f3b40
Mft Zone End   :                   0x00000000586ff060
Max Device Trim Extent Count :     255
Max Device Trim Byte Count :       0x40000000
Max Volume Trim Extent Count :     62
Max Volume Trim Byte Count :       0x40000000
Resource Manager Identifier :     6EE6E157-9637-11ED-B85D-AA05C0D01B6E

C:\Windows\system32>fsutil fsinfo ntfsinfo g:
NTFS Volume Serial Number :        0x5af89e0df89de811
NTFS Version   :                   3.1
LFS Version    :                   2.0
Number Sectors :                   0x000000017ffbe7ff
Total Clusters :                   0x000000002fff7cff
Free Clusters  :                   0x0000000009af7e05
Total Reserved :                   0x0000000000000400
Bytes Per Sector  :                512
Bytes Per Physical Sector :        512
Bytes Per Cluster :                4096
Bytes Per FileRecord Segment    :  1024
Clusters Per FileRecord Segment :  0
Mft Valid Data Length :            0x000000008ab80000
Mft Start Lcn  :                   0x00000000000c0000
Mft2 Start Lcn :                   0x0000000000000002
Mft Zone Start :                   0x0000000016eaebc0
Mft Zone End   :                   0x0000000016eaf100
Max Device Trim Extent Count :     255
Max Device Trim Byte Count :       0x40000000
Max Volume Trim Extent Count :     62
Max Volume Trim Byte Count :       0x40000000
Resource Manager Identifier :     6EE6E160-9637-11ED-B85D-AA05C0D01B6E

Beide ca 80% voll,

ein Debugging können wir gerne mal vornehmen,
ist einfach ein Live System ;-)

Aktuell restore ist die 6TB um sie in einer Test VM einmal zu leeren (Inhalt) um sie dann dort zu sichern und zu testen ob derselbe Fehler ... und wenn ja, kann ich die Disk bereitstellen ;-)
 
Oder Dateinamen + Ordner mehr als 255 Zeichen? Alles was nicht ganz NTFS Konform ist, kann irgendwann Probleme machen.
 
sub2o5 said:
Wie erwähnt klappt das Mounten ja problemlos, wenn man das Blockdevice vom PVE direkt vom PBS mappt und mountet. Der Kernel sollte es "eigentlich" nicht sein, zumindest der NTFS-Treiber ist ja seit Jahren identisch.
Click to expand...

das stimmt so nicht - es gibt mehrere NTFS treiber fuer linux, zwei davon im kernel ;)

aber ja, ein file-restore erzeugt ein logfile wo einiges drin steht:

https://pve.proxmox.com/pve-docs/chapter-vzdump.html#_single_file_restore

es ist auch moeglich (bitte erst sicherstellen dass keine file-restore VM mehr fuer den betreffenden snapshot laufen) durch aufrufen von folgenden befehlen als root die VM im debug modus zu starten:

Code: 
# passwort oder token secret
 export PBS_PASSWORD='...';
# falls self-signed zertifikat im einsatz ist
export PBS_FINGERPRINT='...'
PBS_QEMU_DEBUG=1 proxmox-file-restore list vm/104/2023-01-16T13:24:58Z drive-scsi0.img.fidx --repository USER@REALM@HOST:DATASTORE

im letzten befehl entsprechend VMID, snapshot timestamp, drive und repository infos ersetzen. der letzte befehl sollte dann sowas in der art ausgeben:

Code: 
Connect to '/run/proxmox-backup/file-restore-serial-10.sock' for shell access

der angegebene pfad ist eine serielle konsole und laesst sich z.b. mit "minicom" benutzen:

Code: 
minicom -D unix:/run/proxmox-backup/file-restore-serial-10.sock

Strg-A+Z gibt die keybindings aus ;)

im backup modus ist auch der file-restore log etwas umfangreicher.
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom