Virtuelle Festplatte (VDI) nach resize nicht mehr bootbar

[Potassium]

Servus,
nach einigen Jahren bin ich nun wieder da und suche die Hilfe der Community

Auf einem Ubuntu-Server läuft in einer VirtualBox ein Win2008 Server. Dessen Festplatte sollte gestern mittels

VBoxManage modifyhd Fluor.vdi --resize 2500000

von 1.5 auf 2.5 TiB erweitert werden. Seither weigert sich allerdings das System strikt von der Platte zu booten. GParted erkennt dort nur mehr unallocated space.
Mittels testdisk lassen sich 3 Partitionen erkennen wobei die aber alle nicht mehr taufrisch sein dürften.

Das ergibt beispielsweise die Sektion "Advanced-->Boot" von der entsprechenden Platten.

TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/nbd0 - 2621 GB / 2441 GiB - 5120000000 sectors
Partition Start End Size in sectors
1 * HPFS - NTFS 14335 3057399799 3057385465

Boot sector
Warning: number of heads/cylinder mismatches 255 (NTFS) != 1 (HD)
Warning: number of sectors per track mismatches 63 (NTFS) != 1 (HD)
Status: OK

Backup boot sector
Status: Bad

Sectors are not identical.

A valid NTFS Boot sector must be present in order to access
any data; even if the partition is not bootable.

Da stimmts irgendwo hinten und vorne nicht, aber ich seh mich nimma raus. Hat da jemand Erfahrung was ich da machen könnte um das System doch noch laufend zu bekommen?
Für die (klassischen) Fragen: Nein, vollständiges Backup gibt's nicht und platt machen und neu machen ist daher auch keine Option

[Don Manuel]

Ich glaube, das ist das erste Mal, dass ich im WCM von einer virtuellen Platte lese, die per network block device (/dev/nbd0) eingebunden ist .
Das ist wirklich eine kuriose Mischung absoluter Spezialisten-Technik und maximal dilettantischem Vorgehen. Denn wer seinen Server virtualisiert aber für den backups offenbar "klassische" Altertümer sind, der MUSS einmal einen Server verlieren, um eine wichtige Lernerfahrung zu machen. Da verschwende ich kein Hirnschmalz in mühsamste recovery, DAS wäre ebenso dilletantische Pädagogik

[Potassium]

Danke für die Blumen -_-
Natürlich gibt's ein Backup der Daten, jedoch nicht vom System, einfach weil dafür nicht genug Platz vorhanden war. Blöd im Nachhinein. Mittlerweile konnte ich die Partitionstabelle mittels gdisk ins GPT Format konvertieren, habe jedoch jetzt Probleme weil die Virtuelle Maschine nun mit EFI statt BIOS booten muss und das mag ned so richtig.
PS: Die Idee das VDI als nbd einzubinden ist einfach von diesem "Tutorial" http://bethesignal.org/blog/2011/01/...box-vdi-image/

[Don Manuel]

In einem analogen Tutorial über resizing wäre sicher das gestanden, was in den unzünftigen GUI-apps ohnedies immer zuerst aufpopt: backup before resizing!
Wobei ich persönlich noch einen ganz anderen Weg gehe: speed-installation. D.h. meine Server sind alle so exakt dokumentiert, dass sie in kürzester Zeit wieder neu aufgesetzt und online sind.
Beim resizing ist halt eine der Tücken, dass disks keine partitions sind und partitions keine filesystems. Mir scheint, Du hast verabsäumt diese Logik exakt einzuhalten und nach resizen des jeweilgen containers auch den content entsprechend anzupassen.

[Potassium]

Najo nach dem resizen des Containers konnte ich den Content nicht mehr entsprechend anpassen weil das leider die Partitionstabelle nicht mehr mitgemacht hat hrmpf. Da aber Virtualbox ein Verkleinern des Volumes (auch wenns nur die Max-Größe und nicht die tatsächliche Größe ist) nicht zulässt bin ich nun irgendwie in der Rue de Gack.

EFI und Windows Guest dürfte bei VirtualBox mal gar nicht funktionieren. D.h. das System kann ich sowieso abschreiben und werde mich bei dieser Gelegenheit mal ganz von Windows-Servern zurückziehen.
Mittlerweile bin ich soweit, dass mir ein auslesen der Partitionen reichen würde um da nur die nicht gesicherten Sachen rauszuziehen. Das Problem ist, dass er mich das FS nicht mounten lässt, weil er was von Fehlern schreibt:

user@gallium:~$ sudo mount -t ntfs /dev/nbd0p1 /media/p1/
[sudo] password for user:
ntfs_mst_post_read_fixup_warn: magic: 0x00000001 size: 1024 usa_ofs: 24 usa_count: 65535: Invalid argument
Record 0 has no FILE magic (0x1)
Failed to load $MFT: Input/output error
Failed to mount '/dev/nbd0p1': Input/output error
NTFS is either inconsistent, or there is a hardware fault, or it's a
SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows
then reboot into Windows twice. The usage of the /f parameter is very
important! If the device is a SoftRAID/FakeRAID then first activate
it and mount a different device under the /dev/mapper/ directory, (e.g.
/dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation
for more details.

PS: Womit dokumentierst du deine Server? Rein Plaintext oder benutzt du dazu irgendwelche Hilfs-SW?

[Don Manuel]

Ich habe mit "dokumentieren" einen vagen Begriff gewählt, weil es dazu viele Ansätze geben kann. Letztlich ist ein backup technisch auch eine Art Dokumentation
Nun, ich habe den Weg gewählt, install.wim-s von allen von mir verwendeten OS-Versionen vorrätig zu halten. Die sind mit updates, Treibern, diversen modifizierten reg-keys und fallweise auch mit einer kompletten SW-Installation/config versehen. Alles was da config-technisch nicht reingehört oder gar nicht reingeht ist dann eine plain-text checklist. Install.wim über pxe mit imagex auf HDD schreiben, bcdboot ausführen und einmalig ein bisschen längerer reboot to desktop ist für mich seit WinNT6.0 (Vista) der einzig akzeptable Weg, Windows zu installieren.
Im übrigen verwende ich für virtual-box vhd-disks, wie ich ja auch OmniBoot verbreite. (Welches übrigens in seinem pxe-server-modul auch einen nbd-Server enthält).

[Don Manuel]

Sorry, habe mich nicht konzentriert und die alte at-domain verlinkt. http://omniboot.org heißt es jetzt.