• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

Möglichkeiten einer Datenrettung von HD

crotchmaster

happy BSD user
Themenstarter #1
Moin Forenleser,

gestern hat sich bei mir die Existenz von Murphys Law mal wieder bestätigt. ;'(

Ich habe gestern an meinem Desktop-System an der Aufteilung der Slices und Partitionen gearbeitet, um mehr Platz zuhaben. Vor den Arbeiten habe ich natürlich ein Backup auf eine externe USB-HD gemacht. Die eigentlichen Arbeiten habe ich mit dem fixit-Modus der 8.2-amd64 DVD gemacht, die Filesysteme /, /usr und /var konnte ich zurückspielen. Dann habe ich den Rechner neugestartet, um mein recovertes FreeBSD 8.2 zustarten und Netzwerk zuhaben, was auch klappte. Dann wollte ich das /home-FS zurückspielen und da traff mich der Schlag. Die externe HD ist nicht mehr mount- und lesbar. gpart zeigt mir noch den vorhandenen Slice an, aber nicht die darin befindliche Partition. Das glabel scheint auch im Allerwersten zu sein.

Welche Möglichkeiten habe ich noch, da etwas zu retten? Ich habe von recoverdisk gelesen. Wie groß sind die Chancen, damit etwas zureißen? Eine so große bzw. größere Disk wie die Backup-HD habe ich im Moment nicht bzw. sind die anderen Disks anderweitig belegt, müsste mir also eine HD kaufen.

Ich wäre für alle Tipps sehr dankbar.

Gruß c.
 
#2
Also recoverdisk(1) wird dir nicht dabei helfen, ein zerdeppertes Label bzw. Metadata einer HD etc. wiederherzustellen.
Es kan dir aber einen 1:1 Clone der Platte im jetzigen Zustand liefern. Je nachdem wie risikofreudig du bist würde ich zuallererst die defekte USB-HD duplizieren und danach alle Versuche, zu retten was zu retten ist auf der Kopie ausführen.
gpart(8) hat einen -recover schalter (man gpart(8) ).
Hast du keine +/- aktuellen Backups?
Das ist doch alles UFS, oder ?
Viel Glück und Erfolg.
 

Fusselbär

Makefile Voyeur
#3
file kann auf dem Devicenode nachschauen, was es noch an Filesystemen sieht, so etwa:
Code:
file -s /dev/da*
Das zeigt alles an, was es an Filesystemen auf Direct Access Devices findet,
das kann es unabhängig davon, ob eine Partition gemounted ist, oder nicht.
Abbild machen mit dd oder ddrescue wäre gut vor irgendwelchen Experimenten zum Daten retten.
sysutils/ddrescue ist in den Ports: http://www.freshports.org/sysutils/ddrescue/


Edit:
Fällt mir noch was ein: meine glabel gehen auch immer flöten, wenn ich das Laufwerk in eine andere Kiste stecke,
um von dort aus bequem mit fsck_ufs UFS2 Filesysteme mit Macken zu reparieren, die sich aus bislang ungeklärter Ursache nicht in der ursprünglichen Maschine haben reparieren lassen.
Nach dem fsck_ufs ist dann in der Ursprungsmaschine jedes mal ein neues glabeln nötig gewesen, was aber relativ harmlos ist, so etwa:
Code:
glabel label -v var0 /dev/ada0p4.eli
und:
Code:
glabel label -v usr0 /dev/ada0p5.eli
 
Zuletzt bearbeitet:

Nonpareille

Well-Known Member
#4
Ich hab diesbezüglich mit "testdisk" gute Erfahrungen gemacht. (Allerdings nur unter OpenBSD bzw. nativ von der UBCD). Hast Du die USB-Platte versuchsweise mal aus dem Gehäuse genommen und direkt an einen Computer angeschlossen? Sehr oft hilft das schon.
 

crotchmaster

happy BSD user
Themenstarter #5
Hallo Metro, Fusselbär und Nonpareille,

Danke für die Antworten. Die Backup-HD hat eigentlich auch UFS als Filesystem und ein altes Backup habe ich auch noch, aber das ist wirklich alt, Oktober 2010. Den recover-Schalter von gpart habe ich auch gesehen, aber der scheint nur bei HDDs mit GPT zuwirken, meine externe HD hat natürlich nur MBR.
Ein Blick in die man page von recoverdisk zeigte mir, das es wohl soetwas ähnliches wie dd in eine große Datei macht, die man dann mit mdconfig hoffentlich zufassen bekommt. Insofern arbeitet man dann nicht mehr mit der Original-HD.

