Nas-ban szetesett raid javitasa

Merevlemezek, vezérlők

Sziasztok!

 

Volt egy Seagete NAS csoda amiben valszeg aramszunet hatasara a raid5 szetesett. (4 db 4Tb lemez). Gondoltam majd linux alatt vhogy osszeutjuk.

Jol sejtem, hogy ha fdisk a 4 lemezbol ketton nem lat particiokat akkor az kuka?

Disk /dev/sdb: 3,65 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: ST4000DM000-1F21
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 4CAE0830-E4EC-4719-B3B7-44D23E7FEC29

Disk /dev/sdc: 3,65 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: ST4000DM000-1F21
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 8566909A-0325-4AAA-AE7B-A8349BD7A597

Eszköz       Start       Vége  Szektorok   Size Típus
/dev/sdc1       41       1953       1913 956,5K Microsoft basic data
/dev/sdc2     2048    1953791    1951744   953M Microsoft basic data
/dev/sdc3  1953792    3905535    1951744   953M Microsoft basic data
/dev/sdc4  3905536    3926015      20480    10M Microsoft basic data
/dev/sdc5  3926016    5879807    1953792   954M Microsoft basic data
/dev/sdc6  5879808    5900287      20480    10M Microsoft basic data
/dev/sdc7  5900288    5922815      22528    11M Microsoft basic data
/dev/sdc8  5922816    6504447     581632   284M Microsoft basic data
/dev/sdc9  6504448    8503295    1998848   976M Microsoft basic data
/dev/sdc10 8503296 7814035254 7805531959   3,6T Microsoft basic data

Partition 1 does not start on physical sector boundary.

Disk /dev/sdd: 3,65 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: ST4000DM000-1F21
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 7FE0C213-2C6A-4E32-83A0-A1F47D448A23

Disk /dev/sde: 3,65 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: ST4000DM000-1F21
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 0C492D14-615B-454F-B02D-43D53EAAE44B

Eszköz       Start       Vége  Szektorok   Size Típus
/dev/sde1       41       1953       1913 956,5K Microsoft basic data
/dev/sde2     2048    1953791    1951744   953M Microsoft basic data
/dev/sde3  1953792    3905535    1951744   953M Microsoft basic data
/dev/sde4  3905536    3926015      20480    10M Microsoft basic data
/dev/sde5  3926016    5879807    1953792   954M Microsoft basic data
/dev/sde6  5879808    5900287      20480    10M Microsoft basic data
/dev/sde7  5900288    5922815      22528    11M Microsoft basic data
/dev/sde8  5922816    6504447     581632   284M Microsoft basic data
/dev/sde9  6504448    8503295    1998848   976M Microsoft basic data
/dev/sde10 8503296 7814035254 7805531959   3,6T Microsoft basic data

  • 860 megtekintés

( SzBlackY | 2021. 03. 18., cs – 00:29 )

0) Ha van elfekvőben elég tárhelyed, akkor nulladik lépésnek csinálj image-t az összes diskről, és azon dolgozz (ddrescue ilyenkor a barátod).
1) A kettő "elesett" lemezre nézz rá gparted-dal, ha a primary gpt hibás, de jónak látja a secondary-t, az kedvesen mondja (párszor már találkoztam ezzel, hogy rosszkor kapcsolt le gép, GPT használhatatlan, gparted elindít, nyávog, hogy ő a backupot akarja használni, aztán egy tetszőleges partíción tetszőleges flaget átütsz majd vissza, és akkor javítja az elsődlegest)
2) Ha a másik két lemezen a backup GPT sem jó, ugyanezekkel a start/end szektorokkal még mindig lehet játszani. Jó lenne tudni, hogy milyen Seagate csoda volt (típusszám / esetleg firmware verzió szám), abból kiderülne, hogy milyen RAID implementációt használhat, azzal már előrébb vagyunk (pl. Synology RAID1-es tömbjéről már mentettem adatokat egy rosszul sikerült diszk csere után, de ahhoz is tudni kellett, hogy mi merre hány lépés).

Egyelőre ne add fel, esélyesen menthető, de ne nyúlj az eredeti lemezekhez!

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

( asm v | 2021. 03. 18., cs – 00:33 )

Miutan elbucsuztatok az adatoktol, esetleg azt ki lehetne probalni, hogy a particios tablat (csak azt) atmasolni egy jo diszkrol. Latszik, hogy a ket jo diszknek teljesen azonos a particio meretei, nyilvan a masik kettonek is annak kell lennie.

