File: README.de

package info (click to toggle)
e2undel 0.82-1
  • links: PTS
  • area: main
  • in suites: lenny
  • size: 316 kB
  • ctags: 300
  • sloc: ansic: 4,112; makefile: 109
file content (200 lines) | stat: -rw-r--r-- 9,545 bytes parent folder | download | duplicates (4)
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
e2undel 0.5 (aktuelle Informationen in README)

1. Voraussetzungen und Installation
-----------------------------------

siehe INSTALL


2. Grunds�tzliche Arbeitsweise
------------------------------

e2undel besteht aus zwei Programmen:

- die Bibliothek 'libundel' ersetzt �ber den Preload-Mechnismus
  (Enivorenment-Variable LD_PRELOAD) die Funktionen unlink(2) und remove(3)
  der C-Bibliothek. libundel protokolliert Namen, Inode und Device-Nummer jeder
  Datei, die �ber eine dieser Systemfunktionen gel�scht wird, in seinem Logfile
  (/var/e2undel/e2undel) mit.

- das Programm 'e2undel' liest diese Log-Datei und sucht auf dem spezifizierten
  Device nach gel�schten Inodes, wobei es jedem gel�schten Inode seinen
  (ehemaligen) Namen zuzuordnen versucht.

- Die gefundenen, gel�schten Inodes fasst e2undel anschlie�end in einer
  Tabelle zusammen, sortiert nach dem (fr�heren) Besitzer und dem Zeitpunkt des
  L�schens. Das Sortieren nach dem L�schintervall dient dazu, die h�ufig sehr
  lange Liste gel�schter Inodes etwas handhabbarer zu machen: Meist wei� man
  ja noch, ob man eine Datei gerade erst eben, gestern, irgendwann in den
  letzten Tagen oder schon viel fr�her gel�scht hat. Die Intervalle:
  
  - innerhalb der letzten 12 Stunden;
  - innerhalb der letzten 48 Stunden, aber nicht in den letzten 12 Stunden
  - innerhalb der letzten Woche, aber nicht in den letzten beiden Tagen
  - innerhalb des letzten Monats, aber nicht in den letzten 7 Tagen
  - innerhalb des letzten Jahres, aber nicht in den letzten 30 Tagen
  - �lter.

  Nach Auswahl eines Besitzers und eines L�schintervalls erh�lt man eine Liste
  der Inodes mit Gr��e, exaktem L�schdatum und (fr�herem) Namen.

- Dateien, deren Daten bereits teilweise �berschrieben sind, werden in rot 
  angezeigt.

- Durch Auswahl einer Inode-Nummer l�sst sich die zugeh�rige Datei
  wiederherstellen. Die wiederhergestellte Datei erh�lt den in der Liste
  angezeigten vollst�ndigen Pfadnamen, wobei "/" durch "_" ersetzt wird.

- Auf Wunsch (Option "-a") zeigt e2undel auch gel�schte Dateien an, die nicht
  im Logfile protokolliert sind (siehe auch Hinweise weiter unten). Bei diesen
  Dateien kann das Programm nat�rlich keinen Namen anzeigen.
  
- Wurde die vollst�ndig Version ('make e2undel-file') gebaut, versucht e2undel
  bei Angabe der Option "-t", f�r jede Datei den Dateityp zu bestimmen. Der
  Code f�r diesen Programmteil stammt aus dem file-Programm von Ian F. Darwin.
  Wenn es einen ausreicht, anhand von Dateityp und L�schdatum das File zu
  bestimmen, das man wiederherstellen m�chte, kann man auf libundel verzichten.

- Dateien, deren Name nicht bekannt ist, erhalten als Namen die Inode-Nummer
  ("inode-nnnnn"), bei Angabe von "-t" zus�tzlich den Dateityp.

- Mit 'e2undel -l' erh�lt man eine Liste aller Dateien im Logfile, sortiert
  nach Dateisystemen.


3. En detail
------------

Aufruf: e2undel -d device -s path [-a] [-t]
        e2undel -l

"-d": Zu bearbeitendes Dateisystem, z.B. /dev/hda1. Sollte idealerweise nicht
      gemountet sein.

