Ubuntu-Forum & Kubuntu-Forum | www.Ubuntu-Forum.de

Leider bin ich doch wieder auf die Hürde zurückgeworfen, welche ich bereits glaubte gelöst zu haben:
http://www.ubuntu-forum.de/post/397610/o…html#post397610
(und warum eigentlich kann man hier nicht eigene Postings als Zitat einfügen? )

Die Einstellungen habe ich so gesetzt:


Das neu aufgetauchte Problem ist nun, dass nach Neustart und neu anschliessen der USB Festplatte, in "mnt" nun die bereits - völlig automatisch - eingehängte USB Festplatte zu sehen ist.


Genau das was ich eben nicht will.

Logisch Weise klappt auch ein "read-only" mounten am vorgesehen Einhängepunkt nicht mehr:


Ich kann "usb-TOSHIBA_External_USB_3.0_23945C152747-0:0-part1" natürlich nach abstecken löschen, aber es kommt sofort wieder wenn ich die USB Platte wieder anstecke
Wie bekomme ich es also gebacken, dass kein automatisches mounten der USB Laufwerke erfolgt

Das Problem scheint in einem Eintrag in der /etc/fstab gelegen zu haben:


Keine Ahnung wie und warum oder wann der dort hineingekommen ist, aber mit auskommentieren dieses Eintrags klappt das nun, dass USB Laufwerke nicht mehr beim anstecken automatisch eingehängt werden.
Auch nach einem Neustart.

Wenn ich das was ich über ext4magic gelesen habe richtig verstanden habe, dann ist es keineswegs "Jacke wie Hose", ob die Partition aus welcher ich Daten retten möchte zwischendurch noch mal oder auch öfter "normal" eingehängt wurde.

Ok
Dann stelle ich nochmal die Frage wie es am besten zu machen wäre, dass USB Laufwerke generell NICHT automatisch eingehängt werden, oder ob es sinnvoller ist gleich auf eine "Server Variante" umzusteigen, wo dies - wenn ich es richtig verstanden habe - sowieso die Standardeinstellung ist

Ok, danke

Dann bleib ich beim „dconf-editor" aus den „dconf-tools“.
Damit klappt sowas mit den weiter oben gezeigten Einstellungen.
Der Fehleintrag in der /etc/fstab stammte nämlich nicht vom "dconf-editor" sondern vom "Laufwerke" tool, wie ich in der Zwischenzeit ausgetestet habe.


"ext4magic" funzt übrigens auch - offenbar problemlos - an externen USB Festplatten, wie ich zwischenzeitlich ebenfalls ausgetestet habe und auch auf/ mit jener mittels GParted "gesicherten" Partition, wo ich die verlustig gegangenen Dateien finden sollte.
Allerdings will "ext4magic" mit sudo gestartet werden, sonst hagelts Fehlermeldungen.
Ein Einhängen (zB read-only) der externen Festplatte ist darüber hinaus völlig überflüssig (bzw nach meinem Verständnis sogar eher schädlich, weil datenvernichtend), da man problemlos direkt auf /dev/sdb1 (aktuell bei mir die interessierende, erste Partition auf der externen USB Festplatte) zugreifen kann:



Die restaurierten Dateien werden bei obigem Befehl im "/home/recovery_ext4magic" Ordner abgelegt, welcher schon vorhanden sein muss bzw man zuvor anlegen muss. Wie man diesen benennen möchte und wo der erstellt wird, ist im Prinzip völlig egal.

Leider ist - bei allem Fortschritt - das von mir gesuchte noch nicht zum Vorschein gekommen was zwar bitter aber nicht verwunderlich ist, da ich den Verlust ja erst relativ spät bemerkt habe und zwischenzeitlich einiges im System umgerührt wurde.
Werde also noch ein paar verschärfte Varianten durchprobieren.

Zusammenfassung (m)eines Datenrecovery mittels ext4magic für noobs, von einem noob
(bezieht sich hier konkret auf die Rettung einer grösseren gelöschten Datei in der Partition des Hauptsystems)


Erster und wichtigster Schritt:


Bei allem Ärger über den erlittenen Datenverlust, darf man sich zuallererst mit dem Gedanken anfreunden, dass eine Datenrettung viel Geduld, einiges an Geld und nicht weniges an Lernkurve verlangt.
Hat man diesen ersten Schritt einer nicht unerheblichen mentale Hürde erst mal gepackt, steht man als noob (wie ich zB) vor etlichen weiteren handwerklichen Hürden, Fallstricken und Klippen.


