Názory k článku Záchrana dat ze starého RAID 0 vytvořeného pomocí fakeRAID

Ja bych to zbytecne nemergoval.. stacilo pouzit 2x losetup a pak dale jiz stejny postup jaky se pouziva k pristupu na fakeraid (tj. sestaveni pole v runtime) - skrze dmraid ,)

taky by to šlo, já dmraid ještě nepoužil a hlavně ze začátku jsem si myslel, že mám nt striped volume a udělal jsem vlastně na to ten skript, který jde použít i na fakeraid0

pro zajímavost jsem někde na netu našel i prográmek v javě, který dělá to stejné (teď se mi to nedaří najít)

Clanek dobry, ale proc v prvnim reseni pouzivas sync a proc rovnou 2x?

Vzdyt kdyby se to mohlo prohodit, tak se na bash nelze spolehnout. Pri spousteni s & za prikazem nebo pri paralelizaci bych prohodeni rozumel i kdyz sync by to nevyresil, ted tomu nerozumim.

tiez som to nepochopil. pokial tam nebude na konci & tak neni dovod aby sa poprehadzovali data

no já bych si tím úplně jist nebyl, dd ve výchozím stavu negarantuje že jsou data zapsány, když skončí

viz man dd: fdatasync - physically write output file data before finishing

To je jedno ci to zapise teraz alebo za minutu ked sa bude flusovat cache. Ale zapisu sa na to miesto, kde sa zapisat malo a nie hocikde.

Jako samozrejme nepocitame s tym ze niekto vytrhne kabel, ze :)

16. 12. 2019, 08:54 editováno autorem komentáře

teď jsem zkusil variantu 1 bez sync a výsledek je sice dobře, ale stejně tomu moc sám nevěřím :)

rychlostně je to pořád o kousek pod variantou 2 a varianta 3 je pořád nejrychlejší

ten sync na fyzicke zapsani ma smysl jen kdyz medium s vysledkem chces realne/fyzicky odpojit (a odnest si od pocitace)

ten sync dvakrát se dříve v dřevních dobách doporučoval, teď to už zřejmě není potřeba, ale ten druhý sync je časově prakticky zadarmo

https://serverfault.com/questions/219187/is-it-really-necessary-to-call-bin-sync-twice-before-an-unmanaged-power-off

Já si tedy také myslím, že data budou zapsána ve správném pořadí i bez sync. Sync by měl pouze zařídit zapsání cache fyzicky na disk. I při nesyncnutých datech bude pořadí správné a budete z disku číst i správná data. Akorát o ně můžete přijít, pokud odpojíte napájení.

Dobrý den, pochopil jsem jen velmi málo z toho o čem tady píšete. Mám ale velmi podobný problém. Mám 2 ks disků ze starého PC který pracoval pod Windows 7. Oba disky lehli skoro současně z mě neznámích důvodů. Bohužel se nemohu žádným běžným způsobem dostat k datům. Nejde mi ani tak o zálohy programů apod. Na discích jsem měl velké množství rodinných fotografií a videi. A ty mě velmi mrzí, že jsem o ně "přišel". Poptával jsem některé firmy, které se zabývají problematikou obnovy dat ale jejich nabídková cena mě přímo šokovala. jeden disk 250 GB a druhý 500 GB a nabídkové ceny se pohybovali od 200 000,- Kč!! No kde by na to obyčejný důchodce sebral? Našel by se někdo, kdo by mi mohl data za rozumnou cenu obnovit nebo alespoň vytáhnout fotky a filmy? Moc děkuji.

disky jsou citelne?
udelejte si jejich image a protlacte je prohledavacem obrazku, ktery dokaze v binarnich datech najit signatury znamych formatu.

Když pán píše, že je důchodce a že nerozuměl tomu, co je v článku, tak jak myslíte, že mu pomůže Vaše rada? :)

Já měl před cca půlrokem podobný problém. Před přechodem z Win7 na Linux se mi pokazil disk. Bohužel jsem udělal tu chybu, že jsem se jej prvně pokusil opravit přes CHKDSK ze záchranného režimu, což skočilo "zaseknutím se" v průběhu opravy a bylo to v háji. Disku se začala sekat hlavička, takže jsem jen musel každou chvíli rozebírat atd. atd. Pánovi doporučuji tedy rozhodně se o opravu nepokoušet sám a pokud mu zde nikdo nevyhoví, najít seriózní společnost, která mu to udělá. Ceny by měly být opravdu tak 10-20t max.

Pro příště také velmi doporučuji zálohovat! Nejlevnější (a nejspolehlivější cesta) jsou DVD 4,7 GB disky, kupujte kvalitní (Sony, Verbatim). Ty větší nekupovat. Vypalovat na nejnižší možnou rychlost, uchovávat ve skříňce (světlo snižuje životnost). Co se týče vypalovačky, nepořizovat slimky, nepoužívat ty notebookové apod. Opravdu kvalitní jsou ty velké (jednoduše řečeno, musí být vysoké přes 3 cm a vysouvají disk elektronicky, ne že se to jen vycvakne). Mají totiž kvalitnější techniku a žerou víc energie (a to je dobře...). Jo a taky dobré, když mají vlastní paměťový buffer (a to ty malé nikdy nemají). Ty potom totiž i dokážou pomocí různých soft. obnovit i jinak "nečitelná" data či otevřít jinak "nečitelné" disky. Mám na to doma jeden program, který nutí mechaniku číst poškozené clustery několikrát a opravu tak lze obnovit většinu dat. Mě takto funguje přes už cca 15 let (CD i DVD) - myslím tím to zálohování, opravovat data jsem takto musel minimálně (dejme tomu na max 10 discích z tak 500).