"-s": Verzeichnis, in dem e2undel wiederhergestellte Dateien speichert. Sollte
      m�glichst auf einem anderen Dateisystem als dem unter "-d" angegebenen
      liegen, damit wiederhergestellte Dateien keine gel�schten Daten
      �berschreiben.

"-a": Mit dieser Option zeigt e2undel nicht nur gel�schte Dateien an, deren
      Namen im Logfile auftauchen, sondern alle gel�schten Dateien. Hier
      muss man die gew�nschte Datei anhand Gr��e, L�schdatum und (fr�herem)
      Besitzer identifizieren. Der Name des wiederhergestellten Files lautet
      "inode-nnnnn", wobei 'nnnnn' durch die Inode-Nummer ersetzt wird.
      Dateien, deren Namen im Logfile auftauchen, werden auch dann mit ihrem 
      Namen wiederhergestellt.

"-t": In Kombination mit "-a": Bestimme den Dateityp gel�schter Dateien, deren
      Name nicht im Logfile steht.

"-l": Zeigt alle Dateien im Log-File, sortiert nach Dateisystemen.


4. Hinweise
-----------

siehe auch BUGS

1. Wieso taucht ein gerade gel�schtes File nicht in der e2undel-Liste auf?
   Wieso enth�lt eine wiederhergestellte Datei nicht die Daten, die eigentlich
   in dem File stehen m�ssten?
   Wieso stehen in der e2undel-Liste Dateien, die nach Installieren der
   libundel gel�scht wurden, aber trotzdem keinen Namen haben?

Es ist eminent wichtig, dass _jeder_ Prozess gel�schte Files �ber libundel
mitprotokolliert; ansonsten kann man nie sicher sein, dass zu einem Inode
tats�chlich der im Logfile gespeicherte Name geh�rt: M�glicherweise wurde
nach dem L�schen ein neues File auf demselben Inode gespeichert und (ohne
Eintrag ins Protokoll) gel�scht. In diesem Fall wird das zuletzt dort
gel�schte File unter dem Namen des zuvor auf diesem Inode gel�schten
wiederhergestellt -- ganz abgesehen davon, dass ein doch gerade eben
gel�schtes File nicht im Logfile auftaucht. Das kann f�r viel Verwirrung
sorgen.

- Ein 'su' (ohne angeh�ngtes -) �bernimmt die Umgebungsvariabale LD_PRELOAD
  nicht in die root-Shell. Was man jetzt l�scht, l�uft am Log-File vorbei!

- Da LD_PRELOAD erst �bers Profile beim Einloggen gesetzt wird, bleiben alle
  L�schaktionen in Init-Skripten sowie von aus Init-Skripten gestarteten
  Prozessen unprotokolliert.
  Abhilfe: LD_PRELOAD auch in Init-Skripten definieren. Achtung: libundel 
  funktioniert beim Booten erst, nachdem das Dateisystem mit dem Verzeichnis
  /var beschreibbar gemountet wurde. Bei den Stopp-Skripten muss man darauf
  achten, dass beim Unmounten der Dateisysteme die libundel nicht mehr geladen
  ist; ansonsten wird das Dateisystem mit /var nicht sauber unmountet, und beim
  n�chsten Systemstart ist ein fsck-Lauf f�llig.
  Test auf Wirkung: Die meisten laufenden Daemonen in der Prozessliste sollten
  /usr/lib/libundel.so ge�ffnet haben (testen mit 'lsof' oder 'fuser -v').

- Je nach Version und Distribution startet Netscape unter Umst�nden �ber ein
  Skript, das die Umgebungsvariable $LD_PRELOAD �berschreibt. Test: Via tail
  /var/e2undel/e2undel beobachten, Netscape starten, einige Seiten anlaufen,
  aus Netscape heraus den Festplattencache l�schen (Edit -> Preferences ->
  Advanced -> Cache). Es m�ssen mehrere Files aus dem Netscape-Cache-Verzeichnis
  (normalerweise ~/.netscape/cache) auftauchen. Wenn nicht: Netscape-Startskript
  �ndern oder das Netscape-Binary direkt starten.

