Dotaz: Obnova struktury a jmen adresářů a soborů z My Cloud Home WD

[Makala]

Ahoj, prosím, potřeboval bych radu, Linuxu se to týká částečně, ale věřím, že se najde nějaká dobrá duše, která bude ochotna mi pomoct :)

Používal jsem jako domácí úložiště My Cloud Home (teď už vím, že to byla obrovská chyba tuto šílenost pořídit a další chyba byla, že většinu dat nemám zazálohovanou jinde). Stalo se to, že po nějakém výpadku serveru u WD se mi nedaří standardní cestou (přes webové rozhraní, desktopovou windowsovskou aplikaci ani mobilní aplikaci) na disk připojit. U tohoto zařízení neexistuje přímé připojení k PC ani jiná možnost, jak data stáhnout. Přes bombardování hotline WD a výměně několika desítek mailů mně pořád tvrdí, že je chyba na disku a že se s tím nedá nic dělat, jedině hard reset do továrního nastavení = smazání všech dat.

To si nechci nechat líbit, tak s diskem laboruju. Podařilo se mi přes Linux a nějaký recovery soft prozkoumat disk, soubory jsou na disku evidentně v pořádku (jdou prohlížet fotky, videa). ALE: v tomto zařízení je struktura adresářů a souborů pod databází, takže jednotlivé soubory mají zakódované názvy typu ZMFK15DJIHJ14, nedá se ani rozklíčovat, jakého je konkrétní soubor typu (jen pokusem o otevření a odhadem podle velikosti souboru). Na disku je ale k dispozici soubor index.db, který by měl minimálně názvy a typy souborů dekódovat. Bohužel na tohle jsem krátký.

Zde je tedy můj dotaz: byl by, prosím, někdo ochoten poradit mi, jak by se dalo soubory uložit s původními názvy, popřípadě přinejlepším i se strukturou adresářů? Nemáte, prosím, s tímto někdo zkušenost? Strávil jsem dlouhé hodiny hledáním řešení na webech a youtube. Jakýsi postup existuje, dá se stáhnout skript, který by měl tohle zajistit, ale vůbec netuším, jak ho použít... Data jsou při prohlížení umístěna ve složkách s názvy 0 až 9 a A až Z. Cenných dat je na disku poměrně málo (tipuju tak 200 GB), většina souborů je pro mě postradatelná.

Moc děkuji za každou radu a unesu nadávky za mou blbost s nezálohováním souborů :)

Makala

---

---

Odpovědi

[AraxoN]

1) Draze: UFS Explorer Professional Recovery.

2) Zdarma: mycloud-restsdk-recovery-script
Návod: How to recover files and data from WD MyCloud Home for free

Zdar Max

[X]

V kostce ve skriptu upravis tri promenne:

db='/cesta/kde/mas/index.db'
filedir='/cesta/kde/jsou/data'
dumpdir='/cesta/kde/bude/vysledek'

Musis mit dost mista a v nazvech NEDAVEJ NAKONEC LOMITKO. Spustis:

python3 restsdk_public.py

[X]

Program je pro linux. Pokud ho nemas nabootuj nejake live USB distro etc.

[Jendа]

Je to skript v Pythonu který otevře SQLite databázi, udělá jeden SELECT a dostane seznam souborů, které pak popřesouvá. Tohle bude fungovat na libovolném OS.

[X]

Intended for python3.6 on linux, probably won't work on Windows

Jen na vlastni nebezpeci.

[Makala]

Díky za koment :) Údajně je ale nebezpečí při připojení disku na PC s Windows, že si Windowsy začnou přepisovat systém souborů. Možná je to blbost, ale varovalo mě už víc lidí. Kdybych disk připojil externě přes USB, toto by ale nemuselo hrozit, nebo? Nerad bych data nějak nevratně poškodil... Děkuji!

[X]

Muzes tam mit antivir, ktery to hned zacne testovat, prozkoumas v exporeru a windows sivytvori skryte soubory, zacne disk indexovat pro prohledavani a podobne zhovadilosti ktere muzes mit zapnute a ani o tom nevis. Proc riskovat.

[Makala]

No, přesně tak. Jenže jak jsem psal, Linux je pro mě španělská ves, rozjel jsem ho na NTB, tak se s ním pomalu seznamuju :) Ze všech rad si udělám nějaký obrázek a poprosím nějaké známé ajťáky, když jim naservíruju řešení, tak snad už nebude pro někoho potíž převést ho do praxe :) Ještě jsem si říkal, jestli ten disk nenaklonovat, měl bych prostor na neúspěšné pokusy...

[xxxs]

"jestli ten disk nenaklonovat" -nevahaj.

[Makala]

:)

[Makala]

Ano, moc díky, na tohle jsem se taky asi díval, moje znalosti Linuxu a skriptování jsou bohužel téměř nulové, ale určitě v okolí najdu někoho, kdo mně s tím pomocí tohoto návodu pomůže. Ještě jednou děkuji! :)

[Makala]

Ano, moc díky, na UFS jsem se taky díval, to je pro mě finančně nedostupné. Návod zkusím prostudovat :)

[Makala]

Příloha:

• LOG_LINUX.png (178059 bytů)

Ahoj pánové,

tak se mně po včerejším 4hodinovém boji nepodařilo strukturu dat opravit. Skript jsem snad správně upravil a spustil, vyhodí mi to chybu viz foto + přikládám kód, jak jsem ho upravil dle návodu. Situace byla taková: vytvořil jsem si bootovací flash s Linux Mint, spustil PC. Připojil jsem disk přes USB. Potřebnou složku s daty i souborem index.db jsem našel. Jednotlivé soubory jsou identifikovány, co se typu týče, ale nejdou otevřít. Pomůže překopírovaní na jiný disk, tam už se otevřít podaří (nechápu proč). Potom jsem zkoušel několik takto zkopírovaných dat otevřít ve Win, chybí jim přípony, ale při přejmenování jdou normálně otevřít (zkoušel jsem JPG, Word a AVI). To pořád neřeší můj problém, ale aspoň se těžce, ale přece, některých potřebných dat dopátrám.

