Sie sind nicht angemeldet.

21

27.01.2018, 20:49

Auf die externe USB soll ja überhaupt nichts weiter geschrieben werden!
Wenn die Dateien einem anderen User gehören, kannst du sie auch nicht lesen. Da es meistens nur einen User gibt ist die Wahrscheinlichkeit groß daß es eh der gleiche ist wie jetzt wieder. Die UID ist ja normalerweise 1000. Außer jemand hat unbedacht als root gearbeitet und dabei den Eigentümer und die Rechte verändert.

wie checke ich, ob die Inhalte "eh schon mir gehören"?
Rechtsklick auf eine Datei und Eigenschaften ansehen. Fast wie in Windows. Oder

Quellcode

1
ls -l /mnt/sdb1
mir is wurscht

  • »nochamal« ist der Autor dieses Themas

Beiträge: 116

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 16.04 LTS - Xenial Xerus

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

22

28.01.2018, 00:06

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:

Quellcode

1
2
3
4
5
XX:~$ sudo mount -o ro /dev/sdb1 /mnt/sdb1
 
mount: /dev/sdb1 is already mounted or /mnt/sdb1 busy
       /dev/sdb1 is already mounted on /mnt/usb-TOSHIBA_External_USB_3.0_23945C152747-0:0-part1
XX:~$


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 :?:

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »nochamal« (28.01.2018, 00:12)


23

28.01.2018, 02:45

Keine Ahnung wo man überall fuhrwerken muss, um sowas hinzulegen. Von dconf hat hier niemand was gesagt und auch nicht von automount. Lass doch bitte Sachen links liegen, die keiner verlangt hat. Die Sache ist schon schwierig genug, da braucht es keine nebenbei eingebauten Zusatzfehlerquellen. Kaum einer von uns befasst sich mit dconf oder automount, weil das keiner braucht der zum Frühstück bis zu den Ellbogen in das System eintaucht. Wenn du da was verdrehst, ist die Hilfe eher eingeschränkt. Man könnte auch sagen, Suppen die du dir selbst einbrockst...

Normalerweise werden externe Geräte automatisch eingebunden, ja. Aber nicht unter /mnt/ sondern in /media/. Warum die jetzt da auftaucht, wissen wir nicht, weil wir auch nicht wissen wo du da gedreht hast.
Im Grunde ist es aber Hose wie Jacke. Wäre sie in /media gemountet, könnte man sie trotzdem auch woanders mounten, selbst mit anderen Optionen. Mit anderen Worten: Du hättest sie unter normalen Umständen gar nicht bemerkt. Wieso das jetzt nicht geht - siehe oben.

Kurz und gut: Unmounte sie und mounte sie danach so wie du sie für deine weiteren Schritte haben willst.
mir is wurscht

  • »nochamal« ist der Autor dieses Themas

Beiträge: 116

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 16.04 LTS - Xenial Xerus

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

24

28.01.2018, 03:23

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

Quellcode

1
/dev/disk/by-id/usb-TOSHIBA_External_USB_3.0_23945C152747-0:0-part1 /mnt/usb-TOSHIBA_External_USB_3.0_23945C152747-0:0-part1 auto nosuid,nodev,nofail,x-gvfs-show 0 0


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.

Beiträge: 839

Registrierungsdatum: 08.11.2015

Derivat: unbekannt

Version: gar kein Ubuntu

Architektur: 64-Bit PC

Desktop: LXDE

Andere Betriebssysteme: Debian 9.5 "stretch" / 4.9.0-8-amd64

  • Nachricht senden

25

28.01.2018, 13:26

x-gvfs-show


Diese Option wird von dem GUI Tool gesetzt!

Derartige Änderungen an Systemdateien (wie die fstab), sollte man auch nie unbedacht einem GUI Tool überlassen. Ich empfehel da ausschließlich die manuelle Änderung in einem Editor (wie nano, vi, gedit ...).

ps: ich empfehle auch extundelete. [Vorstellung] Datenrettung von ext4 mit extundelete
Hast Du Schnotten an der Nase, bist Du in der Schnupfenphase! :)












banane tanzt.gif

26

28.01.2018, 15:00

Keine Ahnung wie und warum oder wann der dort hineingekommen ist
Siehe oben. Eigenmächtiges Herumspielen mit Tools die keiner empfohlen hat.

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.
Dann hast du es nicht richtig verstanden. Solange du nicht auch noch mit irgendwelchen Tools auf die Backups losgehst, geht es vorwiegend um die Platte mit den zerstörten Daten. Siehe auch hier:
als wichtigstes, erstmal keine Schreibzugriffe mehr auf die Platte.

Allerdings ist das ohnehin irrelevant, denn zum Kopieren aus dem Backup brauchst du kein extundelete und umgekehrt sinken die Chancen für extundelete mit jedem Schreibzugriff auf die interne Platte. Soweit ich mich erinnere, liegen da die zerstörten Daten.
Ich weiß momentan nicht, welche Methode du gerade anwenden willst.
mir is wurscht

Beiträge: 839

Registrierungsdatum: 08.11.2015

Derivat: unbekannt

Version: gar kein Ubuntu

Architektur: 64-Bit PC

Desktop: LXDE

Andere Betriebssysteme: Debian 9.5 "stretch" / 4.9.0-8-amd64

  • Nachricht senden

27

28.01.2018, 16:27

Geht es jetzt um kopieren oder sichern?

Ich meine, kopier die Daten doch von der extrnen, (meinetwegen als root) und ändere im Nachhinein die Rechte per chown.

Oder wo genau ist jetzt das Problem? Gibt es überhaupt ein Problem? :whistling:
Hast Du Schnotten an der Nase, bist Du in der Schnupfenphase! :)