Damit die grösstmöglichen Chancen auf eine Datenrettung bestehen, muss sofort nach entdecken des Verlustes die entsprechende Partition stillgelegt und auf die eine oder andere Art gesichert bzw gerettet werden.
Da bei mir die zu rettenden Daten auf meinem Hauptsystem gelegen hatten, diese jedoch für den Normalbetrieb nicht zwingend erforderlich waren, hab ich mir ein Zweitsystem gebastelt, um das Hauptsystem während des absehbar langwierigen recoveryprozesses weiter benutzen zu können .

Dh
1. sofort nach entdecken des Verlustes das Hauptsystem ausschalten und
2. das "Journal" der betroffenen Partition zB auf einen USB Stick sichern bzw retten
3. die gesamte Partition des Hauptsystems in einem Stück
4. zB mittels GParted aus zB einem Live-Ubuntu heraus auf
5. eine externe Festplatte kopieren.

Es macht Sinn, die externe Festplatte gross genug zu wählen, dass zwei Kopien der zu sichernden Partition darauf Platz finden (man arbeitet dann immer nur mit der einen und hält die andere für den Fall der Fälle in Reserve), oder man legt eine Reservekopie der zu sichernden Partition noch irgendwo anders ab.
Falls der Geldbeutel dies zulässt macht es auch Sinn, dafür eine schnelle SSD anzuschaffen, welche mit einer schnellen Schnittstelle (USB3) angebunden werden kann vor allem, wenn die zu sichernde Partition etwas grösser ist und jedes hantieren damit eh schon lange dauert.

Wie man sich ein Live-Ubuntu (in meinem Fall ein Xenial, "16.04 Desktop 64bit") zB für einen USB Stick oder eine CD/ DVD erstellt ist leicht herauszufinden und gut dokumentiert.
Allerdings muss man sich dieses in einem Fall wie dem meinen, zwingend bereits von einem anderen System aus erstellen !!!


Beim Bootvorgang mit dem Live-Ubuntu auf dem zu sichernden System
1. zuerst ins BIOS springen (geht iA mit Esc, F1 oder F2, sonst im i-net herausfinden), dort
2. die System-Festplatte in der Bootreihenfolge ganz ans Ende setzen) und
3. dann das Live-Ubuntu starten lassen.


Da auf einem Live-Ubuntu das Programm GParted üblicherweise bereits vorhanden ist, startet man dieses nun und sucht sich
1. die zu sichernde Partition (in meinem Fall sda1)
2. muss diese ggf noch aushängen (geht per rechtsklick auf die Grafik)
3. markiert und kopiert sie in einem Stück
4. in jene externe(n) Festplatte(n), welche man für die Sicherung(en) der Partition hernehmen möchte bzw vorbereitet hat

Die Auswahl der - beim Start von GParted - im System vorhandenen Datenträger erfolgt über den pulldown-button rechts oben.
Wird einen neuer Datenträger angesteckt muss man
1. entweder GParted neu starten oder
2. über das pulldown Menü "GParted"
3. -> "Geräte aktualisieren" auswählen
um diesen sehen bzw bearbeiten zu können.

Es ist von einigem Vorteil, wenn man mit GParted bereits etwas vertraut ist, da man sich damit - wie auch mit dem Terminal natürlich - einiges oder gleich auch das ganze System zerschiessen kann

https://wiki.ubuntuusers.de/GParted/


Genauso wichtig wie die Sicherung bzw. Rettung der betroffenen Partition in bestmöglichem Zustand ist die Sicherung und Rettung des "Journal" der betroffenen Partition.
Dieses "Journal" degeneriert nämlich, soweit ich dies verstanden habe, bei jedem Zugriff auf die Partition, also auch schon bei einem Einhängen oder auch bei jedem Durchsuchen mit ext4magic.

Der nachfolgende Befehl "debugfs" geht davon aus, dass das zu rettende bzw. zu sichernde "Journal" (bzw der uns interessierende Teil davon) in der zu rettenden bzw zu sichernden Partition /dev/sdc1 liegt und dass auf dem Live-Ubuntu bereits ein "recovery_ext4magic_JournalCopy" Ordner in /home angelegt wurde.
Im Prinzip ist es natürlich egal, wie der Ordner benannt und wo er erstellt wird.