Die device-Einträge beschränken sich auf /dev/da3 und /dev/da3s1, keine BSD-Partition a.
file -s /dev/da* werde ich ausprobieren und ddrescue mir mal anschauen.

Ein image der Disk werde ich aber auch machen. Ich habe noch zwei identische Disks, die den gleichen MBR und das gleiche disklabel haben. Ich werde mal versuchen, beides von einer heilen Platte auf die kaputte zuklatschen, vielleicht hilft es ja.

Meine Lehre ist auf jedenfall, vor solchen Aktionen zusätzlich zum aktuellen Vollbackup noch ein Backup zumachen.

Gruß c.
 

pit234a

Well-Known Member
#7
sysutils/sleuthkit
daraus mmls zum Beispiel. Das zeigt die Partitionen und wo sie liegen.
hexdump(1) liefert schöne Darstellungen und so kann etwa der MBR ausgelesen werden (ich würde ihn mir mit dd ziehen) und auch die "MBR" der Partitionen. Irgendwo muss da was falsch sein. Wikipedia hat gute Artikel, die MBR und Partitionstabelle erklären.

Hast du die Lage deiner Partition entdeckt, kannst du die wieder mittels dd sichern.
Das so erzeugte File kannst du dann vielleicht wieder mounten.
In GNU/Linux hat mount die Option -o loop und kann auch direkt einen Offset Wert übernehmen, um so zu mounten. In FreeBSD gibt es diese Option leider nicht und ich denke, man muss wahrscheinlich den Umweg über das Ziehen der Daten nehmen und dann ein md-Device zum Mounten anlegen.
Eine Sicherung mittels dd ist in jedem Fall vorab empfehlenswert.

Vielleicht kannst du auch einen Fehler im MBR oder dem ersten Block der Partition entdecken und evtl direkt mit einem Hexeditor bereinigen.
Vielleicht könntest du auch eine neue Partition erstellen und dann nur die Daten (also nach den Stellen mit nix drin hinter dem ersten Block) auf diese Partition übertragen, dd sollte das können, aber manchmal hat mich FreeBSD dd etwas enttäuscht und ich musste dann sdd (sysutils/sdd) nehmen, das etwas mehr kann.

Automatische Dinge, sysutils/testdisk, photorec(1) oder auch andere Tools aus dem Sleuthkit lesen sich oft gut, aber irgendwie habe ich damit nie wirklich Erfolg gehabt. Die Suche durch die Bytes ist nicht so gut für die Augen und man kann schon mal Kopfschmerzen bekommen, aber letztlich hatte es mir am ehesten Erfolg gebracht, wenn ich mir diese Mühe gemacht habe.
Gottlob braucht man das nur selten, aber genau deshalb macht man auch gerne Fehler!
Ein zusätzlicher Backup der Daten ist daher extrem empfehlenswert.
 
Themenstarter #10
Yeah!

Diesen Post schreibe ich von meinem wiederhergestellten System. :D

Ich habe zuerst die Daten aus dem alten Backup wiederhergestellt, damit ich ersteinmal arbeiten konnte.

Anschließend habe ich auf einer externen und baugleichen Platte Platz geschaffen. Danach habe ich mit dd die 'kaputte' HD auf die leere HD 1:1 gespiegelt, das hat ewig gedauert. Nun konnte ich mit scan_ffs (sysutils/scan_ffs) auf der Kopie das UFS-Filesystem zumindest sehen. Mein Verdacht war dann, dass nur das disklabel kaputt ist. Ich habe mir die offsets notiert und nun mit disklabel -w /dev/da4s1 ein Standardlabel geschrieben. Das folgende Anpassen des Offsets konnte ich mir schon sparen, der war schon richtig. Das glabel tauchte auch schon unter /dev/label auf. Nach einem fsck-Lauf, der nichts reparieren musste, konnte ich die Platte mounten und voila, alles war wieder da. Das nochmalige Wiederherstellen war dann eine leichte Übung.

Scheinbar war es in diesem Fall kein so schwerwiegendes Problem.

Ich danke Euch nochmal für die Tipps und Anregungen.

Gruß c.
 

Lance

Well-Known Member
#11
Moin,

