dane z partycji logicznej

Question

Mam pytanie jak przywrócić utracone dane z partycji logicznej Chodzi mi o partycję 'D', zaznaczoną na rysunku (NTFS, 10001.4MB, 53.1/9948.3MB). Znaj...

Anonymous · Answer

Poprosze o odczyt 0-100 lba z MHDD komenda atof i plik odczytu na forum.
A obrazek naumysnie zrobiony zeby nie mozna bylo powiekszyc? =>

zeby taki obrazek zostal musial kolega wyedytowac to sam recznie.
Jezeli kolega jak pisze sformatowal tylko systemowa partycja, tu popatrzec jak wyglada przykladowy podzial dysku na dyski logiczne =>

czerwone paski to zapisy w partition table, w pierwszym widzimy wykorzystane sa wszystkie 4 zapisy w PT w mbr i na takim dysku moze byc tylko 4 dyski logiczne, w drugim widzimy 2 zapisy PT w mbr z ktorych drugi jest odnosnikiem na kolejny boot extended i tak po lancuchu dalej, i przy takim podzialu na dyski logiczne moze byc wiecej niz 4 dyski logiczne .

Scotty · Answer

Log z MHDD funkcji atof (0-100 lba)

Anonymous · Answer

teraz poprosze o odczyt 21623480- 21623580 lba

Scotty · Answer

Log 21623480- 21623580 lba

Anonymous · Answer

teraz poprosze te obszary => 20492791 - 20492991 lba 20502839 - 20503039 lba 25817800 - 25817900 lba

Scotty · Answer

W/w logi:20492791 - 20492991 lba20502839 - 20503039 lba25817800 - 25817900 lba

Anonymous · Answer