Potom jsem upravil skript, namapoval index.db, cestu k datům a cestu, kam se mají data obnovit. Je vidět, že disk pracuje, ale po pár vteřinách vyskočí chyba. Zkoušel jsem nastavit různé cesty, kam data přeuložit, ale tady zakopaný pes není. Napadá mě, jestli to nemůže být tím, že je disk připojený přes USB. Jinak nevím...

Opět děkuji za každou radu!

Makala

[X]

Ma to problem s tou databazi. Udelal bych test. Vytvor kopii toho souboru index.db do /tmp/ nastav cestu ve skriptu na /tmp/index.db a pust to znova.

[Makala]

Díky za tip, tam je asi ta chyba. Nejde to překopírovat. Po pár sekundách vyskočí Error reading from the file: Input/output error. Na disku je ještě adresář dbBackup, tam je taky index.db. Zkusím namapovat ho. Pokud tohle nepůjde, tak to bude asi v čudu…

[Makala]

Tak huráááá, funguje to :) Namapoval jsem soubor index.db z adresáře dbBackup a data se stahují se správnými názvy souborů i adresářů, jupí... :) Jen mám obavu, že se nestáhne všechno. Soubor index.db ze složky db má cca 500 MB, index.db ze složky dbBackup jen cca 300 MB. Uvidíme, aspoň něco zachráním :) Moc díky za cenné rady!

[X]

Puvodni index.db je teoreticky mozne castecne obnovit, zalezi jak moc je poskozeny. Muzes otestovat:

sqlite3 index.db ".dump" | sqlite3 /tmp/dump.db

nebo pripadne:

sqlite3 index.db ".recover" | sqlite3 /tmp/recover.db

[Jendа]

Ten index.db nemá celý, protože mu to spadne na IO error při kopírování, měl by se pokusit ten poškozený kousek přeskočit (jako to dělá ddrescue) a doufat že konec bude zase v pohodě.

[Makala]

Díky, zkusím to, ale prvně stáhnu aspoň data pomocí index.db z dbBackup. Kdyby se to podělalo, tak snad aspoň něco zachráním :)

[Makala]

Příloha:

• Screenshot from 2022-11-08 19-05-40.png (34934 bytů)

Opět zdravím, tak první pokus o recovery vyšel na 75 %. Index.db z dbBackup obnovil cca 3/4 dat, z 1,3 TB mám asi 900 GB. To tak odpovídá, protože zálohovaný index měl má asi o třetinu menší velikost. To je super výsledek, ale jako na potvoru je tam jen málo těch souborů, který jsem vlastně potřeboval :( Takže bych se asi pokusil o opravu původního index.db. Díval jsem se na kód, který jsi napsal, ale nevím, jak ho aplikovat. Můžu poprosit o přesné znění kódu, pokud je cesta k index.db taková?

/media/mint/e8b978a4-3ca7-49d2-a664-bb56c0c8c00f/restsdk/data/db/index.db

To už bude poslední věc, se kterou otravuju :)

Pokud se index nepodaří opravit, potom už zbývá asi jen možnost proklikat se hromadou souborů se zakódovanými názvy a vytřídit si potřebné... Blbý je, že Linux takto asi rozezná jen standardní soubory jako .doc, .xls, .txt, .pdf atd. Mám tam ale třeba hodně věcí z Adobe (.psd, .indd, .ai). Dá se to nějak rozklíčovat i bez pomoci .db?

Děkuji!

[X]

Jak radil Jenda. Otervri si terminal. Nejprive nainstaluj ddrescue:

sudo apt-get -y install ddrescue

Pripoj disk 'read only' a nasledne zavolas ddrescue na ten soubor:

sudo mount -o ro,noload /media/mint/e8b978a4-3ca7-49d2-a664-bb56c0c8c00f
sudo ddrescue /media/mint/e8b978a4-3ca7-49d2-a664-bb56c0c8c00f/restsdk/data/db/index.db /tmp/rescue.db

V lepsim pripade dostanes obnovenou databazi, kterou se muzes pokusit zrekonstruovat do pouzitelneho tvaru:

sqlite3 /tmp/rescue.db ".dump" | sqlite3 /tmp/dump.db

nebo pripadne:

sqlite3 rescue.db ".recover" | sqlite3 /tmp/recover.db

Pokud nejaky prikaz selze tak sem posli vystup a nekdo ti poradi.

[Makala]

Super, díky, jdu na to... :) Nevěděl jsem, jak "zavolat" ten soubor. Díky za trpělivost!

[Makala]

Chlapci, děkuji za perfektní rady!!! Soubor index.db se mně podařilo opravit. Verze po projetí DDRESCUE má stejnou velikost jako zdroj, zkusil jsem ho aplikovat zatím na jeden z adresářů ve FILES, začaly se stahovat i soubory, které v backupovém index.db chyběly. Tak věřím, že to přechroustá a obnoví téměř 100 % :)

Ještě jednou všem moc děkuji! Nevím, jak to oplatit... Já se zabývám grafickými pracemi, tak pokud byste potřebovali třeba někdy poradit s Adobe (InDesign, Photoshop, Illustrator), Corel apod., jsem k dispozici!

[X]

Pohoda. Na oplatku by jsi mohl pokracovat s Linuxem ;).

[Makala]

Tak to slíbím, ale nesmíte mně dávat žádnej test... :)

[Peter Golis]

Ani prieskum spokojnosti?