Da "debugfs" auf einem Live-Ubuntu üblicherweise bereits vorhandenen ist, öffnet man mit Strg + Alt + t das Terminal und gibt folgendes ein:



ACHTUNG
diesen Befehl aus irgendwelchen englischsprachigen pages zu kopieren führt iA zu einer Fehlermeldung, da die Anführungszeichen dort oft andere sind und der Befehl deshalb nicht angenommen wird.

Da wir die Datei "journal.copy" später für das ausführen von ext4magic natürlich brauchen werden, müssen wir diese in der Folge zB auf einen externen USB Stick kopieren.


Wie es scheint, ist es unter Ubuntu selbst in der ver 16.04 noch sowas wie eine Geheimwissenschaft, wie ein USB Stick für den allgemeinen Gebrauch zurechtzuklopfen sei.
Meine Methode ist es, einen neuen USB Stick
1. in GParted mit ext4 zu formatieren und
2. nachfolgend in Nautilus auf das noch leere Fenster des Stick
3. einen Rechtsklick ausführen
4. -> "im Terminal öffnen" auswählen und
5. im Terminal dann ausführen


Damit ist einer weiterer wichtiger Schritt, nämlich die Sicherung der Daten(reste) sowie des zugehörigen "Journal" in bestmöglichem Zustand getan und sind die ersten Voraussetzungen für eine hoffentlich erfolgreiche Datenrettung geschaffen.


Mein nächster Schritt war es, mir ein massgeschneidertes Zweitsystem aufzubauen, damit ich mich der eigentlichen Datenrettung unabhängig und ohne Stress irgendwas zu verbiegen oder zu zerschiessen, widmen kann.
Mit dem eh schon vorhandenen Live-Ubuntu hab ich mir also ein komplettes, neues Sytem (in meinem Fall Xenial Desktop 64bit) installiert.


Nach dem ersten Start des neuen Systems ruft man sinnvoller Weise
1. erst mal die Aktualisierungsverwaltung auf, geht
2. in die Einstellungen und hakelt
3. unter dem Reiter "Ubuntu Anwendungen" "main, universe, restricted, multiverse" an, lässt
4. die automatisch einsetzende Suche nach neuen Paketen fertig laufen und
5. installiert diese auch gleich
6. mittels -> "jetzt installieren",
was etwas dauern kann.


Für weitere Installationen unter einer grafischen Oberfläche (mit der Kommandozeilenakrobatik im Terminal hab ich echt meine Probleme !) hab ich mir Synaptic installiert:

https://wiki.ubuntuusers.de/Synaptic/

Mit Strg + Alt + t ein Terminal öffnen und



ausführen.

Als Tastenfreak erleichtert man sich den Krampf mit den Terminal übrigens erheblich, indem man diesem die üblichen Tasten-shortcuts beibringt:

1. man geht im pulldown "bearbeiten"
2. auf Einstellungen
3. im Tab Tastenkürzel geht man
4. auf Bearbeiten und
5. auf Kopiern, dort dann
6. auf "Tastenkombination" doppelklicken (um diese zu ändern) und
7. "Strg + c" drücken (was sofort übernommen wird)
und macht dasselbe auch noch für die Funktion Einfügen (Strg + v)

Netter Weise merkt sich das Terminal (auch nach dem schliessen) zumindest die Litanei der einmal ausgeführten Befehle, durch welche man mit "Pfeiltaste nach oben bzw. unten" scrollen kann.



Als nächsten Schritt macht man sich am besten etwas schlau zu "ext4magic"


Einiges Wissen hierzu kann man sich bei den üblichen Verdächtigen und insbesondere auch hier anlesen:
http://ext4magic.sourceforge.net/ext4magic_de.html
http://ext4magic.sourceforge.net/tips_de.html
http://ext4magic.sourceforge.net/manpage_de.html
sowie auf etlichen anderen pages, oft in etwas krausem Englisch.

Für ein recovery aus einer ext4 formatierten Partition (wie bei mir zB) wird dz die ver. 0.3.2.xxx empfohlen.