- �berschriebene Dateien (z.B. durch ein 'mv') lassen sich nicht recovern.

- Dateien, die vor der Installation von libundel gel�scht wurden, lassen sich
  nat�rlich nicht �ber ihren Namen herstellen. e2undel zeigt die Files mit der
  Option "-a" an, bei "-t" zus�tzlich mit einem Hinweis auf ihren Inhalt, und
  kann sie dann auch wiederherstellen.


2. Wieso behauptet 'e2undel', mehr Eintr�ge aus dem Logfile gelesen zu
   haben, als nachher angezeigt werden? Und wieso enth�lt das Logfile in
   Wirklichkeit noch mehr Eintr�ge?

'e2undel' gibt nach dem Einlesen des Logfiles die Anzahl der Eintr�ge mit
unterschiedlichen Inode-Nummmern aus. Da mehrfach Dateien auf demselben Inode
gespeichert und gel�scht worden sein k�nnen, ist die Zahl in der Regel geringer
als die Zahl der Zeilen im Logfile.

Angezeigt werden anschlie�end lediglich die Eintr�ge, die auf gel�schte Inodes
verweisen. Wenn auf einem Inode inzwischen eine neue Datei gespeichert wurde,
l�sst sich eine zuvor auf diesem Inode gespeicherte und gel�schte Datei nicht
mehr wiederherstellen. Logfile-Eintr�ge f�r nicht mehr gel�schte Inode-Nummern
sind daher hinf�llig. Wurde 'e2undel' nicht mit Option "-l" aufgerufen, werden
au�erdem nur die Eintr�ge f�r das mit "-d" ausgew�hlte Dateisystem angezeigt.


3. Gibt es Sicherheitsma�nahmen zu beachten?

- Das Dateisystem, auf dem man Daten retten will, sollte nicht gemountet sein;
  sonst besteht das Risiko, dass andere Prozesse ein als wiederherstellbar
  angezeigtes Files w�hrend des Recoverns "im Hintergrund" �berschreiben. Ist
  das nicht m�glich (z.B. weil es um Dateien auf dem /-Dateisystem geht), kann
  es bei wichtigen Daten sinnvoll sein, die Platte in ein anderes System
  einzubauen oder von Floppy oder CD-ROM zu booten. Ansonsten ist zumindest der
  Single User Mode zu empfehlen.

- Wenn das Dateisystem gemountet ist, kann ein vorheriges 'sync' nicht schaden.

- Das Verzeichnis, in dem e2undel wiederhergestellte Dateien speichert, sollte
  auf keinen Fall auf dem Dateisystem liegen, von dem man Daten recovern will:
  Es besteht das Risiko, dass die gerade wiederhergestellten Dateien als
  recoverbar angezeigte Dateien �berschreiben.

- Je nach Aktivit�t auf dem System kann das Logfile sehr schnell anwachsen;
  eine gelegentliche Kontrolle seiner Gr��e ist zu empfehlen. Das Skript
  compactlog.pl entfernt obsolete Eintr�ge: Werden auf einem Inode mehrfach
  Dateien gespeichert und gel�scht, l�sst sich sowieso nur die letzte davon
  wiederherstellen. Alle �lteren Eintr�ge f�r diesen Inode k�nnen raus.


4. Ist das Recovern gel�schter Files nicht gef�hrlich? Kann e2undel das
   Dateisystem besch�digen?

- e2undel greift lediglich lesend auf das Dateisystem zu und sollte daher
  nichts kaputt machen. Gelegentliche e2fsck-L�ufe beim Testen k�nnen
  trotzdem nicht schaden ...


5. Wieso findet e2undel auf ext3-Dateisystemen keine gel�schten Files? ext3
   und ext2 sind doch kompatibel.

ext3 unterscheidet sich in einer Hinsicht von ext2: Werden Dateien gel�scht,
werden auch alle Informationen im Inode inklusive der Nummern der belegten
Blocks entfernt. Auf ext3 lassen sich Dateien daher nicht mit der e2undel-
Methode wiederherstellen.