Linux Ext2fs Undeletion mini-HOWTO
Autor: Aaron Crane aaronc@poboc.com
v1.3, 2 lutego 1999
ssaawwiicckkiibb@@eeee..ppww..eedduu..ppll
v1.0, 15 kwietnia 1999
Wyobra¼ sobie. Trzy ostatnie trzy dni spêdzi³e¶ bez snu, jedzenia, a
nawet bez prysznica. W³a¶nie ukoñczy³e¶ program, który przyniesie Ci
¶wiatow± s³awê i uznanie. Musisz go jeszcze tylko starowaæ i umie¶ciæ
na Metalab-ie. No, i skasowaæ wszystkie kopie zapasowe tworzone przez
Emacs-a. Piszesz wiêc rm * ~. Ju¿ za pó¼no, zauwa¿y³e¶ dodatkow±
spacjê w poleceniu. W³a¶nie skasowa³e¶ ca³e swoje dzie³o ! Nadchodzi
pomoc. Dokument ten wyja¶nia jak odzyskiwaæ skasowane pliki w sys
temie plików Second Extended File System. Mo¿e uda Ci siê jednak opub
likowaæ Twój genialny program. Dokument ten zosta³ napisany w stan
dardzie ISO-8859-2. Orygina³ tego dokumentu znajduje siê pod adresem
http://pobox.com/~aaronc/ <http://pobox.com/~aaronc/>.
______________________________________________________________________
Spis tre¶ci
1. Wstêp
1.1 Historia publikacji
1.1.1 Zmiany w wersji 1.1
1.1.2 Zmiany w wersji 1.2
1.1.3 Zmiany w wersji 1.3
1.2 Inne lokalizacje tego dokumentu
2. Jak nie skasowaæ plików
3. Jakiego wspó³czynnika odzyskania skasowanych plików mogê siê spodziewaæ ?
4. Jak odzyskaæ skasowane pliki ?
5. Odmontowanie systemu plików
6. Przygotowanie do bezpo¶rednich zmian iwêz³ów
7. Przygotowanie do zapisu danych w innym miejscu
8. Szukanie skasowanych iwêz³ów
9. Uzyskiwanie szczegó³owych informacji o iwêz³ach
10. Odzyskiwanie bloków danych
10.1 Ma³e pliki
10.2 Wiêksze pliki
11. Bezpo¶rednie modyfikacje iwêz³ów
12. Czy bêdzie to kiedy¶ ³atwiejsze?
13. Czy s± jakie¶ programy automatyzuj±ce ten proces?
14. Kolofon
15. Wyrazy uznania i bibliografia
16. Formalno¶ci
17. Od t³umacza
______________________________________________________________________
11.. WWssttêêpp
To mini-Howto stara siê dostarczyæ porad jak odzyskiwaæ skasowane
pliki w systemie plików ext2. Zawiera ono równie¿ dyskusjê, jak przede
wszystkim, nie dopu¶ciæ do skasowania wa¿nych plików.
Chcia³bym, aby by³o ono przydatne dla ludzi, którym zdarzy³ siê ma³y
wypadek z rm; jakkolwiek mam równie¿ nadziejê, ¿e przeczytaj± je tak¿e
inni. Nigdy nie wiadomo, pewnego dnia, która¶ z zamieszczonych tu
informacji z mo¿e uratowaæ Ci ty³ek.
Tekst ten zak³ada ogóln± podstawow± wiedzê o systemie plików UNIX-a.
Mam jednak nadziejê, ¿e bêdzie dostêpny dla wiêkszo¶ci u¿ytkowników
Linux-a. Je¶li jeste¶ ca³kowicie pocz±tkuj±cy, obawiam siê, ¿e
odzyskiwanie plików _w_y_m_a_g_a ilo¶ci wiedzy technicznej, której nie
posiadasz.
Nie bêdziesz móg³ odtwarzaæ skasowanych plików z systemu plików ext2
bez praw odczytu do urz±dzenia, na którym by³y one przechowywane.
Ogólnie oznacza to, ¿e musisz byæ administatorem (root). Niektóre
dystrybucje (takie jak Debian GNU/Linux) tworz± grupê disk, której
cz³onkowie maj± dostêp do takich urz±dzeñ. Bêdziesz potrzebowa³ tak¿e
debugfs z pakietu e2fsprogs. Prawdopodobnie jest on ju¿ zainstalowany
przez Twoj± dystrybucjê.
Dlaczego to napisa³em? Wynik³o to g³ównie z moich w³asnych do¶wiadczeñ
ze zwyk³± g³upot± i katastrof± spowodowan± przez komendê rm -r
wykonywan± z prawami administratora. Skasowa³em 97 plików typu JPEG,
których potrzebowa³em i których prawie na pewno nie mo¿na by³o
odzyskaæ z innych ¼rode³. Z pomoc± u¿ytecznych wskazówek (patrz
rozdzia³ ``Wyrazy uznania i Bibliografia'') i du¿ej wytrwa³o¶ci,
odzyska³em 91 nieuszkodzonych plików. Uda³o mi siê odtworzyæ czê¶ciowo
nastêpne piêæ (wystarczaj±co, aby zobaczyæ co by³o na tych obrazkach).
Tylko jednego nie by³em w stanie obejrzeæ, ale nawet w tym przypadku,
jestem prawie pewien, ze stracone zosta³y nie wiecej ni¿ 1024 bajty
(niefortunnie z samego poczatku pliku; uwzglêdniaj±c to, ¿e nic nie
wiem o formacie JPG, zrobi³em wszystko co mog³em).
W dalszych rozwa¿aniach bêdê chcia³ przedstawiæ jakiej wielko¶ci
wspó³czynnika odtworzenia skasowanych plików mo¿esz siê spodziewaæ.
11..11.. HHiissttoorriiaa ppuubblliikkaaccjjii
Istniej± nastêpuj±ce upublicznione wersje tego dokumentu (i daty ich
publikacji):
· v1.0, 18 stycznia 1997
· v1.1, 23 lipca 1997 (patrz rozdzia³ ``Zmiany w wersji 1.1'')
· v1.2, 4 sierpnia 1997 (patrz rozdzia³ ``Zmiany w wersji 1.2'')
· v1.3, 2 lutego 1999 (patrz rozdzia³ ``Zmiany w wersji 1.3'')
11..11..11.. ZZmmiiaannyy ww wweerrssjjii 11..11
Jakie zmiany zosta³y zrobione w tej wersji? Przede wszystkim, zosta³
poprawiony b³±d w przyk³adowym odzyskiwaniu pliku. Dziêkujê wszystkim,
którzy napisali, ¿eby wskazaæ mi ten b³±d. Mam nadziejê, ¿e nauczy³em
siê byæ bardziej uwa¿nym przy interakcyjnej pracy z programem.
Po drugie, rozwa¿ania o systemie plików w UNIX-ie zosta³y przerobione
tak, aby uczyniæ je bardziej zrozumia³ymi. Od pocz±tku nie by³em z
tego zadowolony i dosta³em komentarze, ¿e nie by³o to napisane zbyt
jasno.
Po trzecie, uuencode'owany gzip-owany tar-owany pakiet fsgrab ze
¶rodka pliku zosta³ usuniêty. Teraz program dostêpny jest na mojej
stronie domowej <http://pobox.com/~aaronc/tech/fsgrab-1.2.tar.gz> i na
Metalab-ie <http://metalab.unc.edu/pub/Linux/utils/file/> (i kopiach,
w Polsce - Sunsite
<http://sunsite.icm.edu.pl/pub/Linux/sunsite/utils/file/> ).
Po czwarte, dokument ten zosta³ przet³umaczony na jêzyk sk³adu SGML
u¿ywany w Linux Documention Project. Ten jêzyk mo¿e byæ ³atwo
konwertowany do innych jêzyków sk³adu (np. HTML-a i LaTeX-a) w celu
dogodnego sposobu wy¶wietlania i drukowania. Jedn± z korzy¶ci z tego
jest to, ¿e ³adny wygl±d wersji papierowej jest ³atwiejszy do
osi±gniecia. Inn± jest to, ¿e dokument zawiera wewnêtrzne i zewnêtrzne
odno¶niki, gdy ogl±dany jest przez WWW.
11..11..22.. TToo wwyyddaanniiee zzaawwiieerraa wwyy³³±±cczznniiee ppoopprraawwkkii.. GG³³óówwnniiee uuwwzzggllêêddnnii³³eemm
zzmmiiaannyy ssuuggeerroowwaannee pprrzzeezz cczzyytteellnniikkóóww,, ttoo oonnee ss±± ww³³aa¶¶nniiee nnaajjwwaa¿¿nniieejjsszzee..
PPiieerrwwsszzaa zzmmiiaannaa zzoossttaa³³aa zzaassuuggeerroowwaannaa pprrzzeezz EEggiillaa KKvvaalleebbeerrggaaeeggiill@@kkvvaallee
bbeerrgg..nnoo,, kkttóórryy wwsskkaazzaa³³ nnaa ppoolleecceenniiee dduummpp ww ddeebbuuggffss .. JJeesszzcczzee rraazz,,
ddzziiêêkkii EEggiill.. DDrruuggaa zzmmiiaannaa ppoolleeggaa³³aa nnaa zzaazznnaacczzeenniiuu,, ¿¿ee uu¿¿yycciiee cchhaattttrr
ppoommaaggaa uunniikknn±±ææ sskkaassoowwaanniiaa wwaa¿¿nnyycchh pplliikkóóww.. DDzziieekkuujjêê HHeerrmmaannoowwii SSuuiijjss
HH..PP..MM..SSuuiijjss@@kkuubb..nnll zzaa zzaauuwwaa¿¿eenniiee tteeggoo.. SSttrreesszzcczzeenniiee zzoossttaa³³oo uuaakkttuuaall
nniioonnee.. ZZoossttaa³³yy ddooddaannee UURRLL--ee ddoo oorrggaanniizzaaccjjii ii oopprrooggrraammoowwaanniiaa.. WWpprroowwaadd
zzoonnoo wwiieellee iinnnnyycchh mmnniieejjsszzyycchh zzmmiiaann ((lliitteerróówwkkii ii ttyymm ppooddoobbnnee)).. ZZmmiiaannyy
ww wweerrssjjii 11..22
11..11..33.. ZZmmiiaannyy ww wweerrssjjii 11..33
Pomimo, ¿e jest to pierwsza wersja od 17 miesiêcy, jest tutaj ma³o
nowego. W wersji tej poprawione s± drobniejsze b³êdy (literówki, puste
URL-e, tego typu rzeczy -- szczególnie nie zwi±zane z Open Group),
uaktualniono kilka czê¶ci tekstu, które uleg³y przeterminowaniu,
takich jak partie dotycz±ce wersji j±dra i lde. No i zmieni³em
`Sunsite' na `Metalab'.
To wydanie jest przewidywane jako ostatnie przed wersj± 2.0, która,
mam nadziejê, bêdzie pe³nym Howto. Pracujê nad istotnymi zmianami,
które spowoduj± zwiêkszenie g³ównego numeru wersji.
11..22.. IInnnnee llookkaalliizzaaccjjee tteeggoo ddookkuummeennttuu
Najnowsza publiczna wersja tego dokumentu powinna byæ zawsze dostêpna
na Linux Documentation Project site <http://metalab.unc.edu/LDP/> (i
kopiach, w Polsce - Sunsite
<http://sunsite.icm.edu.pl/pub/Linux/sunsite/docs/LDP/> ).
Najbardziej aktualna wersja jest równie¿ przechowywana na mojej
stronie domowej <http://pobox.com/~aaronc/> w kilku formatach:
· ¼ród³o SGML <http://pobox.com/~aaronc/tech/e2-undel/howto.sgml>.
To jest format ¼ród³owy, tak jak to napisa³em u¿ywaj±c pakietu SGML
Tools.
· HTML <http://pobox.com/~aaronc/tech/e2-undel/html/>. To jest HTML,
automatycznie wygenerowany ze ¼ród³a SGML.
· czysty tekst <http://pobox.com/~aaronc/tech/e2-undel/howto.txt>.
To jest czysty tekst, który równie¿ zosta³ automatycznie
wygenerowany ze ¼ród³a SGML.
22.. JJaakk nniiee sskkaassoowwaaææ pplliikkóóww
Trzeba pamiêtaæ, ¿e Linux ró¿ni siê od MS-DOS je¶li chodzi o kasowanie
plików. W MS-DOS (jak i w Windows 95), dosyæ ³atwo jest odzyskaæ
skasowane pliki - `system operacyjny' (u¿ywam tego terminu dosyæ
swobodnie) dostarcza nawet narzêdzi, które automatyzuj± ten proces. W
Linux-ie jest inaczej.
Regu³a numer jeden (podstawowa wskazówka) brzmi:
RRÓÓBB KKOOPPIIEE ZZAAPPAASSOOWWEE
bez wzglêdu na wszystko. Pomy¶l o wszystkich swoich danych. Byæ mo¿e,
jak ja, trzymasz kilkuletni zbiór listów, kontaktów, programów,
dokumentów na swoim komputerze. Pomy¶l co by siê sta³o z Twoim ¿yciem,
gdyby Twój dysk uleg³ katastrofalnemu uszkodzeniu, lub gdyby -- o
wielkie nieba ! -- z³o¶liwy craker wyczy¶ci³ Twój dysk. To nie jest
niemo¿liwe; korespondowa³em z wieloma lud¼mi w takiej sytuacji. My¶lê,
¿e teraz wszyscy rozs±dnie my¶l±cy u¿ytkownicy Linux-a wyjd±, kupi±
urz±dzenie do robienia kopii zapasowych, opracuj± kalendarz
archiwizacji i _b_ê_d_± _s_i_ê _j_e_g_o _t_r_z_y_m_a_æ. Ja u¿ywam wolnego dysku twardego
w innym komputerze i okresowo kopiujê tam przez sieæ ethernet mój
katalog domowy. Wiêcej informacji o planowaniu kalendarza archiwizacji
znajdziesz u Frischa (1995) (patrz rozdzia³ ``Bibliografia i Wyrazy
Uznania'').
Co wtedy, gdy nie ma kopii zapasowej? (lub nawet przy istnieniu kopii
zapasowej: ¿adne ¶rodki bezpieczeñstwa nie s± z³ym rozwi±zaniem w
miejscu gdzie przechowywane s± wa¿ne dane).
Spróbuj ustawiæ prawa dostêpu do wa¿nych plików na 440 (lub mniej):
odebranie sobie samemu praw zapisu oznacza, ¿e rm bêdzie wymaga³
potwierdzenia przed skasowaniem. (Zauwa¿y³em, ¿e je¶li rekursywnie
kasujê katalog rm -r, pro¶ba potwierdzenia pojawi siê przy pierwszym i
drugim pliku, potem program zachowuje siê jak rm -rf).
Niez³± sztuczk± dla wybranych plików jest utworzenie w ukrytym
katalogu twardych dowi±zañ do nich. Kiedy¶ us³ysza³em historiê o
administatorze, który przez pomy³kê skasowa³ /etc/passwd (nieomal w
ten sposób niszcz±c system). Jednym z rozwi±zañ takiego k³opotu jest
zrobienie czego¶ nastêpuj±cego (jako root):
# mkdir /.backup
# ln /etc/passwd /.backup
Teraz skasowanie pliku wymaga wiêkszego wysi³ku: gdy napiszesz tylko
# rm /etc/passwd
wtedy
# ln /.backup/passwd /etc
odtworzy Twój plik. Oczywi¶cie, to rozwi±zanie nie pomo¿e je¶li
nadpiszesz plik, wiêc nie zapomninaj o kopii zapasowej.
W systemie plików ext2 jest mo¿liwe u¿ycie atrybutów ext2, aby
ochraniaæ pliki. Atrybuty te mog± byæ zmieniane za pomoc± komendy
chattr. Istnieje atrybut `append-only`: plik z tym atrybutem mo¿e byæ
tylko powiêkszany, nie mo¿e byæ skasowany i istniej±ca zawarto¶æ nie
mo¿e byæ nadpisana. Je¶li atrybut ten ma katalog, ka¿dy plik czy
katalog w nim le¿±cy mo¿e byæ normalnie modyfikowany, ale ¿aden z
plików nie mo¿e zostaæ skasowany. Atrybut `append-only' ustawia siê
poleceniem
$ chattr +a FILE...
Istnieje równie¿ atrybut `immutable', który mo¿e byæ zapalany lub
gaszony tylko przez administratora. Pliku lub katalogu z tym atrybutem
nie mo¿na zmienieniæ, skasowaæ, zmieniæ jego nazwy, czy utworzyæ do
niego twardego dowi±zania. Mo¿na go ustawiæ w nastêpuj±cy sposób:
# chattr +i FILE...
Ext2fs dostarcza równie¿ atrybutu `undeletable' (+u in chattr).
Za³o¿enie by³o takie, ¿e plik z tym atrybutem po skasowaniu zostaje
przeniesiony w bezpieczne miejsce `safe location', aby rzeczywiste
skasowanie przesun±æ w czasie. Niestety funkcja ta nie jest jeszcze
zaimplementowana w j±drze. My¶la³em, ¿e bêdzie wiêksze zainteresowanie
ni± i stanie siê to szybko, ale nie jest ona dostêpna (wed³ug mojej
wiedzy) w ¿adnej aktualnej wersji j±dra.
Niektórzy radz±, aby zrobiæ alias lub funkcjê w pow³oce rm, która
wykonywa³aby rm -i (bêdziesz musia³ potwierdziæ skasowanie _k_a_¿_d_e_g_o
pliku). Dystrubucja Red Hat <http://www.redhat.com/> robi to
domy¶lnie dla wszystkich u¿ytkowników, w tym i dla root-a. Ja
osobi¶cie nie lubiê oprogramowania, które nie mo¿e dzia³aæ bez mojej
pomocy, dlatego nie u¿ywam tego sposobu. Wcze¶niej, czy pó¼niej mo¿e
pojawiæ siê kolejny problem: kiedy bêdziesz pracowa³ w trybie singe-
user, lub bêdziesz u¿ywa³ innej pow³oki lub nawet innej maszyny, gdzie
Twoja funkcja rm nie istnieje. Je¶li bêdziesz spodziewa³ siê, ¿e ka¿de
skasowanie wymaga potwierdzenia, dosyæ ³atwo jest nie przewidzieæ
tego, ¿e kaza³e¶ skasowaæ zbyt wiele plików. Równie¿ skrypty i
programy, które podmieniaj± rm mog± byæ bardzo niebezpieczne.
Trochê lepszym rozwi±zaniem jest u¿ycie pakietu, który umo¿liwia
`odtwarzalne' kasowanie poprzez specjaln± komendê zastêpuj±ca rm.
Szczegó³y znajdziesz u Peeka (1993) (patrz rozdzia³ ``Bibliografia i
Wyrazy Uznania''). Jednak w ten sposób przyzwyczajamy u¿ytkownika do
pewniej nonszalancji przy kasowaniu plików. Nie jest to najlepsze,
bowiem system typu Unix wymaga jednak uwa¿nego dzia³ania.
33.. JJaakkiieeggoo wwssppóó³³cczzyynnnniikkaa ooddzzyysskkaanniiaa sskkaassoowwaannyycchh pplliikkóóww mmooggêê ssiiêê
ssppooddzziieewwaaææ ??
To zale¿y. Problem wynika z tego, ¿e w systemie operacyjnym wysokiej
jako¶ci, wielozadaniowym, wielou¿ytkownikowym, takim jak Linux, nie
mo¿esz przewidzieæ kiedy kto¶ zechce zapisaæ co¶ na dysk. Po chwili, w
której kaza³e¶ systemowi skasowaæ jaki¶ plik, bloki przez niego zajête
mog± zostaæ u¿yte, gdy system bêdzie chcia³ zapisaæ co¶ nowego. (Jest
to jeden przyk³ad ogólnej zasady systemów typu Unix: j±dro i zwi±zane
z nim programy zak³adaj±, ¿e u¿ytkownicy nie s± idiotami). Ogólnie
rzecz bior±c, im bardziej obci±¿ona jest Twoja maszyna, tym mniej
prawdopodobne jest odzyskanie plików.
Znaczenie mo¿e mieæ równie¿ fragmentacja dysku. Je¶li partycja, na
której by³ skasowany plik jest bardzo pofragmentowana, masz ma³e
szanse na odczytanie ca³ej jego tre¶ci.
Je¶li Twój komputer, tak jak mój, realnie jest maszyn±
jednou¿ytkownikow± i nie robi³e¶ niczego co intensywnie korzysta³o z
dysku w tragicznej chwili skasowania pliku, mo¿esz siê spodziewaæ
wspó³czynnika odzysku zbli¿onego do tego wymienionego ni¿ej. Ja
odzyska³em prawie 94% plików (by³y to pliki binarne) w stanie
nieuszkodzonym. Je¿eli otrzymasz 80% lub wiêcej, my¶lê, ¿e bêdziesz z
siebie zadowolony.
44.. JJaakk ooddzzyysskkaaææ sskkaassoowwaannee pplliikkii ??
Operacja ta polega g³ównie na znalezieniu danych na urz±dzeniu
partycji i uczynieniu ich ponownie widocznymi dla systemu
operacyjnego. S± dwa sposoby, ¿eby to zrobiæ: pierwszy polega na
takiej zmianie systemu plików, ¿eby usun±æ znacznik `deleted' ze
skasowanych iwêz³ów z nadziej±, ¿e pliki nagle pojawi± siê na swoim
miejscu. Inn± metod±, bezpieczniejsz±, ale wolniejsz± jest znalezienie
po³o¿enia interesuj±cych danych na partycji i zapisaniu ich jako nowy
plik w innym systemie plików.
Przed odtwarzeniem danych musisz zrobiæ kilka rzeczy; patrz rozdzia³y
``Odmontowanie systemu plików'', ``Przygotowanie do bezpo¶rednich
zmian w iwêz³ach'' i ``Przygotowanie do zapisania danych w innym
miejscu''. Informacjê jak odzyskiwaæ pliki znajdziesz w rozdzia³ach
``Szukanie skasowanych iwêz³ów'', ``Uzyskiwanie szczegó³owych
informacji o iwêz³ach'', ``Odzyskiwanie bloków danych'' i
``Bezpo¶rednie modyfikacje iwêz³ów''.
55.. OOddmmoonnttoowwaanniiee ssyysstteemmuu pplliikkóóww
Niezale¿nie od metody jak± wybra³e¶, pierwszym krokiem jest
odmontowanie systemu plików zawieraj±cego skasowane pliki.
Zdecydowanie nie polecam ¿adnych dzia³añ na zamontowanym systemie
plików. Krok ten powinien byæ wykonany najszybciej jak to bêdzie
mo¿liwe od momentu, gdy zauwa¿y³e¶, ¿e pomy³kowo skasowa³e¶ pliki. Im
szybciej odmontujesz system plików, tym wiêksza bêdzie szansa, ¿e
Twoje dane nie zostan± nadpisane (zamazane).
Najprostsz± metod±, aby to zrobiæ jest: zak³adaj±c, ¿e skasowane pliki
by³y systemie plików /usr,
# umount /usr
Je¶li chcesz mo¿esz równie¿ utrzymaæ widoczno¶æ katalogu /usr.
Zamontuj go w trybie tylko-do-odczytu:
# mount -o ro,remount /usr
W przypadku, gdy skasowane pliki by³y na g³ównej partycji musisz dodaæ
opcjê -n, aby zabroniæ programowi mount na próby zapisu do /etc/mtab:
# mount -n -o ro,remount /
Poza tym wszystkim, mo¿liwe jest równie¿, ¿e jaki¶ inny proces u¿ywa
interesuj±cego nas systemu plików (spowoduje to b³±d typu `Resource
busy' przy próbie odmontowania). fuser jest programem, który wy¶le
sygna³ do ka¿dego procesu u¿ywaj±cego wskazanego pliku lub punktu
montowania. Spróbuj tego dla partycji /usr:
# fuser -v -m /usr
W ten sposób uzyskasz listê przeszkadzaj±cych Ci procesów. Zak³adaj±c,
¿e ¿aden z nich nie jest niezbêdny, mo¿esz napisaæ
# fuser -k -v -m /usr
aby wys³aæ sygna³ SIGKILL do ka¿dego z nich ( gwarantuje to ich
zabicie), albo
# fuser -k -TERM -v -m /usr
aby przekazaæ ka¿demu sygna³ SIGTERM (spowoduje to normalne
zakoñczenie pracy procesów).
66.. PPrrzzyyggoottoowwaanniiee ddoo bbeezzppoo¶¶rreeddnniicchh zzmmiiaann iiwwêêzz³³óóww
Moja rada? Nie u¿ywaj tej metody. Nie uwa¿am, ¿eby dobrym pomys³em
by³a zabawa na niskim poziomie w systemie plików. Metoda ta stwarza
równie¿ problemy je¶li chcesz odtworzyæ pliki wiêksze ni¿ 12 bloków.
W celu odzyskania du¿ych plików, tak czy owak, bêdziesz musia³ u¿yæ
innej metody. (Chocia¿ patrz rozdzia³ ``Czy bêdzie to kiedy¶
³atwiejsze?'' w celu dodatkowych informacji.)
Je¿eli jednak chcesz koniecznie u¿yæ tego sposobu, lepiej skopiuj
bezpo¶rednio obraz partycji na inn± partycjê, a pó¼niej zamontuj j±
u¿ywaj±c pêtli zwrotnej (loopback):
# cp /dev/hda5 /root/working
# mount -t ext2 -o loop /root/working /mnt
(Niektóre wersje mount nie potrafi± tego zrobiæ. Je¶li Twój mount nie
dzia³a poprawnie, zalecam u¿ycie najnowszej wersji, conajmniej 2.7.
Du¿o starsze wersje maj± problemy z utrzymaniem bezpieczeñstwa
danych.)
U¿ywaj±c pêtli zwrotnej, nawet je¶li ca³kowicie zniszczysz system
plików, mo¿esz ponownie skopiowaæ partycjê i zacz±æ próby od nowa.
77.. PPrrzzyyggoottoowwaanniiee ddoo zzaappiissuu ddaannyycchh ww iinnnnyymm mmiieejjssccuu
Je¿eli wybierzesz tê drogê dzia³ania, musisz znale¼æ partycjê
ratunkow± -- miejsce, gdzie zapiszesz nowe kopie odzyskanych plików.
Na ca³e szczê¶cie, twój system zawiera kilka partycji: prawdopodobnie
partycjê g³ówn±, /usr i /home. Wybierz jedn± z nich i utwórz na niej
nowy katalog.
Je¶li masz tylko partycjê g³ówn± i wszystko przechowujesz na niej,
rozwi±zanie troszkê siê skomplikuje. Mo¿e masz partycje MS-DOS lub
Windows, której bedziesz móg³ u¿yæ ? Albo masz sterownik do ramdisk-u
w swoim j±drze, albo w module ? W celu u¿ycia ramdisk-u (zak³adaj±c,
¿e j±dro jest nowsze od 1.3.48), napisz:
# dd if=/dev/zero of=/dev/ram0 bs=1k count=2048
# mke2fs -v -m 0 /dev/ram0 2048
# mount -t ext2 /dev/ram0 /mnt
W ten sposób stworzy³e¶ 2MB wolumen ramdisk-u i zamontowa³e¶ do w
/mnt.
Krótkie ostrze¿enie: je¿eli u¿ywasz kerneld (lub zastêpuj±cego go kmod
w j±drach 2.2.x i pó¼nych 2.1.x) w celu automatycznego ³adowania i
od³adowywania modu³ów, nie odmontowuj ramdisk-u dopóki nie skopiujesz
wszystkich plików na bardziej trwa³y no¶nik. W chwili, gdy go
odmontujesz, kerneld zak³ada, ¿e mo¿e od³adowaæ modu³ (zwykle jednak
czeka pewien okres). Gdy to ju¿ siê stanie, pamiêæ zostanie u¿yta
przez inne czê¶ci j±dra i stracisz wszystkie godziny spêdzone na
odzyskiwaniu danych.
Je¿eli masz napêd Zip, Jaz, LS-120 lub co¶ podobnego, mo¿e on spe³niaæ
z powodzeniem rolê partycji ratunkowej. W pozosta³ych przypadkach,
u¿yj po prostu napêdu stacji dyskietek.
Bêdziesz jeszcze potrzebowa³ programu, który potrafi czytaæ dane ze
¶rodka partycji. W³a¶ciwie mo¿e to zrobiæ dd, ale aby przeczytaæ dane
le¿±ce od 600 MB do 800 MB, dd musi przeczytaæ i zignorowaæ pierwsze
600 MB. Zajmuje to dosyæ du¿o czasu, nawet na szybkich dyskach. Moim
sposobem na obej¶cie tego problemu by³o napisanie programu, który
przeskakuje w ¶rodek partycji. Nazywa siê on fsgrab; pakiet ze ¼ród³em
mo¿esz znale¼æ na mojej stronie domowej
<http://pobox.com/~aaronc/tech/fsgrab-1.2.tar.gz> lub na Metalab-ie
<http://metalab.unc.edu/pub/Linux/utils/file/> (i kopiach, w Polsce -
Sunsite <http://sunsite.icm.edu.pl/pub/Linux/sunsite/utils/file/> ).
Je¶li bêdziesz chcia³ stosowaæ tê metodê, w dalszej czê¶ci tego mini-
JTZ zak³adam, ¿e masz fsgrab.
Nie potrzebujesz fsgrab-a, je¿eli ¿aden z plików, które starasz siê
odzyskaæ, nie zajmuje wiêcej ni¿ 12 bloków (przewa¿nie blok ma rozmiar
jednego kilobajta).
Je¿eli musisz u¿yæ fsgrab-a, ale nie chce Ci siê go ¶ci±gaæ i
kompilowaæ, jest te¿ prosta droga na przet³umaczenie polecenia dla
fsgrab na polecenie dla dd. Maj±c
fsgrab -c _c_o_u_n_t -s _s_k_i_p _d_e_v_i_c_e
mo¿esz u¿yæ komendy dd (przewa¿nie jest to du¿o wolniejsze)
dd bs=1k if=_d_e_v_i_c_e count=_c_o_u_n_t skip=_s_k_i_p
Muszê Ciê ostrzec, ¿e chocia¿ dla mnie fsgrab dzia³a doskonale, nie
mogê braæ odpowiedzialno¶ci za jego funkcjonowanie. Pisa³em go dosy¶
szybko i niestarannie, po prostu, aby dzia³a³ poprawnie. Wiêcej
szczegó³ów o gwarancji znajdziesz w rozdziale `No Warranty' w pliku
COPYING do³aczonym do pakietu (the GNU General Public Licence).
88.. SSzzuukkaanniiee sskkaassoowwaannyycchh iiwwêêzz³³óóww
Nastêpnym krokiem jest odnalezienie w systemie plików tych iwêz³ów,
które zosta³y ostanio uwolnione. Do tego zadania u¿yjemy programu
debugfs. Uruchom debugfs z nazw± urz±dzenia, na którym przechowywany
jest system plików:
# debugfs /dev/hda5
Je¿eli chcesz bezpo¶rednio wprowadzaæ zmiany do iwêz³ów, dodaj opcjê
-w, aby umo¿liwiæ zapisywanie do systemu plików:
# debugfs -w /dev/hda5
lsdel jest poleceniem debugfs, które wyszukuje skasowane iwêz³y. Po
zachêcie programu, napisz wiêc:
debugfs: lsdel
Po chwili ¶wiergotania dysku, d³uga lista zostanie przekierowana do
Twojego ulubionego ³amacza na strony (ang. pager) (warto¶æ zmiennej
$PAGER). Powinienne¶ zachowaæ gdzie¶ kopiê tej listy. Je¿eli u¿ywasz
less, mo¿esz po prostu napisaæ -o i nazwê pliku wyj¶ciowego. W innym
razie, bêdziesz musia³ przes³aæ wyniki do pliku w inny sposób.
Spróbuj czego¶ takiego:
debugfs: quit
# echo lsdel | debugfs /dev/hda5 > lsdel.out
Teraz, tylko na podstawie czasu skasowania, rozmiaru, praw w³asno¶ci i
w³a¶ciciela musisz okre¶liæ, które iwêz³y nale¿a³y do skasowanych
plików. Bêdzie to prawdopodobnie proste zadanie je¶li wypadek
przydarzy³ siê 5 minut temu, je¶li nie, przeszukaj listê bardzo
uwa¿nie.
Polecam wydrukowanie sobie listy iwêz³ów, które chcesz odzyskaæ.
U³atwi Ci to dalsz± pracê.
99.. UUzzyysskkiiwwaanniiee sszzcczzeeggóó³³oowwyycchh iinnffoorrmmaaccjjii oo iiwwêêzz³³aacchh
debugfs dysponuje poleceniem stat, które wy¶wietla szczegó³owe
informacje o iwê¼le. Wykonaj tê komendê dla wszystkich iwêz³ów, które
chcesz odzyskaæ. Na przyk³ad, je¿eli interesuje Ciê iwêze³ o numerze
148003, napisz tak:
debugfs: stat <148003>
Inode: 148003 Type: regular Mode: 0644 Flags: 0x0 Version: 1
User: 503 Group: 100 Size: 6065
File ACL: 0 Directory ACL: 0
Links: 0 Blockcount: 12
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x31a9a574 -- Mon May 27 13:52:04 1996
atime: 0x31a21dd1 -- Tue May 21 20:47:29 1996
mtime: 0x313bf4d7 -- Tue Mar 5 08:01:27 1996
dtime: 0x31a9a574 -- Mon May 27 13:52:04 1996
BLOCKS:
594810 594811 594814 594815 594816 594817
TOTAL: 6
Gdy chcesz odzyskaæ wiele plików, dobrze bêdzie jak zautomatyzujesz
ten proces. Przy za³o¿eniu, ¿e Twoja lsdel lista interesuj±cych
iwêz³ów znajduje siê w pliku lsdel.out, napisz co¶ takiego:
# cut -c1-6 lsdel.out | grep "[0-9]" | tr -d " " > inodes
Nowy plik inodes zawiera tylko numery iwêz³ówm, które chcesz odzyskaæ,
po jednym w jednej linii. Zapisali¶my to, bowiem pó¼niej bardzo nam
siê przyda. Potem piszesz po prostu:
# sed 's/^.*$/stat <\0>/' inodes | debugfs /dev/hda5 > stats
i plik stats zawiera wyniki wszystkich poleceñ stat.
1100.. OOddzzyysskkiiwwaanniiee bbllookkóóww ddaannyycchh
Ta czê¶æ jest albo bardzo ³atwa, albo trudna, w zale¿no¶ci od tego,
czy plik który chcesz odzyskaæ zajmowa³ wiêcej ni¿ 12 bloków.
1100..11.. MMaa³³ee pplliikkii
Je¿eli plik ma mniej ni¿ 12 bloków, numery wszystkich bloków, które on
zajmuje zapisane s± w jednym iwê¼le. Mo¿esz odczytaæ je po wykonaniu
polecenie stat dla tego iwêz³a. Ponadto, w debugfs jest polecenie,
które automatycznie odzyskuje taki plik. We¼my ten sam przyk³ad co
poprzednio:
debugfs: stat <148003>
Inode: 148003 Type: regular Mode: 0644 Flags: 0x0 Version: 1
User: 503 Group: 100 Size: 6065
File ACL: 0 Directory ACL: 0
Links: 0 Blockcount: 12
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x31a9a574 -- Mon May 27 13:52:04 1996
atime: 0x31a21dd1 -- Tue May 21 20:47:29 1996
mtime: 0x313bf4d7 -- Tue Mar 5 08:01:27 1996
dtime: 0x31a9a574 -- Mon May 27 13:52:04 1996
BLOCKS:
594810 594811 594814 594815 594816 594817
TOTAL: 6
Plik ten zajmuje sze¶æ bloków. Poniewa¿ jest to mniej ni¿ 12, mo¿emy
u¿yæ debugfs, aby zapisaæ plik w nowym miejscu, na przyk³ad
/mnt/recovered.000:
debugfs: dump <148003> /mnt/recovered.000
Oczywi¶cie mo¿na to zrobiæ równie¿, pos³uguj±c siê fsgrab. Poka¿ê jak
wygl±da takie przyk³adowe wywo³anie:
# fsgrab -c 2 -s 594810 /dev/hda5 > /mnt/recovered.000
# fsgrab -c 4 -s 594814 /dev/hda5 >> /mnt/recovered.000
Zarówno przy korzystaniu z debugfs jak i fsgrab, na koñcu pliku
/mnt/recovered.000 pozostan± ¶mieci. Nie ma to wiêkszego znaczenia.
£atwo mo¿na siê ich pozbyæ. Najprostsz± metod± jest odczytanie pola
Size w iwê¼le i wpisanie tej warto¶ci za opcj± bs komendy dd:
# dd count=1 if=/mnt/recovered.000 of=/mnt/resized.000 bs=6065
Mo¿e siê okazaæ, ¿e jeden lub wiêcej z bloków zosta³o straconych,
bowiem zosta³y ju¿ nadpisane. Je¿eli tak bêdzie, po prostu nie mia³e¶
szczê¶cia: bloki te odesz³y ju¿ na zawsze. (Wybra¼ sobie, ¿e
odmontowa³e¶ je wcze¶niej!)
1100..22.. WWiiêêkksszzee pplliikkii
Problem pojawia siê, gdy plik zajmuje wiêcej ni¿ 12 bloków danych.
Przypadek ten wymaga pewnej wiedzy o tym jak zbudowany jest system
plików UNIX-a. Dane pliku przechowywane s± w jednostkach zwanych
`blokami'. Bloki te s± numerowane sekwencyjnie. Ka¿dy plik ma
równie¿ `iwêze³', w którym przechowywane s± informacje typu:
w³a¶ciciel, prawa dostêpu i typ. Podobnie jak bloki, iwêz³y s±
numerowane sekwencyjnie, chocia¿ maj± one ró¿ne numeracje. Pozycja w
katalogu odpowiadaj±ca plikowi sk³ada siê z jego nazwy i numeru
iwêz³a.
Jednak na postawie tych informacji j±dro nie jest jeszcze w stanie
odnale¼æ na partycji danych odpowiadaj±cych jednej z pozycji w
katalogu. ¯eby to umo¿liwiæ, iwêze³ przechowuje po³o¿enia bloków
danych zajmowanych przez plik. Zorganizowane jest to w nastêpuj±cy
sposób:
· Numery pierwszych 12 bloków danych przechowywane s± bezpo¶rednio w
iwê¼le; czasami nazywa siê je _b_l_o_k_a_m_i _b_e_z_p_o_¶_r_e_d_n_i_m_i.
· Iwêze³ zawiera numer _p_o_¶_r_e_d_n_i_e_g_o _b_l_o_k_u. Blok po¶redni zawiera
numery nastêpnych 256 bloków z danymi.
· Iwêze³ zawiera numer _p_o_d_w_ó_j_n_i_e _p_o_¶_r_e_d_n_i_e_g_o _b_l_o_k_u. Blok podwójnie
po¶redni zawiera numery dodatkowych 256 bloków po¶rednich.
· Iwêze³ zawiera numer _p_o_t_r_ó_j_n_i_e _p_o_¶_r_e_d_n_i_e_g_o _b_l_o_k_u. Blok potrójnie
po¶redni zawiera numery dodatkowych 256 bloków podwójnie
po¶rednich.
Przeczytaj to jeszcze raz: wiem, ¿e to jest skomplikowane, ale bardzo
wa¿ne.
Niestety wszystkie implementacje j±dra, a¿ do wersji 2.0.36 podczas
kasowania pliku zeruj± bloki po¶rednie (podwójnie po¶rednie, itd.).
Je¶li Twój plik jest wiêkszy ni¿ 12 bloków, nie masz gawarancji, ¿e
bêdzie mo¿liwe odnalezienie numerów wszystkich jego bloków, nie mówi±c
ju¿ nic o ich zawarto¶ci.
Jedyn± metod± jak± uda³o mi siê znale¼æ, jest oparcie siê na
za³o¿eniu, ¿e plik nie by³ pofragmentowany. Je¿eli by³, masz powa¿ny
problem. Zak³adaj±c, ¿e plik nie by³ pofragmentowany, istnieje kilka
sekcji bloków danych, w zale¿no¶ci od tego ile bloków danych zajmuje
plik:
00 ddoo 1122
Numery bloków przechowywane s± w iwê¼le, jak to by³o opisane
wcze¶niej.
1133 ttoo 226688
Po blokach bezpo¶rednich, odlicz jeden na blok po¶redni, dalej
znajduje siê 256 bloków danych.
226699 ddoo 6655880044
Tak jak poprzednio jest: 12 bezpo¶rednich bloków, (nieprzydatny)
blok po¶redni i 256 bloków. Po tym wszystkim nastêpuje
(nieprzydatny) podwójnie po¶redni blok oraz 256 powtórzeñ
jednego (nieprzydatnego) bloku po¶redniego i 256 bloków danych.
6655880055 lluubb wwiiêêcceejj
Po³o¿enie piewszych 65804 bloków jak wy¿ej. Potem potrójnie
po¶redni blok i 256 powtórzeñ `sekwecji podwójnie po¶redniej'.
Ka¿da podwójnie po¶rednia sekwencja zawiera (nieprzydatny)
podwójnie po¶redni blok, po którym nastêpuje 256 powtórzeñ
jednego (nieprzydatnego) bloku po¶redniego i 256 bloków danych.
Oczywi¶cie, nawet je¶li numery bloków, które przyjêli¶my, s± poprawne,
nie ma ¿adnych gwarancji, ¿e dane s± w nich s± nienaruszone.
Dodatkowo, im d³u¿szy by³ plik, tym mniejsze szanse, ¿e system
operacyjny zapisa³ go bez ¿adnej fragmentacji (za wyj±tkiem
wyj±tkowych sytuacji).
Za³o¿y³em, ¿e rozmiar Twoich bloków wynosi 1024 bajty, tyle ile
warto¶æ standardowa. Je¶li Twój blok jest wiêkszy, niektóre z liczb
podanych wy¿ej zmieni± siê. Sprecyzujmy: dopóki numer ka¿dego bloku
ma d³ugo¶æ 4 bajtów, rozmiarbloku/4 jest liczb± numerów bloków, które
mog± byæ przechowane w ka¿dym bloku po¶rednim. Ka¿de wyst±pienie
liczby 256 we wcze¶niejszym opisie, zast±p na rozmiarbloku/4. Zmianie
ulegn± równie¿ ograniczenia na ilo¶æ wymaganych bloków.
Popatrz na przyk³adowe odzyskiwanie du¿ego pliku.
debugfs: stat <1387>
Inode: 148004 Type: regular Mode: 0644 Flags: 0x0 Version: 1
User: 503 Group: 100 Size: 1851347
File ACL: 0 Directory ACL: 0
Links: 0 Blockcount: 3616
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x31a9a574 -- Mon May 27 13:52:04 1996
atime: 0x31a21dd1 -- Tue May 21 20:47:29 1996
mtime: 0x313bf4d7 -- Tue Mar 5 08:01:27 1996
dtime: 0x31a9a574 -- Mon May 27 13:52:04 1996
BLOCKS:
8314 8315 8316 8317 8318 8319 8320 8321 8322 8323 8324 8325 8326 8583
TOTAL: 14
Wydaje siê, ¿e mamy pewne szanse, ¿e plik nie jest pofragmentowany.
Pewne jest tylko, ¿e pierwsze 12 bloków, których numery s± zawarte w
iwê¼le, jest `po kolei'. Mo¿emy wiêc odtworzyæ te bloki:
# fsgrab -c 12 -s 8314 /dev/hda5 > /mnt/recovered.001
Nastêpny blok, wymieniony w iwê¼le, 8326, jest blokiem po¶rednim,
który ignorujemy. Mamy jednak nadziejê, ¿e nastepne 256 bloków jest
naszymi blokami danych (numery 8327 do 8582).
# fsgrab -c 256 -s 8327 /dev/hda5 >> /mnt/recovered.001
Ostatnim blokiem wymienionym w iwê¼le jest 8583. Nadal zak³adamy, ¿e
istnieje ci±g³o¶æ w blokach. Jest to jednak uzasadnione bowiem:
ostatnim blokiem danych by³ blok o numerze 8582 (8327 + 255). Blok
8583 jest podwójnie po¶redni i mo¿e byæ zignorowany. Teraz mo¿e
nast±piæ do 256 powtórzeñ bloku po¶redniego (który mo¿na pomin±æ) i
256 bloków danych. Trochê arytmetyki i ju¿ mo¿na pisaæ kolejne
polecenie. Zauwa¿, ¿e pominêli¶my podwójnie po¶redni blok 8583 oraz
po¶redni blok 8584 i rozpoczêli¶my czytaæ dane od bloku numer 8585.
# fsgrab -c 256 -s 8585 /dev/hda5 >> /mnt/recovered.001
# fsgrab -c 256 -s 8842 /dev/hda5 >> /mnt/recovered.001
# fsgrab -c 256 -s 9099 /dev/hda5 >> /mnt/recovered.001
# fsgrab -c 256 -s 9356 /dev/hda5 >> /mnt/recovered.001
# fsgrab -c 256 -s 9613 /dev/hda5 >> /mnt/recovered.001
# fsgrab -c 256 -s 9870 /dev/hda5 >> /mnt/recovered.001
Dodajmy to wszystko, zapisali¶my do tej pory 12 + (7 * 256) bloków, co
daje 1804. Wyniki polecenia `stat' dla iwêz³a da³y nam `blockcount'
(liczba bloków) równe 3616. Niestety s± to bloki o rozmiarze 512
bajtów (zasz³o¶æ z UNIX-a), na prawdê potrzebujemy wiêc 3616/2 = 1808
bloków o rozmiarze 1024 bajty. Oznacza to, ¿e musimy jeszcze odnale¼æ
cztery bloki. Ostatni przeczytany blok danych mia³ numer 10125. Tak
jak to robili¶my do tej pory, pomijamy blok po¶redni (numer 10126) i
mo¿emy ju¿ zapisaæ ostatnie cztery bloki.
# fsgrab -c 4 -s 10127 /dev/hda5 >> /mnt/recovered.001
Przy pewnym szczê¶ciu uda³o nam siê odzyskaæ ca³y plik.
1111.. BBeezzppoo¶¶rreeddnniiee mmooddyyffiikkaaccjjee iiwwêêzz³³óóww
Metoda ta jest du¿o prostsza. Jednak, tak jak wspomnia³em wcze¶niej,
nie mo¿e byæ jeszcze stosowana do plików wiêkszych ni¿ 12 bloków.
W ka¿dym iwê¼le, który chcesz odzyskaæ musisz ustawiæ licznik
pod³±czeñ (linkcount) na jeden i czas skasowania (deletion time) na
zero. Robi siê to za pomoc± polecenia mi (modify inode) w debugfs.
Przyk³adowe wywo³anie, modyfikacja iwêz³a 148003 (tego co wcze¶niej):
debugfs: mi <148003>
Mode [0100644]
User ID [503]
Group ID [100]
Size [6065]
Creation time [833201524]
Modification time [832708049]
Access time [826012887]
Deletion time [833201524] 0
Link count [0] 1
Block count [12]
File flags [0x0]
Reserved1 [0]
File acl [0]
Directory acl [0]
Fragment address [0]
Fragment number [0]
Fragment size [0]
Direct Block #0 [594810]
Direct Block #1 [594811]
Direct Block #2 [594814]
Direct Block #3 [594815]
Direct Block #4 [594816]
Direct Block #5 [594817]
Direct Block #6 [0]
Direct Block #7 [0]
Direct Block #8 [0]
Direct Block #9 [0]
Direct Block #10 [0]
Direct Block #11 [0]
Indirect Block [0]
Double Indirect Block [0]
Triple Indirect Block [0]
Ustawi³em czas skasowania na 0, licznik pod³±czeñ na 1 i nacisn±³em
Enter dla wszystkich innych pól. Jest to pewn± niedogodno¶ci±, je¿eli
masz wiele plików do odzyskania. My¶lê jednak, ¿e mo¿na z tym ¿yæ.
Je¶li oczekujesz wygody, lepiej zacznij u¿ywaæ graficznego `systemu
operacyjnego' ze ¶licznym `Koszem na ¶mieci'.
Przy okazji: polecenie mi pokazuje `Czas stworzenia' (Creation time) w
iwê¼le. To k³amstwo ! (lub, jak kto woli, pomy³ka.) Prawda jest taka,
¿e nie mo¿na w systemie plików UNIX-a stwierdziæ kiedy dany plik
zosta³ utworzony. Pole st_ctime w struct stat zawiera `czas zmiany
iwêz³a', czyli czas ostaniej zmiany, którego¶ z parametrów iwêz³a. To
tyle z dzisiejszej lekcji.
Nowsze wersje debugfs ni¿ moja, prawdopodobnie nie wy¶wietalaj±
niektórych pól w iwê¼le (szczególnie, Reserved1 i Fragment).
Po zmianie w iwêz³ach, mo¿esz wyj¶æ z debugfs i napisaæ:
# e2fsck -f /dev/hda5
Pomys³ polega na tym, ¿e ka¿dy ze skasowanych plików zosta³
odkasowany, ale nie pojawi³ siê w ¿adnym katalogu. Program e2fsck
umie to wykryæ i doda pozycjê dla ka¿dego z nich w katalogu
/lost+found systemu plików. (Je¿eli partycja by³a zamontowana w /usr,
pliki pojawi± siê w /usr/lost+found, gdy j± zamontujesz.) Prac±, któr±
musisz jeszcze zrobiæ, to nadanie plikom nazw i umieszczenie ich we
w³a¶ciwym miejscu drzewa plików.
Po uruchomieniu e2fsck, wy¶wietli Ci on trochê informacji, ale zada
równie¿ pytania, które zniszczenia naprawiaæ. Odpowiadaj `yes' (tak)
na wszystko co dotyczy `summary information' lub iwêz³ów, które
zmienia³e¶. Resztê pozostawiam do Twojej decyzji, pamiêtaj, ¿e nie
jest najlepsz± metod± odpowiadanie `tak' na wszystkie pytania. Po
skoñczeniu pracy przez e2fsck, mo¿esz ponownie zamontowaæ system
plików.
Istnieje alternatywne rozwi±zanie do pozwolenia, aby e2fsck utworzy³
pliki w /lost+found. Mo¿esz u¿yæ debugfs i stworzyæ w systemie plików
do³±czenie (link) do iwêz³a. S³u¿y do tego polecenie link w debugfs,
po zmianach w samym iwê¼le:
debugfs: link <148003> foo.txt
W ten sposób powstanie w bie¿±cym katalogu plik o nazwie foo.txt;
foo.txt bêdzie Twoim odzyskanym plikiem. Nadal musisz jednak
uruchomiæ e2fsck, aby uaktualniæ informacje ogólne, liczniki bloków
itp. itd.
1122.. CCzzyy bbêêddzziiee ttoo kkiieeddyy¶¶ ³³aattwwiieejjsszzee??
Tak. W³a¶ciwie, mam nadziejê, ¿e tak. Chocia¿, gdy to piszê,
aktualna, stabilna wersja j±dra (seria 2.0.x) zeruje bloki po¶rednie.
Wersje serii rozwojowej 2.1.x i stabilnej 2.2.x nie maj± tej wady.
Dzisiaj, 2 lutego 1999 minê³o dopiero kilka dni od wydania j±dra
2.2.1; prawdopodobnie pojawi siê ono w dystrybucjach za jeden, dwa
miesi±ce.
Kiedy wersje j±dra rozwi±¿± problem zerowania bloków po¶rednich, wiele
moich rêcznych technik modyfikacji iwêz³ów nie bêdzie ju¿ potrzebnych.
W tym samym czasie stanie siê mo¿liwe u¿ycie polecenia dump w debugfs
dla du¿ych plików i innych programów narzêdziowych do odzyskiwania
plików.
1133.. CCzzyy ss±± jjaakkiiee¶¶ pprrooggrraammyy aauuttoommaattyyzzuujj±±ccee tteenn pprroocceess??
Pewnie, ¿e s±. Niestety cierpi± one na te same problemy co rêczna
technika zmian w iwêz³ach: bloki po¶rednie s± nieodzyskiwalne. Warto
im siê przyjrzeæ, bowiem wydaje siê, ¿e ograniczenie to wkrótce
zniknie.
Napisa³em program e2recover, który jest w³a¶ciwie tylko Perl-ow±
otoczk± dooko³a fsgrab. Stara siê on poradziæ sobie z wyzerowanymi
blokami po¶rednimi i wydaje sie, ¿e dzia³a ca³kiem nie¼le dla du¿ych
plików, które nie uleg³y fragmentacji. Ustawia poprawne prawa dostêpu
(i w³a¶ciciela, gdy to jest mo¿liwe). Upewnia siê równie¿, ¿e
odzyskiwany plik ma poprawny rozmiar.
Program e2recover by³ planowany jako czê¶æ powa¿nych zmian w tym
Howto; oznacza to niestety, ¿e wiêcej u¿ytecznej dokumentacji do
e2recover bêdzie zamieszczone dopiero w nowej wersji tego dokumentu.
Jednak i teraz mo¿e on siê komu¶ przydaæ; mo¿na go ¶ci±gn±æ z mojej
strony domowej <http://pobox.com/~aaronc/tech/e2-undel/>, i wkrótce z
Metalab-a (jest ju¿ w Polsce - Sunsite
<http://sunsite.icm.edu.pl/pub/Linux/sunsite/utils/file/>).
Scott D. Heavner jest autorem programu lde, the Linux Disk Editor.
Mo¿e on byæ u¿ywany zarówno jako binarny edytor dysku i jako
odpowiednik debugfs dla systemów plików ext2 i minix, a nawet dla
systemu plików xia (chocia¿ wsparcie dla xia przesta³o byæ dostêpne w
j±drach 2.1.x i 2.2.x). Zawarto w nim kilka pomys³ów wspomagaj±cych
odzyskiwanie skasowanych plików: ¶ledzenie listy bloków tworz±cych
plik i wyszukiwanie danych na dysku. Zawiera on tak¿e ca³kiem
u¿yteczn± dokumentacjê o podstawach systemu plików oraz jak go u¿ywaæ
do odzyskiwania plików skasowanych. Wersja 2.4 lde jest dostêpna na
Metalab-ie
<http://metalab.unc.edu/pub/Linux/system/filesystems/lde-2.4.tar.gz>
(i kopiach, w Polsce - Sunsite
<http://sunsite.icm.edu.pl/pub/Linux/sunsite/system/filesystems/lde-2.4.tar.gz>),
lub na stronie domowej autora
<http://www.geocities.com/CapeCanaveral/Lab/7731/lde.html>.
Inne mo¿liwo¶ci oferowane s± przez GNU Midnight Commander, mc. Jest to
pe³noekranowe narzêdzie do zarz±dzania plikami, oparte na znanym w
¶rodowisku MS-DOS programie o nazwie `NC'. mc obs³uguje mysz zarówno
na konsoli, jak i w oknie xterm-a, dostarcza mechanizm wirtualnych
systemów plików, co umo¿liwia triki takie jak cd do archiwum tar.
Odzyskiwanie plików obs³ugiwane jest przez jeden z takich wirtualnych
systemów plików. Wszystko to brzmi bardzo zachêcaj±co, ale muszê
przyznaæ, ¿e nie u¿ywam tego programu -- wolê staromodne polecenia
pow³oki.
Aby u¿ywaæ mo¿liwo¶ci odzyskiwania skasowanych plików, musisz
skonfigurowaæ program z opcj± --with-ext2undel; bêdziesz równie¿
potrzebowa³ bibliotek w wersji rozwojowej i niektórych plików
zawartych w pakiecie e2fsprogs. W ten sposób zbudowana jest wersja
dostarczana w Debian GNU/Linux <http://www.debian.org/>; tak samo mo¿e
byæ w innych dystrybucjach. Teraz mo¿esz po prostu kazaæ mu cd
undel:/dev/hda5, i otrzymasz `zawarto¶æ katalogu' ze skasowanymi
plikami. Jak wiele innych i ten program bardzo ¼le radzi sobie z
zerowaniem bloków po¶rednich -- przewa¿nie odtwarza tylko pierwsze 12k
wiêkszych plików.
Aktualn± wersjê mo¿na ¶ci±gn±æ z serwera ftp the Midnight Commander
<ftp://ftp.nuclecu.unam.mx/Midnight/devel/>.
1144.. KKoollooffoonn
Mam zamiar regularnie uaktualniaæ ten dokument tak d³ugo jak bêdê mia³
wystarczaj±co du¿o czasu i co¶ ciekawego do powiedzenia. Oznacza to,
¿e bardzo mi zale¿y na komentarzach od czytelników. Czy moje pisanie
mo¿e byæ bardziej zrozumia³e? Czy my¶licie o czym¶, co uczyni³oby
problem prostszym? Jest jaki¶ program, który robi to wszystko
automatycznie? Je¿eli masz co¶ do powiedzenia o tym dokumencie, albo o
fsgrab, albo o e2recover, napisz do mnie aaronc@pobox.com.
1155.. WWyyrraazzyy uuzznnaanniiaa ii bbiibblliiooggrraaffiiaa
`Je¿eli widzê dalej od innych, to dlatego, ¿e stojê na
ramionach olbrzymów.' (Isaac Newton)
To mini-Howto wywodzi siê z listu zamieszczonego w grupie
comp.os.linux.misc przez Robina Glovera swrglovr@met.rdg.ac.uk.
Chcia³bym podziekowaæ Robinowi za wspania³omy¶lne pozwolenie na
przetworzenie jego pomys³ów w to mini-Howto.
Korzystaj±c z okazji, chcia³bym jeszcze raz podziêkowaæ wszystkim,
którzy napisali do mnie o tym Howto. Otrzymywanie wyrazów
wdzieczno¶ci czyni pracê wart± wysi³ku.
Niektóre odno¶niki bibliograficzne:
· FFrriisscchh, Æleen (1995), _E_s_s_e_n_t_i_a_l _S_y_s_t_e_m _A_d_m_i_n_i_s_t_r_a_t_i_o_n, second e
O'Reilly and Associates, Inc., ISBN: 1-56592-127-5.
· GGaarrffiinnkkeell, Simson, Daniel WWeeiissee and Steven SSttrraassssmmaannnn (1994), _T_h_e
_U_n_i_x_-_H_a_t_e_r_s _H_a_n_d_b_o_o_k, IDG Books, ISBN: 1-56884-203-1. Wiêkszo¶æ
tej ksi±¿ki wype³niaj± jednynie m³odociane jêki ludzi, którzy my¶l±
¿e _i_c_h system operacyjny by³ o wiele lepszy od Unix-a; a reszta
ksi±¿ki nie dotyczy Ciê, je¿eli u¿ywasz dobrego otoczenia
u¿ytkownika jakim jest GNU. S± tam jednak pewne ciekawe rzeczy; na
przyk³ad, dyskusja o tym jak ³atwo jest skasowaæ plik pod Unix-em
warta jest przeczytania.
· GGlloovveerr, Robin (31 Jan 1996), _H_O_W_-_T_O _: _u_n_d_e_l_e_t_e _l_i_n_u_x _f_i_l_e_s
_(_e_x_t_2_f_s_/_d_e_b_u_g_f_s_), comp.os.linux.misc Usenet posting.
· PPeeeekk, Jerry, Tim OO''RReeiillllyy, Mike LLoouukkiiddeess et al (1993), _U_N_I_X _P_o_w_e_r
_T_o_o_l_s, O'Reilly and Associates, Inc./Random House, Inc., ISBN:
0-679-79073-X. Second edition, 1998.
1166.. FFoorrmmaallnnoo¶¶ccii
Wszystkie znaki towarowe s± w³asno¶ci± ich prawowitych w³a¶cicieli.
Konkretnie:
· _M_S_-_D_O_S i _W_i_n_d_o_w_s s± znakami towarowymi Microsoftu
<http://www.microsoft.com/>.
· _U_N_I_X jest znakiem towarowym the Open Group
<http://www.opengroup.org/>.
· _L_i_n_u_x jest znakiem towarowym zarejestrowanym w USA i kilku innych
pañstwach dla Linusa Torvalds.
Prawa autorskie do tego dokumentu 1997, 1999 posiada Aaron Crane
aaronc@pobox.com. Mo¿e on byæ darmowo rozpowszechniany w ca³o¶ci,
³±cznie z t± not± autorsk±. Nie mo¿e byæ zmieniany bez zgody autora
lub koordynatora Linux Documentation Project HOWTO. Nie dotyczy to
tylko kopiowania jego czê¶ci w celu przegl±dania lub cytowania; w
takim przypadku, czê¶ci te musz± byæ poprawnymi cytatami i nie musz±
zawieraæ noty o prawach autorskich.
Autor oczekuje, ale nie wymaga, ¿e ten kto bêdzie chcia³ sprzedawaæ
kopie tego dokumentu, niezale¿nie od tego, czy na no¶niku
elektronicznym, czy papierowym, poinformuje jego lub koordynatora
projektu Linux HOWTO o swoich zamiarach.
Koordynatorem projektu Linux HOWTO jest aktulanie Tim Bynum linux-
howto@sunsite.unc.edu.
1177.. OOdd tt³³uummaacczzaa
Stara³em siê, aby t³umaczenie by³o najwierniejsze z mo¿liwych. Dlatego
nie ma ¿adnych zmian w stosunku do orgina³u, za wyj±tkiem odno¶ników
do polskiej kopii serwera Metalab na Sunsite.icm.edu.pl.
Czekam na komentarze pod adresem: Bartosz Sawicki
sawickib@ee.pw.edu.pl.
