ubuntuusers.de

Es gibt noch The Coroner's Toolkit (Paket tct). Hab aber selber auch noch nichts davon benutzt.

Sorry, hab den Thread erst jetzt gesehen.

der Eintrag bei "grep" hat mir gerade nen Haufen Arbeit erspart! Danke ☺

Wer möchte diesen Artikel ein wenig überarbeiten? Es fehlen ein paar Informationen (s. Artikeltext).

Hallo,

ich muss gerade mit dd_rescue eine defekte Festplatte wiederherstellen. Den entsprechenden Abschnitt kann ich dabei prüfen.

Laut Wiki-Artikel gibt es aber zu dd_rescue noch eine Beschreibung:

Die Anwendung von dd_rescue ist relativ simpel und sehr ausführlich auf linux-user.de 🇩🇪 beschrieben, eine kurze Beschreibung findet man auch im Wiki-Artikel Notfall.

Wo ist die Erklärung abgeblieben?

Torsten

unbekannt1984 schrieb:

Wo ist die Erklärung abgeblieben?

• Festplatten Problembehebung (Abschnitt „Daten-von-defekten-Datentraegern-kopieren“)

• gddrescue

Hinweis für NTFS:

ntfsfix: new option -d to clear the dirty flag if fix is successful

2012.1.15: Neue NTFS-3G-Ausgabe veröffentlicht 23 Januar 2012 Für ntfsfix gibt es die neue Option -d. Diese hebt das “Dirty Flag” auf, wenn ein Fix erfolgreich durchlaufen ist. Mit einer weiteren Option können sich Anwender die Liste schlechter Sektoren anzeigen lassen.

http://www.bitblokes.de/2012/01/2012-1-15-neue-ntfs-3g-ausgabe-veroffentlicht/

http://www.tuxera.com/community/release-history/

Das duerfte unter Ubuntu vorerst keine Rolle spielen, da diese Version derzeit nicht in den offiziellen Paketquellen enthalten ist (ntfs-3g).

Sollte einmal grob überarbeitet werden - zumindest von der Syntax her.

Die letzte Tabelle bei safecopy macht irgendwie überhaupt keinen Sinn. Einfach

safecopy /dev/device ~/diskimage

erstellt ein Image des Dateisystems vom beschädigten Datenträger

wäre wohl besser, oder?

MfG, PCHSwS

PCHSwS: Könntest Du das etwas näher erläutern? Ich sehe keinen Unterschied zwischen Deinem Vorschlag und dem Artikel?

Den Befehl lsdel bei Datenrettung#Methode-2-debugfs gibt es laut manpage nicht. Stattdessen wird von ls -d gesprochen.

Naja, eine Tabelle wäre imho nur dann angebracht, wenn man jetzt mehrere Syntaxbeispiele hätte. Aber da ja in jeder Spalte nur ein Eintrag ist, ist sie doch überflüssig, noch dazu die redundante Überschrift.

Außerdem stimmt die Überschrift der 1. Spalte gar nicht. Das ist kein Parameter, das ist ein Aufrufbeispiel. Also wenn schon "Befehl". Daher würde ich die Tabelle einfach auflösen.

MfG

Hallo aasche, long time no see 😉

Uijuijui. Dieser Artikel ist ja taufrisch! 😉

Mir ist doch tatsächlich (durch eine Fehlbedienung/Mißverständnis) eine Datei aus einem ext4-Dateisystem flöten gegangen. (Ok, es gibt schlimmere Mißgeschicke!)

Aber, ich dachte mir: Super! Jetzt kann ich mal was ausprobieren/lernen! Wie rettet man eigentlich Dateien unter Linux? (Anm.: ohne ZFS)

Leider fiel mir beim googeln diese deutsche Seite gar nicht auf, weil ich gleich englisch gesucht hatte. Schade. Sonst hätte ich deren Gehalt gleich mal auf Herz und Nieren prüfen können...

Aber: sofortiger Unmount des Datenträgers ging nicht (weil "in use") und auf die Idee mit <Ctrl>+<Alt>+<Druck>+U kam ich in dem Moment nicht. ☹

Also runterfahren und ins Live-System..., weitersuchen (im Netz) dann Installation von Werkzeugen (ich habe es zuerst mit foremost, dann mit extundelete versucht - beide sind in Ubuntu Repos).

Kurzfassung, beide Versuche scheiterten, beim Letzteren sogar katastrophal (erzeugte 300 GB an Dateien beim Versuch 1 Textdatei aus einem Volume von nur 15 GB Gesamtgröße zu extrahieren und endete erst, als das Ziel-Dateisystem voll war!).

Aber, da ja alles mehr die Simulation eines Ernstfalles war, als eine echte Krise, nutze ich die Laufzeit der Tools, die Datei aus einem Backup und anderen Informationen zu rekonstruieren. Und wahrscheinlich ist sie sogar noch in meinem Git-Repository. Doch erlerne ich git gerade erst und habe mir genau DAMIT die Datei zerschossen, als ich sie aus dem Repository-INDEX nehmen wollte und "git rm <Datei>" ausführte, OHNE den Schalter --cached einzusetzen (bzw. ganz ähnlich blöde).

Quintessenz? Ich kann immer noch keine Daten aus ext4 retten, habe aber auf diese Weise festgestellt, daß meine Backup-Strategie ziemlich gut funktioniert! ☺

datenninja schrieb:

Quintessenz? Ich kann immer noch keine Daten aus ext4 retten, ...

Ja, zu ext4 sind die Informationen rar. Aber was mir noch einfaellt: kuerzlich ist der Artikel Papierkorb ueberarbeitet worden und es gibt mind. drei Loesungen fuer die Kommandozeile - wenn man den Umgang mit diesen Loesungen verinnerlichen kann.

PS: die Markierung "ausbaufaehig" entfernt - diese stammt von 2008...

Huch! Es ist ja schon Mittag... und ich hab letzte Nacht noch nicht geschlafen...

Danke für den Hinweis. Aber a) habe ich ja mein Problem bereits gelöst, b) wäre in der Tat die Datei noch in git gewesen und c) hat ja ein Programm (git) die Datei gelöscht. Da wäre also der Papierkorb sowieso nutzlos gewesen.

Aber die "Baustelle Datenrettung" habe ich bereits verlassen und mache mich nun mehr mit den "Innereien von git" vertraut. Versionskontrolle haben wir auch schon vor 20 Jahren eingesetzt, aber DVCS - das ist schon etwas Anderes!

Und mal bald poofen... 😉

datenninja schrieb:

Und mal bald poofen... 😉

Und danach mal einen Blick auf Ext4magic 🇩🇪 werfen 😉