No, disk po mechanické havárii s obnovením dat stál 30 tisíc, záchrana dat začíná tak na 10 tisících. Těch 200 tisíc je nějak divně vysoká cena.
Pokud se disky točí a jsou čitelné, záleží na tom, jak jsou data poškozena. Aplikace tesdisk dokáže najít fotky i na disku, kterému chybí značná část systému souborů (typicky přepsaný začátek).
Těžko radit takto na dálku - ale, viz výše, je dobré provádět pokusy o záchranu na kopii dat. Což znamená, že pokud jste to nikdy nedělal, je lépe to někomu přenechat.
A poměrně drahé to bude už jen proto, že jsou to časově náročné operace.

Dobrý deň. Kontaktujte ma pomocou emailu pmd1980@mail.com

Napíšete taky článek, pokud se to podaří?

"Našel by se někdo, kdo by mi mohl data za rozumnou cenu obnovit nebo alespoň vytáhnout fotky a filmy? Moc děkuji."

Osoba dala dotaz ohľadne opravy HDD odpovedal som. Ak narážate na jeden "sajt", kde som robil dizajn a preklady. V tej dobe som mal na to čas ale žiaľbohu teraz už nie. Nevedel som, že na roote sa "takhle" nálepkuje a pritom aj jednookému musí byť jasné, že moj zdroj príjmu, nie je písanie;)

ja netusim na co pan "narazel" ale podle lajku spis myslim, ze by to jeho i ostatni zajimalo bez ohledu na to jakou nalepku kde mate a jestli to napisete zadarmo a nebo za penize :)

Ještě jednodušší bylo ty disky dát do PC s Windows.

Kdyby základní deska nepodporovala daný fakeraid, windowsy by to samy zvládly namontovat?

Nesmyslnost volání syncu po zápisu do souboru už byla rozebrána výše, ale já bych chtěl upozornit na jinou vlastnost dd (minimálně toho GNU), o které se moc neví: když nastavíte bs, tak to říká, jak velký bude buffer pro read(2), a count říká, kolik readů se provede. Ale vůbec nikdo negarantuje, že read dostane buffer naplněný! Jádro úplně v pohodě může vrátit třeba i jenom jeden bajt. To se může stát třeba při signálu nebo při čtení z pomalého zařízení. A vyřešit se to dá třeba pomocí iflag=fullblock.

Díky za tip.

Pro zrychlení dd používám iflag=direct
také čtení a zápis pouštím v samostatných procesech, což má smysl, pokud jsou disky na samostatných řadičích.

Pak to vypadá třeba:
dd if=/dev/sdc bs=8M iflag=direct | dd of=/dev/sdb bs=8M oflag=direct

Direct a fullblock se dají kombinovat?

Velikost bs dávám s ohledem na cache řadiče.
Zjistitelné třeba přes hdparm -i /dev/sdx hodnota BuffSize.
Ne každý disk se o ten údaj podělí.

Když se rychlost blíží parametrům max rychlosti čtení z disku tak fajn.
A ta se dá zjistit přes: hdparm -t /dev/sdx

A pro ty co to netuší: stav dd, tedy kolik už se zkopírovalo, se dá vypsat zasláním signálu USR1.

fullblock je zbytečný pokud dd nepoužíváš na odměřování přesného množství dat. Ty dva procesy jsou zajímavé, i když si myslím, že to pořeší cache a readahead v jádře.

teď nově není třeba kill -1 a je možné dát přímo dd parametr status=progress a ukazuje to sám

případně jde použít externí nástroj progress

Tak pv je na trubky. Mimochodem ještě existuje příkaz progress, který zobrazí aktuální progress již běžícího procesu, a funguje asi na 30 různých programů (cp, mv, gzip…). Funguje tak, že se koukne do /proc/pid/fd na symlinky a pak si z /proc/pid/fdin­fo/číslo přečte pozici v souboru. A to je současně návod jak to emulovat ručně pro programy, které v progressu explicitní podporu nemají (třeba ffmpeg, nebo něco co jste napsali sami).

(2) za názvem značí, že to je syscall. (3) by byla funkce z libc, (1) by byl uživatelský příkaz, (8) administrátorský příkaz (viz man man). Zde je to celkem bez kolize (resp. man read bez čísla na mém systému zobrazí nějakou funkci z Tcl), ale vyzkoušej si rozdíl mezi man 2 mount a man 8 mount.

To neví, ale když si tu manuálovou stránku otevřeš, tak je to v tomto formátu napsané úplně nahoře.

název(číslo) je standardní konvence pro man. Jestli chcete vědět od kdy, tak se dejte na počítačovou archeologii, zavede vás to nejspíš někam do 70. let.