1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<META HTTP-EQUIV="content-type" content="text/html; charset=iso-8859-2">
<TITLE>Linux Ext2fs Undeletion mini-HOWTO</TITLE>
</HEAD>
<BODY>
<H1>Linux Ext2fs Undeletion mini-HOWTO<BR></H1>
<H2>Autor: Aaron Crane
<A HREF="mailto:aaronc@pobox.com">aaronc@poboc.com</A><BR>
v1.3, 2 lutego 1999<BR> <B>Wersja polska: Bartosz Sawicki
<A HREF="mailto:sawickib@ee.pw.edu.pl">sawickib@ee.pw.edu.pl</A><BR></B>
v1.0, 15 kwietnia 1999 </H2>
<P><HR>
<EM>Wyobra sobie. Trzy ostatnie trzy dni spêdzie bez snu, jedzenia, a nawet bez
prysznica. Wanie ukoñczye program, który przyniesie Ci wiatow
sawê i uznanie. Musisz go jeszcze tylko starowaæ i umieciæ na
Metalab-ie. No, i skasowaæ wszystkie kopie zapasowe tworzone przez Emacs-a.
Piszesz wiêc <CODE>rm * ~</CODE>. Ju za póno, zauwaye dodatkow spacjê w
poleceniu. Wanie skasowae cae swoje dzieo !
Nadchodzi pomoc. Dokument ten wyjania jak odzyskiwaæ skasowane pliki w
systemie plików Second Extended File System. Moe uda Ci siê jednak opublikowaæ Twój genialny program.
Dokument ten zosta napisany w standardzie ISO-8859-2.
Orygina tego dokumentu znajduje siê pod adresem
<A HREF="http://pobox.com/~aaronc/">http://pobox.com/~aaronc/</A>.</EM>
<HR>
<H2><A NAME="s1">1. Wstêp</A></H2>
<P>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
dopuciæ do skasowania wanych plików.
<P>Chciabym, aby byo ono przydatne dla ludzi, którym zdarzy siê may wypadek z
<CODE>rm</CODE>; jakkolwiek mam równie nadziejê, e przeczytaj je take inni.
Nigdy nie wiadomo, pewnego dnia, która z zamieszczonych tu informacji z moe
uratowaæ Ci tyek.
<P>Tekst ten zakada ogóln podstawow wiedzê o systemie plików UNIX-a.
Mam jednak nadziejê, e bêdzie dostêpny dla wiêkszoci uytkowników Linux-a.
Jeli jeste cakowicie pocztkujcy, obawiam siê, e odzyskiwanie plików
<EM>wymaga</EM> iloci wiedzy technicznej, której nie posiadasz.
<P>Nie bêdziesz móg odtwarzaæ skasowanych plików z systemu plików ext2 bez praw
odczytu do urzdzenia, na którym byy one przechowywane. Ogólnie oznacza to,
e musisz byæ administatorem (root). Niektóre dystrybucje (takie jak
<A HREF="http://www.debian.org/">Debian GNU/Linux</A>) tworz
grupê <CODE>disk</CODE>, której czonkowie maj dostêp do takich urzdzeñ.
Bêdziesz potrzebowa take <CODE>debugfs</CODE> z pakietu <CODE>e2fsprogs</CODE>.
Prawdopodobnie jest on ju zainstalowany przez Twoj dystrybucjê.
<P>Dlaczego to napisaem? Wyniko to gównie z moich wasnych dowiadczeñ ze
zwyk gupot i katastrof spowodowan przez komendê <CODE>rm -r</CODE> wykonywan
z prawami administratora. Skasowaem 97 plików typu JPEG, których potrzebowaem
i których prawie na pewno nie mona byo odzyskaæ z innych rode. Z pomoc
uytecznych wskazówek (patrz rozdzia
<A HREF="#sec-credits">Wyrazy uznania i Bibliografia</A>) i duej wytrwaoci, odzyskaem 91 nieuszkodzonych
plików. Udao mi siê odtworzyæ czêciowo nastêpne piêæ (wystarczajco, aby
zobaczyæ co byo na tych obrazkach). Tylko jednego nie byem w stanie obejrzeæ,
ale nawet w tym przypadku, jestem prawie pewien, ze stracone zostay nie wiecej
ni 1024 bajty (niefortunnie z samego poczatku pliku; uwzglêdniajc to,
e nic nie wiem o formacie JPG, zrobiem wszystko co mogem).
<P>W dalszych rozwaaniach bêdê chcia przedstawiæ jakiej wielkoci wspóczynnika
odtworzenia skasowanych plików moesz siê spodziewaæ.
<P>
<H2>1.1 Historia publikacji</H2>
<P>Istniej nastêpujce upublicznione wersje tego dokumentu (i daty ich
publikacji):
<P>
<UL>
<LI>v1.0, 18 stycznia 1997
</LI>
<LI>v1.1, 23 lipca 1997 (patrz rozdzia
<A HREF="#sec-v1.1">Zmiany w wersji 1.1</A>)
</LI>
<LI>v1.2, 4 sierpnia 1997 (patrz rozdzia
<A HREF="#sec-v1.2">Zmiany w wersji 1.2</A>)
</LI>
<LI>v1.3, 2 lutego 1999 (patrz rozdzia
<A HREF="#sec-v1.3">Zmiany w wersji 1.3</A>)
</LI>
</UL>
<P>
<H3><A NAME="sec-v1.1"></A> Zmiany w wersji 1.1</H3>
<P>Jakie zmiany zostay zrobione w tej wersji? Przede wszystkim, zosta
poprawiony bd w przykadowym odzyskiwaniu pliku. Dziêkujê wszystkim, którzy
napisali, eby wskazaæ mi ten bd. Mam nadziejê, e nauczyem siê byæ bardziej
uwanym przy interakcyjnej pracy z programem.
<P>Po drugie, rozwaania o systemie plików w UNIX-ie zostay przerobione tak,
aby uczyniæ je bardziej zrozumiaymi. Od pocztku nie byem z tego zadowolony
i dostaem komentarze, e nie byo to napisane zbyt jasno.
<P>Po trzecie, uuencode'owany gzip-owany tar-owany pakiet <CODE>fsgrab</CODE> ze rodka
pliku zosta usuniêty. Teraz program dostêpny jest na
<A HREF="http://pobox.com/~aaronc/tech/fsgrab-1.2.tar.gz">mojej stronie domowej</A>
i na
<A HREF="http://metalab.unc.edu/pub/Linux/utils/file/">Metalab-ie</A>
(i kopiach, w Polsce -
<A HREF="http://sunsite.icm.edu.pl/pub/Linux/sunsite/utils/file/">Sunsite</A>
).
<P>Po czwarte, dokument ten zosta przetumaczony na jêzyk skadu SGML uywany
w Linux Documention Project. Ten jêzyk moe byæ atwo konwertowany do innych
jêzyków skadu (np. HTML-a i LaTeX-a) w celu dogodnego sposobu wywietlania i
drukowania. Jedn z korzyci z tego jest to, e adny wygld wersji papierowej
jest atwiejszy do osigniecia. Inn jest to, e dokument zawiera wewnêtrzne
i zewnêtrzne odnoniki, gdy ogldany jest przez WWW.
<P>
<A HREF="mailto:egil@kvaleberg.no">egil@kvaleberg.no</A>,
który wskaza na polecenie <CODE>dump</CODE> w <CODE>debugfs</CODE>. Jeszcze raz, dziêki
Egil.
Druga zmiana polegaa na zaznaczeniu, e uycie <CODE>chattr</CODE> pomaga uniknæ
skasowania wanych plików. Dziekujê Hermanowi Suijs
<CODE>
<A HREF="mailto:H.P.M.Suijs@kub.nl">H.P.M.Suijs@kub.nl</A></CODE>
za zauwaenie tego.
Streszczenie zostao uaktualnione. Zostay dodane URL-e do organizacji i
oprogramowania. Wprowadzono wiele innych mniejszych zmian (literówki i tym
podobne).
<H3></H3>
<H3><A NAME="sec-v1.3"></A> Zmiany w wersji 1.3</H3>
<P>Pomimo, e jest to pierwsza wersja od 17 miesiêcy, jest tutaj mao
nowego. W wersji tej poprawione s drobniejsze bêdy (literówki, puste
URL-e, tego typu rzeczy -- szczególnie nie zwizane z Open Group),
uaktualniono kilka czêci tekstu, które ulegy przeterminowaniu, takich jak
partie dotyczce wersji jdra i <CODE>lde</CODE>. No i zmieniem `Sunsite' na
`Metalab'.
<P>To wydanie jest przewidywane jako ostatnie przed wersj 2.0, która, mam
nadziejê, bêdzie penym Howto. Pracujê nad istotnymi zmianami, które
spowoduj zwiêkszenie gównego numeru wersji.
<P>
<H2>1.2 Inne lokalizacje tego dokumentu</H2>
<P>Najnowsza publiczna wersja tego dokumentu powinna byæ zawsze dostêpna na
<A HREF="http://metalab.unc.edu/LDP/">Linux Documentation Project site</A>
(i kopiach, w Polsce -
<A HREF="http://sunsite.icm.edu.pl/pub/Linux/sunsite/docs/LDP/">Sunsite</A>
).
<P>Najbardziej aktualna wersja jest równie przechowywana na
<A HREF="http://pobox.com/~aaronc/">mojej stronie domowej</A>
w kilku formatach:
<P>
<UL>
<LI>
<A HREF="http://pobox.com/~aaronc/tech/e2-undel/howto.sgml">ródo SGML</A>.
To jest format ródowy, tak jak to napisaem uywajc pakietu SGML
Tools.</LI>
<LI>
<A HREF="http://pobox.com/~aaronc/tech/e2-undel/html/">HTML</A>.
To jest HTML, automatycznie wygenerowany ze róda SGML.</LI>
<LI>
<A HREF="http://pobox.com/~aaronc/tech/e2-undel/howto.txt">czysty tekst</A>.
To jest czysty tekst, który równie zosta automatycznie wygenerowany
ze róda SGML.</LI>
</UL>
<P>
<P>
<H2><A NAME="s2">2. Jak nie skasowaæ plików</A></H2>
<P>Trzeba pamiêtaæ, e Linux róni siê od MS-DOS jeli chodzi o
kasowanie plików. W MS-DOS (jak i w Windows 95), dosyæ atwo jest odzyskaæ
skasowane pliki - `system operacyjny' (uywam tego terminu dosyæ swobodnie)
dostarcza nawet narzêdzi, które automatyzuj ten proces.
W Linux-ie jest inaczej.
<P>Regua numer jeden (podstawowa wskazówka) brzmi:
<P>
<BLOCKQUOTE>
<B>RÓB KOPIE ZAPASOWE</B>
</BLOCKQUOTE>
<P>bez wzglêdu na wszystko. Pomyl o wszystkich swoich danych. Byæ moe, jak ja,
trzymasz kilkuletni zbiór listów, kontaktów, programów, dokumentów na swoim
komputerze. Pomyl co by siê stao z Twoim yciem, gdyby Twój dysk uleg
katastrofalnemu uszkodzeniu, lub gdyby -- o wielkie nieba ! -- zoliwy craker
wyczyci Twój dysk. To nie jest niemoliwe; korespondowaem z wieloma
ludmi w takiej sytuacji. Mylê, e teraz wszyscy rozsdnie mylcy uytkownicy
Linux-a wyjd, kupi urzdzenie do robienia kopii zapasowych, opracuj
kalendarz archiwizacji i <EM>bêd siê jego trzymaæ</EM>. Ja uywam 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
<A HREF="#sec-credits">Bibliografia i Wyrazy Uznania</A>).
<P>Co wtedy, gdy nie ma kopii zapasowej? (lub nawet przy istnieniu kopii
zapasowej: adne rodki bezpieczeñstwa nie s zym rozwizaniem w
miejscu gdzie przechowywane s wane dane).
<P>Spróbuj ustawiæ prawa dostêpu do wanych plików na 440 (lub mniej):
odebranie sobie samemu praw zapisu oznacza, e <CODE>rm</CODE> bêdzie wymaga
potwierdzenia przed skasowaniem. (Zauwayem, e jeli rekursywnie kasujê
katalog <CODE>rm -r</CODE>, proba potwierdzenia pojawi siê przy pierwszym i drugim
pliku, potem program zachowuje siê jak <CODE>rm -rf</CODE>).
<P>Niez sztuczk dla wybranych plików jest utworzenie w ukrytym katalogu
twardych dowizañ do nich. Kiedy usyszaem historiê o administatorze,
który przez pomykê skasowa <CODE>/etc/passwd</CODE> (nieomal w ten sposób
niszczc system).
Jednym z rozwizañ takiego kopotu jest zrobienie czego nastêpujcego (jako
root):
<P>
<BLOCKQUOTE><CODE>
<PRE>
# mkdir /.backup
# ln /etc/passwd /.backup
</PRE>
</CODE></BLOCKQUOTE>
<P>Teraz skasowanie pliku wymaga wiêkszego wysiku: gdy napiszesz tylko
<P>
<BLOCKQUOTE><CODE>
<PRE>
# rm /etc/passwd
</PRE>
</CODE></BLOCKQUOTE>
<P>wtedy
<P>
<BLOCKQUOTE><CODE>
<PRE>
# ln /.backup/passwd /etc
</PRE>
</CODE></BLOCKQUOTE>
<P>odtworzy Twój plik. Oczywicie, to rozwizanie nie pomoe jeli nadpiszesz
plik, wiêc nie zapomninaj o kopii zapasowej.
<P>W systemie plików ext2 jest moliwe uycie atrybutów ext2, aby ochraniaæ
pliki. Atrybuty te mog byæ zmieniane za pomoc komendy <CODE>chattr</CODE>.
Istnieje atrybut `append-only`: plik z tym atrybutem moe byæ tylko
powiêkszany, nie moe byæ skasowany i istniejca zawartoæ nie moe byæ
nadpisana. Jeli atrybut ten ma katalog, kady plik czy katalog w nim lecy
moe byæ normalnie modyfikowany, ale aden z plików nie moe zostaæ skasowany.
Atrybut `append-only' ustawia siê poleceniem
<P>
<BLOCKQUOTE><CODE>
<PRE>
$ chattr +a FILE...
</PRE>
</CODE></BLOCKQUOTE>
<P>Istnieje równie atrybut `immutable', który moe byæ zapalany lub gaszony
tylko przez administratora. Pliku lub katalogu z tym atrybutem nie mona
zmienieniæ, skasowaæ, zmieniæ jego nazwy, czy utworzyæ do niego twardego
dowizania. Mona go ustawiæ w nastêpujcy sposób:
<P>
<BLOCKQUOTE><CODE>
<PRE>
# chattr +i FILE...
</PRE>
</CODE></BLOCKQUOTE>
<P>Ext2fs dostarcza równie atrybutu `undeletable' (<CODE>+u</CODE> in <CODE>chattr</CODE>).
Zaoenie byo 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 jdrze. Mylaem, e bêdzie wiêksze zainteresowanie ni
i stanie siê to szybko, ale nie jest ona dostêpna (wedug mojej wiedzy) w
adnej aktualnej wersji jdra.
<P>Niektórzy radz, aby zrobiæ alias lub funkcjê w powoce <CODE>rm</CODE>, która
wykonywaaby <CODE>rm -i</CODE> (bêdziesz musia potwierdziæ skasowanie
<EM>kadego</EM> pliku).
<A HREF="http://www.redhat.com/">Dystrubucja Red Hat</A> robi to domylnie dla wszystkich uytkowników, w tym i dla root-a.
Ja osobicie nie lubiê oprogramowania, które nie moe dziaaæ bez mojej
pomocy, dlatego nie uywam tego sposobu. Wczeniej, czy póniej moe pojawiæ
siê kolejny problem: kiedy bêdziesz pracowa w trybie singe-user, lub
bêdziesz uywa innej powoki lub nawet innej maszyny, gdzie Twoja funkcja
<CODE>rm</CODE> nie istnieje. Jeli bêdziesz spodziewa siê, e kade skasowanie
wymaga potwierdzenia, dosyæ atwo jest nie przewidzieæ tego, e kazae
skasowaæ zbyt wiele plików. Równie skrypty i programy, które podmieniaj
<CODE>rm</CODE> mog byæ bardzo niebezpieczne.
<P>Trochê lepszym rozwizaniem jest uycie pakietu, który umoliwia
`odtwarzalne' kasowanie poprzez specjaln komendê zastêpujca <CODE>rm</CODE>.
Szczegóy znajdziesz u Peeka (1993) (patrz rozdzia
<A HREF="#sec-credits">Bibliografia i Wyrazy Uznania</A>). Jednak w ten
sposób przyzwyczajamy uytkownika do pewniej nonszalancji przy kasowaniu
plików. Nie jest to najlepsze, bowiem system typu Unix wymaga jednak uwanego
dziaania.
<P>
<P>
<H2><A NAME="s3">3. Jakiego wspóczynnika odzyskania skasowanych plików mogê siê spodziewaæ ?</A></H2>
<P>To zaley. Problem wynika z tego, e w systemie operacyjnym wysokiej
jakoci, wielozadaniowym, wielouytkownikowym, takim jak Linux, nie moesz
przewidzieæ kiedy kto zechce zapisaæ co na dysk. Po chwili, w której kazae systemowi
skasowaæ jaki plik, bloki przez niego zajête mog zostaæ uyte, gdy system
bêdzie chcia zapisaæ co nowego. (Jest to jeden przykad ogólnej zasady
systemów typu Unix: jdro i zwizane z nim programy zakadaj, e uytkownicy
nie s idiotami). Ogólnie rzecz biorc, im bardziej obciona jest Twoja
maszyna, tym mniej prawdopodobne jest odzyskanie plików.
<P>Znaczenie moe mieæ równie fragmentacja dysku. Jeli partycja, na której
by skasowany plik jest bardzo pofragmentowana, masz mae szanse na
odczytanie caej jego treci.
<P>Jeli Twój komputer, tak jak mój, realnie jest maszyn jednouytkownikow i
nie robie niczego co intensywnie korzystao z dysku w tragicznej chwili
skasowania pliku, moesz siê spodziewaæ wspóczynnika odzysku zblionego do
tego wymienionego niej. Ja odzyskaem prawie 94% plików (byy to
pliki binarne) w stanie nieuszkodzonym. Jeeli otrzymasz 80%
lub wiêcej, mylê, e bêdziesz z siebie zadowolony.
<P>
<P>
<H2><A NAME="s4">4. Jak odzyskaæ skasowane pliki ?</A></H2>
<P>Operacja ta polega gównie na znalezieniu danych na urzdzeniu 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 pooenia interesujcych danych na partycji i zapisaniu ich
jako nowy plik w innym systemie plików.
<P>Przed odtwarzeniem danych musisz zrobiæ kilka rzeczy; patrz rozdziay
<A HREF="#sec-umount">Odmontowanie systemu plików</A>,
<A HREF="#sec-prep-chg">Przygotowanie do bezporednich zmian w iwêzach</A> i
<A HREF="#sec-prep-wrt">Przygotowanie do zapisania danych w innym miejscu</A>.
Informacjê jak odzyskiwaæ pliki znajdziesz w rozdziaach
<A HREF="#sec-finding">Szukanie skasowanych iwêzów</A>,
<A HREF="#sec-obtain">Uzyskiwanie szczegóowych informacji o iwêzach</A>,
<A HREF="#sec-recover">Odzyskiwanie bloków danych</A> i
<A HREF="#sec-modify">Bezporednie modyfikacje iwêzów</A>.
<P>
<P>
<H2><A NAME="sec-umount"></A> <A NAME="s5">5. Odmontowanie systemu plików</A></H2>
<P>Niezalenie od metody jak wybrae, pierwszym krokiem jest odmontowanie
systemu plików zawierajcego skasowane pliki. Zdecydowanie nie polecam
adnych dziaañ na zamontowanym systemie plików. Krok ten powinien byæ
wykonany najszybciej jak to bêdzie moliwe od momentu, gdy zauwaye, e
pomykowo skasowae pliki. Im szybciej odmontujesz system plików, tym
wiêksza bêdzie szansa, e Twoje dane nie zostan nadpisane (zamazane).
<P>Najprostsz metod, aby to zrobiæ jest: zakadajc, e
skasowane pliki byy systemie plików <CODE>/usr</CODE>,
<P>
<BLOCKQUOTE><CODE>
<PRE>
# umount /usr
</PRE>
</CODE></BLOCKQUOTE>
<P>Jeli chcesz moesz równie utrzymaæ widocznoæ katalogu <CODE>/usr</CODE>.
Zamontuj go w trybie tylko-do-odczytu:
<P>
<BLOCKQUOTE><CODE>
<PRE>
# mount -o ro,remount /usr
</PRE>
</CODE></BLOCKQUOTE>
<P>W przypadku, gdy skasowane pliki byy na gównej partycji musisz dodaæ opcjê
<CODE>-n</CODE>, aby zabroniæ programowi <CODE>mount</CODE> na próby zapisu do
<CODE>/etc/mtab</CODE>:
<P>
<BLOCKQUOTE><CODE>
<PRE>
# mount -n -o ro,remount /
</PRE>
</CODE></BLOCKQUOTE>
<P>Poza tym wszystkim, moliwe jest równie, e jaki inny proces uywa
interesujcego nas systemu plików (spowoduje to bd typu `Resource busy'
przy próbie odmontowania). <CODE>fuser</CODE> jest programem, który wyle sygna do
kadego procesu uywajcego wskazanego pliku lub punktu montowania. Spróbuj
tego dla partycji <CODE>/usr</CODE>:
<P>
<BLOCKQUOTE><CODE>
<PRE>
# fuser -v -m /usr
</PRE>
</CODE></BLOCKQUOTE>
<P>W ten sposób uzyskasz listê przeszkadzajcych Ci procesów. Zakadajc, e aden
z nich nie jest niezbêdny, moesz napisaæ
<P>
<BLOCKQUOTE><CODE>
<PRE>
# fuser -k -v -m /usr
</PRE>
</CODE></BLOCKQUOTE>
<P>aby wysaæ sygna <CODE>SIGKILL</CODE> do kadego z nich ( gwarantuje to ich zabicie),
albo
<P>
<BLOCKQUOTE><CODE>
<PRE>
# fuser -k -TERM -v -m /usr
</PRE>
</CODE></BLOCKQUOTE>
<P>aby przekazaæ kademu sygna <CODE>SIGTERM</CODE> (spowoduje to normalne zakoñczenie
pracy procesów).
<P>
<P>
<H2><A NAME="sec-prep-chg"></A> <A NAME="s6">6. Przygotowanie do bezporednich zmian iwêzów</A></H2>
<P>Moja rada? Nie uywaj tej metody. Nie uwaam, eby dobrym pomysem
bya zabawa na niskim poziomie w systemie plików. Metoda ta stwarza równie
problemy jeli chcesz odtworzyæ pliki wiêksze ni 12 bloków. W celu
odzyskania duych plików, tak czy owak, bêdziesz musia uyæ innej metody.
(Chocia patrz rozdzia
<A HREF="#sec-easier">Czy bêdzie to kiedy atwiejsze?</A> w celu
dodatkowych informacji.)
<P>Jeeli jednak chcesz koniecznie uyæ tego sposobu, lepiej skopiuj bezporednio
obraz partycji na inn partycjê, a póniej zamontuj j uywajc pêtli
zwrotnej (loopback):
<P>
<BLOCKQUOTE><CODE>
<PRE>
# cp /dev/hda5 /root/working
# mount -t ext2 -o loop /root/working /mnt
</PRE>
</CODE></BLOCKQUOTE>
<P>(Niektóre wersje <CODE>mount</CODE> nie potrafi tego zrobiæ. Jeli Twój <CODE>mount</CODE>
nie dziaa poprawnie, zalecam uycie najnowszej wersji, conajmniej 2.7. Duo
starsze wersje maj problemy z utrzymaniem bezpieczeñstwa danych.)
<P>Uywajc pêtli zwrotnej, nawet jeli cakowicie zniszczysz system plików,
moesz ponownie skopiowaæ partycjê i zaczæ próby od nowa.
<P>
<P>
<H2><A NAME="sec-prep-wrt"></A> <A NAME="s7">7. Przygotowanie do zapisu danych w innym miejscu</A></H2>
<P>Jeeli wybierzesz tê drogê dziaania, musisz znaleæ partycjê ratunkow
-- miejsce, gdzie zapiszesz nowe kopie odzyskanych plików. Na cae
szczêcie, twój system zawiera kilka partycji: prawdopodobnie partycjê
gówn, <CODE>/usr</CODE> i <CODE>/home</CODE>. Wybierz jedn z nich i utwórz na
niej nowy katalog.
<P>Jeli masz tylko partycjê gówn i wszystko przechowujesz na niej,
rozwizanie troszkê siê skomplikuje. Moe masz partycje MS-DOS lub Windows,
której bedziesz móg uyæ ? Albo masz sterownik do ramdisk-u w swoim
jdrze, albo w module ? W celu uycia ramdisk-u (zakadajc, e jdro jest
nowsze od 1.3.48), napisz:
<P>
<BLOCKQUOTE><CODE>
<PRE>
# dd if=/dev/zero of=/dev/ram0 bs=1k count=2048
# mke2fs -v -m 0 /dev/ram0 2048
# mount -t ext2 /dev/ram0 /mnt
</PRE>
</CODE></BLOCKQUOTE>
<P>W ten sposób stworzye 2MB wolumen ramdisk-u i zamontowae do w
<CODE>/mnt</CODE>.
<P>Krótkie ostrzeenie: jeeli uywasz <CODE>kerneld</CODE> (lub zastêpujcego go
<CODE>kmod</CODE> w jdrach 2.2.x i pónych 2.1.x) w celu automatycznego adowania i
odadowywania moduów, nie odmontowuj ramdisk-u dopóki nie skopiujesz
wszystkich plików na bardziej trway nonik. W chwili, gdy go odmontujesz,
<CODE>kerneld</CODE> zakada, e moe odadowaæ modu (zwykle jednak czeka pewien
okres). Gdy to ju siê stanie, pamiêæ zostanie uyta przez inne czêci jdra
i stracisz wszystkie godziny spêdzone na odzyskiwaniu danych.
<P>Jeeli masz napêd Zip, Jaz, LS-120 lub co podobnego, moe on speniaæ z
powodzeniem rolê partycji ratunkowej. W pozostaych przypadkach, uyj po prostu
napêdu stacji dyskietek.
<P>Bêdziesz jeszcze potrzebowa programu, który potrafi czytaæ dane ze rodka
partycji. Waciwie moe to zrobiæ <CODE>dd</CODE>, ale aby przeczytaæ dane lece
od 600 MB do 800 MB, <CODE>dd</CODE> musi przeczytaæ i zignorowaæ pierwsze 600 MB.
Zajmuje to dosyæ duo czasu, nawet na szybkich dyskach. Moim sposobem na
obejcie tego problemu byo napisanie programu, który przeskakuje w rodek
partycji. Nazywa siê on <CODE>fsgrab</CODE>; pakiet ze ródem moesz znaleæ na
<A HREF="http://pobox.com/~aaronc/tech/fsgrab-1.2.tar.gz">mojej stronie domowej</A>
lub na
<A HREF="http://metalab.unc.edu/pub/Linux/utils/file/">Metalab-ie</A>
(i kopiach, w Polsce -
<A HREF="http://sunsite.icm.edu.pl/pub/Linux/sunsite/utils/file/">Sunsite</A>
). Jeli bêdziesz chcia stosowaæ tê metodê, w dalszej czêci tego
mini-JTZ zakadam, e masz <CODE>fsgrab</CODE>.
<P>Nie potrzebujesz <CODE>fsgrab-a</CODE>, jeeli aden z plików, które starasz siê
odzyskaæ, nie zajmuje wiêcej ni 12 bloków (przewanie blok ma rozmiar jednego
kilobajta).
<P>Jeeli musisz uyæ <CODE>fsgrab-a</CODE>, ale nie chce Ci siê go cigaæ i kompilowaæ,
jest te prosta droga na przetumaczenie polecenia dla <CODE>fsgrab</CODE> na
polecenie dla <CODE>dd</CODE>. Majc
<P>
<BLOCKQUOTE><CODE>
fsgrab -c <EM>count</EM> -s <EM>skip</EM> <EM>device</EM>
</CODE></BLOCKQUOTE>
<P>moesz uyæ komendy <CODE>dd</CODE> (przewanie jest to duo wolniejsze)
<P>
<BLOCKQUOTE><CODE>
dd bs=1k if=<EM>device</EM> count=<EM>count</EM> skip=<EM>skip</EM>
</CODE></BLOCKQUOTE>
<P>Muszê Ciê ostrzec, e chocia dla mnie <CODE>fsgrab</CODE> dziaa doskonale, nie
mogê braæ odpowiedzialnoci za jego funkcjonowanie. Pisaem go dosy szybko i
niestarannie, po prostu, aby dziaa poprawnie. Wiêcej szczegóów o
gwarancji znajdziesz w rozdziale `No Warranty' w pliku <CODE>COPYING</CODE>
doaczonym do pakietu (the GNU General Public Licence).
<P>
<P>
<H2><A NAME="sec-finding"></A> <A NAME="s8">8. Szukanie skasowanych iwêzów</A></H2>
<P>Nastêpnym krokiem jest odnalezienie w systemie plików tych iwêzów,
które zostay ostanio uwolnione. Do tego zadania uyjemy programu
<CODE>debugfs</CODE>. Uruchom <CODE>debugfs</CODE> z nazw urzdzenia, na którym
przechowywany jest system plików:
<P>
<BLOCKQUOTE><CODE>
<PRE>
# debugfs /dev/hda5
</PRE>
</CODE></BLOCKQUOTE>
<P>Jeeli chcesz bezporednio wprowadzaæ zmiany do iwêzów, dodaj opcjê
<CODE>-w</CODE>, aby umoliwiæ zapisywanie do systemu plików:
<P>
<BLOCKQUOTE><CODE>
<PRE>
# debugfs -w /dev/hda5
</PRE>
</CODE></BLOCKQUOTE>
<P><CODE>lsdel</CODE> jest poleceniem <CODE>debugfs</CODE>, które wyszukuje skasowane iwêzy. Po
zachêcie programu, napisz wiêc:
<P>
<BLOCKQUOTE><CODE>
<PRE>
debugfs: lsdel
</PRE>
</CODE></BLOCKQUOTE>
<P>Po chwili wiergotania dysku, duga lista zostanie przekierowana do Twojego
ulubionego amacza na strony (ang. pager) (wartoæ zmiennej
<CODE>$PAGER</CODE>). Powinienne zachowaæ gdzie kopiê tej listy.
Jeeli uywasz <CODE>less</CODE>, moesz po prostu napisaæ <CODE>-o</CODE> i nazwê pliku
wyjciowego. W innym razie, bêdziesz musia przesaæ wyniki do pliku w inny
sposób. Spróbuj czego takiego:
<P>
<BLOCKQUOTE><CODE>
<PRE>
debugfs: quit
# echo lsdel | debugfs /dev/hda5 > lsdel.out
</PRE>
</CODE></BLOCKQUOTE>
<P>Teraz, tylko na podstawie czasu skasowania, rozmiaru, praw wasnoci i
waciciela musisz okreliæ, które iwêzy naleay do skasowanych plików.
Bêdzie to prawdopodobnie proste zadanie jeli wypadek przydarzy siê 5 minut
temu, jeli nie, przeszukaj listê bardzo uwanie.
<P>Polecam wydrukowanie sobie listy iwêzów, które chcesz odzyskaæ. Uatwi Ci
to dalsz pracê.
<P>
<P>
<H2><A NAME="sec-obtain"></A> <A NAME="s9">9. Uzyskiwanie szczegóowych informacji o iwêzach</A></H2>
<P><CODE>debugfs</CODE> dysponuje poleceniem <CODE>stat</CODE>, które wywietla szczegóowe
informacje o iwêle. Wykonaj tê komendê dla wszystkich iwêzów, które chcesz
odzyskaæ. Na przykad, jeeli interesuje Ciê iwêze o numerze 148003, napisz
tak:
<P>
<BLOCKQUOTE><CODE>
<PRE>
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
</PRE>
</CODE></BLOCKQUOTE>
<P>Gdy chcesz odzyskaæ wiele plików, dobrze bêdzie jak zautomatyzujesz ten
proces. Przy zaoeniu, e Twoja <CODE>lsdel</CODE> lista interesujcych iwêzów
znajduje siê w pliku <CODE>lsdel.out</CODE>, napisz co takiego:
<P>
<BLOCKQUOTE><CODE>
<PRE>
# cut -c1-6 lsdel.out | grep "[0-9]" | tr -d " " > inodes
</PRE>
</CODE></BLOCKQUOTE>
<P>Nowy plik <CODE>inodes</CODE> zawiera tylko numery iwêzówm, które chcesz odzyskaæ,
po jednym w jednej linii. Zapisalimy to, bowiem póniej bardzo nam siê
przyda. Potem piszesz po prostu:
<P>
<BLOCKQUOTE><CODE>
<PRE>
# sed 's/^.*$/stat <\0>/' inodes | debugfs /dev/hda5 > stats
</PRE>
</CODE></BLOCKQUOTE>
<P>i plik <CODE>stats</CODE> zawiera wyniki wszystkich poleceñ <CODE>stat</CODE>.
<P>
<P>
<H2><A NAME="sec-recover"></A> <A NAME="s10">10. Odzyskiwanie bloków danych</A></H2>
<P>Ta czêæ jest albo bardzo atwa, albo trudna, w zalenoci od tego,
czy plik który chcesz odzyskaæ zajmowa wiêcej ni 12 bloków.
<P>
<H2>10.1 Mae pliki</H2>
<P>Jeeli plik ma mniej ni 12 bloków, numery wszystkich bloków, które on
zajmuje zapisane s w jednym iwêle. Moesz odczytaæ je po wykonaniu
polecenie <CODE>stat</CODE> dla tego iwêza. Ponadto, w <CODE>debugfs</CODE> jest polecenie,
które automatycznie odzyskuje taki plik. Wemy ten sam przykad co poprzednio:
<P>
<BLOCKQUOTE><CODE>
<PRE>
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
</PRE>
</CODE></BLOCKQUOTE>
<P>Plik ten zajmuje szeæ bloków. Poniewa jest to mniej ni 12, moemy uyæ
<CODE>debugfs</CODE>, aby zapisaæ plik w nowym miejscu, na przykad
<CODE>/mnt/recovered.000</CODE>:
<P>
<BLOCKQUOTE><CODE>
<PRE>
debugfs: dump <148003> /mnt/recovered.000
</PRE>
</CODE></BLOCKQUOTE>
<P>Oczywicie mona to zrobiæ równie, posugujc siê <CODE>fsgrab</CODE>. Pokaê jak
wyglda takie przykadowe wywoanie:
<P>
<BLOCKQUOTE><CODE>
<PRE>
# fsgrab -c 2 -s 594810 /dev/hda5 > /mnt/recovered.000
# fsgrab -c 4 -s 594814 /dev/hda5 >> /mnt/recovered.000
</PRE>
</CODE></BLOCKQUOTE>
<P>Zarówno przy korzystaniu z <CODE>debugfs</CODE> jak i <CODE>fsgrab</CODE>, na koñcu pliku
<CODE>/mnt/recovered.000</CODE> pozostan mieci. Nie ma to wiêkszego znaczenia.
atwo mona siê ich pozbyæ. Najprostsz metod jest odczytanie pola
<CODE>Size</CODE> w iwêle i wpisanie tej wartoci za opcj <CODE>bs</CODE> komendy <CODE>dd</CODE>:
<P>
<BLOCKQUOTE><CODE>
<PRE>
# dd count=1 if=/mnt/recovered.000 of=/mnt/resized.000 bs=6065
</PRE>
</CODE></BLOCKQUOTE>
<P>Moe siê okazaæ, e jeden lub wiêcej z bloków zostao straconych, bowiem
zostay ju nadpisane. Jeeli tak bêdzie, po prostu nie miae szczêcia:
bloki te odeszy ju na zawsze. (Wybra sobie, e odmontowae je
wczeniej!)
<P>
<H2>10.2 Wiêksze pliki</H2>
<P>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. Kady plik ma równie `iwêze', w którym
przechowywane s informacje typu: waciciel, prawa dostêpu i typ. Podobnie
jak bloki, iwêzy s numerowane sekwencyjnie, chocia maj one róne
numeracje. Pozycja w katalogu odpowiadajca plikowi skada siê z jego nazwy
i numeru iwêza.
<P>Jednak na postawie tych informacji jdro nie jest jeszcze w stanie odnaleæ na
partycji danych odpowiadajcych jednej z pozycji w katalogu. eby to umoliwiæ,
iwêze przechowuje pooenia bloków danych zajmowanych przez plik.
Zorganizowane jest to w nastêpujcy sposób:
<P>
<UL>
<LI>Numery pierwszych 12 bloków danych przechowywane s bezporednio
w iwêle; czasami nazywa siê je <EM>blokami bezporednimi</EM>.
</LI>
<LI>Iwêze zawiera numer <EM>poredniego bloku</EM>. Blok poredni zawiera
numery nastêpnych 256 bloków z danymi.
</LI>
<LI>Iwêze zawiera numer <EM>podwójnie poredniego bloku</EM>. Blok podwójnie
poredni zawiera numery dodatkowych 256 bloków porednich.
</LI>
<LI>Iwêze zawiera numer <EM>potrójnie poredniego bloku</EM>. Blok potrójnie
poredni zawiera numery dodatkowych 256 bloków podwójnie porednich.</LI>
</UL>
<P>Przeczytaj to jeszcze raz: wiem, e to jest skomplikowane, ale bardzo wane.
<P>Niestety wszystkie implementacje jdra, a do wersji 2.0.36 podczas
kasowania pliku zeruj bloki porednie (podwójnie porednie, itd.). Jeli
Twój plik jest wiêkszy ni 12 bloków, nie masz gawarancji, e bêdzie moliwe
odnalezienie numerów wszystkich jego bloków, nie mówic ju nic o ich
zawartoci.
<P>Jedyn metod jak udao mi siê znaleæ, jest oparcie siê na zaoeniu, e
plik nie by pofragmentowany. Jeeli by, masz powany problem. Zakadajc,
e plik nie by pofragmentowany, istnieje kilka sekcji bloków danych, w
zalenoci od tego ile bloków danych zajmuje plik:
<P>
<DL>
<DT><B>0 do 12</B><DD><P>Numery bloków przechowywane s w iwêle, jak to byo opisane
wczeniej.
<P>
<DT><B>13 to 268</B><DD><P>Po blokach bezporednich, odlicz jeden na blok poredni,
dalej znajduje siê 256 bloków danych.
<P>
<DT><B>269 do 65804</B><DD><P>Tak jak poprzednio jest: 12 bezporednich bloków,
(nieprzydatny) blok poredni i 256 bloków. Po tym wszystkim nastêpuje
(nieprzydatny) podwójnie poredni blok oraz 256 powtórzeñ jednego
(nieprzydatnego) bloku poredniego i 256 bloków danych.
<P>
<DT><B>65805 lub wiêcej</B><DD><P>Pooenie piewszych 65804 bloków jak wyej. Potem
potrójnie poredni blok i 256 powtórzeñ `sekwecji podwójnie poredniej'.
Kada podwójnie porednia sekwencja zawiera (nieprzydatny) podwójnie
poredni blok, po którym nastêpuje 256 powtórzeñ jednego (nieprzydatnego)
bloku poredniego i 256 bloków danych.
</DL>
<P>Oczywicie, nawet jeli numery bloków, które przyjêlimy, s poprawne, nie ma
adnych gwarancji, e dane s w nich s nienaruszone. Dodatkowo, im duszy
by plik, tym mniejsze szanse, e system operacyjny zapisa go bez
adnej fragmentacji (za wyjtkiem wyjtkowych sytuacji).
<P>Zaoyem, e rozmiar Twoich bloków wynosi 1024 bajty, tyle ile
wartoæ standardowa. Jeli Twój blok jest wiêkszy, niektóre z liczb podanych
wyej zmieni siê. Sprecyzujmy: dopóki numer kadego bloku ma dugoæ 4
bajtów, rozmiarbloku/4 jest liczb numerów bloków, które mog byæ
przechowane w kadym bloku porednim. Kade wystpienie liczby 256 we
wczeniejszym opisie, zastp na rozmiarbloku/4. Zmianie ulegn równie
ograniczenia na iloæ wymaganych bloków.
<P>Popatrz na przykadowe odzyskiwanie duego pliku.
<P>
<BLOCKQUOTE><CODE>
<PRE>
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
</PRE>
</CODE></BLOCKQUOTE>
<P>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'. Moemy wiêc odtworzyæ te bloki:
<P>
<BLOCKQUOTE><CODE>
<PRE>
# fsgrab -c 12 -s 8314 /dev/hda5 > /mnt/recovered.001
</PRE>
</CODE></BLOCKQUOTE>
<P>Nastêpny blok, wymieniony w iwêle, 8326, jest blokiem porednim, który
ignorujemy. Mamy jednak nadziejê, e nastepne 256 bloków jest naszymi
blokami danych (numery 8327 do 8582).
<P>
<BLOCKQUOTE><CODE>
<PRE>
# fsgrab -c 256 -s 8327 /dev/hda5 >> /mnt/recovered.001
</PRE>
</CODE></BLOCKQUOTE>
<P>Ostatnim blokiem wymienionym w iwêle jest 8583. Nadal zakadamy, e
istnieje cigoæ w blokach. Jest to jednak uzasadnione bowiem: ostatnim
blokiem danych by blok o numerze 8582 (8327 + 255). Blok 8583 jest
podwójnie poredni i moe byæ zignorowany. Teraz moe nastpiæ do 256
powtórzeñ bloku poredniego (który mona pominæ) i 256 bloków danych.
Trochê arytmetyki i ju mona pisaæ kolejne polecenie. Zauwa, e pominêlimy
podwójnie poredni blok 8583 oraz poredni blok 8584 i rozpoczêlimy czytaæ
dane od bloku numer 8585.
<P>
<BLOCKQUOTE><CODE>
<PRE>
# 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
</PRE>
</CODE></BLOCKQUOTE>
<P>Dodajmy to wszystko, zapisalimy do tej pory 12 + (7 * 256) bloków, co daje
1804. Wyniki polecenia `stat' dla iwêza day nam `blockcount' (liczba
bloków) równe 3616. Niestety s to bloki o rozmiarze 512 bajtów (zaszoæ 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 robilimy do tej pory,
pomijamy blok poredni (numer 10126) i moemy ju zapisaæ ostatnie cztery
bloki.
<P>
<BLOCKQUOTE><CODE>
<PRE>
# fsgrab -c 4 -s 10127 /dev/hda5 >> /mnt/recovered.001
</PRE>
</CODE></BLOCKQUOTE>
<P>Przy pewnym szczêciu udao nam siê odzyskaæ cay plik.
<P>
<P>
<H2><A NAME="sec-modify"></A> <A NAME="s11">11. Bezporednie modyfikacje iwêzów</A></H2>
<P>Metoda ta jest duo prostsza. Jednak, tak jak wspomniaem wczeniej, nie
moe byæ jeszcze stosowana do plików wiêkszych ni 12 bloków.
<P>W kadym iwêle, który chcesz odzyskaæ musisz ustawiæ licznik podczeñ
(linkcount) na jeden i czas skasowania (deletion time) na zero. Robi siê to
za pomoc polecenia <CODE>mi</CODE> (modify inode) w <CODE>debugfs</CODE>. Przykadowe
wywoanie, modyfikacja iwêza 148003 (tego co wczeniej):
<P>
<BLOCKQUOTE><CODE>
<PRE>
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]
</PRE>
</CODE></BLOCKQUOTE>
<P>Ustawiem czas skasowania na 0, licznik podczeñ na 1 i nacisnem Enter
dla wszystkich innych pól. Jest to pewn niedogodnoci, jeeli masz wiele
plików do odzyskania. Mylê jednak, e mona z tym yæ. Jeli
oczekujesz wygody, lepiej zacznij uywaæ graficznego `systemu operacyjnego'
ze licznym `Koszem na mieci'.
<P>Przy okazji: polecenie <CODE>mi</CODE> pokazuje `Czas stworzenia' (Creation
time) w iwêle. To kamstwo ! (lub, jak kto woli, pomyka.) Prawda jest taka,
e nie mona w systemie plików UNIX-a stwierdziæ kiedy dany plik zosta
utworzony. Pole <CODE>st_ctime</CODE> w <CODE>struct stat</CODE> zawiera `czas zmiany
iwêza', czyli czas ostaniej zmiany, którego z parametrów iwêza. To tyle
z dzisiejszej lekcji.
<P>Nowsze wersje <CODE>debugfs</CODE> ni moja, prawdopodobnie nie wywietalaj
niektórych pól w iwêle (szczególnie, <CODE>Reserved1</CODE> i <CODE>Fragment</CODE>).
<P>Po zmianie w iwêzach, moesz wyjæ z <CODE>debugfs</CODE> i napisaæ:
<P>
<BLOCKQUOTE><CODE>
<PRE>
# e2fsck -f /dev/hda5
</PRE>
</CODE></BLOCKQUOTE>
<P>Pomys polega na tym, e kady ze skasowanych plików zosta odkasowany, ale
nie pojawi siê w adnym katalogu. Program <CODE>e2fsck</CODE> umie to wykryæ i
doda pozycjê dla kadego z nich w katalogu <CODE>/lost+found</CODE> systemu
plików. (Jeeli partycja bya zamontowana w <CODE>/usr</CODE>, pliki pojawi siê
w <CODE>/usr/lost+found</CODE>, gdy j zamontujesz.) Prac, któr musisz jeszcze
zrobiæ, to nadanie plikom nazw i umieszczenie ich we waciwym miejscu
drzewa plików.
<P>Po uruchomieniu <CODE>e2fsck</CODE>, wywietli 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 zmieniae.
Resztê pozostawiam do Twojej decyzji, pamiêtaj, e nie jest najlepsz
metod odpowiadanie `tak' na wszystkie pytania. Po skoñczeniu pracy
przez <CODE>e2fsck</CODE>, moesz ponownie zamontowaæ system plików.
<P>Istnieje alternatywne rozwizanie do pozwolenia, aby <CODE>e2fsck</CODE> utworzy
pliki w <CODE>/lost+found</CODE>. Moesz uyæ <CODE>debugfs</CODE> i stworzyæ w systemie
plików doczenie (link) do iwêza. Suy do tego polecenie <CODE>link</CODE> w
<CODE>debugfs</CODE>, po zmianach w samym iwêle:
<P>
<BLOCKQUOTE><CODE>
<PRE>
debugfs: link <148003> foo.txt
</PRE>
</CODE></BLOCKQUOTE>
<P>W ten sposób powstanie w biecym katalogu plik o nazwie <CODE>foo.txt</CODE>;
<CODE>foo.txt</CODE> bêdzie Twoim odzyskanym plikiem. Nadal musisz jednak uruchomiæ
<CODE>e2fsck</CODE>, aby uaktualniæ informacje ogólne, liczniki bloków itp. itd.
<P>
<P>
<H2><A NAME="sec-easier"></A> <A NAME="s12">12. Czy bêdzie to kiedy atwiejsze?</A></H2>
<P>Tak. Waciwie, mam nadziejê, e tak. Chocia, gdy to piszê, aktualna,
stabilna wersja jdra (seria 2.0.x) zeruje bloki porednie. 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 jdra 2.2.1; prawdopodobnie pojawi siê
ono w dystrybucjach za jeden, dwa miesice.
<P>Kiedy wersje jdra rozwi problem zerowania bloków porednich, wiele moich
rêcznych technik modyfikacji iwêzów nie bêdzie ju potrzebnych. W tym
samym czasie stanie siê moliwe uycie polecenia <CODE>dump</CODE> w <CODE>debugfs</CODE>
dla duych plików i innych programów narzêdziowych do odzyskiwania plików.
<P>
<H2><A NAME="s13">13. Czy s jakie programy automatyzujce ten proces?</A></H2>
<P>Pewnie, e s. Niestety cierpi one na te same problemy co rêczna
technika zmian w iwêzach: bloki porednie s nieodzyskiwalne. Warto im siê
przyjrzeæ, bowiem wydaje siê, e ograniczenie to wkrótce zniknie.
<P>Napisaem program <CODE>e2recover</CODE>, który jest waciwie tylko Perl-ow
otoczk dookoa <CODE>fsgrab</CODE>. Stara siê on poradziæ sobie z wyzerowanymi
blokami porednimi i wydaje sie, e dziaa cakiem niele dla duych plików,
które nie ulegy fragmentacji. Ustawia poprawne prawa dostêpu (i waciciela,
gdy to jest moliwe). Upewnia siê równie, e odzyskiwany plik ma poprawny
rozmiar.
<P>Program <CODE>e2recover</CODE> by planowany jako czêæ powanych zmian w tym Howto;
oznacza to niestety, e wiêcej uytecznej dokumentacji do <CODE>e2recover</CODE>
bêdzie zamieszczone dopiero w nowej wersji tego dokumentu. Jednak i teraz
moe on siê komu przydaæ; mona go cignæ z
<A HREF="http://pobox.com/~aaronc/tech/e2-undel/">mojej strony domowej</A>, i wkrótce z Metalab-a (jest ju w Polsce -
<A HREF="http://sunsite.icm.edu.pl/pub/Linux/sunsite/utils/file/">Sunsite</A>).
<P>Scott D. Heavner jest autorem programu <CODE>lde</CODE>, the Linux Disk Editor.
Moe on byæ uywany zarówno jako binarny edytor dysku i jako odpowiednik
<CODE>debugfs</CODE> dla systemów plików ext2 i minix, a nawet dla systemu plików
xia (chocia wsparcie dla xia przestao byæ dostêpne w jdrach 2.1.x i 2.2.x).
Zawarto w nim kilka pomysów wspomagajcych odzyskiwanie skasowanych plików:
ledzenie listy bloków tworzcych plik i wyszukiwanie danych na dysku. Zawiera
on take cakiem uyteczn dokumentacjê o podstawach systemu plików oraz jak go
uywaæ do odzyskiwania plików skasowanych. Wersja 2.4 <CODE>lde</CODE> jest dostêpna na
<A HREF="http://metalab.unc.edu/pub/Linux/system/filesystems/lde-2.4.tar.gz">Metalab-ie</A> (i kopiach, w Polsce -
<A HREF="http://sunsite.icm.edu.pl/pub/Linux/sunsite/system/filesystems/lde-2.4.tar.gz">Sunsite</A>), lub na
<A HREF="http://www.geocities.com/CapeCanaveral/Lab/7731/lde.html">stronie domowej autora</A>.
<P>Inne moliwoci oferowane s przez GNU Midnight Commander, <CODE>mc</CODE>. Jest to
penoekranowe narzêdzie do zarzdzania plikami, oparte na znanym w
rodowisku MS-DOS programie o nazwie `NC'. <CODE>mc</CODE> obsuguje mysz zarówno
na konsoli, jak i w oknie xterm-a, dostarcza mechanizm wirtualnych systemów
plików, co umoliwia triki takie jak <CODE>cd</CODE> do archiwum tar. Odzyskiwanie
plików obsugiwane jest przez jeden z takich wirtualnych systemów plików.
Wszystko to brzmi bardzo zachêcajco, ale muszê przyznaæ, e nie uywam
tego programu -- wolê staromodne polecenia powoki.
<P>Aby uywaæ moliwoci odzyskiwania skasowanych plików, musisz skonfigurowaæ
program z opcj <CODE>-</CODE><CODE>-with-ext2undel</CODE>; bêdziesz równie potrzebowa
bibliotek w wersji rozwojowej i niektórych plików zawartych w pakiecie
<CODE>e2fsprogs</CODE>. W ten sposób zbudowana jest wersja dostarczana w
<A HREF="http://www.debian.org/">Debian GNU/Linux</A>; tak samo moe
byæ w innych dystrybucjach. Teraz moesz po prostu kazaæ mu <CODE>cd
undel:/dev/hda5</CODE>, i otrzymasz `zawartoæ katalogu' ze skasowanymi
plikami. Jak wiele innych i ten program bardzo le radzi sobie z zerowaniem
bloków porednich -- przewanie odtwarza tylko pierwsze 12k wiêkszych
plików.
<P>Aktualn wersjê mona cignæ z
<A HREF="ftp://ftp.nuclecu.unam.mx/Midnight/devel/">serwera ftp the Midnight Commander</A>.
<P>
<P>
<H2><A NAME="s14">14. Kolofon</A></H2>
<P>Mam zamiar regularnie uaktualniaæ ten dokument tak dugo jak bêdê mia
wystarczajco duo czasu i co ciekawego do powiedzenia. Oznacza to, e bardzo
mi zaley na komentarzach od czytelników. Czy moje pisanie moe byæ
bardziej zrozumiae? Czy mylicie o czym, co uczynioby problem prostszym?
Jest jaki program, który robi to wszystko automatycznie? Jeeli masz co do
powiedzenia o tym dokumencie, albo o <CODE>fsgrab</CODE>, albo o <CODE>e2recover</CODE>,
napisz do mnie <CODE>
<A HREF="mailto:aaronc@pobox.com">aaronc@pobox.com</A></CODE>.
<P>
<P>
<H2><A NAME="sec-credits"></A> <A NAME="s15">15. Wyrazy uznania i bibliografia</A></H2>
<P>
<BLOCKQUOTE>
`Jeeli widzê dalej od innych, to dlatego, e stojê na ramionach
olbrzymów.' (Isaac Newton)
</BLOCKQUOTE>
<P>To mini-Howto wywodzi siê z listu zamieszczonego w grupie
<CODE>
<A HREF="news:comp.os.linux.misc">comp.os.linux.misc</A></CODE>
przez Robina Glovera
<CODE>
<A HREF="mailto:swrglovr@met.rdg.ac.uk">swrglovr@met.rdg.ac.uk</A></CODE>.
Chciabym podziekowaæ Robinowi za wspaniaomylne pozwolenie na
przetworzenie jego pomysów w to mini-Howto.
<P>Korzystajc z okazji, chciabym jeszcze raz podziêkowaæ wszystkim, którzy
napisali do mnie o tym Howto. Otrzymywanie wyrazów wdziecznoci czyni
pracê wart wysiku.
<P>Niektóre odnoniki bibliograficzne:
<P>
<UL>
<LI><B>Frisch</B>, Æleen (1995), <EM>Essential System Administration</EM>,
second e
O'Reilly and Associates, Inc., ISBN: 1-56592-127-5.
</LI>
<LI><B>Garfinkel</B>, Simson, Daniel <B>Weise</B> and Steven <B>Strassmann</B>
(1994), <EM>The Unix-Haters Handbook</EM>, IDG Books, ISBN: 1-56884-203-1.
Wiêkszoæ tej ksiki wypeniaj jednynie modociane jêki ludzi, którzy
myl e <EM>ich</EM> system operacyjny by o wiele lepszy od Unix-a; a reszta
ksiki nie dotyczy Ciê, jeeli uywasz dobrego otoczenia uytkownika jakim
jest GNU. S tam jednak pewne ciekawe rzeczy; na przykad, dyskusja o tym jak
atwo jest skasowaæ plik pod Unix-em warta jest przeczytania.
</LI>
<LI><B>Glover</B>, Robin (31 Jan 1996), <EM>HOW-TO : undelete linux files
(ext2fs/debugfs)</EM>, comp.os.linux.misc Usenet posting.
</LI>
<LI><B>Peek</B>, Jerry, Tim <B>O'Reilly</B>, Mike <B>Loukides</B> et al (1993),
<EM>UNIX Power Tools</EM>, O'Reilly and Associates, Inc./Random House, Inc.,
ISBN:
0-679-79073-X. Second edition, 1998.</LI>
</UL>
<P>
<P>
<H2><A NAME="s16">16. Formalnoci</A></H2>
<P>Wszystkie znaki towarowe s wasnoci ich prawowitych wacicieli.
Konkretnie:
<P>
<UL>
<LI><EM>MS-DOS</EM> i <EM>Windows</EM> s znakami towarowymi
<A HREF="http://www.microsoft.com/">Microsoftu</A>.
</LI>
<LI><EM>UNIX</EM> jest znakiem towarowym
<A HREF="http://www.opengroup.org/">the Open Group</A>.
</LI>
<LI><EM>Linux</EM> jest znakiem towarowym zarejestrowanym w USA i kilku innych
pañstwach dla Linusa Torvalds.</LI>
</UL>
<P>Prawa autorskie do tego dokumentu 1997, 1999 posiada Aaron Crane
<CODE>
<A HREF="mailto:aaronc@pobox.com">aaronc@pobox.com</A></CODE>.
Moe on byæ darmowo rozpowszechniany w caoci, cznie z t not autorsk.
Nie moe byæ zmieniany bez zgody autora lub koordynatora Linux
Documentation Project HOWTO. Nie dotyczy to tylko kopiowania jego czêci w
celu przegldania lub cytowania; w takim przypadku, czêci te musz byæ
poprawnymi cytatami i nie musz zawieraæ noty o prawach autorskich.
<P>Autor oczekuje, ale nie wymaga, e ten kto bêdzie chcia sprzedawaæ kopie
tego dokumentu, niezalenie od tego, czy na noniku elektronicznym, czy
papierowym, poinformuje jego lub koordynatora projektu Linux HOWTO o swoich
zamiarach.
<P>Koordynatorem projektu Linux HOWTO jest aktulanie Tim Bynum
<CODE>
<A HREF="mailto:linux-howto@sunsite.unc.edu">linux-howto@sunsite.unc.edu</A></CODE>.
<P>
<P>
<H2><A NAME="s17">17. Od tumacza</A></H2>
<P>Staraem siê, aby tumaczenie byo najwierniejsze z moliwych. Dlatego
nie ma adnych zmian w stosunku do orginau, za wyjtkiem odnoników do
polskiej kopii serwera Metalab na
<A HREF="http://sunsite.icm.edu.pl">Sunsite.icm.edu.pl</A>.
<P>Czekam na komentarze pod adresem: Bartosz Sawicki
<CODE>
<A HREF="mailto:sawickib@ee.pw.edu.pl">sawickib@ee.pw.edu.pl</A></CODE>.
<P>
</BODY>
</HTML>
|