UFS Explorer Standard Recovery ist übrigens ein kommerzielles Datenrettungstool - auch für FreeBSD - welches man auch für die Datenrettung von allen möglichen Dateisystemen nutzen kann, kostet in der Standard 39,-EURO. Neben AnyDesk (wenn es mal ausgereift ist) das zweite kommerzielle Tool für FreeBSD, welches ich gut gebrauchen kann!

Anbei freut es mich immer wieder wenn ich sehe dass Hersteller auch an FreeBSD denken ;)
 

bsd4me

Well-Known Member
#12
Yeah!
Diesen Post schreibe ich von meinem wiederhergestellten System. :D
...
Ich danke Euch nochmal für die Tipps und Anregungen.
Gruß c.
Gratulation!! :) Tja, was Backup angeht, da bin ich im Laufe der Zeit schon halb-paranoid geworden ;-) (Sogar) zu Hause habe ich 2 "alt"-Rechner mit jweils 3 bzw. 5 "kleinen" Platten, wo ich immer mal wieder ein Backup per rsync aufspiele, die dann auch noch raidz1 bzw. raidz2 (ZFS) sind :) Und sogar noch eine externe Platte, die allerdings seltener aktualisiert wird...

VG Norbert
 

Athaba

Libellenliebhaber
#15
Ich stimme zu. UFS Explorer ist wirklich großartig für sowas. Ich hab' mal bei einem Bekannten in Verwendung gesehen. Ziemlich nett.
 

rakso

Well-Known Member
#16
Wie sieht das denn mit kaputten ZFS Datesets oder Raid-Z pools aus, gibt es dafür auch tools? Habe ich noch nirgends erwähnt gesehen..
 

pit234a

Well-Known Member
#17
Wie sieht das denn mit kaputten ZFS Datesets oder Raid-Z pools aus, gibt es dafür auch tools? Habe ich noch nirgends erwähnt gesehen..
soweit ich das gelesen habe, gibt es da nichts, denn ZFS ist "per Definition unkaputtbar" und wenn es dann doch mal gefetzt ist, dann ist es auch unrettbar verloren, weil eben die HW hin ist. So lange es noch geht, bleibt ZFS erhalten und es repariert sich sogar so ein wenig selbst, falls nötig.
 

pit234a

Well-Known Member
#19
ich sollte wohl immer dazu sagen, dass ich persönlich grundsätzlich nur bei OpenSource suche.

Trotzdem bin ich da nicht schlecht überrascht und frage mich, wie das geht. Bei Standars-Dateisystemen kann ich mir da vorstellen, dass es relativ einfach ist. Ich sage mal, Bytes und Sektoren abzählen und da kann man schon ziemlich weit kommen. Bei ZFS stelle ich mir das deutlich komplizierter vor.
 

Lance

Well-Known Member
#20
Moin,

bzgl Datenrettung habe ich hier was nettes gefunden, läuft auch unter Linux und FreeBSD!

https://diskdigger.org/linux

weiter unten steht, wie man es auch unter FreeBSD startet. Es ist im prinzip 4free aber wenn man keine Lizenz (14$) hat, nerft es jedes mal mit einer Aufforderung. 14$ geht aber.
 

turrican

Well-Known Member
#21
... ZFS ist "per Definition unkaputtbar" und wenn es dann doch mal gefetzt ist, dann ist es auch unrettbar verloren...
Falls man mit "zpool destroy" gewütet hat, hat man mit "zpool import -D" gute Chancen, zumindest den Pool auf den Platten wieder zur Verfügung stellen zu können - allerdings muss man für die Daten dann meist noch zdb bemühen, und die transaction groups zurückspielen ... sofern die noch da und intakt sind...
Is allerdings schon ein paar Jahre her, seit ich mich damit befaßt hatte (befassen mußte) - hab im Leben mehr ext-fs Crashes gesehen, als ZFS crashes (genaugenommen nur den einen), ufs und xfs interessanterweise eigentlich auch nie :P
 

Lance

Well-Known Member
#23
Alter Thread aber ich hatte soeben DiskDigger unter FreeBSD erfolgreich gestartet. Wer also grafisch kostenlos Daten retten will.. Einen Versuch ist es wert!
 

Lance

Well-Known Member
#25
@Rakor
Nein, das nicht. Aber ich hatte es schon öfter gemacht. Nur fehlte mir bisher unter Linux und vor allem FreeBSD ein kostenloses "bequemes Klickibunti Werkzeug". Und ich dachte, den einen oder anderen FreeBSD Einsteiger könnte die Info nützlich sein.