laga trasig ext3

--EDIT----------------------------------------------

Ursäkta om det blev lite för detaljerat, men då andra även läser detta kan det vara bra med full förklaring.

Ser nu att det är md0 du försöker jobba med, det är alltså frågan om en raid.
Det verkar som om du har en ogiltig disk-setup i raiden.
Har du ändrat något bland hårddiskarna händer det att block-enheterna möbleras om och du måste på nytt peka om raiden till dem nya block-enheterna.

Kolla upp med mdadm om allt står rätt till.
Exempel:

# mdadm --misc --examine /dev/[s,h]d*

Jämför utdata från kommandot ovan med innehållet i filen /etc/mdadm.conf och se om du har rätt block-enheter signerade till md0

läs vidare om mdadm med man:

# man mdadm

--TIDE----------------------------------------------

Det bästa du kan göra är att börja om på ny kaka om du har en fullgod backup.
Har du data att rädda tror jag det bästa du kan göra är att först säkerhetskopiera hela partitionen i "rådata-form" till en annan disk med minst lika mycket utrymme som hela partitionen i fråga. Detta fixas enkelt med kommandot 'dd'

Angående dd: Växeln "if" står för "input file" och "of" för "output file"

Se först till att partitionen du skall säkerhetskopiera är monterad som "ro" (Read-Only)

I detta exempel:
sdz2 är partitonen som skall säkerhetskopieras.
/mnt/mounted-filesystem/ är punkten där du har tillräckligt med utrymme för backupen.

# mount -o remount,ro /dev/sdz2
# dd conv=notrunc,noerror if=/dev/sdz2 of=/mnt/mounted-filesystem/partition-backup-image.dd

Rad 1: Monterar om partitionen, om den är monterad, i read-only mode.
Rad 2: Kopierar rådata från partitionen sdz2, till fil med namnet "partition-backup-image.dd"

Fördelen med att säkerhetskopiera partitionen i "blindo" är att man sedan kan leka och testa med partitionen utan att riskera att data gårt förlorade ifall något går fel.
Skulle det gå fel är det bara att läsa tillbaka data med dd igen:

dd if=/mnt/mounted-filesystem/partition-backup-image.dd of=/dev/sdz2

Om dd -kommandot ger dig läsfel (io-error) har du en trasig hårddisk, byt ut hårddisken A.S.A.P - Troligen är det försent att rädda data, om det gått så långt att dd inte kan läsa partitionen.

Nästa steg efter "säkerhetskopieringen" är att försöka reparera filsystemet.
Du har redan försökt fsck, men prova dett i alla fall.
Återigen är partition sdz2 bara ett exempel, korrigera till den partition du skall försöka reparera.

# mount -o remount,ro /dev/sdz2
# fsck.ext3 -fvp /dev/sdz2

Rad 1: Monterar om partitionen, om den är monterad, i read-only mode.
Rad 2: Utan frågor, helt automatiskt, så kommer fsck utföra en analys och eventuell reparation av partition sdz2

Kom ihåg att fsck, även med -f, kan bara reparera partitioner som inte är monterade i skrivbart läge, därav remount -växeln i mount -kommandot.

Lyckas du inte trots detta, är det bästa att ta bort partitionen, skapa en ny partition och sedan fomrattera partitionen till valfritt filsystem.
Varför jag rekommenderar att ta bort partitionen och skapa den på nytt är för att skapa om en ny MBR utifall felet beror på en överlappande/ogiltig partition.

Jodå!

Block-enhet: Lagringsmedia eller minne. Tilldelas en nod i /dev -trädet.
Exempel på block-enheter:

┌SATA-Hårddisk, kanal 1: /dev/sda
│  └ Partition 1: /dev/sda1
│
├ SATA-Hårddisk, kanal 2: /dev/sdb
│  ├ Partition 1: /dev/sdb1
│  └ Partition 2: /dev/sdb2
│
├ SATA-Hårddisk, kanal 3: /dev/sdc
│  ├ Partition 1: /dev/sdc1
│
└ USB-Minne: /dev/sdd
.  └ Partition 1: /dev/sdd1

En raid består av flera block-enheter.
Till exempel genom att kombinera /dev/sda1 och /dev/sdc1 bildar dessa två block-enheter en ny blockenhet med deras kombinerade lagringskapacitet.

Exempel:

┌SATA-Hårddisk, kanal 1: /dev/sda
│  └ Partition 1: /dev/sda1 (raid-flaggad)
│
├ SATA-Hårddisk, kanal 2: /dev/sdb
│  ├ Partition 1: /dev/sdb1
│  └ Partition 2: /dev/sdb2
│
├ SATA-Hårddisk, kanal 3: /dev/sdc
│  └ Partition 1: /dev/sdc1 (raid-flaggad)
│
├ USB-Minne: /dev/sdd
│  └ Partition 1: /dev/sdd1
│
├ Raid: /dev/md
.   └ Raid0 blockenhet 1: ( /dev/sda1 + /dev/sdc1 ): /dev/md/0

Tilldelning av nodnamn såsom sda, sdb och så vidare är tilldelad i dynamisk ordning som enheterna detekteras.

Skulle vi ta bort hårddisken på SATA kanal 2 kommer nod-tilldelningen bli annorlunda:

┌SATA-Hårddisk, kanal 1: /dev/sda
│  └ Partition 1: /dev/sda1 (raid-flaggad)
│
├ SATA-Hårddisk, kanal 3: /dev/sdb
│  └ Partition 1: /dev/sdb1 (raid-flaggad)
│
├ USB-Minne: /dev/sdc
│  └ Partition 1: /dev/sdc1
│
├ Raid: /dev/md
.   └ Raid0 blockenhet 1: ( /dev/sda1 + /dev/sdc1 ): /dev/md/0

I sista exemplet ser du nu att block-enheten /dev/md/0 är "trasig" då /dev/sdc flyttades till den lediga noden /dev/sdb, och nu är raiden inte komplett längre.

Försöker man reparera raiden i det här skicket kommer data på USB-minnet att gå förlorade då raid-konfigurationen fortfarande använder den noden som nu tas upp av USB-minnet istället.
Följd till detta är att filsystemet på /dev/md/0 inte är helt längre, då halva filsystemet flyttades till en annan nod.

I det här fallet måste man tala om för raid-konfigurationen att den skall använda /dev/sdb1 istället för /dev/sdc1.
Detta görs i filen /dev/mdadm.conf

När omkonfigureringen har gjorts kommer dem korrekta data att återigen finnas.

Att tänka på:
Försöker man ändra innehållet i en okomplett raid-konfiguration, kan data korrupteras.
fsck ser det som filsystem-fel när halva raiden har flytttats till annan nod.