Es az igy letrejott negy /dev/sdx10-en probalni osszerakni a RAID5-ot.

Es az igy letrejott negy /dev/sdx10-en probalni osszerakni a RAID5-ot.

Nem biztos, hogy olyan forrón eszik a kását, lehet, hogy Windows alapú izé (https://www.seagate.com/gb/en/support/kb/nas-os-installer-downloads-005… <- Business Storage akármi);  a "Microsoft basic data" is erre utal (a 4-bay firmware valami Linux, az ránézésre LVM over md-raidet használhat). Először tényleg az eszköz típusát kellene tudni.

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Akár lehet is, de szvsz. a sötétben tippelgetés helyett érdemes lenne megvárni az OP-ot, hogy milyen eszközről beszélünk :) [és minél több példányban minél vastagabban kiírni, hogy ha egy mód van rá, ne nyúljon az eredeti diskekhez csak read-only módban]

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

ne nyúljon az eredeti diskekhez csak read-only módban]

Mi a legrosszabb, ami történhet? Nem sikerül a raid-et visszaállítani, újra létre kell hozni az egészet üresen és visszatölteni rá a mentést.

OK, elmegy vele jó pár óra, de azért nem a világ vége.

Az összeborult lemezekről image mentést készíteni várhatóan szintén több órás feladat. Mivel az egész RAID megjavításnak maximum az időnyereség lehet a célja, az image készítés pont ezt az előnyt csökkenti.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Hát, mivel a RAID egyetlen célja az, hogy egy diszk kiesése esetén ne essen ki a szolgáltatás, de jól tudottan nem ad megoldást adatvesztés ellen, így igen...

Ha nem volt mentés, akkor remélem majd tanul az esetből és legközelebb lesz.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Ugyanezt akartam írni. Mentésből visszatölteni a dolgokat.

 

Amúgy az ilyen hókuszpókuszolással eltöltött jó eséllyel sikertelen órákat/napokat ki lehet számlázni? Én hozzá sem fognék, kürt, ha nagyon kell az adat, ha annyira mégse, akkor engem sem fizetnének ki gondolom.

Eloszor is nem a sajatom, cimbisegbol probalok segiteni egy baratomon. Nyilvan mindenki tudja hogy kellet volna, most, mar O is.

Ennek ellenere azt latom, hogy KKV-nal nagyon keves helyen mukodik jol. Vagy mert nem tudja hogy kellene, vagy tudja, de nincs ra kerete. Ha fontos az adat ment, ha nem meg szivas van. Kar ezen rugozni, egyszer az eletben mindenki beleszalad...

vati

"Nincs rá kerete"... Ne vicceljünk, nem tud venni 1-2 nagyobb külső HDD-t és akár hetente 1x kézzel rámásolni (nem felülírva) a mindenséget, majd lecsatlakoztatni, hogy legalább offline legyen. Felénk is rendszeresen jönnek ezzel a "dehát drága", és amikor felvillantjuk, hogy ez nem drága, hanem ennyibe kerül az üzletmenet folytonosság, a biztonsági mentés ÉS az erősen ajánlott offline/offsite mentés. Azt számolgassák ki szorgosan, hogy mire jutnak, hogy ha _mindenük_ elfüstöl (lásd most már a szomorú OVH esetet) diszkhibák, áramszünet (ingadozás, UPS hiba..) okán.

Az első lépés, hogy mondjuk 1-2 hétig nemnagyon tudnak működni, mert szerencséses valahogy valaki horror pénzen visszahozta az adatok legalább egy jelentős részét. A második lépés, hogy ha mondjuk teljesen könnyes búcsút vettek az adatoktól akkor mi van velük? Leverik az ájtin, mert ugye mindenért az ájti a hibás és ménem szólt..., hát szólt ugye...

tud venni 1-2 nagyobb külső HDD-t és akár hetente 1x kézzel rámásolni

Évekkel ezelőtt segítettem egy cimborának, pont ezt csinálta. Nem mondom, hogy kifinomult és elegáns megoldás de működik.

Aztán ezt megtartva összeraktam neki egy másikat, ami egyszerűen cron-ból a fájl szerverről mindent átmásolt a főnök desktop gépére rsync-kel úgy, hogy ha a fájl szerver megsemmisült, akkor a főnök egyszerűen rebootolja a saját gépét, a boot menüből kiválasztja a második opciót és a gépe hipp-hopp átvette a fájl szerver szerepét, az alkalmazottak folytathatják a munkát.