Also hab ich mir ext4magic mittels der Synaptic-Paketverwaltung installiert:
1. "Strg + f" lässt in Synaptic ein Suchfenster aufpoppen, in welches man
2. "ext4magic" schreibt oder hineinkopiert, was daraufhin
3. die dz. neueste Version 0.3.2-3 zum Vorschein bringt, welche man
4. mit Rechtsklick zum installieren vormerkt und
5. den button "Anwenden" drückt, woraufhin
6. die Sicherheitsabfrage zu checken und
7. der ganzen Krempel zu installieren ist

Wenn man grad schon dabei ist, macht es Sinn auf die selbe Art gleich auch noch "GParted" zu installieren (welches aus für mich unerfindlichen Gründen in der Ubuntu Desktop Variante standardmässig nicht mitinstalliert wird) sowie "gksu" und "dconfg-tools" (dz. aktuelle Version 0.24.0-2), welche wir noch brauchen werden.


Damit ist ein weiterer wichtiger Schritt getan.


Also üben wir uns jetzt in einem recovery mittels ext4magic an irgendeiner USB Festplatte, auf welcher wir
1. irgendeinen "TestOrdner" mit
2. irgendeiner "TestDatei" darin
3. erstellen und
4. daraufhin den "TestOrdner" samt "TestDatei" darin löschen.

Bevor man aber damit beginnt, die verlustig gegangenen Daten rekonstruieren zu wollen, ist es im Sinne des Daten(reste)erhaltes meiner Ansicht nach wichtig, dass externe Festplatten - auf welchen ja die zu durchsuchenden Partitionen nun liegen - nicht automatisch eingehängt werden.

Die einfachste (und zumindest bei mir auch tatsächlich funktionierende) Methode welche ich dafür gefunden habe ist mit dem Programm "dconfg-tools" realisierbar.

https://wiki.ubuntuusers.de/Automount/

Man startet den dconf-Editor in gewohnter Weise, und navigiert - wie im wiki zu lesen -
1. zu org -> gnome -> desktop -> media.handling und hakelt dort
2. "automount" und "automount-open" aus und
3. "autorun-never" an

Diese Einstellung wird beim schliessen des dconf-Editor sofort übernommen. Es braucht also keinen Neustart.


Damit hat man einen weiteren wichtigen Schritt getan.


Ob alles soweit klappt probiert man am besten mit der zuvor präparierten USB Festplatte zuerst aus.

Diese muss in Nautilus zwar (in der linken Leiste) aufscheinen, darf aber - weil ja nicht eingehängt - keinen Pfeil bzw button zum aushängen neben sich anzeigen.
Keinesfalls aus Neugierde anklicken, da die Partition dadurch eingehängt würde, was wir ja vermeiden wollen.

Um ganz sicher zu gehen, kann man sich auch mit dem Terminal mühen:



Hier sollte dann zu sehen sein, was wie gemountet im System vorhanden ist.
Die externe(n) Partitionen müssten logischer Weise als "not-mounted" aufscheinen.

Diese Ausgabe ist ebenfalls hilfreich, was aktuell die genau Bezeichnung der externen Festplatte sei (diese kann sich bei neuanstecken ändern!), weil die genaue Bezeichnung brauchen wir dann ja auch für einen ersten Testlauf von "ext4magic".
Alternativ kann man die aktuelle Bezeichnung (/dev/sxyz) auch mit GParted ermitteln.

Damit die restaurierten Dateien an einem mehr oder weniger sinnvollen Platz abgelegt werden, erstellt man auf dem System zB in /home einen Ordner "recovery_ext4magic123".
Wie man diesen benennen möchte und wo dieser erstellt wird, ist im Prinzip jedoch völlig egal.

Zu guter Letzt öffnet man wiedereinmal ein Terminalfenster und führt zB folgenden Befehl aus:



ACHTUNG
Der obige Befehl ist nur und ausschliesslich für einen Probelauf gedacht.
Auf jener Partition aus welcher man Daten retten möchte ist es dringend angeraten, ext4magic die Suche in der Partition ausschliesslich über ein zuvor gerettetes "Journal" zu erlauben (Erklärung findet sich weiter oben).
Unter der Voraussetzung, dass die zu untersuchende, externe Festplatte /dev/sdb1 war, sollten sich nun in /home/recovery_ext4magic123 alle restaurierten Dateien - und somit auch die gelöschte Datei "TestDatei" - befinden.



Ist auch dies erfolgreich verlaufen, war dies der letzte vorbereitende Schritt für eine hoffentlich erfolgreiche Restaurierung der Daten aus der ganz zu Beginn gesicherten Partition sowie des zugehörigen, ganz zu Beginn gesicherten Journal.



