Fórum Root.cz
Hlavní témata => Hardware => Téma založeno: Kyblík 28. 03. 2015, 12:31:18
-
Dobrý den. Švagr vyváděl něco se svým diskem My Book Live a povedlo se mu smazat značnou část souborů, včetně rodinných archivů. Samozřejmě body obnovy nemá žádné. Napadlo mě, aby to donesl ke mě, zkusit to píchnout na můj NAS server se Sambou co mám na debianu, ale tady končím i já. Předně nevím, jak postupovat.
root@debian:/# sfdisk -l
VAROVÁNÍ: Na „/dev/sdb“ nalezena GPT (GUID tabulka rozdělení disku)! Nástroj sfdisk nepodporuje GPT. Použijte GNU Parted.
Disk /dev/sdb: cylindrů: 243201, hlav: 255, sektorů/stopu: 63
Jednotky = cylindry po 8225280 bajtech, bloky po 1024 bajtech, počítáno od 0
Zařízení Boot Začátek Konec Cyldrů Bloků Id Systém
/dev/sdb1 0+ 243201- 243202- 1953514583+ ee GPT
začátek: (c,h,s) předpoklad (0,0,2) nalezeno (0,0,1)
/dev/sdb2 0 - 0 0 0 Prázdný prostor
/dev/sdb3 0 - 0 0 0 Prázdný prostor
/dev/sdb4 0 - 0 0 0 Prázdný prostor
-
Pokud si těch dat ceníte, tak to okamžitě odpojte a předejte nějaké firmě, co ví co dělat...
-
Co znamená že "smazal"? Jestli prostě smazal soubory z FS, tak photorec.
-
Smazal jako smazal, zůstali tam adresáře, v některých soubory také, ale některé jsou prázdné, sám neví, co dělal a já už tuplem nemám představu, opilej nebyl.
-
Disk vykazuje objem dat jako předtím, zdá se mi, jakoby smazal jenom informace o souborech.
-
Pokud si nejsi jistý co s tím, tak záleží na tom, jak moc si ceníte těch dat. Pokud málo, můžeš se začít snažit. Pokud víc, doporučuji odborníky. Třeba někoho, kdo ví co s tím, nebo firma.
-
Pokud si těch dat ceníte, tak to okamžitě odpojte a předejte nějaké firmě, co ví co dělat...
Pokud si nejsi jistý co s tím, tak záleží na tom, jak moc si ceníte těch dat. Pokud málo, můžeš se začít snažit. Pokud víc, doporučuji odborníky. Třeba někoho, kdo ví co s tím, nebo firma.
Nesmysl, kdyz si to prvni vyzalohuje a az potom s tim bude neco delat tak nic pokazit nemuze.
Pokud je tam neco jineho nez ntfs/fat32 tak uz zminovany photorec, jinak mam dobrou zkusenost s getdataback, ale pocital bych s tim ze uz se vse zachranit nepodari.
-
Tim vyzalohovanim jsem mel samozrejme namysli bitovou kopii toho disku, ne vyzalohovani tech zbyvajich souboru. :P
-
Disk vykazuje objem dat jako předtím
To je divné, když pustíš du, tak to ukazuje jinak než kolik je used? Hledej rozdíly.
-
Jeste bych se zkusil pripadne podivat do lost+found, na nekterych fs se tam da obcas neco najit kdyz to nejak divne crashne. :P
-
Pokud po smazání nevidíš úbytek místa, tak je tam aktivní time machine, čili jsou snapshoty fs a pomocí TM by se to mohlo dát obnovit.
-
Toz vzhledem k tomu, ze tazatel je brouk Sacek a ani nenapsal, co tam je nebo co tam puvodne bylo za FS a dal sem akorat jakysi vypis z programu, ktery nepodporuje GPT, tak muzeme hypotetizovat do aleluja. Nakonec se mozna jedna o zasah mimozemstanu nebo NSA.
-
Vzhledem ke gpt tipuji na widle a ntfs, takze jina masina s widlemi a recuva. Recuvou jsem mnohokrat obnovil giga vzacnych dat.
-
A to jako proc? GPT muze byt s klidem z Macu. Systemove disky v Macu uz delsi dobu snad ani jinak nejsou.
-
No mas asi recht, hdd z maca jsem mel v ruce naposledy u stareho crt imaca:-) Pokud ale jsou data smazana v hfs, tak nevim, jestli pujdou nejak obnovit.
-
@Fantomas: Photorec udajne chrochta i na HFS+.
-
kdyz zustalo obsazene misto stejne... neni to v kosi ? ;)
jinak v ramci bezpecnosti, udelat tu bitovou kopii jak radi aaa (pomoci dd), pak udelat kopii te bitove kopie a na tom primo laborovat, ne na tom hardisku
-
Ak je to nejaka katastrofalna krabicka od Western Digital, najskor tam bezi male GNU/Linuxove distro a teda cely recovery process ma skor zmysel cez SSH priamo z toho zariadenia.
Cize najskor cez dd odalohovat, potom riesit recovery priamo cez nabootovany NAS cez SSH naprikjlad pomocou photorecu. Bolo by vsak dobre vediet co to pouziva za system... LVM? mdraid? Ako je to cele zostavene... etc. Potom by nemal byt recovey extra problem.
-
Tak to bych vubec nezapinal, vymontoval bych z toho disk, udelal obraz a pak zkousel resit ten. U takoveho kramu se snizuje pravdepodobnost obnovy s kazdym zapnutim, protoze to ma vlastni OS, ktery si ty disky montuje rw a pak s nimi dela kdovi co.
-
s/kdovi co/nsa vi co/
-
Odmlčel jsem se, protože jsem čekal na nový HDD, kterýžto jsem objednal k uložení dat, jelikož photorec by mě to na stejnej HDD nevměstnal a nechtěl jsem zažít horror se zaplněním disku.
Takže ti, kdož nevědí, co je to za disk, napsal jsem název toho zařízení v prvním příspěvku a po napsání do google vám vyjede taková krabička, je to domácí NAS.
Přes SSH jsem se do toho nevěděl dostat, protože to má nějaký vlastní OS.
Teď dojel photorec, trvalo to bezmála 12 hodin.
Vyplivl milion souborů v půl miliónu adresářů, označených tak, že se v tom prase nevyzná.
Švagr je na prášky, protože by to ručně třídil 10 000 let.
přemýšlím co dál, data jsou zatím tak jak byly na tom disku, disk je namountován v debianu, kde mám SSD jako systémový a ten novej disk, kam se to všechno napěchovalo.
-
pokud jsou data opravdu smazana a jsou nekde "schovany" jako v "sitovym kosi" tak to pravdepodobne lepsi nebude co se na ext3 smaze
se da v drtivy vetsine najit jen podle obsahu souboru bez informace o jmene a miste.
-
Problém je třebas i v tom, že to má nějakej divnej šifrovací systém, neboco, protože třebas:
find . -name "*.avi"
vám nevyplivne zhola nic, i když vím, že nějaký nesmazaný avi soubory tam na 100pro jsou a jdou i přehrát, když byl disk ještě v původní krabici.
-
Ještě bych prosil, kdyby byl nékdo tak laskav a napsal mě příkaz cp, který najde všechny soubory daného typu /př. avi/ a přesune je do daného adresáře, aby to alespoň bylo pohromadě, protože teď je z toho taková polívka, že se s tim lidskému člověku nedá skutečně pracovat, díky.
-
Odmlčel jsem se, protože jsem čekal na nový HDD, kterýžto jsem objednal k uložení dat, jelikož photorec by mě to na stejnej HDD nevměstnal a nechtěl jsem zažít horror se zaplněním disku.
Tak to mate kliku, jak od blazince, protoze obnovovat data na stejny disk, je nejvetsi blbost, jakou muzete udelat. Je to idealni cesta na to, abyste o vetsinu tech dat prisel.
Teď dojel photorec, trvalo to bezmála 12 hodin.
Vyplivl milion souborů v půl miliónu adresářů, označených tak, že se v tom prase nevyzná.
Švagr je na prášky, protože by to ručně třídil 10 000 let.
přemýšlím co dál, data jsou zatím tak jak byly na tom disku, disk je namountován v debianu, kde mám SSD jako systémový a ten novej disk, kam se to všechno napěchovalo.
Tohle jsem nedavno resil, dole mate skript, ktery ta data nahardlinkuje do adresaru podle rozsireni souboru. Pochazi primo ze sajtu testdisku a photorecu. Jsou tam jine, ale tenhle me zaujal nejvic a take je asi nejrychlejsi. Na cilovem disku musi byt k dispozici FS s podporou hardlinku, takze jestli tam mate NTF, tak to z Linuxu nejspis nepujde, i kdyz NTFS dnes nejspis hardlinky umi. Nesmysly, jako .cab, .jar .... a kdovi, co se tam mohlo priplest, pak vymazete a fotkami, filmy atd., se svagr bude muset prokousat. Fotky by mozna sly prejmenovat v posloupnosti podle data z EXIF, pokud je k dispozici. Lepsi, nez nic.
#!/bin/bash
## Hardlinks files into another directory structure
## In the target the files are sorted in folders by extention
## Usefull after using photorec to recover files.
recup_dir="${1%/}"
[ -d "$recup_dir" ] || {
echo "Usage: $0 recup_dir";
echo "Mirror files from recup_dir into recup_dir.by_ext, organized by extension";
exit 1
};
find "$recup_dir" -type f | while read k; do
ext="${k##*.}";
ext_dir="$recup_dir.by_ext/$ext";
[ -d "$ext_dir" ] || mkdir -p "$ext_dir";
echo "${k%/*}"
ln "$k" "$ext_dir";
done
-
Ten nový disk, na kterým je to všechno teď uložené, jsem udělal jako ext3 /dev/sdc1 takže by ten scriptměl jít?
Co se týče kliky, ikdyž jsem totální lama, tak těch pár nebezpečí si SNAD uvědomuju. Disk jsem koupil nejen pro záchranu těch dat, ale použiju ho později pro můj domácí NAS, který mám v debianu se sambou a 1TB disk už je plnej. Mě se tyhlety lowend BFU friendly zařízení nelíbí právě už proto, co teď s tím mám práce.
Jo, a mockrát děkuju všem za pomoc.
-
A ještě dotaz, ten script mám spustit z jakého aktuálního adresáře?
Mám to teď tak:
/mnt/disk - namountován disk z toho krámu
/mnt/disk1 - nový disk s obnovenýmy soubory
Děkuji.
-
Tak už jsem přišel na to jak to funguje, ale má to háček, těch adresářů recup_dir je 491 uff.
-
vám nevyplivne zhola nic, i když vím, že nějaký nesmazaný avi soubory tam na 100pro jsou a jdou i přehrát, když byl disk ještě v původní krabici.
Jako ze jsi disk vyndal z puvodniho wd ramecku? Pozor na to, nektery ty wd kramy sifrujou a heslo je nekde v tom radici. Kdyz radic vyhodis, tak jsi v kyblu. Ale na disku bez wd řadiče pak neni videt gpt, tvari se jako prazdnej, vyplnenej nadodnyma datama. Tak to treba neni tvuj pripad.
-
Dík Jarda.P za script.
Pustil jsem se studovat, jak jej spustit 491x s parametrem recup_dir.X, kde X bude od 1 do 491, ale to je hodně nad moje síly.
-
No ten photorec najde spoustu veci, ale nevi, jak se jmenovali a kde byli, je to gulash
Jeste bys moh vyzkouset opravit v linuxu ten hfs+, to by pak byli i jmena. Udelej ale prvne zálohu pres dd, pro jistotu. A ty výsledky photorec nezavazuje. Pak treba tu: https://abhinay.wordpress.com/2009/04/12/repair-fix-mac-hfs-partition-using-ubuntu-cd/
-
jeste doplnim, prvne zkus
sudo fsck_hfs -y /dev/sdb1a pak pripadne
sudo fsck_hfs -y -r /dev/sdb1
-
Pokud si těch dat ceníte, tak to okamžitě odpojte a předejte nějaké firmě, co ví co dělat...
njn, měl jsem pravdu...
-
Dík Jarda.P za script.
Pustil jsem se studovat, jak jej spustit 491x s parametrem recup_dir.X, kde X bude od 1 do 491, ale to je hodně nad moje síly.
Jezkovy brejle, to se spousti z adresare, ve kterem jsou vsechny ty recup_dir, tedy jenom jednou a zada se tomu cesta, kde ma vytvorit novou strukturu a tam to nahardlinkovat. V tom je kouzlo toho skriptu. Akorat vytvori novy pohled na vec bez toho, ze by to zralo misto na disku. Pak si to prekopiruju, kam chci, pokud potrebuji. Tedy treba na puvodni disk, po te, co jsem ho znovu naformatoval.
-
Dík Jarda.P za script.
Pustil jsem se studovat, jak jej spustit 491x s parametrem recup_dir.X, kde X bude od 1 do 491, ale to je hodně nad moje síly.
Jezkovy brejle, to se spousti z adresare, ve kterem jsou vsechny ty recup_dir, tedy jenom jednou a zada se tomu cesta, kde ma vytvorit novou strukturu a tam to nahardlinkovat. V tom je kouzlo toho skriptu. Akorat vytvori novy pohled na vec bez toho, ze by to zralo misto na disku. Pak si to prekopiruju, kam chci, pokud potrebuji. Tedy treba na puvodni disk, po te, co jsem ho znovu naformatoval.
Promiň, ale mě to tak nefunkuje, zadá se tomu cesta, odkud má brát ty soubory a ono to vytvoří adresář samo. Takže po sort_by_ext.sh recup_dir.450 vytvoří recup_dir.450.by_ext
-
Promiň, ale mě to tak nefunkuje, zadá se tomu cesta, odkud má brát ty soubory a ono to vytvoří adresář samo. Takže po sort_by_ext.sh recup_dir.450 vytvoří recup_dir.450.by_ext
Tak ja nevim, nejsem v bashi tak uplne borec, ale jak koukam do toho skriptu, tak tam vidim, ze to spustim z adresare, pod kterym mam vsechny ty recup adresare a zadam tomu cestu, kam to ma nahazet.
-
ja tam vidim ze zadam recur_dir a vytvori to recur_dir.by_ext, do nej prislusne podadresare jmenem pripon a do toho to hardlinkuje
pro vice recur_diru to pustit ve smycce (pro vse zacinajici recur_dir, ale nekoncici na by_ext, aby to nebyla nekonecna smycka :):
for dir in recur_dir!(*.by_ext); do jmeno_toho_scriptu $dir; done
pozor na to ze hardlink i kdyz to vypada jako normalni soubor, tak jde pouze o odkaz na ten puvodni soubor, tedy nemazat to nerostridene dokud to roztridene nezkopirujes na jinej hdd :)
prejmenovani jpg podle exif data/infa jde napr. pomoci jhead
-
pozor na to ze hardlink i kdyz to vypada jako normalni soubor, tak jde pouze o odkaz na ten puvodni soubor, tedy nemazat to nerostridene dokud to roztridene nezkopirujes na jinej hdd :)
Tak to snad ne. Hardlink je dalsi reference na stejny soubor. Kdyz vymazu hardlinkovany soubor, puvodni mi zustane, jen se snizi pocet referenci o jednu. FS musi podporovat hardlinky.
-
Tak já jsem to vyřešil takovouhle pr...sárnou, za což se omlouvám znalejším, ale na víc nemám.
cp -r -v /mnt/disk1/cast1/recup_dir.*/*.mpg /mnt/disk1/cast1/mpg
Musel jsem těch 500 adresářů rozdělit, pač mě cp hlásil příliš mnoho argumentů. Proto je tam ten adresář ./cast1. Napsal jsem to do scriptu, zkopíroval pro ostatní 3 části a spustil. Pak pro ostatni extendy přepsal.
-
Tak to snad ne. Hardlink je dalsi reference na stejny soubor. Kdyz vymazu hardlinkovany soubor, puvodni mi zustane, jen se snizi pocet referenci o jednu. FS musi podporovat hardlinky.
nepochopeno :)
neroztridene = puvodni soubory
roztridene = hardlinky
Tak já jsem to vyřešil takovouhle pr...sárnou, za což se omlouvám znalejším, ale na víc nemám.
...
tak skoda ze sem ti nenapsal jak pustit ten skript ve smycce ze :-D
-
Sorry, omlouvám se, ale už jsem měl polovinu setříděnou.
-
nepochopeno :)
neroztridene = puvodni soubory
roztridene = hardlinky
jarda ma pravdu, predsedo :)
sem myslel, ze tohle bude noubody znat
neni rozdil mezi neroztridenym a roztridenym, oba budou ukazovat na stejny soubor na stejnou inode, coz ma vyhodu, ze to zabira min mista; jestli je mista dost, tak bych radsi udelal cp
PS: hardlinky se tezko hledaj, trebas:
sudo find / -type f -links +1
-
Tak ne, odvolavam, co jsem odvolal, slibuji, co jsem prislibil. Ten skript jede s recup dit a udela si novy adresar, kam to sazi podle pripon. Pricemz recup dir je adresar, pod kterym je vsechen ten bordel. Jede to rekurzivne, protoze u find neni nastven maxdepth.
-
tak jarda psal obracene ze po smazani hardlinkovaneho zustane puvodni, nicmene mate pravdu ze i pri smazani puvodniho opravdu zustava hardlinkovanej :) sem nikdy nerekl ze vim vse a ze se i po tech letech porad nemam co ucit ;)
-
vsak ja taky nic nerikam ;D voni totiz jsou si pak ty dva hardlinky rovny, je jedno, kterej byl puvodni a kterej potom k nemu hardlinkovanej
stejnak hard je zlo, nemelo by se to uz pouzivat, misto toho soft nebo nejprogresivnejsi je reflink, ten funguje zatim jenom na btrfs a zfs (COW), udela jakoze hardlink na puvodni soubor, ale muzes menit oba dva nezavisle, to se pak bloky rozpoji
v pripade hardlinku, kdyz zmenis obsah jednoho, tak samozrejme zaroven tim i druhyho
http://www.pixelbeat.org/docs/unix_links.html
jestli mate COW FS, tak se hodi
alias cp='cp --reflink=auto --sparse=always'
-
tak jarda psal obracene ze po smazani hardlinkovaneho zustane puvodni, nicmene mate pravdu ze i pri smazani puvodniho opravdu zustava hardlinkovanej :) sem nikdy nerekl ze vim vse a ze se i po tech letech porad nemam co ucit ;)
Jak ty dva od sebe poznas?
@trubicoid2: Zalezi na tom, co s nimi delas. Ja je treba pouzivam, kdyz chci nekolika lidem dat stejny soubor. Zalozim pro kazdeho adresar, pak to tam nahardlinkuji a kdyz se s nimi vidim, presunu to na jejich medium. Pocet odkazu se snizi o jednu, po poslednim soubor zmizi. A me to bere misto na disku jen jednou a nemusim si pamatovat, co jsem komu mel dat.
-
Tak ten reflink ti bude dělat přesně to samý, tedy 10 kopií zabere pořád místo jedné kopie. Navíc můžeš nejen kopie nezávisle mazat, ale i měnit. No a tak funguje v btrfs deduplikace, když bys deduplikoval hardlinkama (např. fdupes -L), tak to může něco rozbít.
-
To jo. Ale mam formatovat USB flash nebo SD na zfs nebo brtfs?
-
to asi nee, i kdyz jsem poprve videl zfs zrovna na tomto videu ;D
http://video.google.com/videoplay?docid=7760232806099469333
naky kecy k tomu:
https://blogs.oracle.com/constantin/entry/csi_munich_how_to_save
-
gugli video je rozbity, tak toto: https://youtu.be/1zw8V8g5eT0