0 hardver költsége volt ennek a megoldásnak, és innentől két mentésük volt, (persze nem várom, hogy valaki nem IT-s saját maga kitalálja és összerakja ezt).

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Ha fontos az adat ment, ha nem ...

Ez rendben is van. A fontos adatról van mentés, a nem fontos adat meg nem volt fontos, nem baj, ha elveszett.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Remélem, amikor az autópályán látsz egy tömegkarambolt és végignézed, ahogy a mentősök próbálják visszatuszkolni a félhalottba a beleit, akkor is állsz karba tett kézzel és mondogatod az összes sérültnek, hogy "hát igen, kellett volna a biztonsági öv...".

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Ha direktben igyekszik helyreállítani, akkor esélyes, hogy egyetlen dobása van. Ha a másolatokon, akkor kb. csak az szab határt, hogy mennyi ideje van rá.

Persze jogos a meglátás hogy sok idő és pláne sok hely, de ez inkább elvi kérdés. Ha meg nincs hely és/vagy mód másolatokat csinálni, akkor az is marad.

( debtamas88 | 2021. 03. 18., cs – 00:51 )

Szerkesztve: 2021. 03. 18., cs – 00:54

Szia!

Tudtommal az fdisk az nem kezel GPT diszket, amit kiír, az nem biztos hogy a valóság.

Nézd meg ezzel: parted
$> parted -s --list

Tudtommal ezek a NAS rendszerek linux-software-raid ( mdadm ) használnak, erre raknak egy LVM-et és azon hozzák létre az EXT3/EXT4/BTRFS partíciót amin dolgoznak - vagy raw-ban a linux-software-raid - formázzák meg particónak ( EXT3/EXT4/BTRFS ).

$> mdadm -ay
$> vgscan
$> lvscan
$> pvscan

Ezek után nézd meg, hogy a parted miket lát.
$> parted -s --list

( vati | 2021. 03. 18., cs – 08:01 )

Koszonom az eddigi reakciokat. A Nas tipusa:

seagate business Storage 4-bay nas. Mode: SRN04D

Ahogy nezem a 10. particio elotti particiok Raid1-ben voltak (system) ahogy Synonal is, de ennek ellenere a rendszer nem all fel. 

vati

( vati | 2021. 03. 18., cs – 08:30 )

parted ez mondja:

Típus: ATA ST4000DM000-1F21 (scsi)
/dev/sdb lemez: 4001GB
Szektorméret (logikai/fizikai): 512B/4096B
Partíciós tábla: gpt
Lemezjelzők:

Szám  Kezdet  Vég  Méret  Fájlrendszer  Név  Jelzők

Típus: ATA ST4000DM000-1F21 (scsi)
/dev/sdc lemez: 4001GB
Szektorméret (logikai/fizikai): 512B/4096B
Partíciós tábla: gpt
Lemezjelzők:

Szám  Kezdet  Vég     Méret   Fájlrendszer  Név      Jelzők
 1    21,0kB  1000kB  979kB                 CLAIM    msftdata
 2    1049kB  1000MB  999MB                 RFS1     msftdata
 3    1000MB  2000MB  999MB                 RFS2     msftdata
 4    2000MB  2010MB  10,5MB                CONF     msftdata
 5    2010MB  3010MB  1000MB                SWAP     msftdata
 6    3010MB  3021MB  10,5MB                KERN1    msftdata
 7    3021MB  3032MB  11,5MB                KERN2    msftdata
 8    3032MB  3330MB  298MB                 CRFS     msftdata
 9    3330MB  4354MB  1023MB                FWUPGR   msftdata
10    4354MB  4001GB  3996GB                primary  msftdata

Típus: ATA ST4000DM000-1F21 (scsi)
/dev/sdd lemez: 4001GB
Szektorméret (logikai/fizikai): 512B/4096B
Partíciós tábla: gpt
Lemezjelzők:

Szám  Kezdet  Vég  Méret  Fájlrendszer  Név  Jelzők

Típus: ATA ST4000DM000-1F21 (scsi)
/dev/sde lemez: 4001GB
Szektorméret (logikai/fizikai): 512B/4096B
Partíciós tábla: gpt
Lemezjelzők:

Szám  Kezdet  Vég     Méret   Fájlrendszer  Név      Jelzők
 1    21,0kB  1000kB  979kB                 CLAIM    msftdata
 2    1049kB  1000MB  999MB                 RFS1     msftdata
 3    1000MB  2000MB  999MB                 RFS2     msftdata
 4    2000MB  2010MB  10,5MB                CONF     msftdata
 5    2010MB  3010MB  1000MB                SWAP     msftdata
 6    3010MB  3021MB  10,5MB                KERN1    msftdata
 7    3021MB  3032MB  11,5MB                KERN2    msftdata
 8    3032MB  3330MB  298MB                 CRFS     msftdata
 9    3330MB  4354MB  1023MB                FWUPGR   msftdata
10    4354MB  4001GB  3996GB                primary  msftdata

vati

( SzBlackY | 2021. 03. 18., cs – 08:39 )

Szerkesztve: 2021. 03. 18., cs – 08:43

Gondolom ezen már túl vagy, de pakold át a diskeket egy rendes gépbe.
Tölts le egy System Rescue CD-t és bootold be (adatmentéskor kevéssé szerencsés, ha a mindenféle nagyon okos DE pl. automatikusasn fel akarna csatolni dolgokat)
Mindegyik partícióra mondj egy mdadm --examine /dev/sdXY -t, és dobd fel a kimenetét pl. pastebinre.
(aztán egyelőre hagyd futni a gépet, hogy nehogy újra számozza az eszközöket)

Szerk.: ill. egy sfdisk -d /dev/sdc és sfdisk -d /dev/sde kimenet is menjen a pastebinre, ha a SysRescCD alatt is ez a két eszköz, amin látszódnak a partíciók.

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Ez az a pont, ahonnan jobb lenne másolatokon dolgozni... egyelőre ne nyúljunk a diskekhez, read-only loop device :)

losetup --find --read-only --offset=4353687552 /dev/sdd
mdadm --examine /dev/loop0

Aztán nézd meg, hogy megtalálta-e a metaadatokat. Ha igen, akkor ugyanezt a másik három diskre is (persze mindig a legutolsó loop device-ot examine-olva). Amikor meg van a négy loop device-od, akkor egy mdadm --assemble /dev/mdnagy /dev/loop{0,1,2,3,4} --readonly

Szerk.: offset javítva, nem sector, hanem byte offset kell
Szerk 2.: mdadm is kapott egy readonly -t, bár az alatta levő device-ok is azok, de legyen ott ott is

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

( vati | 2021. 03. 18., cs – 10:04 )

Szerkesztve: 2021. 03. 18., cs – 10:07

Koszonom, megnezem.

Csak egy gondolat: ez egy 4 lemezes raid5 volt ami kibir 1 lemez elvesztest. Ezen a vonalon nem tudunk elindulni, hogy csak az egyik “rossz” lemez particios tablajat pofozzuk ki, es ugy allitjuk ossze a tombot?

(kozben keritek lemezeket, most mar tenyleg elkezdem dd-zni)

vati

Ha van róluk másolat, akár lehet is :) Elvileg nem szabadna hülyeséget csinálnia, de kb. a nulladik lépésben frissíteni fogja az md metaadatot (ha más nem, az update time-ot), ha meg bármi miatt hülyeséget ír a metaadatokba, akkor már azt is javítanunk kell.

(igen, feleslegesen óvatos vagyok, de tényleg szerencsésebb egy másolaton read-only módban dolgozni, mint egy rosszul kiadott parancs miatt végleg búcsúzni az adatoktól)

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Na az a vicces, hogy ma mikor elinditottam a gepet akkor valtozott az fdisk lista. Most azon is lat particiot amin eddig nem, cserebe a masikon nem.

Disk /dev/sdb: 3,65 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: ST4000DM000-1F21
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 8566909A-0325-4AAA-AE7B-A8349BD7A597

Eszköz       Start       Vége  Szektorok   Size Típus
/dev/sdb1       41       1953       1913 956,5K Microsoft basic data
/dev/sdb2     2048    1953791    1951744   953M Microsoft basic data
/dev/sdb3  1953792    3905535    1951744   953M Microsoft basic data
/dev/sdb4  3905536    3926015      20480    10M Microsoft basic data
/dev/sdb5  3926016    5879807    1953792   954M Microsoft basic data
/dev/sdb6  5879808    5900287      20480    10M Microsoft basic data
/dev/sdb7  5900288    5922815      22528    11M Microsoft basic data
/dev/sdb8  5922816    6504447     581632   284M Microsoft basic data
/dev/sdb9  6504448    8503295    1998848   976M Microsoft basic data
/dev/sdb10 8503296 7814035254 7805531959   3,6T Microsoft basic data