banane tanzt.gif

  • »nochamal« ist der Autor dieses Themas

Beiträge: 116

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 16.04 LTS - Xenial Xerus

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

28

28.01.2018, 18:42

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 :?:

29

28.01.2018, 20:29

Gibt es überhaupt ein Problem?
Ja, ein ganz massives im Layer 8.
wie es am besten zu machen wäre, dass USB Laufwerke generell NICHT automatisch eingehängt werden
Du müsstest sämtliche in Frage kommenden Mechanismen deaktivieren, und davon gibt es einige je nach Version und runlevel. Am einfachsten wäre ein Hochfahren in den single-mode. Das ist dann reine Konsole ohne Schnickschnack.
Noch besser wäre eine Live-CD im single-mode.

Die Frage ist nur wozu das ganze. Wenn du kopieren willst brauchst du den Zugriff und solange du nicht selbst auf die externe schreibst, macht das auch sonst keiner. Und wie schon gesagt, kannst du sie ja zur Sicherheit read-only remounten.
mir is wurscht

  • »nochamal« ist der Autor dieses Themas

Beiträge: 116

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 16.04 LTS - Xenial Xerus

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

30

28.01.2018, 22:30

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:

Quellcode

1
sudo ext4magic /dev/sdb1 -m -d /home/recovery_ext4magic


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.

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »nochamal« (28.01.2018, 22:40)


31

29.01.2018, 01:07

Klingt wie eine gefährliche Drohung.

Hoffentlich weißt wenigstens du was du da machst. Ich glaube, hier im Forum kann dir keiner mehr folgen.
Letzter Versuch dir das klarzumachen: ext4magic & co sind dazu da um gelöschte Daten zu restaurieren. Was in Torvalds Namen willst du damit auf der Backup-Platte erreichen?
Jeder andere hätte sich gefreut ein Backup zu haben, daß sich die Platte von alleine mountet und er die Daten nur rüberziehen braucht. Einer aber restauriert auf dem Backup herum und denkt an eine Serverinstallation. :wacko:
mir is wurscht

  • »nochamal« ist der Autor dieses Themas

Beiträge: 116

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 16.04 LTS - Xenial Xerus

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

32

29.01.2018, 18:16

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:

Quellcode

1
sudo debugfs -R "dump <8> /home/recovery_ext4magic_JournalCopy/journal.copy" /dev/sdc1


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

Quellcode

1
sudo chown 777 ./
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

Quellcode

1
sudo apt-get install synaptic


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:

Quellcode

1
sudo blkid -o list -w /dev/null


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:

Quellcode

1
sudo ext4magic /dev/sdb1 -m -d /home/recovery_ext4magic123


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

Quellcode

1
sudo ext4magic /dev/sdb1 -j /home/recovery_ext4magic_JournalCopy/journal.copy -m -d /home/recovery_ext4magic1


oder alternativ mit

Quellcode

1
sudo ext4magic /dev/sdb1 -j /home/recovery_ext4magic_JournalCopy/journal.copy -R -a $(date -d "-10day" +%s) -b $(date -d "-6day" +%s) -d /home/recovery_ext4magic2


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

Quellcode

1
gksudo nautilus


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.

Dieser Beitrag wurde bereits 12 mal editiert, zuletzt von »nochamal« (01.02.2018, 11:12)


  • »nochamal« ist der Autor dieses Themas

Beiträge: 116

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 16.04 LTS - Xenial Xerus

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

33

29.01.2018, 18:47

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.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »nochamal« (29.01.2018, 19:11)


35

29.01.2018, 21:23

Somit versuche ich zuerst die verlustig gegangenen Daten zu recovern

Irgendwie dürfte mir entgangen sein, daß du mit einem Reservesystem arbeitest und sdb1 die Platte mit den zerstörten Daten ist. Hättest auch auf meine entsprechenden Einwände eingehen können, dann wär das auch mir klar geworden.
Jetzt ergibt es jedenfalls einen Sinn.
mir is wurscht

Beiträge: 839

Registrierungsdatum: 08.11.2015

Derivat: unbekannt

Version: gar kein Ubuntu

Architektur: 64-Bit PC

Desktop: LXDE

Andere Betriebssysteme: Debian 9.5 "stretch" / 4.9.0-8-amd64

  • Nachricht senden

36

29.01.2018, 21:59

Zitat

Gute Nacht


Gute Nacht John Boy! :)
Hast Du Schnotten an der Nase, bist Du in der Schnupfenphase! :)












banane tanzt.gif

  • »nochamal« ist der Autor dieses Themas

Beiträge: 116

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 16.04 LTS - Xenial Xerus

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

37

29.01.2018, 23:15


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 :!:

  • »nochamal« ist der Autor dieses Themas

Beiträge: 116

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 16.04 LTS - Xenial Xerus

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

38

02.02.2018, 18:35

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.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »nochamal« (02.02.2018, 18:48)


Beiträge: 839

Registrierungsdatum: 08.11.2015

Derivat: unbekannt

Version: gar kein Ubuntu

Architektur: 64-Bit PC

Desktop: LXDE

Andere Betriebssysteme: Debian 9.5 "stretch" / 4.9.0-8-amd64

  • Nachricht senden

39

02.02.2018, 19:41

Wenn Du die genauen Dateinamen der velorenen Dateien hast, empfehle ich weiterhin extundelete. Link weiter oben mit Anleitung.
Hast Du Schnotten an der Nase, bist Du in der Schnupfenphase! :)












banane tanzt.gif

  • »nochamal« ist der Autor dieses Themas

Beiträge: 116

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 16.04 LTS - Xenial Xerus

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

40

03.02.2018, 09:52

das nächst mal vielleicht