Dazu kopiert man nun das im allerersten Schritt in das file "journal.copy" gerettete bzw gesicherte Journal zB in den lokal anzulegenden Ordner "/home/recovery_ext4magic_JournalCopy"

Falls die Rettung des Journal oben vergessen wurde oder aus irgendeinem Grund nicht möglich war, müssten die entsprechenden Schritte allerspätestens jetzt - und vor jedem weiteren Zugriff auf die zu durchsuchende Partition - nach der oben beschriebenen Weise ausgeführt werden!

Nun wirds ernst:
Im Terminal kann nun zB mit



oder alternativ mit



nach gelöschten Dateien gesucht werden.

Der erste Befehl sucht nach sämtlichen je auf der Partition gelöschten Daten, was schnell mal eine Million an Treffern oder mehr ergeben kann.
Der zweite Befehl sucht nach auf der Partition gelöschten Daten, welche - vom aktuellen Datum aus gerechnet - vor 6 bis 10 Tagen gelöscht wurden. Für ein anderes (vermutetes) Löschdatum müssen nur die Ziffern ("6" bzw "10") entsprechend korrigiert werden.

Beide Varianten dauern natürlich ihre Zeit.
Es macht Sinn, sich für jeden neuen recovery Durchgang einen eigenen "recovery_ext4magic123" Ordner anzulegen und natürlich auch den Befhl entsprechend anzupassen.

Da mit einiger Wahrscheinlichkeit (wie auch bei mir) einiges an Daten in Ordner "recovery_ext4magic123" mit rootrechten gesperrt sein wird, startet man sich ein Nautilus mit rootrechten aus dem Terminal mittels



um in dem ganzen Wust die recoverten Dateien einigermassen komfortabel suchen zu können.

Dateien welche ext4magic nicht mehr vollständig zuordnen konnte, können sich uU auch noch in den Ordnern "Magic-123" verstecken.

Zitat von »Fredl«

Klingt wie eine gefährliche Drohung.

Ich glaube, hier im Forum kann dir keiner mehr folgen.

Echt?
Ich habs eh bereits weiter oben klar ausgebreitet:

Ja ich habe auch noch eine Backup-Platte im Talon.
Aber diese ist - wie üblicher Weise alle !!! Backups - natürlich nicht mehr wirklich taufrisch.

Somit versuche ich zuerst die verlustig gegangenen Daten zu recovern, weil diese sind - logo - "as taufrisch as can be".

Sollte ich mit meinen recovery Versuchen trotz verschärfter Vorgehensweise (siehe tips und tricks zu ext4magic) in der Sackgasse landen, dann werd ich in den sauren Apfel beissen (müssen) und versuchen die Dateien der leicht angegammelten backup Platte aufzubürsten.

Zitat von »Fredl«

Irgendwie dürfte mir entgangen sein, daß du mit einem Reservesystem arbeitest und sdb1 die Platte mit den zerstörten Daten ist.

Kein Problem.
So sind meine durchlittenen ups and downs vielleicht auch für andere hilfreich und damit doch noch zu etwas gut.


+++

Danke jedenfalls für alle Hilfestellungen

So jetzt muss ich leider doch aufgeben.

Habe x gefinkelte recovery Varianten mit ext4magic durch.
Das beste Ergebnis war ein recovery von ein paar kB der original mehrere GB grossen Datei.
War wohl schon zuviel geschehen bevor ich den Verlust bemerkt hatte.

Hat man die Logik wie der Befehl für ext4magic Stück für Stück aufgebaut werden muss ([Pfad zu durchsuchender Partition] [Pfad und Name des einzubindenden Journal] [Zeitfenster wo gelöscht wurde entweder mittels zurückliegender Tage oder mittels UTC] [Art der Suchfunktion] [Pfad zum Ausgabe Ordner]) erst mal durchschaut, gehts damit ganz gut.

Ist halt alles sehr zeitaufwändig und man darf nicht vergessen, dass auch ein riesiger Haufen Unbrauchbares immer wieder zu löschen ist, was ebenfalls viel Zeit in Anspruch nimmt.

Insofern war meine Entscheidung mir extra dafür ein Zweitsystem zu basteln die Richtige gewesen, auch wenn sichs in diesem Fall leider nicht ausgezaht hat.

das nächst mal vielleicht