Recover Data From a dead hard drive using dd_rescue

Szerszám

Like dd, dd_rescue does copy data from one file or block device to another. dd_rescue is a tool to help you to save data from crashed partition. It tries to read and if it fails, it will go on with the next sectors where tools like dd will fail. If the copying process is interrupted by the user it is possible to continue at any position later. It can copy backwards.

Read Full article here.

--

Adatvisszaállítás sérült merevlemezről a dd_rescue segítségével

A dd_rescue egy olyan eszköz, amellyel lementheted az adataidat sérült partícióról. Megpróbálja olvasni az adatokat, ami ha nem sikerül, akkor ugrik a következő szektorra. Ha a másolási folyamat felhasználó által megszakításra kerül, akkor a későbbiekben bármely pozíciótól van lehetőség a folytatásra.

A teljes cikk itt.

( phanatic | 2006. 11. 28., k – 19:17 )

már megint kezdődik?
--
ubuntu linux member

Összesen AFAIK öt ilyen cikk volt a szavazás befejezése óta (hozzáteszem az olvasottságuk 1 000 felett volt, úgyhogy tekinthetjük őket akár népszerűnek is), úgyhogy a "minden második hír a debianadmin.com-ról lett belinkelve" állítást kicsit csúsztatásnak érzem, tekintve, hogy egy átlagos napon 10 cikk jelenik meg, a szavazás pedig szeptemberben volt. Miattam mehetnek a devnull-ba, de akkor kéretik itt jelezni, hogy ki nem tart a továbbiakban rájuk igényt.

--
trey @ gépház

jah, meg különben is... mark ma aszonta, hogy "MS have done some wonderful things for the world" ejnye-bejnye, eladjuk a lelkünket az ördögnek, már itt kopogtat az ajtón az ms/canonical megállapodás, és akkor aztán jajj lesz a fos(s) közösségnek :D
--
ubuntu linux member

Na jó. Szóval amikor valaki arra élvez, hogy neki az mc-je is SSE2-optimized (sic!), és hasonlók, akkor ezt muszáj. De megértem azokat, akik Gentoo-t használnak _komoly_ célra (vinnuival beszéltük meg IRL sörözés közben).
--
Gentoo motto: It's worth spending eight hours trying to make something load 20ns faster.

Skacok, a szemelyeskedesre senki nem kivancsi, es semmi koze a cikkhez. Az ilyet tartsatok meg magatoknak. Nezzetek meg, teljesen szetoffoltatok ezt a jo kis hirt, az ertelmes hozzaszolasokat meg sem lehet talalni. Gondolkodjatok el ezen, allitsuk meg a gabucinizaciot! :) Par eve meg sokkal kellemesebb hely volt a HUP...

Csatlakozom! Szerintem is hasznos volt.

Lehet, hogy egy debianos helyről van, de én (sok társamhoz hasonlóan) azt nem olvasom. Ez viszont mindenki számára hasznos hír volt, nem debian-specifikus.
(Ja, legalábbis az olyan kezdő lámereknek, mint én, akinek csak egy-két hírforrást van ereje követni ;-) Az üzenet közvetítésében részt vevő elektronok és pixelek meg újrahasznosíthatók, így nem okoz nagy kárt, ha egyesek két helyről is olvashatják :-) )

( ng | 2006. 11. 28., k – 20:09 )

Tök hasznos hír, gondolom a kürtösök a fejüket fognák meg nem javallanák lekaszálni a lemez adatait de kisebb értékű cuccosnál még jól jöhet.

Nekem pl. egy reiserfs particio pusztult el olyan kivalo modon, hogy nem lehetett mountolni, es nem talalt rajta superblockot. Mivel a superblock egy allitolag read erroros reszen volt, igy nem lehetett lementeni se
egyszeruen.

dd_rescue hipp-hopp leszedte, aztan az image-en fsck, es kesz, ott volt minden adatom.

dd_rescue jofele allat.

Mar csak tar-hoz kellene hasonlo, mert van egy serult tar fajlom, benne sok avi, es a tar megserult, vagymi.

A felesegem meg nem tudja megbocsatani, hogy a lanyunk szuletese.avi nem
visszaallithato. Meg persze en is orulnek neki.

Szar ugy, amikor az ember keszit backupot, es a backup megserul.

G

Akkor egy apró ötlet: tar 512 byte-os blokkokkal dolgozik. A file fejléce is 512 byte-os, ott van letárolva minden adata.

De a legegyszerubb modszer, hogy megkeresed a RIFF fejlécet a tar-ban, az elotti 512 byte a header. Ebben le van tárolva a file mérete. Ha sérült, akkor a köv. 512 byte-os fejlécig tart a file. A fejléc amúgy elég látványos felépítésű, szemre is felismerhető. Akkor van cumi, ha az avi header is sérült... de ez esetben ugyis kefélheted :)

Ha megvannak a file pozíciói, akkor onnan már néhány paranccsal (head + tail) kiszedhető a kép, es mplayerrel/mencoderrel kinyerhető az adat.

Persze mindez függ attól, hogy mennyire fosta össze magát a tarod.

---
pontscho / fresh!mindworkz

( apal v | 2006. 11. 28., k – 21:07 )

Erdekes... de miben kulonbozik egy sima 


dd if=/dev/hdXy of=/akarmi/part.xxfs bs=512 conv=sync,noerror

hivastol? Ugyertem ez itt pont azt csinalja, mint a dd_rescue a fenti leiras szerint (es ez nekem 20...40...80 gigas fizikailag serult diszkek eseten e fenti nagyon jol bevalt a gyakorlatban is).

A.

( deejayy | 2006. 11. 29., sze – 07:55 )

ez a program mit csinal a 'dma timeout retry: status=' üzenetekkel? :) van pár ilyen vincsim...

deejayy DOT hu

oké oké ;]
úgy gondoltam, hogy a vincsit felismeri a BIOS, látszik a /dev-ben is,
némelyiket fel is tudom mountolni, de amikor megpróbálok olvasni róla, akkor kis kerregés után kiírja, hogy 'dma timeout'.

a kérdés arra irányult, hogy az ilyen üzenetek megléte esetén is képes-e adatot kinyerni a vincsiről.

deejayy DOT hu

Jaja, ez bizony nem mechanikai/felületi hiba, hanem leginkább rossz/rosszul bekonfigolt ide vezérlő, rossz kábel lehet. Bár az is elképzelhető, hogy vinyó busz interfész elektronikája döglődik. A smart-ban a 199 UDMA CRC error count-ot érdemes megfigyelni.
Gyógymód szokott lenni, hogy a vinyót egyedül rakod masternek egy csatornára. Vannak bugzós ide vezérlők (Khm highpoint, khm), amik a slave eszközre is ráerőszakolják a master sebességét. Különösen vicces ez egy ATA133 master melletti ATA33-as slave-nél. :)
---
Keep on trolling

( budee | 2006. 11. 29., sze – 17:59 )

Ez a cikk most igen jol jott nekem, epp van egy badsector-os diszkem :)

koszi, bud