RAID und Prtitionen

[mson]

weiss nicht ob ich hier richtig bin.

ich habe einen server in dem nur EINE 80gb platte war. konfiguriert als ein logical-drive.
nun habe ich den fehler(?) gemacht und das die configuration des ServeRaid (IBM)
gelöscht und ein neues logical drive mit genau der selben platte angelegt.

nun ist es so das linux nicht mehr startet. per boot-disk und fdisk sind auch keine(!!!)
partitionen mehr zu sehen.

ich kann mir nicht vorstellen das ich die partitionen irg wie gegrillt habe.
besteht da ein zusammenhang zwischen dem RAID-wechsel und den fehlenden
partitionen?.

ich will debian nicht die platte neu partitionieren lassen, denn auf der HDD sind
noch einige daten.

danke
mson

[rendegast]

Du könntest testdisk auf das raw-device (backup!) anwenden.
Sollte das Dateisystem noch vorhanden sein und bei einem block beginnen,
wäre das die einfachste Möglichkeit.
(1.Stufe zylinderweise Suche -> blockweise Suche)

Code: Alles auswählen

mount -o ro,offset=$((blocks*blocksize)) .... ....

Sollte der Dateisystemanfang überschrieben worden sein,
heißt es diesen händisch zu ermitteln, die (hoffentlich noch vorhandenen) superblocks zu bestimmen,
und einen mount-Befehl mit diesem offset zu konstruieren.

[mson]

okeee, erst mal danke.

ich habe RStudio in der demo-version drauf losgelassen und das findet annähernd 500.000 files und die Superblocks.

wie wäre also das weitere vorgehen ?

1. ein backup von der 80gb platte machen
- würde dazu ddrescue nehmen und auf eine 140gb platte schreiben.

2. weiter gehts mit der 140gb (backup) paltte
- kann fsck was helfen ?

wenn nicht.. kannst du mir das mit den superblocks und dem mount etwas genauer erklären?
oder hast du den link zu nem howto mit erklärungen ?

danke schon mal

[rendegast]

'1.' fängt ja gut an.

Bei '2.',
Im Fall eines Plattencrash versucht mensch zeuerst mal ein Image zu erstellen,
und arbeitet dann mit einer Kopie desselben um im weiteren Verlauf zumindest vor weiteren Plattenfehlern ungestört zu sein.
Hier jedoch ist die Platte selbst fehlerfrei und du kannst mit dem raw-device arbeiten.
(Damit werden zumindest mögliche Probleme durch geänderte Interpretation der Geometrie Image<->Platte vermieden.)

(Bei einem ext*-Dateisystem) Die Superblock-Kopien sind eine Art backup des eigentlichen Superblocks,
wobei der "Master"-Superblock den aktuellsten Zustand widerspiegelt.
Leider kann man wohl nicht so genau sagen, wo diese angelegt werden, das legt das mkfs-Tool beim Formatieren fest
(Versionsabhängigkeiten nicht ausgeschlossen).
Eine dummy-Formatierung würde das ausgeben, Bsp.:

Code: Alles auswählen

       -n     Causes mke2fs to not actually create a filesystem, but display what it  would  do  if  it
              were  to  create  a filesystem.  This can be used to determine the location of the backup
              superblocks for a particular filesystem, so long  as  the  mke2fs  parameters  that  were
              passed  when  the  filesystem was originally created are used again.  (With the -n option
              added, of course!)

("... so long as the mke2fs parameters that were passed when the filesystem was originally created are used again.")

Code: Alles auswählen

$ /sbin/mkfs.ext2 -n ext.img 
mke2fs 1.42.5 (29-Jul-2012)
ext.img ist kein spezielles Block-Gerät.
Trotzdem fortsetzen? (j,n) j
Dateisystem-Label=
OS-Typ: Linux
Blockgröße=4096 (log=2)
Fragmentgröße=4096 (log=2)
Stride=0 Blöcke, Stripebreite=0 Blöcke
65536 Inodes, 262144 Blöcke
13107 Blöcke (5.00%) reserviert für den Superuser
Erster Datenblock=0
Maximale Dateisystem-Blöcke=268435456
8 Blockgruppen
32768 Blöcke pro Gruppe, 32768 Fragmente pro Gruppe
8192 Inodes pro Gruppe
Superblock-Sicherungskopien gespeichert in den Blöcken: 
        32768, 98304, 163840, 229376

$ /sbin/mkfs.ext4 -n ext.img 
mke2fs 1.42.5 (29-Jul-2012)
ext.img ist kein spezielles Block-Gerät.
Trotzdem fortsetzen? (j,n) j
Dateisystem-Label=
OS-Typ: Linux
Blockgröße=4096 (log=2)
Fragmentgröße=4096 (log=2)
Stride=0 Blöcke, Stripebreite=0 Blöcke
65536 Inodes, 262144 Blöcke
13107 Blöcke (5.00%) reserviert für den Superuser
Erster Datenblock=0
Maximale Dateisystem-Blöcke=268435456
8 Blockgruppen
32768 Blöcke pro Gruppe, 32768 Fragmente pro Gruppe
8192 Inodes pro Gruppe
Superblock-Sicherungskopien gespeichert in den Blöcken: 
        32768, 98304, 163840, 229376

Die Lage ist relativ zum Dateisystemanfang.

Bei einem funktionierenden Dateisystem gibt es solche Info:

Code: Alles auswählen

# dumpe2fs /dev/sdd6 | grep superblock
dumpe2fs 1.42.5 (29-Jul-2012)
  Primary superblock at 0, Group descriptors at 1-1
  Backup superblock at 32768, Group descriptors at 32769-32769
  Backup superblock at 98304, Group descriptors at 98305-98305
  Backup superblock at 163840, Group descriptors at 163841-163841
  Backup superblock at 229376, Group descriptors at 229377-229377
  Backup superblock at 294912, Group descriptors at 294913-294913
  Backup superblock at 819200, Group descriptors at 819201-819201
  Backup superblock at 884736, Group descriptors at 884737-884737
  Backup superblock at 1605632, Group descriptors at 1605633-1605633