Dysk naprawde wyglanda na tylko co sformatowany , raniej ten volume'in byl fat32 i tylko potem zostal sformatowany na ntfs o czym swiadczy boot copy fat32 ktory znajduje sie tam gdzie i powinien 69 sektor ot boot extended. Nic nie moze tak raptem uszkodzic zawartosc na dysku ulokowanym na extended kiedy formatujemy primary, przydalo by wiecej informacji co do tego zdarzenia z formatowaniem primary =>Code: text Expand Select all Copy to clipboard0x0000   EB 58 90 4D 53 57 49 4E 34 2E 31 00 02 20 20 00   ëX�MSWIN4.1..  .
0x0010   02 00 00 00 00 F8 00 00 3F 00 FF 00 01 F3 49 01   .....ø..?.ÿ..óI.
0x0020   FC 8A 38 01 90 13 00 00 00 00 00 00 3A 01 00 00   üŠ8.�.......:...
0x0030   01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0x0040   80 00 29 DF 14 22 38 44 52 45 41 4D 00 00 00 00   €.)ß."8DREAM....
0x0050   00 00 46 41 54 33 32 20 20 20 FA 33 C9 8E D1 BC   ..FAT32   ú3ÉŽÑ¼
0x0060   F8 7B 8E C1 BD 78 00 C5 76 00 1E 56 16 55 BF 22   ø{ŽÁ½x.Åv..V.U¿"
0x0070   05 89 7E 00 89 4E 02 B1 0B FC F3 A4 8E D9 BD 00   .‰~.‰N.±.üó¤ŽÙ½.
0x0080   7C C6 45 FE 0F 8B 46 18 88 45 F9 38 4E 40 7D 25   |ÆEþ.‹F.ˆEù8N@}%
0x0090   8B C1 99 BB 00 07 E8 97 00 72 1A 83 EB 3A 66 A1   ‹Á™»..è—.r.ƒë:f¡
0x00A0   1C 7C 66 3B 07 8A 57 FC 75 06 80 CA 02 88 56 02   .|f;.ŠWüu.€Ê.ˆV.
0x00B0   80 C3 10 73 ED BF 02 00 83 7E 16 00 75 45 8B 46   €Ã.sí¿..ƒ~..uE‹F
0x00C0   1C 8B 56 1E B9 03 00 49 40 75 01 42 BB 00 7E E8   .‹V.¹..I@u.B».~è
0x00D0   5F 00 73 26 B0 F8 4F 74 1D 8B 46 32 33 D2 B9 03   _.s&°øOt.‹F23Ò¹.
0x00E0   00 3B C8 77 1E 8B 76 0E 3B CE 73 17 2B F1 03 46   .;Èw.‹v.;Îs.+ñ.F
0x00F0   1C 13 56 1E EB D1 73 0B EB 27 83 7E 2A 00 77 03   ..V.ëÑs.ë'ƒ~*.w.
0x0100   E9 FD 02 BE 7E 7D AC 98 03 F0 AC 84 C0 74 17 3C   éý.¾~}¬˜.ð¬„Àt.<
0x0110   FF 74 09 B4 0E BB 07 00 CD 10 EB EE BE 81 7D EB   ÿt.´.»..Í.ëî¾�}ë
0x0120   E5 BE 7F 7D EB E0 98 CD 16 5E 1F 66 8F 04 CD 19   å¾}ëà˜Í.^.f�.Í.
0x0130   41 56 66 6A 00 52 50 06 53 6A 01 6A 10 8B F4 60   AVfj.RP.Sj.j.‹ô`
0x0140   80 7E 02 0E 75 04 B4 42 EB 1D 91 92 33 D2 F7 76   €~..u.´Bë.‘’3Ò÷v
0x0150   18 91 F7 76 18 42 87 CA F7 76 1A 8A F2 8A E8 C0   .‘÷v.B‡Ê÷v.ŠòŠèÀ
0x0160   CC 02 0A CC B8 01 02 8A 56 40 CD 13 61 8D 64 10   Ì..Ì¸..ŠV@Í.a�d.
0x0170   5E 72 0A 40 75 01 42 03 5E 0B 49 75 B4 C3 03 18   ^r.@u.B.^.Iu´Ã..
0x0180   01 27 0D 0A 4E 69 65 70 72 61 77 69 64 6C 6F 77   .'..Nieprawidlow
0x0190   79 20 64 79 73 6B 20 FF 0D 0A 42 6C 61 64 20 57   y dysk ÿ..Blad W
0x01A0   65 2F 57 79 20 20 20 20 FF 0D 0A 57 79 6D 69 65   e/Wy    ÿ..Wymie
0x01B0   6E 20 64 79 73 6B 20 69 20 6E 61 63 69 73 6E 69   n dysk i nacisni
0x01C0   6A 20 64 6F 77 6F 6C 6E 79 20 6B 6C 61 77 69 73   j dowolny klawis
0x01D0   7A 20 20 0D 0A 00 00 00 49 4F 20 20 20 20 20 20   z  .....IO      
0x01E0   53 59 53 4D 53 44 4F 53 20 20 20 53 59 53 7E 01   SYSMSDOS   SYS~.
0x01F0   00 57 49 4E 42 4F 4F 54 20 53 59 53 00 00 55 AA   .WINBOOT SYS..Uª
Mapa woluminu teraz wyglanda tak boot extended 21623490 lba -liczymy ten 021623553 boot ntfs ten 63 .69 boot copy fat 32 ( pozastalosc od poprzedniego systemu plikow )4 klaster pierwszy zapis MFT jezeli liczyc boot extended za 0 to bedzie 95 sektor. Teraz by przydalo zrobic kopia mft pierwszych zapisow i obszar data 102-110 ( 21623490+95 - 21623490+110 ).

Scotty · Answer

Ok, jeśli dobrze zrozumiałem to chodzi teraz o logi z (102-110 oraz 21623585-21623600) lba, więc je załączam Chciałem przetestować pewien program, ponieważ nie działał on na "starym" systemie (błędne wpisy w rejestrze, brak *.dll, itd.). Postanowiłem, że przy pomocy Partition Magic Pro 8.05 oraz Norton Ghost 8.3 z Hiren's BootCD postawię z obrazu "świeży" system (win2k pro). Z uwagi, że program przy drugim obrazie dalej nie wykazywał cech działania, stwierdziłem że spróbuję zainstalować z płyty winXp pro. Ponownie uruchomiłem PM (raczej wszystkie partycje były typu NTFS) i kolejny raz wybrałem formatowanie partycji 'C:'. Pamiętam jednak, że po dokonaniu zmian przez PM z partycji 'D:' (logicznej), zniknęła jej nazwa, więc nadałem 'zwyczajową' nazwę i dokonałem zmian + kolejny reset:!: Po tym wszystkim bardzo się zdziwiłem, gdy zobaczyłem uruchamiający się system (nie powinno już go być) Resztę już opisałem, dodam jeszcze, że dokonałem Testdisk'iem 6.8 analizowanie ("Analyse"), ale to było jeszcze przed chkdsk'iem (dwa wywołania checkdisk'a pominąłem, partycja wówczas nie była dostępna, nie miała wielkości oraz typu). Żadnych zmian nie dokonywałem w tym programie, zauważyłem że pojawiło się po w/w teście przy partycji logicznej 'D:' coś z 'ext FAT32 ' To byłoby tyle To rozumiem:) Rzeczywiście wygląda na to, że "nieszczęsna" partycja 'D:' FAT32--->NTFS :x Nie mam pojęcia kiedy i jak mogło się to stać.Jeśli możesz, proszę wytłumacz mi po co są te logi: ??

Scotty · Answer

Mam pytanie odnośnie wyniku skanowania w/w hdd'ka programem testdisk. Mianowicie wyszukał on 3 wpisy dot. interesującej mnie partycji 'D:' (zdjęcie poniżej). Podejrzałem więc zawartość tych wpisów za pomocą opcji P (P=list file) i jeśli dobrze rozumiem pierwszy wpis dot. obecnego "stanu" partycji logicznej, a kolejne dwa to pozostałości?
Dodam jeszcze, że tylko przy dwóch ostatnich wpisach ("D FAT32 LBA" i "D HPFS - NTS") coś widać na kształt danych (m.in.: niezrozumiałe ciągi znaków i nieaktualne daty). Jeżeli przywrócę 3 wpis to dane powrócą na miejsce? Piszę tylko o trzeciej opcji, ponieważ partycja była NTFS!

Proszę Was o radę

Anonymous · Answer

Jezeli kolega opowie cala prawda, o tym co sie stalo ? =>1. bedzie lzej cos poradzic.2. Powiem ze aktualny jest tylko wpis NTFS, FAT32 struktura to tylko boot fat copy, dla tego wlasnie ja i prosilem o te 3 dodatkowe obszary, zeby w tym byc pewnym !Kolega moze podac odczyt ostatnich 100 sektorow tej partycji .

Scotty · Answer

Jak już wcześniej pisałem w wątku, chciałem przetestować działanie pewnego programu, ponieważ nie działał on na "zaśmieconym" systemie, zdecydowałem się na postawienie windy z obrazu (nośniki: partycja D/płyta CD/win XP) - wykonałem 3 próby.

skróty oznaczają:
*-możliwość wystąpienia błędu;
#-możliwość zauważenia zmiany partycji logicznej 'D:' z NTFS--->FAT32;
HB-Hiren's Boot CD v.81;
PM-Partition Magic Pro 8.05 (format w NTFS);
NG-Norton Ghost 8.3;

Przebieg prób:

1. HB--->PM--->reboot--->HB --->NG--->użycie obrazu partycji przechowywanej na 'D:'--->reboot--->uruchomienie win2k pro (sp2);
Jak widać błąd tu nie wystąpił, ponieważ nie było by dostępnego obrazu!

2. HB--->PM*--->reboot--->HB --->NG--->użycie obrazu na CD --->reboot--->uruchomienie win2k pro (sp4);

Z uwagi na to, że przywracałem system z obrazu znajdującego się na CD, to przy formatowaniu partycji primery (systemowej), mogłem sformatować partycję "D:' (NTFS--->FAT32) i wówczas nie zauważyłbym tego po uruchomieniu windy. Jednak jak sobie przypominam windows normalnie się uruchomił, bez konsolowego polecenia 'chkdsk /f'.

3.HB--->#PM--->reboot---użycie instalki winXP pro ---reboot--->uruchomia się win2k pro, a nie instalator XP z CD ;

# w tym miejscu mogłem zauważyć błąd (NTFS--->FAT32), gdyby wystąpił w etapie nr 2! Partition Magic wyróżnia kolorem rodzaje partycji (NTFS-różowy, FAT32-zielony) i raczej nie było innego typu systemu plików - wszystko było na różowo (jak później się okazało jednak nie

)! Pewien byłbym błędu, gdyby PM sortował je według systemu plików i wówczas partycja 'D:' (FAT32) mogłaby się znaleźć wyżej niż 'C:' (NTFS) i w następstwie tego mogłem bezmyślnie sformatować pierwszą z góry (sprawdzę czy tak jest w tym programie).
Wyciągnąć można z tego wniosek, że to nie była primery, bo wówczas uruchomił by się instalator Xp, więc sformatowałem 'D' (NTFS czy na FAT32)?! Przecież PM sam z siebie się tego nie zrobił, ale w takim wypadku dlaczego później uruchamiał się checkdisk?
Czego jestem pewien na 100% to to, że lable partycji logicznej zniknął, więc nadałem mu standardową nazwę ('Dream'). Po tym wszystkim reboot i czekanie na uruchomianie się instalatora.

4. Uruchomia się win2k pro, którego nie miało już być

5. Dwukrotnie anuluje działanie konsolowego chkdsk /f przed pojawieniem się pulpitu. Przy jednym z tych dwóch uruchomień włączyłem Testdisk'a 6.8 (funkcja "Analyse") i już wtedy widziałem w rezultatach "analizowania", że przy interesującej mnie partycji jest coś z "FAT32"! Nie dokonywałem jakichkolwiek zmian wykorzystując ten program!
Dodam, że partycja wówczas nie była dostępna, nie miała wielkości oraz typu (RAW?).
6. Po ponownym uruchomieniu kompa już z chkdsk'iem, partycja 'D:' jest dostępna z formatem pliku NTFS, ale bez danych.

To wszystko

okzo wrote:
Kolega moze podac odczyt ostatnich 100 sektorow tej partycji

21623553 lba (boot NTFS) + 20482812 lba (rozmiar partycji logicznej D) ---> log 42106264 - 42106364 lba

Proszę oto ten log.

Anonymous · Answer

Przywrocenie ntfs po istniajacym boot copy nie da jakichkolwiek skutkow, boot copy ma ta sama zawartosc co i istniajacy boot. Tu trzeba szukac innego rozwiazania, uzywajac to co pozostalo z metadanych. Metoda jest dosc ryzykowna dla takich typow prac, i lepiej jak by kolega to zrobil na kopii 1x1 calego dysku lub zrobic kopia bezpieczenstwa tej partycji 1x1 do pliku uzyc mozna tej samej komendy atof i skopiowac obszar od boot extended do boot copy tej partycj (wlacznie). Powtarzam KOPIA 1X1 jest niezbedna !! tu info odnosnie struktur mft i ntfs => https://www.elektroda.pl/rtvforum/topic891920.html Teraz sama operacja Teraz troche info jak mozna odbudowac sformatowana ( tu u kolegi problem jest 1x1) partycja NTFS bez jakich kolwiek narzedzi dodatkowych tylko dowolny edytor dyskowy ( moze byc i zwykly hex redaktor w parze z MHDD, komendy atof i ff ktorego pomoga odczytac i zapisac sektory po edycji na dysk ) . Naszym celem bedzie reczne odzyskiwanie danych calej sformatowanej partycji NTFS bez jakichkolwiek dodatkowych narzedzi dla odzyskiwania danych , wszystko co bedzie potrzebne to dowolny edytor dyskowy i chkdsk (slynny zabojca partycji moze posluzyc do ich ratowania po formacie). W trakcie formatowania przeprowadza sie bezpowrotne zniszczenie wiekszosci kluczowych struktur metadanych - danych, ktore recznie odzyskiwac byloby bardzo ciezko, tego wlasnie i nie potrzeba . Caly sens jest w tym, zeby przywrocic partycji utracone zapisy systemu plikow, a pozostala prace niech robi chkdsk . Jedyna struktura danych bez ktorej nie moze pracowac chkdsk jest atrybut $DATA pliku $MFT. Dlatego nam potrzebne jest odbudowac poprzedni $MFT:$DATA i ulokowac go zamiast ewentualnych zapisow . Jezeli $MFT:$DATA nie jest fragmetowany, to mozna zrobic prosto powiekszeniem jego dlugosci. Jak to zrobic ? $DATA (80h) powiekszamy znaczenia pola Allocated Size/Real Size/Compressed Size na potrzebna ilosc rownolegle korygujac spis odcinkow (runlist). Allocated Size musi byc obowiazkowo wielokrotnoscia rozmiaru klastra ( 1klastr = 8sektorow= 4096 b ), inaczej chkdsk nic nie potrafi zrobic . Prawidlowa dlugosc pliku MFT wyliczac nie ma potrzeby, wystarczy wziasc dlugosc wieksza, niepotrzebna wyrzuci sam chkdsk (i lepiej brac wiecej niz mniej). tu daje fragment $mft:$data kolegi Code: text Expand Select all Copy to clipboard0x0000   80 00 00 00 48 00 00 00 01 00 40 00 00 00 02 00   €...H.....@.....
0x0010   00 00 00 00 00 00 00 00 0B 00 00 00 00 00 00 00   ................
0x0020   40 00 00 00 00 00 00 00 00 C0 00 00 00 00 00 00   @........À......
0x0030   00 88 00 00 00 00 00 00 00 88 00 00 00 00 00 00   .ˆ.......ˆ......
0x0040   11 0C 04 00   ....
Kolega moglbym podac obszar 21623490-21623690 lba ( tu musi byc nasz MFT ) . Jasne jezeli MFT byl fragmentowany to juz powazny problem i bez odbudowania ( runlist), bedzie ciezko cos zropbic. Patrzymy FAQ NTFS tu znajdujemy opis $ DATA. TYLKO JAK NAPISALEM WCZESNIEJ JESZCE RAZ POWTORZE KOPIA 1X1 OBOWIAZKOWA ( LEPIEJ CALEGO DYSKU , JEDNAK MOZE BYC I TYLKO TA PARTYCJA CALKIEM ) https://www.elektroda.pl/rtvforum/topic891920.html

Scotty · Answer

Obecnie posiadam miejsca na 42106364 lba ~ 22GB (primery + część EXT - C+D). Może jutro będę dysponował hdd'kiem ~160GB, więc jeśli to konieczne to zrobię kopię całego dysku.Mały OT, przeanalizowałem w/w FAQ'u już wcześniej w trakcie powstawanie (a propos bardzo dobry pomysł) Nie wiem czy to ważne, ale dysk (tylko ext) przed stratą danych był defragmentowany!!!Oczywiście poniżej załączam log

Anonymous · Answer

Ten $mft:$data kolega podal ostatni =>Code: text Expand Select all Copy to clipboard0x0000   80 00 00 00 48 00 00 00 01 00 40 00 00 00 02 00   €...H.....@.....
0x0010   00 00 00 00 00 00 00 00 0F 00 00 00 00 00 00 00   ................
0x0020   40 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00   @...............
0x0030   00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00   ................
0x0040   11 10 04 00  ....
Ten $mft:$data podal przed tym Code: text Expand Select all Copy to clipboard0x0000   80 00 00 00 48 00 00 00 01 00 40 00 00 00 02 00   €...H.....@.....
0x0010   00 00 00 00 00 00 00 00 0B 00 00 00 00 00 00 00   ................
0x0020   40 00 00 00 00 00 00 00 00 C0 00 00 00 00 00 00   @........À......
0x0030   00 88 00 00 00 00 00 00 00 88 00 00 00 00 00 00   .ˆ.......ˆ......
0x0040   11 0C 04 00   .... teraz patrzymy, 28/8 - Rozmiar obszaru danych, zajetego przez plik na dysku(allocated size) - 00 00 01 00 00 00 00 00 terazniejszy, 00 C0 00 00 00 00 00 00 poprzedni30/8 - Realna dlugosc pliku (real size)- 00 00 01 00 00 00 00 00 terazniejszy, 00 88 00 00 00 00 00 00 poprzedni38/8 - Rozmiar inicjalizowanego obszaru pamieci dyskowej, wydzielonnej dla przychowynia pliku , 00 00 01 00 00 00 00 00 terazniejszy, 00 88 00 00 00 00 00 00 poprzedni .. Kolega cos juz robil z partycja ? dla czego kolega o tym => napisal tylko teraz ?

Scotty · Answer

Ok, przeanalizowałem wpisy z $MFT:$DATA i mam związku z tym pytanie - dlaczego "poprzednia" i "teraźniejsza" tablica $MFT są blisko siebie? Ten "obecny"powstał po chkdsk'u, a "przeszły" - właściwy to pozostałość??

Quote:
Kolega cos juz robil z partycja ?
dla czego kolega o tym =>
Quote:

Nie wiem czy to ważne, ale dysk (tylko ext) przed stratą danych był defragmentowany!!!

napisal tylko teraz ?

Nie, nie! Dysk był często defragmentowany, ale przed tym kłopotem. Nie, nie zrobiłbym defragmentacji po tym jak mi dane zniknęły!

Anonymous · Answer

Ona nie jest blisko siebie, to ten sam MFT z ta sama data utworzenia, tylko ze, ze zmieniona dlugoscia !
A jezeli kolega ma na mysli boot copy, jak pozostalosc, to kolega te dwa sektory jednakowe od 1 do ostatniego bita, boot i jego kopia ! Adres pierwszego klastra mft wpisany w boot, i chkdsk jego nie zmienia.