Hallo, aaarg. Irgendwann musste mir sowas ja passieren: durch einen Scriptfehler (in einem meiner eigenen Scripts an dem ich gerade arbeite) habe ich die ganze Arbeit von zwei Tagen zerstört (solange liegt das letzte Backup zurück). Ich habe mal wo aufgeschnappt, dass man den Befehl irgendwie Rückgängig machen könnte (habe zwar keine grosse Hoffnung, aber vielleicht gehts ja doch? Der Befehl bezog sich zum Glück "nur" auf den Inhalt EINES verzeichnisses). greetinXs, Telefon: 07275/918796 Michael Hilscher Handy: 0173/3071899 -- Would Mozart have been more productive if he had scribes to help him, a secretary and a CEO to lead his way? -- Linus Torvalds
Hallo Michael!
aaarg. Irgendwann musste mir sowas ja passieren: durch einen Scriptfehler (in einem meiner eigenen Scripts an dem ich gerade arbeite) habe ich die ganze Arbeit von zwei Tagen zerstört (solange liegt das letzte Backup zurück).
Ich habe mal wo aufgeschnappt, dass man den Befehl irgendwie Rückgängig
Wo!? Wäre echt toll, wenn das ginge. *grummel*
machen könnte (habe zwar keine grosse Hoffnung, aber vielleicht gehts ja doch? Der Befehl bezog sich zum Glück "nur" auf den Inhalt EINES verzeichnisses).
DAS kenne ich auch *Mitleid*. Mir ist keine Rettung bekannt. "rm" ist meines Wissens nach _sehr_ gründlich... Tschüss, Christian Weickhmann.
* Christian Weickhmann schrieb am 16.Feb.2002: Bitte den Vorredner nennen.
aaarg. Irgendwann musste mir sowas ja passieren: durch einen Scriptfehler (in einem meiner eigenen Scripts an dem ich gerade arbeite) habe ich die ganze Arbeit von zwei Tagen zerstört (solange liegt das letzte Backup zurück).
Ich habe mal wo aufgeschnappt, dass man den Befehl irgendwie Rückgängig
machen könnte (habe zwar keine grosse Hoffnung, aber vielleicht gehts ja doch? Der Befehl bezog sich zum Glück "nur" auf den Inhalt EINES verzeichnisses).
Inhalt eines Verzeichnisses ist niergends im Dateisystem abgebildet. Es ist völlig egal, ob in einem oder in meheren Verzeichnissen.
DAS kenne ich auch *Mitleid*. Mir ist keine Rettung bekannt. "rm" ist meines Wissens nach _sehr_ gründlich...
Nein, ist es nicht. Es ist zwar alles andere als leicht, und evtl. auch gefährlich, gelöschte Daten wiederherzustellen. Wenn man aber super geheime Daten hat an die jemand interessiert ist, und der dafür sehr, sehr viel Zeit investiert, dann braucht er sich nur die Device anzusehen, und die einzelne Blöcke zu lesen. Der Rest ist ein Puzzlespiel. Neuschreiben ist da natürlich viel schneller, wenn man die Daten kennt. Bernd -- ROTFL = Rolling On The Floor, Laughing = Auf dem Boden wälzen, lachend. SCNR = Sorry, Could Not Resist = Sorry, Ich konte nicht wiederstehen. AFAIK = As Far As I Know = So weit ich weis|BTW = By The Way = Nebenbei bemerkt IMHO = In My Humble Opinion = meiner bescheidenen Meinung nach |Zufallssig. 9
Hallo, at Sun, 17 Feb 2002 07:55:14 +0100 Bernd Brodesser wrote:
* Christian Weickhmann schrieb am 16.Feb.2002:
DAS kenne ich auch *Mitleid*. Mir ist keine Rettung bekannt. "rm" ist meines Wissens nach _sehr_ gründlich...
Nein, ist es nicht. Es ist zwar alles andere als leicht, und evtl. auch gefährlich, gelöschte Daten wiederherzustellen.
Also ein "rm" löscht die Daten logisch und nicht physikalisch ? Gruß Michael -- Homepage temporarily out of order Registered Linux User #228306 Phone/Fax +49 7000 MACBYTE http://counter.li.org GNU PGP-Key ID 22C51B8D0140F88B ++ Webdesign ++ PHP Development ++
Michael Raab schrieb:
Hallo,
at Sun, 17 Feb 2002 07:55:14 +0100 Bernd Brodesser wrote:
* Christian Weickhmann schrieb am 16.Feb.2002:
DAS kenne ich auch *Mitleid*. Mir ist keine Rettung bekannt. "rm" ist meines Wissens nach _sehr_ gründlich...
Nein, ist es nicht. Es ist zwar alles andere als leicht, und evtl. auch gefährlich, gelöschte Daten wiederherzustellen.
Also ein "rm" löscht die Daten logisch und nicht physikalisch ?
"rm" löscht nur den Eintrag in der Inode-Tabelle (jedenfalls bei ext2), die eigentlichen Datenblöcke werden nur zum Überschreiben freigegeben. Der Inhalt der Datenblöcke ist deshalb erst unwiderbringlich verloren, wenn das System diese freigegebenen Blöcke tatsächlich für das Speichern anderer Daten verwendet. _Was_ bei "rm" wirklich verloren geht, ist nur der Dateiname. Und der Inhalt der freigegebenen Blöcke läßt sich mit "debugfs" retten, wenn sie noch nicht für neue Dateien beansprucht worden sind. Grüße, Patrick
Hallo, On Sun, 17 Feb 2002, Patrick Hess wrote:
_Was_ bei "rm" wirklich verloren geht, ist nur der Dateiname.
Auch das nicht. Im Verzeichnis steht (zumindest eine Zeitlang) noch die Zuordnung Name <-> Inode, womit sich dann auch der Name wiederherstellen laesst. -dnh -- What boots up must come down. -- Paul Tomblin
Michael Hilscher schrieb:
aaarg. Irgendwann musste mir sowas ja passieren: durch einen Scriptfehler (in einem meiner eigenen Scripts an dem ich gerade arbeite) habe ich die ganze Arbeit von zwei Tagen zerstört (solange liegt das letzte Backup zurück).
Ich habe mal wo aufgeschnappt, dass man den Befehl irgendwie Rückgängig machen könnte (habe zwar keine grosse Hoffnung, aber vielleicht gehts ja doch? Der Befehl bezog sich zum Glück "nur" auf den Inhalt EINES verzeichnisses).
Welches Dateisystem wird denn auf der betreffenden Partition eingesetzt? In der SuSE SDB steht, wie man Dateien bei einem ext2-Dateisystem wiederherstellen kann. Ob es bei anderen Dateisystemen noch Hoffnung gibt, wage ich zu bezweifeln... Grüße, Patrick
On Sat, Feb 16, 2002 at 04:22:50PM +0100, Patrick Hess wrote:
Welches Dateisystem wird denn auf der betreffenden Partition eingesetzt? es ist ext2 - uhuhuh
In der SuSE SDB steht, wie man Dateien bei einem ext2-Dateisystem wiederherstellen kann. Weisst Du zufällig wo es dort steht? Ich bin wohl gerade "etwas" aufgeregt um es selbst zu finden...
greetinXs, Telefon: 07275/918796 Michael Hilscher Handy: 0173/3071899 -- Would Mozart have been more productive if he had scribes to help him, a secretary and a CEO to lead his way? -- Linus Torvalds
Michael Hilscher schrieb:
On Sat, Feb 16, 2002 at 04:22:50PM +0100, Patrick Hess wrote:
Welches Dateisystem wird denn auf der betreffenden Partition eingesetzt? es ist ext2 - uhuhuh
Also jubeln würde ich erst, wenn ich die Datei "in Händen halten" würde... Denn eine Garantie, daß die Wiederherstellung funktioniert, kann dir ext2 nicht geben.
In der SuSE SDB steht, wie man Dateien bei einem ext2-Dateisystem wiederherstellen kann. Weisst Du zufällig wo es dort steht? Ich bin wohl gerade "etwas" aufgeregt um es selbst zu finden...
Ok, versuch mal http://sdb.suse.de/de/sdb/html/cg_rmfiles.html Viel Glück!!!! Patrick
Hallo, at Sat, 16 Feb 2002 16:38:52 +0100 Patrick Hess wrote:
Michael Hilscher schrieb:
On Sat, Feb 16, 2002 at 04:22:50PM +0100, Patrick Hess wrote:
Welches Dateisystem wird denn auf der betreffenden Partition eingesetzt? es ist ext2 - uhuhuh
Also jubeln würde ich erst, wenn ich die Datei "in Händen halten" würde...
Als jubeln würde ich das nicht interpretieren sondern mehr als leidiges Wolfsgeheul. ;-) Gruß Michael -- Homepage temporarily out of order Registered Linux User #228306 Phone/Fax +49 7000 MACBYTE http://counter.li.org GNU PGP-Key ID 22C51B8D0140F88B ++ Webdesign ++ PHP Development ++
Michael Hilscher wrote:
Ich habe mal wo aufgeschnappt, dass man den Befehl irgendwie Rückgängig machen könnte (habe zwar keine grosse Hoffnung, aber vielleicht gehts ja doch? Der Befehl bezog sich zum Glück "nur" auf den Inhalt EINES verzeichnisses).
Es gibt ein Programm. recover und die GTK-GUI zu recover: gtkrecover, Das Problem, was ich sehe, ist das Du an Deinem Rechner weitergearbeitet hast und da kann es sehr leicht passiert sein, daß irgendein Prozeß schon die kleine Chance zunichte gemacht hat, indem die betreffenden Daten schon überschrieben wurden. Grüße Rene
On 16-Feb-2002 Rene Engelhard wrote:
Es gibt ein Programm.
recover und die GTK-GUI zu recover: gtkrecover,
Oder e2undel, undelete und unrm. Alle drei Programme komme ohne GUI aus.
Das Problem, was ich sehe, ist das Du an Deinem Rechner weitergearbeitet hast und da kann es sehr leicht passiert sein, daß irgendein Prozeß schon die kleine Chance zunichte gemacht hat, indem die betreffenden Daten schon überschrieben wurden.
Ich habe alle drei Programme mal getestet. Die Ausbeute war eher
bescheiden, obwohl ich die Partitionen immer sehr schnell ro gemountet
habe :-(
Beste Gruesse,
Heinz.
--
E-Mail: Heinz W. Pahlke
Hallo, On Sat, 16 Feb 2002, Heinz W. Pahlke wrote:
On 16-Feb-2002 Rene Engelhard wrote:
Es gibt ein Programm.
recover und die GTK-GUI zu recover: gtkrecover,
Oder e2undel, undelete und unrm. Alle drei Programme komme ohne GUI aus. [..] Ich habe alle drei Programme mal getestet. Die Ausbeute war eher bescheiden, obwohl ich die Partitionen immer sehr schnell ro gemountet habe :-(
Am besten per Hand mit debugfs... Da war vor ner Weile nen Artikel in der c't aber generell gibt's das ext2-undeletion-HOWTO. Achso, die Partition sollte man unbedingt nur ro (re)mounten. -dnh -- 117: Las Vegas Mekka fuer experimentelle Statistik. (Jens Hoffmann)
Servus und vielen Dank für die Hilfestellungen, ich habe es mit debugfs geschafft die Dateien zurückzuschreiben. Ich habe die anderen Recovertools nicht ausprobiert und die Platte noch nicht mal unmounted. Allerdings sind auf den Volume noch ca 1.8 GB frei, ausserdem habe ich die Arbeitsaktivitäten auf das wesentliche eingeschränkt. Vielleicht hatte ich auch nur einfach einen Riesendusel, dass sogar alle 124 Dateien des Ordners wiederherstellbar waren (oder es lag an den minni-Dateigrössen zwischen 1-50kb). Da jedoch alle Dateinamen wech sind (gelöschte Dateien können nur über Grösse und Löschdatum identifiziert und über den Inode gedumpt werden), kann von Glück reden, wer in all seinen Programmierprojekten sorgfältig ist und neben Datum auch zusätzlich den Dateinamen einkommentiert (leider hatte ich selbst das nicht bei allen benötigten Files gemacht). Der Einspielvorgang war dann eine ziemliche Blödelarbeit - ich habe nirgends nen Befehl entdeckt der alle Inodes die am XX.XX.XXXX um YY:YY:YY gelöscht wurden zurückholt und musste also die 124 Dateien manuell recovern (Cut & Paste - ich habe mich nicht getraut mit < dumpzeilen zu experimentieren) Würde mich für den hoffentlich nie eintrendenden Wiederholungsfall jedoch sehr interessieren, ob und wie es besser geht - werde bei etwas Zeit mal die manpage studieren und auf einem Testsystem rumblödeln.... greetinXs, Telefon: 07275/918796 Michael Hilscher Handy: 0173/3071899 -- Would Mozart have been more productive if he had scribes to help him, a secretary and a CEO to lead his way? -- Linus Torvalds
* Michael Hilscher schrieb am 17.Feb.2002:
ich habe es mit debugfs geschafft die Dateien zurückzuschreiben. Ich habe die anderen Recovertools nicht ausprobiert und die Platte noch nicht mal unmounted.
Ob Du das Dateisystem gemountet ist oder nicht, hat nichts mit dem Erfolg zu tun, es dient nur zur Sicherheit, da man sich sehr schnell das ganze Dateisystem zerschießen kann. Außerdem wird so vermieden, daß man durch die Rettungsaktion sich Blöcke zerstört. Oder cron wird gerade jetzt aktiv schreibt irgend ein log und zerstört dadurch Dein Block.
Allerdings sind auf den Volume noch ca 1.8 GB frei,
Das ist egal.
ausserdem habe ich die Arbeitsaktivitäten auf das wesentliche eingeschränkt.
Das ist der wesentliche Punkt. Sobald Du irgendetwas schreibst, wird das gerade gelöschte überschrieben. Du hast wahrscheinlich keine Datei mehr geschrieben, und auch kein cron oder ein anderer Dämon.
Vielleicht hatte ich auch nur einfach einen Riesendusel, dass sogar alle 124 Dateien des Ordners wiederherstellbar waren (oder es lag an den minni-Dateigrössen zwischen 1-50kb).
Es lag daran, daß in der Zwichenzeit nichts mehr geschrieben wurde.
Da jedoch alle Dateinamen wech sind (gelöschte Dateien können nur über Grösse und Löschdatum identifiziert und über den Inode gedumpt werden), kann von Glück reden, wer in all seinen Programmierprojekten sorgfältig ist und neben Datum auch zusätzlich den Dateinamen einkommentiert (leider hatte ich selbst das nicht bei allen benötigten Files gemacht).
Eine Datei kann ja auch mehere Namen haben. (Hardlinks) und bei Binaries bist Du so wie so aufgeschmissen.
Der Einspielvorgang war dann eine ziemliche Blödelarbeit - ich habe nirgends nen Befehl entdeckt der alle Inodes die am XX.XX.XXXX um YY:YY:YY gelöscht wurden zurückholt und musste also die 124 Dateien manuell recovern (Cut & Paste - ich habe mich nicht getraut mit < dumpzeilen zu experimentieren)
Würde mich für den hoffentlich nie eintrendenden Wiederholungsfall jedoch sehr interessieren, ob und wie es besser geht - werde bei etwas Zeit mal die manpage studieren und auf einem Testsystem rumblödeln....
Besser ist, nie etwas zu löschen, was man noch braucht. Linux ist nun mal ein Mehrbenutzersystem. Wenn wirklich viele User gleichzeitig arbeiten, ist es sehr unwahrscheinlich, daß keiner, auch kein Dämon einen Schreibzugriff macht. Bernd
Michael Hilscher wrote: Auch wenn du es schon geschafft hast. Hier noch mal ne Kruzfassung zu debugfs, für alle die diesen Thread artig mitlesen. Kann sein, daß ich was vergessen habe. Ist schon ein wenig her. DEBUGFS Einen passenden Artikel gibt es in der ct 6/2000. Du startest debugfs dann öffnest du die _nicht gemountete_ Partition mit den gelöschten Daten mit open /dev/Partition Mit dem Kommando lsdel erzeugst du eine Liste aller gelöschten Inodes. Das schöne, Datum und Uhrzeit der Löschung werden mit angegeben. stat <inode> zeigt dir dann die Nummern der Datenblöcke an, die zur Inode gehören dump <inode> dateiname speichert dann die Datenblöcke in eine neue Datei Denk dran. Schreibe die neue Datei auf eine andere Partition. Nicht, daß du eine unwichtige Datei widerherstellst und dabei die wichtige überschreibst. ...Ich habe so einmal ein ganze Partition (500MB) wieder hergestellt. Dennis -- Registered Linux User #250379 (see http://counter.li.org)
Hallo, On Sun, 17 Feb 2002, Dennis Boller wrote:
DEBUGFS Einen passenden Artikel gibt es in der ct 6/2000.
Hier fehlt ein 'mount -o remount,ro'!!!
Du startest debugfs [...]
Achso: man kann auch die Verzeichnisse dumpen und sich dann anhand der Eintraege die Dateinamen wieder raussuchen. ==== ext2fs.h (IIRC) ==== #define EXT2_NAME_LEN 255 struct ext2_dir_entry { __u32 inode; /* Inode number */ __u16 rec_len; /* Directory entry length */ __u16 name_len; /* Name length */ char name[EXT2_NAME_LEN]; /* File name */ }; /* * The new version of the directory entry. Since EXT2 structures are * stored in intel byte order, and the name_len field could never be * bigger than 255 chars, it's safe to reclaim the extra byte for the * file_type field. */ struct ext2_dir_entry_2 { __u32 inode; /* Inode number */ __u16 rec_len; /* Directory entry length */ __u8 name_len; /* Name length */ __u8 file_type; char name[EXT2_NAME_LEN]; /* File name */ }; ===== Ein Eintrag sieht dann z.B. so aus: ==== 1f 00 00 00 .... 0c 00 03 00 74 6d 70 ....tmp ==== Inode ist "0x0000001f" (little endian ;) also 31, der gesamte Eintrag ist 12 byte lang (0x000c), der Name ist 3 (0x0003) bytes lang und lautet "tmp" (0x74 0x6d 0x70) ;) -dnh PS: nein, die Namen sind _nicht_ Null-terminiert... -- 185: LaTeX Eine spülmaschienenfeste Seitenbeschreibungssprache. (Cornell Binder)
On Sun, Feb 17, 2002 at 04:23:20PM +0100, Dennis Boller wrote:
dump <inode> dateiname speichert dann die Datenblöcke in eine neue Datei ...Ich habe so einmal ein ganze Partition (500MB) wieder hergestellt. Doch wohl nicht für jede Datei einzeln dump <inode> dateiname eingegeben? Das wäre ja schier unerträglich - wie hast Du das denn elegant umgesetzt?
greetinXs, Telefon: 07275/918796 Michael Hilscher Handy: 0173/3071899 -- Would Mozart have been more productive if he had scribes to help him, a secretary and a CEO to lead his way? -- Linus Torvalds
Michael Hilscher wrote:
On Sun, Feb 17, 2002 at 04:23:20PM +0100, Dennis Boller wrote:
dump <inode> dateiname speichert dann die Datenblöcke in eine neue Datei ...Ich habe so einmal ein ganze Partition (500MB) wieder hergestellt. Doch wohl nicht für jede Datei einzeln dump <inode> dateiname eingegeben? Das wäre ja schier unerträglich - wie hast Du das denn elegant umgesetzt?
Oh doch. Gut, die Partition war nur zu 68% gefüllt. Zuerst hat ich mir mit lsdel alle gelöschten inodes ausgegeben und in eine Datei geschrieben. Dann habe ich eine Script erzeugt erzeugt, das jede Inode wiederherstellt. Mit cat, cut und wie sie alle heißen geht das recht schnell. Als Dateinamen habe ich die Inode benutzt. Danach habe ich in mühseliger Kleinarbeit mit jede Datei angeschaut und versucht aus dem Inhalt auf den alten Dateinamen zu schließen. Das ging recht zügig. Zumal ich dabei auch gleich aufgeräumt habe. Haken waren bloß Verzeichnisse, die plötzlich als riesengroße Datei vorlagen. Da ich hier keinen besseren Weg wußte, habe ich diese Datei dann mut cut+paste in kleine Dateien zerschnippelt. Irgendwann nach einer Flasche Rotwein, weiß man ziemlich genau wie ein zip-File angfängt und was die ersten Buchstaben eines StarOffice-Dokumentes sind. Und was haben wir gelernt Benutze NIEMALS rm -r *, wenn du im falschen Verzeichnis bist, z.B. /home. Dennis -- Registered Linux User #250379 (see http://counter.li.org)
participants (9)
-
B.Brodesser＠t-online.de -
Christian Weickhmann -
David Haller -
Dennis Boller -
Heinz W. Pahlke -
Michael Hilscher -
Michael Raab -
patrick_hess＠t-online.de -
Rene Engelhard