Partition 1 does not start on physical sector boundary.

Disk /dev/sdc: 3,65 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: ST4000DM000-1F21
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 4CAE0830-E4EC-4719-B3B7-44D23E7FEC29

Disk /dev/sdd: 3,65 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: ST4000DM000-1F21
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 7FE0C213-2C6A-4E32-83A0-A1F47D448A23

Disk /dev/sde: 3,65 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: ST4000DM000-1F21
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 0C492D14-615B-454F-B02D-43D53EAAE44B

Eszköz       Start       Vége  Szektorok   Size Típus
/dev/sde1       41       1953       1913 956,5K Microsoft basic data
/dev/sde2     2048    1953791    1951744   953M Microsoft basic data
/dev/sde3  1953792    3905535    1951744   953M Microsoft basic data
/dev/sde4  3905536    3926015      20480    10M Microsoft basic data
/dev/sde5  3926016    5879807    1953792   954M Microsoft basic data
/dev/sde6  5879808    5900287      20480    10M Microsoft basic data
/dev/sde7  5900288    5922815      22528    11M Microsoft basic data
/dev/sde8  5922816    6504447     581632   284M Microsoft basic data
/dev/sde9  6504448    8503295    1998848   976M Microsoft basic data
/dev/sde10 8503296 7814035254 7805531959   3,6T Microsoft basic data

Partition 1 does not start on physical sector boundary.

vati

Ez csak annyi, hogy más sorrendben találkozott velük a kernel és máshogy számozta be őket (ha megnézed, a GPT-beli disk identifierek ugyanazok, mint amit az sfdisk paste-ben is írtál, ami most az sdb az reggel az sdc volt, az sdd pedig az sde)

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

( SzBlackY | 2021. 04. 01., cs – 21:01 )

Rövid follow-up egy majd részletesebb leírás előtt: sikerült az adatok kinyerése, bár kicsit bonyolultabban, mint terveztük.

A saját javaslatom ellenére (okos ember más hibájából tanul, a hülye a sajátjából sem, én máséból is tanulok, bort prédikálok, aztán 10.000 IQ lépéssel vizet iszom és nem foglalkozom vele :) ) végül anélkül áltunk neki, hogy lett volna mindegyik diskről másolat, úgyhogy a read-onlyra tett lemez-szintű block device-okba "random offseten" belemutattunk loop device-al és erre húztunk sparse fájlokra mutató loop device overlayt (hogy ha valami rosszul sikerül és akar írni a lemezre, az se oda menjen, az a néhány szektor, amit szándékosan írunk, meg végképp). Sajnos a négyből két diszken a superblockk nagyjából nem létező volt (az első szektora végig konstans nulla, az utána levő paddig meg egyéb szemét ott volt), úgyhogy újra kellett csinálni a tömböt. Szerencsére a le-nem-írom-mégegyszer-mennyi-block-device-al-szórakoztunk eszközökön építettük újra, mert a NAS-ban használt régi kernel + mdadm óta egy-két default érték változott és csak többedik kísérletre sikerült kisakkozni az összes paramétert helyesen (addigra már egyébként "offline" teszteltük a partíciók első 5 megájából készült image-el, a hexdumpokat olvasgatva tudtuk, hogy lvm van rajta, tudtuk, hogy ha meg vannak a jó paraméterek, akkor felismerhető lesz a pv/vg/lv - meglettek).

A pv/vg/lv után nagy boldogan jött a mount -o ro /... /..., aztán az első körben kicsit (ugyanez a hiba, ha lehagyod az ro-t egy read-only device-nál), később inkább elkeserítő "superblock could not be read". Utólag van néhány tippem, hogy mi lehetett gond (és mindegyikre ellenérvem, hogy miért nem lehetne), de nem próbáltuk végig (ahhoz engedni kellett volna, hogy írjon a "lemezekre"), szerencsére a testdisk teljesen korrektül (még ha marha lassan is és mutatva néhány már törölt mappa bejegyzését is) beolvasta a mappaszerkezetet és helyesen ki tudta menteni a fájlokat.

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)