Hallo, habe eine sporadisch ausfallende mechanische HDD 500GB HD502HJ von Samsung mit 3 Partitionen. Diese wollte ich mit Hilfe einer ICY Box die auch unkompliziertes Klonen anbietet zur Sicherheit auf eine 500GB SSD auf der sich ein älteres Kali Linux befindet umkopieren. Wie es der Teufel will, habe ich Source und Target verwechselt, weil schwarze Schrift auf Schwarzem Gehäuse. (Nein das soll keine Ausrede sein) Hab also gesteckt, Knöpsken gedrückt und genau in der Sekunde viel mir ein au weia, nicht double gecheckt und auch im selben Moment ausgeschaltet. Trotzdem sind die 3 Partitionen die vorher noch gesehen wurden weg und haben einer Linuxpartition Platz gemacht. Gibt es da noch etwas zu retten? Das wäre nämlich mehr als wünschenswert. Testdisk hab ich schon geladen, aber ich habe den Eindruck die Partitionen werden zwar gesucht, aber das dauert alles quälend lange. Ist das normal, muß ich jetzt Tage für die Suche einplanen?
Auf jeden Fall nicht mit irgend einem Tool auf der Platte rumrödeln sondern erst mal ein komplettes Abbild ziehen. Damit dann weiter arbeiten. Ansonsten, Backup...
Moin, Klaus B. schrieb: > habe eine sporadisch ausfallende mechanische HDD 500GB HD502HJ von > Samsung mit 3 Partitionen. Nee, die hast du jetzt nicht mehr. Also die 3 Partitionen. Aber mein Mitgefuehl haste, weil: Kann passieren... Gruss WK
Klaus B. schrieb: > Trotzdem sind die 3 Partitionen die vorher noch gesehen wurden weg Was waren es denn für Filesysteme? Ich habe immer meine eigene Art und Weise Partition anzulegen. Diese a-priori Wissen würde/ist dann bei Unfällen hilfreich. > ... aber ich habe den Eindruck die Partitionen werden zwar gesucht, > aber das dauert alles quälend lange. Ist das normal, muß ich jetzt Tage > für die Suche einplanen? Es dauert immer wesentlich länger als man Anfang denkt.
:
Bearbeitet durch User
Klaus B. schrieb: > Gibt es da noch etwas zu > retten? Kommt darauf an, wie lange das schon lief und wie gross die Partitionen waren. Mindestens bei der ersten wird das Filesystem zerlegt sein, da kann testdisk dann nur noch einzelne Dateien rekonstruieren, sofern sie nicht fragmentiert sind. Bei den nicht überschriebenen kann es sein, dass testdisk den Partitionsanfang erkennt. Wenn Du (zumindest grob) weisst, wie gross die Partitionen waren, kannst Du Dich auch selbst auf die Suche begeben und dann (unter Linux z.B. mit fdisk) eine neue Partition Table bauen.
Die Schreibgeschwindigkeit wird bei maximal 160MB/s liegen. Bei wenigen Sekunden ist der hintere Teil also noch vollständig. Wenn die erste Partition groß genug ist, also die kompletten zwei Partitionen. Wie die Vorredner schon schrieben, erst mal ein Abbild erstellen (und nicht wieder Quelle und ziel vertauschen, geht bei dd ganz leicht und manchmal vertauschen sich auch /dev/sda und /dev/sdb bei jedem Reboot). ChatGPT erklärt mir gpart oder testdisk könnten Dateisystemanfänge erkennen.
In Zukunft vor solchen Aktionen und für jede vorhandene und neue Festplatte: - Seriennummern der Festplatten aufschreiben und vor dem Kopieren verifizieren (hdparm -I /dev/sdX | grep 'Serial Number') - Partitionstabelle in Datei schreiben (sfdisk -d)
Cartman E. schrieb: > Was waren es denn für Filesysteme? und was für eine Partitionstabelle? Angeblich gibt es eine GPT-Kopie ganz am Ende der Platte. Zusammen mit einer der Superblock-Kopien könnte man theoretisch noch alles lesen, was nicht direkt überschrieben wurde. Warum hört man so wenig davon? https://en.wikipedia.org/wiki/GUID_Partition_Table
Es gibt tools die schreiben/rekonstruieren eine Partitions-/Inode-tabelle neu und zwar so, das jeder nicht allokierte Cluster einen eigenen filenamen bekommt. Dann kann man wnigstens zusammenpuzzlen wie die einzelnen Cluster zusammengehören. Ist natürlich abhängig, welches filesystem drauf ist und bei unkomprimierten Dateien erkennt man Zusammenhänge besser als bei komprimierten. Stichwort "verlorene Cluster". Achja, zuerst sollte man natürlich erinnern, welche Clustergröße die ursprünglichen partitionen hatten ... * https://learn.microsoft.com/de-de/troubleshoot/windows-server/backup-and-storage/disk-space-problems-on-ntfs-volumes * https://www.cgsecurity.org/wiki/Schritt_f%C3%BCr_Schritt_Wiederherstellungsbeispiel
:
Bearbeitet durch User
Bradward B. schrieb: > Es gibt tools die schreiben/rekonstruieren eine > Partitions-/Inode-tabelle neu und zwar so, das jeder nicht allokierte > Cluster einen eigenen filenamen bekommt. Dann kann man wnigstens > zusammenpuzzlen wie die einzelnen Cluster zusammengehören. Kennt man NTFS, weiss man schon vorher dass man sich dort nur sinnfreie Arbeit macht. NTFS fragmentiert sehr schnell, im Vergleich mit ext2/3/4. Ist es nicht gerade Klartext, wird man die binären Puzzleteile nicht wieder zusammengesetzt bekommen. Ein versehentlich gelöschtes Video, konnte ich dagegen mit einem schnellen Reset, und anschliessender Suche und Wiederherstellung mit dem Filesystemdebugger, problemlos auf einem ext3 wieder herstellen. Dieses Filesystem war schon vor Jahren angelegt und auch intensiv benutzt worden. Bei NTFS wäre man da chancenlos. Das Suchen und Zusammenpuzzlen von NTFS-Clustern kann man sich sparen. Man müsste da schon schon das Filesystem frisch angelegt haben, immer nur Dateien geschrieben, und keine gelöscht haben, um die Erfolgsaussichten zu steigern. > Ist natürlich abhängig, welches filesystem drauf ist und bei > unkomprimierten Dateien erkennt man Zusammenhänge besser als bei > komprimierten. Stichwort "verlorene Cluster". Achja, zuerst sollte man > natürlich erinnern, welche Clustergröße die ursprünglichen partitionen > hatten ... Für die gilt sinngemäss bei Binärformaten das Gleiche.
Bradward B. schrieb: > Es gibt tools die schreiben/rekonstruieren eine > Partitions-/Inode-tabelle neu und zwar so, das jeder nicht allokierte > Cluster einen eigenen filenamen bekommt. Und damit verhindert man zuverlässig weitere Rettungsversuche. Jede Schreiboperation auf bereits teilgelöschten Partition ist für die Daten tödlich,
Oliver S. schrieb: > Obwohl: kein Backup, kein Mitleid. Gilt trotzdem. Richtig! kein Backup = kein Ärger
Unter Windows würde ich Dir HxD empfehlen. https://mh-nexus.de/de/hxd/ Standardmäßig werden die Datenträger schreibgeschützt eingebunden. Über ein 'Studium' zum Aufbau von Partitionstabellen (MBR / GPR) kommst Du aber nicht herum.
:
Bearbeitet durch User
> Und damit verhindert man zuverlässig weitere Rettungsversuche. Jede > Schreiboperation auf bereits teilgelöschten Partition ist für die Daten > tödlich, Naja, zur Wiederherstellung einer fälschlicherweise überschriebene Partition müssen natürlich die alte "Verwaltungsdaten" wiederhergestellt werden. Dazu sind nun mal schreiboperationen auf die "teilgelöschten (sic!) Partition nötig. Klar kann man auch erst mal den Patienten Klonen und an dem Klonen das wiederbelben üben. Ist aber letztlich die selbe Prozedure. Linux kennt den Ordner /lost+found für solchen lost/unlinked cluster.
Vielen Dank für die aufmunternden Worte. Die Platte 500 GB ist in 3 gleiche Partitionen NTFS partitioniert. Also ungefähr 155 GB jede einzelne. Ein Backup besteht, allerdings aus 10.24 und damit nicht gerade aktuell. Alle 3 Partitionen waren vollgestopft mit meist belanglosen, aber auch Finanzkram, Bilder Sicherungen vom Mobile Phone und privater Korrespondenz. Nur diese 3 Ordner möchte ich gern wiederherstellen können. Partition Wizard 9.1 hat auch einen Partition recovery Wizard, was ist davon zu halten?
Moin, Bradward B. schrieb: > Ist aber letztlich die selbe Prozedure. Halt wie Springen von was Hohem einmal mit Bungeeseil und das andere Mal ohne. Ist auch letztlich die selbe Prozedur. Gruss WK
Klaus B. schrieb: > Ein Backup besteht, allerdings aus 10.24 und damit nicht > gerade aktuell. Alle 3 Partitionen waren vollgestopft Wenn du schnell genug gestoppt hast, dann ist mit großer Wahrscheinlichkeit ›nur‹ die Partitionstabelle(vollständig) und die erste Partition(teilweise) gelöscht. Wenn es ein GPT Datenträger war, ist die Partitionstabelle dupliziert am Ende des Darenträgers noch einmal vorhanden. Bei MBR/DOS Partitionstabelle ist da gar nichts mehr. Aber Testdisk sollte bei einem kompletten Scan die alten Partitionsgrenzen erkennen/berechnen können und eine neue PartTab schreiben. Damit wären Part.2 und Part.3 und die darin befindlichen Daten gerettet. Ob man ein teilgelöschtes NTFS noch reanimieren kann weiß ich nicht. Vielleicht klappt das, wenn die MFT nicht beschädigt wurde. Dennoch, mit einem halben gebratenen Hühnchen taucht man ja auch nicht bei einem Tierarzt auf. Alle Versuche stets mit einem IMAGE des Datenträgers durchführen. Wenn man's versaut, zieht man sich erneut eines.
:
Bearbeitet durch User
die Platte hat scheinbar am Anfang defekte Sektoren und das kopieren per IcyBox hat jedenfalls nicht geklappt. Zumindest nehm ich das an, weil vorn die Leuchtdioden nach einer kurzen Weile rot blinkten. Die Frage ist, was macht ein Kopierpogramm, wenn es defekte Sektoren erkennt? Stur mitkopieren?
Klaus B. schrieb: > Die Frage > ist, was macht ein Kopierpogramm, Nein. Die Frage ist: Welches benutzt du? Welche Parameter?
Die Partitionstabelle aus dem Backup kannst Du doch kopieren!
Klaus B. schrieb: > Die Frage > ist, was macht ein Kopierpogramm, wenn es defekte Sektoren erkennt? Stur > mitkopieren? Nicht nur weil diese Frage hoechsten die Entwickler von IcyBox beantworten koennten, ist das alles Quatsch, was du da vorhast. Wenn dir irgendwas an den Daten liegt, dann lass sofort saemtliche Wizards und Windowsgedoens weg. Nimm eine neue, groessere, leere Pladde, mach auf die ein Filesystem, konzentrier dich, und mach per ddrescue ein Image der alten Platte als File auf die neue Platte. Damit kannst du dann allen moeglichen Schabernack treiben. Wie ich schon schrub: Wo runterhuepfen, ohne vorher ein Bungeeseil angelegt zu haben, ist unclever. Gruss WK
Beitrag #8068563 wurde von einem Moderator gelöscht.
Ich kann dem nur zustimmen. Mache zuerst ein Image mit ddrescue, und arbeite dann damit weiter. PS: Wenn du das Image auf einer btrfs platte erstellst, kannst du sofort und ohne grossen zusätzlichen Speicherverbrauch ein reflink copy des Image erstellen. Dann kannst du extrem einfach Kopien vom Image machen, und auf denen Sachen ausprobieren, und hast zusätzlich zur platte immer noch das originale Image!
Thomas S. schrieb: > Und damit verhindert man zuverlässig weitere Rettungsversuche. Jede > Schreiboperation auf bereits teilgelöschten Partition ist für die Daten > tödlich, Ein M$-Scandisk, auf einer FAT/ExFAT-Partition, ist quasi die sichere Garantie nichts mehr wiederherstellen zu können. ☺
Norbert schrieb: > Damit wären Part.2 und Part.3 und die darin befindlichen > Daten gerettet. Nochmal: Er hat ein Backup der Partitionstabelle aus 10.24. Die beiden hinteren Partitionen sind schon mal safe. Geht nur um die MFT der ersten Partition. Evtl. sind noch Dateinamen aus dem MFT Mirror zu retten. Dafür würde ich GetDataBack for NTFS verwenden. (selbstverständlich nach dem Klonen mit ddrescue) Alexander schrieb: > https://www.mediafire.com/file/iwqzuo0z3q0ro05
:
Bearbeitet durch User
Alexander schrieb: > Nochmal: Er hat ein Backup der Partitionstabelle aus 10.24. Er schrieb dass er ein Backup hat. Das könnte ein Image der kompletten Platte sein, dann gäbe ich dir Recht. Könnten aber auch einfach nur die gesicherten Daten sein. Ich will da mangels präziserer Informationen keine Annahmen machen.
H. H. schrieb: > Besser kapitulieren. Der Hinweis ist gut - denn: ich hatte mal einen Datenverlust auf einem Usb-Stick wegen einem alten Mainboard. 256kB. Die Datenwiederherstellung war möglich (fast 100%), aber es war eine riesige Puzzlearbeit, die Daten wieder zu reanimieren bzw. zu ordnen. Die lagen nicht geordnet vor, sondern total chaotisch (aber in diesem Schema doch geordnet). Dann hatte ich glaube ich nur ein paar wichtige Sachen zurückkopiert - und das meiste dann doch sein lassen. Ich dachte dann so: "gut dass mir das bei einem kleinen USB-Stick passiert ist". Später gab es dann einige Totalabstürze von Windows ME (20GB) - wo mir das mit dem Datenretten auch nicht in den Sinn kam, aber ich hatte schon vieles auf DatenCDs gebrannt. So konnte ich dann viel rekonstruieren - hätte mir aber einiges wichtige auf einen Zettel schreiben sollen. Bei Windows ME war u.a. das Defragmentierprogramm problematisch. Ein anderes Problem war nach dem Neuaufsetzen war, dass einige Programme die Registrierung verloren hatten und dann auch nicht mehr starteten.
Danke für die nützlichen Antworten. Das ich die Platte erstmal auf ein anderes "Arbeitsmedium" kopieren soll, leuchtet natürlich ein, ist aber nicht so einfach, denn Rescuezilla zB. sieht zwar die Platte, aber sagt: Clone of drives without a partition table and no file system is not supportet yet..... Die Platte muß also wegen der plötzlichen Abschaltung in einem undefinierten Zustand sein. Das Backup muß ich erst noch kontrollieren, ob das als Image Datei, oder als händisch kopiert vorliegt. Mutig wie ich bin, habe ich Partition Wizard nach Lost / deletet Partitionen suchen lassen. Das Programm rödelt ungefähr 8-10 Stunden auf den ersten Clustern rum wie eine Schnecke, aber dann geht es zügig bis zum Ende und findet dabei x Einträge a ca. 4 GB unter anderem eine Boot NTFS soll ich sagen Partition, oder Stelle. Mein Wissen an der Stelle reicht nicht aus um wie im letzten und anderen Posts angemerkt mir das selbst wieder händisch zusammenzupuzzeln. Da werden einem dann sicher Kenntnisse im Hexeditor abverlangt, stimmts? Das passiert mir übrigens zum ersten mal, das eine Platte so aussteigt.
Klaus B. schrieb: > denn > Rescuezilla zB. sieht zwar die Platte, aber sagt: Clone of drives > without a partition table and no file system is not supportet yet..... Deshalb nimmt man auch keine wackeligen bunten ›Klick-mich-ich-brauch-das-jetzt‹ Progrämmchen, sondern etwas Anständiges, etwas Bewährtes. Wurde ja bereits von Anderen im Vorfeld erwähnt. Aber wenn das Zeug schon Stundenlang auf der originalen Platte herumfuhrwerkt hat, dann bleibt nur noch ›Gutes Gelingen‹ zu wünschen.
:
Bearbeitet durch User
Klaus B. schrieb: > Danke für die nützlichen Antworten. > Das ich die Platte erstmal auf ein anderes "Arbeitsmedium" kopieren > soll, leuchtet natürlich ein, ist aber nicht so einfach, denn > Rescuezilla zB. sieht zwar die Platte, aber sagt: Clone of drives > without a partition table and no file system is not supportet yet..... Da guckt man mal in der Kaffeepause mal wieder in dieses Forum und dann der zigste Thread mit/zum Thema Klonen. Was ist daran eigentlich so schwer. Es ist doch schon mehrmals geschrieben worden, dd/ddrescue oder von mir aus noch einfacher cp aus einem laufenden Linux zu verwenden statt irgendwelcher Tools, von denen Du offensichtlich am allerwenigsten weißt, was die tun.
Michael L. schrieb: > Es ist doch schon mehrmals geschrieben worden, dd/ddrescue oder von mir > aus noch einfacher cp aus einem laufenden Linux zu verwenden statt > irgendwelcher Tools, von denen Du offensichtlich am allerwenigsten > weißt, was die tun. Mag daran liegen, dass in solchen threads immer sehr viel dünne Brühe und nur wenig gute Soße dargereicht wird. Da ist die Selektion für Anfänger schwierig. Im Zweifelsfall nimmt man dann instinktiv den einfachen und bequemen Weg. (und vermeidet den tatsächlich richtigen, aber etwas steinigeren Weg)
:
Bearbeitet durch User
Naja, eine Empfehlung wäre ja gewesen ein Kali-Linux auf CD zu nutzen, und mit dem dann rüberkopieren. Aber noch immer kann man das gut gemachte Clonezilla nutzen.
Michael L. schrieb: > Es ist doch schon mehrmals geschrieben worden, dd/ddrescue oder von mir > aus noch einfacher cp aus einem laufenden Linux zu verwenden statt > irgendwelcher Tools, von denen Du offensichtlich am allerwenigsten > weißt, was die tun. ddrescue ist insbesondere hier zu bevorzugen. Das kann man auch unterbrechen und wieder starten, kommt mit Lesefehlern zurecht, etc. Andere Tools sind dafür nicht vorgesehen.
Michael L. schrieb: > Es ist doch schon mehrmals geschrieben worden, dd/ddrescue https://wiki.ubuntuusers.de/gddrescue Beispiel (vorher mit cd ins Zielverzeichnis wechseln)
1 | # ddrescue -n -b512 -r3 /dev/sdc hdd.img gddrescue_hdd_img.log |
Klaus B. schrieb: > Hallo, > habe eine sporadisch ausfallende mechanische HDD 500GB HD502HJ von > Samsung mit 3 Partitionen. Diese wollte ich mit Hilfe einer ICY Box die > auch unkompliziertes Klonen anbietet zur Sicherheit auf eine 500GB SSD > auf der sich ein älteres Kali Linux befindet umkopieren. Falsche Strategie. Deine HDD hat einen offensichtlichen Defekt. Man beginnt mit der Eigenanamnese und fragt den Patient, bzw. die Festplatte, wie so die eigene Gesundheit wahrgenommen wird. Die passenden Tools dazu sind smartmontools und CrystalDiskInfo. >Wie es der > Teufel will, habe ich Source und Target verwechselt, weil schwarze > Schrift auf Schwarzem Gehäuse. (Nein das soll keine Ausrede sein) Hab > also gesteckt, Knöpsken gedrückt und genau in der Sekunde viel mir ein > au weia, nicht double gecheckt und auch im selben Moment ausgeschaltet. Das war genau richtig! Die Festplatte kann laut Internet nachhaltig 130 MB/sek und wenn das schlimmstenfalls 3 Sekunden dauerte, hast Du 400 MB überschrieben. Wie groß waren Deine Partitionen? Wenn die erste Partition nicht kleiner als 400 MB war, sind die Folgepartitionen immer noch intakt. > Trotzdem sind die 3 Partitionen die vorher noch gesehen wurden weg und Eine ist vielleicht weg, die anderen beiden haben sich nur unsichtbar gemacht. :) > haben einer Linuxpartition Platz gemacht. Gibt es da noch etwas zu > retten? Das wäre nämlich mehr als wünschenswert. Testdisk hab ich schon > geladen, aber ich habe den Eindruck die Partitionen werden zwar gesucht, > aber das dauert alles quälend lange. "quälend lange" ist kein quantitative Angabe. Bei einer gesunden Festplatten und 130 MB/sek Übertragungsgeschwindigkeit muss Testdisk in etwa 1,3 Stunden fertig sein! Ist das normal, muß ich jetzt Tage > für die Suche einplanen? Nein. Nach der Eigendiagnose kommt nach der Entscheidung für "selber retten" das Klonen. Nicht herummurksen! Den Klon kannst Du dann nochmals klonen (z.B. in eine Datei) und nach Herzenslust an einem der beiden Klone austoben. H. H. schrieb: > Besser kapitulieren. Kann man später immer noch! Oliver S. schrieb: > Obwohl: kein Backup, kein Mitleid. Gilt trotzdem. Es ist traurig, wenn man fehlendes Wissen durch Häme kompensieren muss! Hmmm schrieb: > testdisk dann nur noch einzelne Dateien rekonstruieren, sofern sie nicht > fragmentiert sind. Nein, das macht Photorec aus dem TestDisk-Paket. TestDisk findet die Partitionsanfänge, wenn sie nicht überschrieben worden ist. Hmmm schrieb: > Bei den nicht überschriebenen kann es sein, dass testdisk den > Partitionsanfang erkennt. Wenn Du (zumindest grob) weisst, wie gross die > Partitionen waren, kannst Du Dich auch selbst auf die Suche begeben und > dann (unter Linux z.B. mit fdisk) eine neue Partition Table bauen. Es ist zeitsparender, dafür TestDisk aus dem TestDisk-Paket zu nutzen (Das TestDisk-Paket enthält auch noch PhotoRec). TestDisk gibt's auch unter Linux. Linux ist die bessere Rettungsplattform, weil Windows-Betriebssysteme sich bei Festplatten leider sehr invasiv verhalten. Die Linux-Nutzung für Datenrettungszwecke erfordert lediglich einen minimalen Befehlsschatz! Anton schrieb: > In Zukunft vor solchen Aktionen und für jede vorhandene und neue > Festplatte: > - Seriennummern der Festplatten aufschreiben und vor dem Kopieren > verifizieren (hdparm -I /dev/sdX | grep 'Serial Number') > - Partitionstabelle in Datei schreiben (sfdisk -d) Vorher mit lsblk sich mal die Festplattenlandschaft angucken! Alternativ zum wohl immer vorhandenen hdparm kann man auch TestDisk aus dem TestDisk-Paket nutzen. Bauform B. schrieb: > und was für eine Partitionstabelle? Angeblich gibt es eine GPT-Kopie > ganz am Ende der Platte. Zusammen mit einer der Superblock-Kopien könnte > man theoretisch noch alles lesen, was nicht direkt überschrieben wurde. > Warum hört man so wenig davon? Weil hier alles nur Stückwerk ist. :( Es gibt zwei Varianten von Partitionstabellen, die alte "MBR"-artige und die GPT. Das Alter der Festplatte legt nahe, dass MBR verwendet wurde. Wichtig ist die gelieferte Information, dass es sich dreimal um NTFS als Dateisystem handelt. Bradward B. schrieb: > Dann kann man wnigstens > zusammenpuzzlen wie die einzelnen Cluster zusammengehören. Das sind fromme Wünsche. Anfang der 2000er Jahre habe ich so eine Datei gerettet. Das war die Einladungsliste zur Hochzeit eines Kollegens im XLS-Format auf einem XP-System, das FAT32 nutzte. Das war die wichtigste Information auf der Festplatte. XLS ist im Gegensatz zu XLSX nicht komprimiert. Die Datei hatte zwei Cluster und die lagen nicht hintereinander. PhotoRec hatte die Date falsch rekonstruiert. Und so konnte man den zweiten Cluster mit der Methode des scharfen Hingucken finden. Versuch' das mal mit einer gepackte Datei, wie z.B. die ???X-Formate von Microsoft im Office-Bereich. Bradward B. schrieb: > Achja, zuerst sollte man > natürlich erinnern, welche Clustergröße die ursprünglichen partitionen > hatten ... Bei 500 GByte waren es wohl 8 Sektoren pro Cluster. PhotoRec schätzt diese Information aus den Positionen von gefundenen Dateianfängen, meine ich. Cartman E. schrieb: > Kennt man NTFS, weiss man schon vorher dass man sich dort nur sinnfreie > Arbeit macht. NTFS fragmentiert sehr schnell, im Vergleich mit ext2/3/4. Die Aussage ist zu pauschal. Primär ist die Nutzungsart maßgeblich: Datengrab oder Arbeitsfestplatte? Ich weiß nicht, welcher Wirkmechanismus die ext-Familie dem NTFS überlegen machen soll. Alexander schrieb: > Richtig! kein Backup = kein Ärger kein Alexander -> weniger Hintergrundrauschen auf µc.net Jörg schrieb: > Unter Windows würde ich Dir HxD empfehlen. > https://mh-nexus.de/de/hxd/ > Standardmäßig werden die Datenträger schreibgeschützt eingebunden. Über > ein 'Studium' zum Aufbau von Partitionstabellen (MBR / GPR) kommst Du > aber nicht herum. Studium ja, manuelle Rekonstruktion von Partitionstabellen bei Ignoranz vorhandener quelloffener kostenloser Produkte wie Testdisk und anderen birgt einen Anfangsverdacht auf Dummheit oder Masochismus. Ja, natürlich man kann man einen Rasen auch mit einer Schere schneiden! Bradward B. schrieb: > Naja, zur Wiederherstellung einer fälschlicherweise überschriebene > Partition müssen natürlich die alte "Verwaltungsdaten" wiederhergestellt > werden. Dazu sind nun mal schreiboperationen auf die "teilgelöschten > (sic!) Partition nötig. > > Klar kann man auch erst mal den Patienten Klonen und an dem Klonen das > wiederbelben üben. Ist aber letztlich die selbe Prozedure. Kennst Du eigentlich den Faden der Ariadne? https://de.wikipedia.org/wiki/Ariadnefaden Norbert schrieb: > Ob man ein teilgelöschtes NTFS noch reanimieren kann weiß ich nicht. Man muss den Klon verschiedenen Datenrettungsprogramm zum Fraß vorwerfen. Ausprobieren ist meist kostenlos. > Vielleicht klappt das, wenn die MFT nicht beschädigt wurde. Dann reicht allerdings sogar TestDisk. Manche Datenrettungsprogramme werten zusätzlich irgendwelche Logdateien aus. Wenn nix mehr geht, hilft nur noch der Carver PhotoRec. Klaus B. schrieb: > die Platte hat scheinbar am Anfang defekte Sektoren und das kopieren per > IcyBox hat jedenfalls nicht geklappt. Zumindest nehm ich das an, weil > vorn die Leuchtdioden nach einer kurzen Weile rot blinkten. Die Frage > ist, was macht ein Kopierpogramm, wenn es defekte Sektoren erkennt? Stur > mitkopieren? Mutmaßlich bricht das in der Dockingstation eingebaute Kopierprogramm ab. Nutze stattdessen ddrescue von der GNU foundation und die Option einer Logdatei, heißt jetzt "manfile". Du kannst mit Hilfe der Logdatei auch die Rettung zwischendurch abbrechen und später fortsetzen. Alexander schrieb: > Die Partitionstabelle aus dem Backup kannst Du doch kopieren! Wenn der Frager nur ein dateibasiertes Backup durchgeführt hat, gibt es keine gesicherte Partitionstabelle, werter Alexander. Daniel A. schrieb: > PS: Wenn du das Image auf einer btrfs platte erstellst, kannst du sofort > und ohne grossen zusätzlichen Speicherverbrauch ein reflink copy des > Image erstellen. Dann kannst du extrem einfach Kopien vom Image machen, Das ist die schlaueste Vorgehensweise, aber eher etwas für Fortgeschrittene, finde ich. Klaus B. schrieb: > Da werden einem dann sicher Kenntnisse im > Hexeditor abverlangt, stimmts? Das passiert mir übrigens zum ersten mal, > das eine Platte so aussteigt. Die Bedienung des Hexeditors ist noch das einfachste. Du müsstest jedoch die NTFS-Strukturen bei Betrachtung der nackten Bytes und der ASCII-Darstellung erkennen. Spätestens bei der Dekodierung von "MFT-Runs" wirst Du aufgeben. Für diesen Zweck gibt es eine Reihe von speziellen Hexeditoren, die NTFS-Strukturen dekodieren. Klaus B. schrieb: > Partition Wizard 9.1 hat auch einen Partition recovery Wizard, was ist > davon zu halten? Keine Ahnung, aber NTFS-Bootsektoren identifizieren und darauf basierend eine Partitionstabelle schreiben, sollte jedes derartige Programm beherrschen. Nimm einfach TestDisk - das kann's!
:
Bearbeitet durch User
Peter M. schrieb: > Alexander schrieb: >> Richtig! kein Backup = kein Ärger > > kein Alexander -> weniger Hintergrundrauschen auf µc.net Ich habe hier lediglich nachgeholfen den Kommentar von Oliver S. (oliverso) in einen brauchbaren Rahmen zu rücken der wenigstens Sinn ergibt, um noch mal herauszupointieren, dass ja hier gerade der Umstand ein Backup anzulegen, erst zum Ärger geführt hat. Das Wörtchen "obwohl" hat mich zu dieser Deutung ermutigt. Peter M. schrieb: > Wie groß waren Deine Partitionen? Wenn die erste Partition nicht kleiner > als 400 MB war, sind die Folgepartitionen immer noch intakt. Steht da, ungefähr 155 GB. Im Wesentlichen hast Du nur noch mal schöner ausgeführt was andere vor dir geschrieben haben. Ich hab auch eine ddrescue Doku und eine Befehlszeile für Dummies hingeklatscht. Und eine Vollversion einer Software verlinkt die auf NTFS ziemlich gut carven kann. Wer sich tief genug im Hintergrundrauschen verloren hat findet dort möglicherweise auch die zweite (bessere) Alternative zu Photorec.
:
Bearbeitet durch User
Die Platte hing im Win 7 Rechner und war mit 3 Partitionen a' ca. 155 GB NTFS formatiert. Ich möchte sie ja kopieren, aber das Kopierprogramm muss dann auch so tolerant sein und defekte Sektoren mitkopieren. Hier sind ja 2 Probleme auf einmal, defekte Sektoren, weswegen der Rechner nicht mehr bootete (eigentlich komisch, denn die Boot C: war ja auf einer anderen Platte. Und dann die dummdusselige Verwechslung der Schächte in der ICY Box. Sind Programme mit GUI grundsätzlich schlechter als Programme mit rudimentärer DOS Textoberfläche? Frage jetzt erstmal weitläufig im Bekanntenkreis rum, ob es da einen Linuxspezialisten hat, bevor ich einen unverzeihlichen 2. Fehler mache.
Klaus B. schrieb: > Ich möchte sie ja kopieren, aber das Kopierprogramm > muss dann auch so tolerant sein und defekte Sektoren mitkopieren ddrescue ddrescue ddrescue
@ Alexander Danke, ich werd mich in die von Dir verlinkte Wiki Seite einlesen. Zumindestens das Istallieren hab ich schon ohne das Ubuntu gemeckert hat hinbekommen. Normalerweise verbeisse ich mich ja in technische Probleme meist so lange, bis sie gelöst sind, aber das hier verträgt keinen 2. Fehler. Ist so ähnlich wie beim Bombenentschärfen.
:
Bearbeitet durch User
Die deutsche Übersetzung ist etwas irreführend. Maximale Versuche sind die Leseversuche, es werden keine Fehler behoben.
Hallo Alexander, Alexander schrieb: > Vollversion einer Software verlinkt die auf NTFS ziemlich gut carven "auf NTFS ziemlich gut carven" Diese Formulierung ist ein Widerspruch in sich. Klaus B. schrieb: > Die Platte hing im Win 7 Rechner und war mit 3 Partitionen a' ca. > 155 GB > NTFS formatiert. Ich möchte sie ja kopieren, aber das Kopierprogramm > muss dann auch so tolerant sein und defekte Sektoren mitkopieren. Hier Nein, fehlerhafte Sektoren sind "pending" in den SMART-Parametern. Die werden ausgelassen. An ihrer Stelle sind Lücken auf dem Kopierziel. Tolerant heißt, nicht an der fehlerhaften Stelle festbeißen sondern über einen vermuteten Fehlerbereich drüber springen, um das Rettbare so schnell wie möglich auf eine gesunde Festplatte zu übertragen. > sind ja 2 Probleme auf einmal, defekte Sektoren, weswegen der Rechner > nicht mehr bootete (eigentlich komisch, denn die Boot C: war ja auf > einer anderen Platte. Und dann die dummdusselige Verwechslung der > Schächte in der ICY Box. > Sind Programme mit GUI grundsätzlich schlechter als Programme mit > rudimentärer DOS Textoberfläche? Nein. > Frage jetzt erstmal weitläufig im Bekanntenkreis rum, ob es da einen > Linuxspezialisten hat, bevor ich einen unverzeihlichen 2. Fehler mache. Wenn Du keinen Zeitdruck bei der Datenrettung hast, dann könntest Du Dir zwei drei Gebrauchtfestplatten oder wiederaufgearbeite Festplatten kaufen, die müssen nicht groß sein. Damit kannst Du dann schön üben. An den Überechner sollten keine weiteren Festplatten angeschlossen werden, die für Dich ein Schadenrisiko bergen. Anhand des untenstehenden Links kannst du sehen, wie wenig Befehle Du für das Klonen unter Linux brauchst. Das mapfile bitte immer erzeugen lassen. Mit seiner Hilfe kannst Du einen einmal begonnene und zwischendurch abgebrochene Suche immer wieder fortsetzen: https://www.computerbase.de/forum/threads/wd-elements-1-tb-festplatte-extern-wird-nicht-mehr-erkannt-win-10.2132442/page-2#post-27931526 Außerdem sagt Dir das Mapfile genau, wo die Fehler liegen. Diese Detailinformation liefert Dir die Auswertung der SMART-Parameter nicht.
:
Bearbeitet durch User
Peter M. schrieb: > "auf NTFS ziemlich gut carven" > Diese Formulierung ist ein Widerspruch in sich. Nö, siehe Peter M. schrieb: > Die Datei hatte zwei Cluster und die lagen nicht hintereinander. > PhotoRec hatte die Daten falsch rekonstruiert. Und so konnte man den > zweiten Cluster mit der Methode des scharfen Hingucken finden. Programm macht genau das - auf NTFS optimiert Peter M. schrieb: > Anhand des untenstehenden Links kannst du sehen, wie wenig Befehle Du > für das Klonen unter Linux brauchst. Beispiel 1 ist Mist. Da wird die Zielfestplatte gelöscht. Völlig unnötig, da ist doch gleich der nächste GAU vorprogrammiert. Man kann doch gleich in eine Imagedatei schreiben. Ist so gut wie eine Festplatte, nur DAU sicher: Die Datei kann sonstwo liegen (nur nicht auf FAT32) Beispiel 2
:
Bearbeitet durch User
Alexander schrieb: > Beispiel 1 ist Mist. Da wird die Zielfestplatte gelöscht. Völlig > unnötig, da ist doch gleich der nächste GAU vorprogrammiert. Man kann > doch gleich in eine Imagedatei schreiben. Ist so gut wie eine Anders als der direkte Festplattenklon erfordert die Imagedatei eine Zielfestplatte, die größer ist als die Quellfestplatte. Die Leute, die die verlinkte Anleitung lesen sind mit dem Anlegen von Festplattenverbünden überfordert, wenn es darum geht, die erforderliche Menge an Speicherplatz für die Zieldatei sicherzustellen. Was passiert mit dem Speicherplatz in der Zieldatei, wenn ddrescue den ersten Sektor ausließt, beim zweiten patzt und dann tausende Sektoren nach vorne springt? Welcher Wert für die Sektoren dazwischen aus der Zieldatei geliefert? Das Beispiel ist noch mit Hilfe der Nutzung des fill-Parameters verbesserbar...
Peter M. schrieb: > Anders als der direkte Festplattenklon erfordert die Imagedatei eine > Zielfestplatte, die größer ist als die Quellfestplatte. Das ist in nahezu allen Fällen falsch. Selbst im ungünstigsten Fall, wenn eine Quellfestplatte tatsächlich randvoll mit unkomprimierbaren Zufallsdaten ist, wird die Imagedatei höchstens genau gleich groß (sans Dateisystem Verwaltungsinformation) Aber in praktisch allen anderen Fällen wird der gewiefte Anwender einfach nur einen einzelnen Parameter hinzu fügen und eine sparse Imagedatei anlegen. In einer solchen werden leere Bereiche (0x00) nur als blockrange abgelegt und nehmen nahezu keinen Speicherplatz in Anspruch. Des weiteren kann man (alternativ zu sparse Dateien) natürlich den erzeugten output auch noch per pipe durch einen Kompressor jagen. Für alle die mit dem Konzept der sparse Dateien nicht vertraut sind:
1 | /tmp$ truncate -s 1G IMAGE # 1GiB Datei anlegen |
2 | /tmp$ ls -l IMAGE # Sieht aus wie 1GiB |
3 | -rw-rw-r-- 1 norbert norbert 1073741824 1. Jul 21:59 IMAGE |
4 | /tmp$ du IMAGE # (disk usage) |
5 | 0 IMAGE # Braucht auf dem Datenträger aber keinen Speicherplatz |
6 | /tmp$ |
Norbert schrieb: > höchstens genau gleich groß (sans Dateisystem Verwaltungsinformation) Norbert schrieb: > Selbst im ungünstigsten Fall, wenn eine Quellfestplatte tatsächlich > randvoll mit unkomprimierbaren Zufallsdaten ist, wird die Imagedatei > höchstens genau gleich groß (sans Dateisystem Verwaltungsinformation) Was ist denn das für eine unsinnige Aussage? Festplatte ist x Bytes groß. Dateisystemwasserkopf kostet y Bytes. Speicherplatzbedarf bei Speicherung von x in einem Dateisystem: x+y. Da y>0 gilt für den Speicherbedarf des neuen Datenträgers: x+y>x Sprich, eine größere Festplatte ist nötig. Ein Airbus kann auch bestimmt auch in Courchevel landen, aber halt nur ohne Passagiere und der Tank darf auch nur zu einem Viertel voll sein... Und wenn nun das Datenrettungsprogramm der Träume ein verwendetes Komprimierverfahren nicht versteht und gerne rohe Datenträgerabzüge verarbeiten will? Und was macht das französische Wort "sans" im deutschen Text?!
:
Bearbeitet durch User
Frank D. schrieb: > Klaus B. schrieb: >> Gibt es da noch etwas zu retten? > > Ja klar, einfach das letzte Backup verwenden. So etwas passiert immer dann, wenn man gerade kein Backup hat. Sehr mysteriös.
Peter M. schrieb: > Was passiert mit dem Speicherplatz in der Zieldatei, wenn ddrescue den > ersten Sektor ausließt, beim zweiten patzt und dann tausende Sektoren > nach vorne springt? Welcher Wert für die Sektoren dazwischen aus der > Zieldatei geliefert? Das passiert ja nur im ersten Durchgang mit dem -n Flag. Es werden Nullen aufgefüllt und im Mapfile vermerkt. Im zweiten Durchgang lässt man das Flag weg, dann entfaltet ddrescue seine Kraft und liest mit Engelsgeduld Sektoren byteweise. Ohne Eingrenzung max-retries kann das Wochen dauern. Norbert schrieb: > Für alle die mit dem Konzept der sparse Dateien nicht vertraut sind: Sparse oder Komprimierung sind in dem Falle unerwünscht (MBR + MFT gelöscht)
Peter M. schrieb: > Festplatte ist x Bytes groß. > Dateisystemwasserkopf kostet y Bytes. > Speicherplatzbedarf bei Speicherung von x in einem Dateisystem: x+y. > Da y>0 gilt für den Speicherbedarf des neuen Datenträgers: > x+y>x > Sprich, eine größere Festplatte ist nötig. Lies dir noch einmal den Teil bezüglich sparse Dateien durch. Langsam. Die sind nämlich so wichtig, das zB. ddrescue einen eigenen Ausgabeparameter dafür hat. Einfach ausgedrückt, jeder 4KiB Block der Quelle welcher keine Daten enthält sondern 0x00, belegt in der Zieldatei keinen Speicherplatz.
1 | /tmp$ mount |grep /tmp |
2 | tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime,size=10240000k) |
3 | /tmp$ truncate -s 50G IMAGE |
4 | /tmp$ ls -l IMAGE |
5 | -rw------- 1 norbert norbert 53687091200 2. Jul 07:09 IMAGE |
6 | /tmp$ du IMAGE |
7 | 0 IMAGE |
Hier ist eine 50GiB sparse Datei erfolgreich im /tmp Dateisystem (RAM) angelegt worden. Und das hat nur eine Größe von 10GiB. Gleich noch einmal:
1 | tmp$ dd if=/dev/zero of=IMAGE bs=1G count=10 conv=sparse |
2 | 10+0 Datensätze ein |
3 | 10+0 Datensätze aus |
4 | 10737418240 Bytes (11 GB, 10 GiB) kopiert, 1,68414 s, 6,4 GB/s |
5 | /tmp$ ls -l IMAGE |
6 | -rw------- 1 norbert norbert 10737418240 2. Jul 07:14 IMAGE |
7 | /tmp$ du IMAGE |
8 | 0 IMAGE |
Und jetzt deine Version:
1 | /tmp$ rm IMAGE |
2 | /tmp$ dd if=/dev/zero of=IMAGE bs=1G count=10 |
3 | dd: Fehler beim Schreiben von 'IMAGE': Auf dem Gerät ist kein Speicherplatz mehr verfügbar |
4 | 10+0 Datensätze ein |
5 | 9+0 Datensätze aus |
6 | 10485485568 Bytes (10 GB, 9,8 GiB) kopiert, 3,76534 s, 2,8 GB/s |
7 | /tmp$ ls -l IMAGE |
8 | -rw------- 1 norbert norbert 10485485568 2. Jul 07:15 IMAGE |
9 | /tmp$ du IMAGE |
10 | 10239732 IMAGE |
Alexander schrieb: > Sparse oder Komprimierung sind in dem Falle unerwünscht (MBR + MFT > gelöscht) Bollocks. Eine sparse Datei entspricht absolut den identischen Rohdaten. Nur halt clever gespeichert. Und sie verhällt sich wie eine normale datei und sie kann mit jedem Folgeprogramm be-/misshandelt werden.
Das Image soll aber als echte Platte behandelt werden (testdisk, ggf losetup kpartx mount etc)
Alexander schrieb: > Das Image soll aber als echte Platte behandelt werden (testdisk, ggf > losetup kpartx mount etc) Norbert: > Und sie verhält sich wie eine normale Datei! > Und sie kann mit jedem Folgeprogramm be-/misshandelt werden! Isses denn so schwer zu verstehen? (losetup…)
Norbert schrieb: > Isses denn so schwer zu verstehen? Anscheinend. Deine Theorie in allen Ehren, bist Du Kernelentwickler?
Nur meine eigenen lsm. Hier, versuch das einmal…
1 | #!python
|
2 | import os |
3 | |
4 | BLOCKSIZE = 4096 |
5 | data = bytes('D'*BLOCKSIZE, 'ascii') |
6 | fh = os.open('/tmp/IMAGE', os.O_RDWR|os.O_CREAT) |
7 | os.write(fh, data) |
8 | os.lseek(fh, BLOCKSIZE, os.SEEK_CUR) |
9 | os.write(fh, data) |
10 | os.close(fh) |
Damit schreibst du vier KiB Daten, vier KiB 0x00(sparse), vier KiB Daten. Und dann ein:
1 | $ ls -l --block-size=1K IMAGE* ; du --apparent-size IMAGE* ; du IMAGE |
2 | -rwx------ 1 norbert norbert 12 2. Jul 08:50 IMAGE |
3 | 12 IMAGE |
4 | 8 IMAGE |
Ergebnis: Ein 12 KiB Datei welche 12 KiB Informationen enthält, jedoch nur 8 KiB im Dateisystem nutzt. Ad. Den hatte ich noch vergessen:
1 | /tmp$ hd IMAGE |
2 | 00000000 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 |DDDDDDDDDDDDDDDD| |
3 | * |
4 | 00001000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
5 | * |
6 | 00002000 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 |DDDDDDDDDDDDDDDD| |
7 | * |
8 | 00003000 |
9 | /tmp$ |
:
Bearbeitet durch User
Was ist jetzt der Unterschied zu
1 | $ fallocate -l 10G bigfile # oder |
2 | $ dd if=/dev/zero of=bigfile bs=1M seek=10240 count=0 |
(beides dateisystemabhängig)
Alexander schrieb: > Was ist jetzt der Unterschied zu > $ fallocate -l 10G bigfile …legt eine dicke 10 GiB große Datei an und belegt auch die vollen 10 GiB. Wohingegen ›truncate -s 10G bigfile‹ eine sparse Datei anlegt und keinen Platz braucht. Und bei dd sorgt der seek Parameter für eine sparse Datei.
:
Bearbeitet durch User
Alexander schrieb: > Anscheinend. Deine Theorie in allen Ehren, bist Du Kernelentwickler? Das ist keine Theorie, das ist ein Feature von jedem gängigen Dateisystem.
Aha. Und das habt ihr auch getestet? testdisk, mount, und sogar Windows Tools wie HxD oder GetDataBack for NTFS greifen wie auf ein ganz normales Blockdevice zu und merken das gar nicht? Sorry ich komme aus der Android Welt da arbeitet man mit abgespeckten Core Utils und Erweiterungen wie simg2img, da ist das definitiv nicht so.
:
Bearbeitet durch User
Frank D. schrieb: > von jedem gängigen > Dateisystem. Ich weiß worauf du hinaus willst, aber Obacht für die Mitleser: Das ganze MS FAT12/16/32/VFAT/ExFAT Gelumpe kann es zum Beispiel nicht.
Alexander schrieb: > Aha. Und das habt ihr auch getestet? testdisk, mount, und sogar Windows > Tools wie HxD oder GetDataBack for NTFS greifen wie auf ein ganz > normales Blockdevice zu und merken das gar nicht? Ja das nennt man Transparenz. > Sorry ich komme aus der Android Welt da arbeitet man mit abgespeckten > Core Utils und Erweiterungen wie simg2img, da ist das definitiv nicht > so. google "sparse files android"
Alexander schrieb: > Aha. Und das habt ihr auch getestet? testdisk, mount, und sogar Windows > Tools wie HxD oder GetDataBack for NTFS greifen wie auf ein ganz > normales Blockdevice zu und merken das gar nicht? Wie sich Windows verhält, interessiert mich nicht. Ich bin mir aber einigermaßen sicher, dass auch Windows auf NTFS mit sparse Dateien umgehen kann. In der Linux Welt funktioniert das sowieso völlig problemlos. Da legst du dir auf der 100GB Festplatte eine 500GiB große sparse Datei an, erstellst zB. ein ext4 darauf, nimmst losetup und anschließend mount. Und schon kannst du nach Herzenslust hineinschreiben. Und die Image-Datei wächst dabei langsam. Jedoch nicht über den physikalisch vorhandenen Speicherplatz hinaus (muss man hoffentlich nicht erwähnen) Man kann sogar wieder darin löschen und mit ›diskfree‹ und anschließendem ›fallocate -p …‹ den Platzbedarf wieder verringern.
Ja ext2/3/4 ist schön, gefällt mir auch besser und es gibt viele Tools dafür. Nur ist es hier halt eine Platte mit drei NTFS Partitionen und gelöschtem (überschriebenen?) MBR und kaputtem Dateisystem. Ich bezweifle stark dass ein Sparse Image hier keine zusätzliche Hürde bei der Datenrettung wäre.
Alexander schrieb: > Ja ext2/3/4 ist schön, gefällt mir auch besser und es gibt viele Tools > dafür. Nur ist es hier halt eine Platte mit drei NTFS Partitionen und > gelöschtem (überschriebenen?) MBR und kaputtem Dateisystem. Unterscheide zwischen Quelle und Ziel.
Peter M. schrieb: > Sprich, eine größere Festplatte ist nötig. Das würde dann aber heißen, dass, wenn man einen Emulator hat für alte CPUs, die mit Disketten arbeiten, dass die Diskettenimages hierfür nicht mehr gehen. Das ist mir bisher aber noch nicht aufgefallen.
Norbert schrieb: > Unterscheide zwischen Quelle und Ziel. Nicht unbedingt. gddrescue muss ja sicher eine Struktur beibehalten damit dieses so erzeugte Sparse Image später als Diskimage durchgeht. Das geht sicher nicht ohne Kenntnis bzw. Interpretation des Inhalts.
Alexander schrieb: > Nicht unbedingt. Doch! UN-BE-DINGT! Das ist ein Container dessen Inhalt vom Betriebssystem verwaltet wird und diesem VÖLLIG egal ist. Es ist eine Sammlung von irgendwelchen nichtinterpretierten Bytes. Erst durch ein losetup/mount erhält das Betriebssystem eine erweiterte Sicht auf den Inhalt. Und vertrau mir, das kann es. Und ob sich die Rohdaten auf einer Lehmplatte in Cuneiform befinden oder über einen nassen gesalzenen Bauwollfaden transportiert werden, davon bekommt das viel weiter darüber liegende Programm überhaupt nichts mit. Dank der Vermittlung über das Betriebssystem.
Norbert schrieb: > Das ist ein Container dessen Inhalt vom Betriebssystem verwaltet wird Also eine reine Linuxgeschichte. Darwin zähle ich mal dazu. Norbert schrieb: > Erst durch ein losetup/mount erhält das Betriebssystem eine erweiterte > Sicht auf den Inhalt. Ich kenne mich mit Windows nicht aus, aber früher brauchte man extra Tools dazu wie OSFmount. GetDataBack for NTFS wird also damit nichts anfangen können, und in HxD sehe ich dann auch keine Disk.
Alexander schrieb: > Also eine reine Linuxgeschichte. Darwin zähle ich mal dazu. Ich hatte es schon zuvor erwähnt: Windows interessiert mich nicht. Und hier in diesem thread geht es um Datenrettung einer Festplatte mit NTFS Partitionen. Nun kannst du versuchen auf Biegen und Brechen das schlechtest taugliche Betriebssystem dafür zu nutzen… …oder du rettest die Daten (ja, auch die im NTFS befindlichen Daten) mit Hilfe eines bestens dazu geeigneten Linux Systems. Und darum geht es hier.
Rbx schrieb: > Peter M. schrieb: >> Sprich, eine größere Festplatte ist nötig. > Das würde dann aber heißen, dass, wenn man einen Emulator hat für alte > CPUs, die mit Disketten arbeiten, dass die Diskettenimages hierfür nicht > mehr gehen. Das ist mir bisher aber noch nicht aufgefallen. Warum? In der emulierten Welt gibt es keine Probleme. Wenn Du aber auf einem Altcomputer ein Diskette nicht klonst, sondern stattdessen als Datei auf eine Diskette schreiben willst, dann bräuchtest Du eine größere Diskette wegen dem zusätzlich erforderlichem Verwaltungswasserkopf. Alexander schrieb: > Ich kenne mich mit Windows nicht aus, aber früher brauchte man extra > Tools dazu wie OSFmount. GetDataBack for NTFS wird also damit nichts > anfangen können, und in HxD sehe ich dann auch keine Disk. Mein Windows-Wissenstand endet bei Windows 7. Meines Wissens bietet Windows 7 keinerlei Bordwerkzeug um eine Datei als virtuelles Blockgerät in der Datenträgerwelt einzubinden. Ist GetDataBack die Software, die nur von Blockgeräten rettet?
Norbert schrieb: > …oder du rettest die Daten (ja, auch die im NTFS befindlichen Daten) mit > Hilfe eines bestens dazu geeigneten Linux Systems. Und darum geht es > hier. Genau. Und da der Anwender in der Linux-Welt nicht heimisch ist, muss er erstmal Starten und Landen können. Bei Interesse kann er sich dann mit dem später mit dem dreifachen Rittberger auseinandersetzen.
:
Bearbeitet durch User
Norbert schrieb: > Nun kannst du versuchen auf Biegen und Brechen das schlechtest taugliche > Betriebssystem dafür zu nutzen… ... oder die bestmögliche NTFS Datenrekonstruktionssoftware empfehlen.
Norbert schrieb: > Da legst du dir auf der 100GB Festplatte eine 500GiB große /sparse/ > Datei an, erstellst zB. ein ext4 darauf, nimmst losetup und anschließend > mount. > Und schon kannst du nach Herzenslust hineinschreiben. Und die > Image-Datei wächst dabei langsam. Jedoch nicht über den physikalisch > vorhandenen Speicherplatz hinaus (muss man hoffentlich nicht erwähnen) Vermutlich ist die Erwähnung in diesem Fall sehr sinnvoll, sonst ist die nächste Frage "was soll denn 'Kein Weltraum links auf dem Gerät' heißen?" SCNR. ;)
Peter M. schrieb: > Genau. Und da der Anwender in der Linux-Welt nicht heimisch ist, muss er > erstmal Starten und Landen können. Verstehe ich. Ich bin mir aber recht sicher, dass er hier zumindest einige zielführende Hilfestellungen erhalten hätte. Die schwierigste Aufgabe für ihn wäre das Herausfiltern und Verwerfen des sonstigen Unsinns. > Bei Interesse kann er sich dann mit > dem später mit dem dreifachen Rittberger auseinandersetzen. s.o.
Sheeva P. schrieb: > Norbert schrieb: >> Jedoch nicht über den physikalisch >> vorhandenen Speicherplatz hinaus (muss man hoffentlich nicht erwähnen) > > Vermutlich ist die Erwähnung in diesem Fall sehr sinnvoll, sonst ist die > nächste Frage "was soll denn 'Kein Weltraum links auf dem Gerät' > heißen?" > > SCNR. ;) LOL. Ich habe auf Linux Systemen schon einige seltsame Übersetzungen 'geniessen' dürfen, aber das… …da käme sofort poedit oder falls nötig hexedit zum Einsatz. Nachdem der Kaffee aus der Tastatur gespült wurde. Manchmal – wenn's schnell gehen soll – auch gerne LC_ALL=C als Präambel zum eigentlichen Befehl.
Norbert schrieb: > Eine sparse Datei entspricht absolut den identischen Rohdaten. Nur > halt clever gespeichert. Man kann mit lseek explizit zum Anfang / Ende des nächsten Lochs springen. Damit würde ich die Löcher als Teil der Daten betrachten, und damit sind die Daten technisch gesehen nicht identisch zu den Rohdaten. Aber solange man nur normal liest / schreibt, oder mmapt, sieht ein Programm effektiv keinen Unterschied. Man könnte aber auch argumentieren, das selbst ein nicht-sparse Image nicht zwangsläufig identisch zu den Rohdaten ist. Bei manchen (älteren) Drives, ist nicht deterministisch, was ein mit TRIM entfernter Bereich zurückgibt, und manche neueren können so eingestellt werden, dass sie einen Fehler zurückgeben, wenn man versucht, solche Bereiche zu lesen. Ein Image allein kann das nicht repräsentieren. Aber in letzterem fall wären wohl wenigstens image + mapfile zusammen vollständig.
Alexander schrieb: > Also eine reine Linuxgeschichte. https://learn.microsoft.com/en-us/windows/win32/fileio/sparse-files Alexander schrieb: > Darwin zähle ich mal dazu. Aua.
Daniel A. schrieb: > Man kann mit lseek explizit zum Anfang / Ende des nächsten Lochs > springen. Damit würde ich die Löcher als Teil der Daten betrachten, und > damit sind die Daten technisch gesehen nicht identisch zu den Rohdaten. Damit versuchst du absichtlich eine Fehlinterpretation zu forcieren. Nimm eine NICHT sparse Datei welche dann tatsächlich die 0x00 Blocks auf die Festplatte geschrieben enthält. Springe absichtlich (wie zuvor von dir vorgeschlagen) über diese Bereiche und du hast den gleichen Effekt. Du kannst auch von beiden Dateien ein sha256 hash erzeugen und die werden identisch sein.
:
Bearbeitet durch User
Norbert schrieb: > Daniel A. schrieb: >> Man kann mit lseek explizit zum Anfang / Ende des nächsten Lochs >> springen. Damit würde ich die Löcher als Teil der Daten betrachten, und >> damit sind die Daten technisch gesehen nicht identisch zu den Rohdaten. > > Damit versuchst du absichtlich eine Fehlinterpretation zu forcieren. > Nimm eine NICHT sparse Datei welche dann tatsächlich die 0x00 Blocks > auf die Festplatte geschrieben enthält. Springe absichtlich (wie zuvor > von dir vorgeschlagen) über diese Bereiche und du hast den gleichen > Effekt. Nein, SEEK_HOLE / SEEK_DATA springen da nicht an den selben ort. > Du kannst auch von beiden Dateien ein sha256 hash erzeugen und die > werden identisch sein. Ja, die prüfen die Löcher auch nicht.
:
Bearbeitet durch User
Daniel A. schrieb: > Nein, SEEK_HOLE / SEEK_DATA springen da nicht an den selben ort. Das hatte ich auch nicht geschrieben. Ich hatte explizit geschrieben: > Springe absichtlich … über DIESE Bereiche Das Dateisystem weiss das dort nur 0x00 stehen und merkt sich das mittels range Einträgen. Wenn es nun nach diesem Block gefragt wird, wird vom Dateisystem ein Block mit 0x00 "on the fly" generiert. Du schreibst Daten und du liest die exakten Daten wieder zurück. Nur einmal brauchst du viel Festplattenplatz und einmal weniger. Worauf willst du eigentlich hinaus? (musst du nicht beantworten)
Hmmm schrieb: > Alexander schrieb: >> Also eine reine Linuxgeschichte. > > https://learn.microsoft.com/en-us/windows/win32/fileio/sparse-files Was hat NTFS Dateikompression mit einem linuxspezifischen Containerformat zu tun? Hmmm schrieb: > Alexander schrieb: >> Darwin zähle ich mal dazu. > > Aua. zeige uns den mount Befehl - in einer Linux Konsole - in einer MacOS Konsole - in einer Windows Konsole
:
Bearbeitet durch User
> Daniel A. schrieb: >> Nein, SEEK_HOLE / SEEK_DATA springen da nicht an den selben ort. Alex kam dazwischen… Noch eines: Wenn du dringend mit SEEK_HOLE arbeiten willst (innerhalb normaler Daten unsinnig), dann bist du für die Interpretation des übersprungenen Bereiches verantwortlich.
:
Bearbeitet durch User
Alexander schrieb: > Was hat NTFS Dateikompression mit einem linuxspezifischen > Containerformat zu tun? Es ging um Filesysteme als "Container". Sparse Files sind ein Filesystem-Feature, das keineswegs auf Linux (und auch nicht auf unixoide Systeme generell) beschränkt ist. Alexander schrieb: > zeige uns den mount Befehl > > in einer Linux Konsole > in einer MacOS Konsole > in einer Windows Konsole Für Dich ist "Linux" also ein Synonym für unixoide Systeme. Ein echter Alecxs.
Daniel A. schrieb: > .... > Aber solange man nur normal liest / schreibt, oder mmapt, sieht ein > Programm effektiv keinen Unterschied. Kommt jetzt noch einer dass die rohen Analogsignale am Lesekopf nicht immer identisch sind? Wart ihr alle zu lange in der Sonne?
Norbert schrieb: > Noch eines: Wenn du dringend mit SEEK_HOLE arbeiten willst (innerhalb > normaler Daten unsinnig), dann bist du für die Interpretation des > übersprungenen Bereiches verantwortlich. Aber genau da da liegt der Hund begraben. Man kann die Löcher sehen, also sind sie nicht vollständig transparent. Und die Löcher enthalten 0en, sind also nicht nur Metadaten. Also sind die Löcher Teil der Daten, und damit die Daten mit und ohne Löcher technisch gesehen nicht identisch. Wenn es SEEK_HOLE / SEEK_DATA nicht gäbe, dann wären Löcher tatsächlich völlig transparent, und damit wären die Daten dann tatsächlich identisch, ob jetzt 0en oder Löcher da sind. Norbert schrieb: > Worauf willst du eigentlich hinaus? Auf gar nichts. Ist nicht wirklich ein Sinnvolles Argument. Mir war nur gerade langweilig.
Hmmm schrieb: > Sparse Files sind ein Filesystem-Feature, das keineswegs auf Linux (und > auch nicht auf unixoide Systeme generell) beschränkt ist. Ja ja das universelle Dateisystemfeature das unter Linux umd Windows kompatibel ist. Hmmm schrieb: > Für Dich ist "Linux" also ein Synonym für unixoide Systeme. Ein echter > Alecxs. Weil es so ist. Welche "unixoiden" nichtlinux Systeme kann man denn sonst noch so nutzen in einem amd64 PC mal eben schnell ne Windows 7 Platte zu klonen? Wo kann man das runterladen und wie installiert man das?
Norbert schrieb: > Sheeva P. schrieb: >> Vermutlich ist die Erwähnung in diesem Fall sehr sinnvoll, sonst ist die >> nächste Frage "was soll denn 'Kein Weltraum links auf dem Gerät' >> heißen?" > > LOL. > > Ich habe auf Linux Systemen schon einige seltsame Übersetzungen > 'geniessen' dürfen, aber das… War AIX oder HP-UX, WIMRE. :-)
Alexander schrieb: > Ja ja das universelle Dateisystemfeature das unter Linux umd Windows > kompatibel ist. Nein, die FAT-Familie (auch Bestandteil der Windows-Dateisysteme) beherrscht keine Sparse Files. Alexander schrieb: > Weil es so ist. Welche "unixoiden" nichtlinux Systeme kann man denn > sonst noch so nutzen in einem amd64 PC mal eben schnell ne Windows 7 > Platte zu klonen? Wo kann man das runterladen und wie installiert man > das? BSD-Derivate und Solaris. Aber "eben schnell" ist doch eine zu optimistische Annahme. :)
:
Bearbeitet durch User
Alexander schrieb: > Ja ja das universelle Dateisystemfeature das unter Linux umd Windows > kompatibel ist. Ist es aus Userland-Sicht tatsächlich. Alexander schrieb: > Welche "unixoiden" nichtlinux Systeme kann man denn sonst noch so nutzen > in einem amd64 PC mal eben schnell ne Windows 7 Platte zu klonen? Beispielsweise eines der diversen BSDs. Alexander schrieb: > Wo kann man das runterladen und wie installiert man das? "Man" kann auf die jeweilige Website gehen und dort alles Notwendige finden. Ob Du das kannst, steht auf einem anderen Blatt.
Alexander schrieb: > Hmmm schrieb: >> Für Dich ist "Linux" also ein Synonym für unixoide Systeme. Ein echter >> Alecxs. > > Weil es so ist. Welche "unixoiden" nichtlinux Systeme kann man denn > sonst noch so nutzen in einem amd64 PC mal eben schnell ne Windows 7 > Platte zu klonen? Wo kann man das runterladen und wie installiert man > das? https://www.freebsd.org/ https://www.netbsd.org/ https://www.openbsd.org/ https://illumos.org/ https://www.openindiana.org/
Ich fang mal hinten an: Daniel A. schrieb: > Norbert schrieb: >> Worauf willst du eigentlich hinaus? > > Auf gar nichts. Ist nicht wirklich ein Sinnvolles Argument. Mir war nur > gerade langweilig. Erkennbar. <grins> Daniel A. schrieb: > Man kann die Löcher sehen, > also sind sie nicht vollständig transparent. Du fragst das Dateisystem aber nicht nach Daten, sondern nach Metadaten bzgl. der Löcher. Nur so siehst du sie. Aber du weißt auch, dass sie per Definition das Gleiche enthalten als wenn die 0x00 physikalisch auf der Platte stünden. > Und die Löcher enthalten > 0en, sind also nicht nur Metadaten. Die Löcher enthalten gar nichts. Die existieren lediglich als range Eintrag in den Metadaten. Das Dateisystem ersetzt sie im normalen Betrieb völlig transparent durch 0x00. In meinem Beispiel oben sind Block 0 und Block 2 tatsächlich auf der Platte zu finden, Block 1 nur als range Information in den Metadaten. > Also sind die Löcher Teil der Daten, > und damit die Daten mit und ohne Löcher technisch gesehen nicht > identisch. Nein, da muss ich energisch widersprechen. Die Daten sind identisch, die Metadaten unterschiedlich. > Wenn es SEEK_HOLE / SEEK_DATA nicht gäbe, dann wären Löcher tatsächlich > völlig transparent, und damit wären die Daten dann tatsächlich > identisch, ob jetzt 0en oder Löcher da sind. Hier stimme ich, was das Ergebnis angeht, zu. Kleiner Nachtrag: Ich denke wir sollten es dabei belassen.
BSD ist also kein Linux, ahja. Komisch, auf Android ist die mksh Standard und die Core Utils und deren Usage sind (bis auf paar gnu spezifische Flags) weitgehend identisch. Aber sei es drum, dann zeige bitte den mount Befehl - in einer BSD Konsole
:
Bearbeitet durch User
Beitrag #8069100 wurde vom Autor gelöscht.
Norbert schrieb: >> Also sind die Löcher Teil der Daten, >> und damit die Daten mit und ohne Löcher technisch gesehen nicht >> identisch. > > Nein, da muss ich energisch widersprechen. Die Daten sind identisch, die > Metadaten unterschiedlich. Nein, die Daten sind technisch gesehen nicht identisch, die Löcher sind nicht Metadaten, sie beschreiben die Daten nicht nur, es sind die Daten. Die Daten sind nur praktisch gesehen identisch.
Alexander schrieb: > BSD ist also kein Linux, ahja. Lies erst ein wenig. Dann schreibe eine Antwort.
Daniel A. schrieb: > Nein, die Daten sind technisch gesehen nicht identisch, die Löcher sind > nicht Metadaten, sie beschreiben die Daten nicht nur, es sind die > Daten. Die Daten sind nur praktisch gesehen identisch. Du arbeitest nicht technisch, sondern praktisch mit den Daten. Wenn du sie erstellst sind sie gleich. Wenn du sie nutzt sind sie gleich. Wenn du einen hash berechnest sind sie gleich. Wenn du in beide schreibst sind sie gleich. Wenn du sie weitergibst sind sie gleich. Und eine Planck-Zeit vor dem Löschen sind sie ebenfalls gleich. > die Löcher sind nicht Metadaten Und deshalb werden die Informationen über diese Bereiche in den Metadaten aufbewahrt.
Norbert schrieb: > Lies erst ein wenig. Was denn? Das Linux und Mac von BSD geklaut haben, was wiederum von Unix geklaut hat?
Nein, Alexander, das tun sie nicht: https://www.reddit.com/r/programming/comments/i9lzqj/paragon_releases_their_ntfs_linux_kernel/ Die neu aufgenommene Version ist schneller, unterstützt aber z.B. keine ADS ("alternate data stream"). Um die Verwirrung komplett zu machen, verkauft Paragon einen anderen NTFS-Treiber mit einer anderen Codebasis, der auch ADS kann.
:
Bearbeitet durch User
Peter M. schrieb: > Nein, Alexander, das tun sie nicht: > > https://www.reddit.com/r/programming/comments/i9lzqj/paragon_releases_their_ntfs_linux_kernel/ > > Die neu aufgenommene Version ist schneller, unterstützt aber z.B. keine > ADS ("alternate data stream"). > Um die Verwirrung komplett zu machen, verkauft Paragon einen anderen > NTFS-Treiber mit einer anderen Codebasis, der auch ADS kann. Der ist doch mittlerweile auch schon wieder veraltet. Es soll wohl schon wieder einen neuen Treiber geben: https://www.phoronix.com/news/NTFS-Windows-Symbolic-Links, der den Alten (davor readonly) Treiber ersetzt.
Peter M. schrieb: > verkauft Paragon einen anderen NTFS-Treiber nun ja anscheinend nicht mehr laut deinem Link
Sheeva P. schrieb: > https://www.freebsd.org/ > https://www.netbsd.org/ > https://www.openbsd.org/ > https://illumos.org/ > https://www.openindiana.org/ https://www.dragonflybsd.org
Hallo Leute, es ist interessant Eure Ausführungen zu verfolgen, aber ich verstehe nur Tempelgong. An mechanischen HDDs leide ich keinen Mangel und deshalb extra eine mit 1TB für das Klonen der 500GB vorbereitet. Außerdem lauern hier auf den Rechnern noch 3-4 unterschiedliche Linux Versionen. Fast alle sind aktuell und Inzwischen sind auf einem System auch die entsprechenden Programme ddRescue (Befehle per copy und paste) installiert. Diverse Adapter USB to IDE/SATA sind ebenfalls present. Jetzt kommt der Haken, ich bin mit der Befehlssyntax im Terminal mit ddRescue nicht vertraut. Konkret, ich habe "ausreichend Bedenken" das ich (nahe 70) irgend etwas bei der Plattenzuweisung falsch mache. Für Euch mag das ein easy Spaziergang sein, aber für mich eben leider nicht.
Das war klar bei so viel Fachsimpelei. Okay dann Spoonfeeding. Öffne ein Terminal und tippe
1 | $ lsblk |
Bist du in der Lage die Quell-Festplatte zu identifizieren?
Beitrag #8070747 wurde vom Autor gelöscht.
Das war nicht herablassend gemeint und ein ehrliches Angebot. Kann hier jeder machen.
Nur zur Info, bin gerade dabei die Platte mit dd rescue zu klonen. Der Prozess ist in Pass 5 forward und es sind 99.98% rescued. Die letzten paar MB scheinen hartnäckig zu sein, die current Rate ist auf 642 B/s gesunken und die remaining time klettert auf weiter 15 von bereits 6 Stunden. Read Errors bis jetzt 733. Ich berichte weiter, aber morgen ist erstmal Wandertag. Schönes Wochenende allerseits
Moin, Klaus B. schrieb: > 642 B/s gesunken und die remaining time klettert auf weiter 15 von > bereits 6 Stunden. Read Errors bis jetzt 733. Voellig normal. Lass einfach ddrescue weiterwursteln waehrend deines Wandertags. Gruss WK
Dergute W. schrieb: > Voellig normal. > Lass einfach ddrescue weiterwursteln waehrend deines Wandertags. Jepp. Würde mich allerdings nicht wundern, wenn auch nach hunderten oder tausenden Läufen keine weitere Verbesserung mehr eintritt. Meine Erfahrung ist: Was in den ersten ca. 10 Läufen nicht gelesen werden konnte, das kommt auch später nicht mehr. Manchmal hilft es allerdings, die Umweltbedingungen zu ändern, um doch noch was zu Tage zu fördern. Also, z.B.: Lauf abbrechen, alles gründlich abkühlen lassen und dann wieder starten.
Bitte auf Luftfeuchtigkeit und Kondenswasser achten wenn die Platte in/ aus dem Kühlschrank befördert wird.
"Würde mich allerdings nicht wundern, wenn auch nach hunderten oder tausenden Läufen keine weitere Verbesserung mehr eintritt. Meine Erfahrung ist: Was in den ersten ca. 10 Läufen nicht gelesen werden konnte, das kommt auch später nicht mehr." ja, das habe ich mich auch schon gefragt, es sind jetzt noch 47 MB die zu "retten" wären und 99.99% rescued. Die Platten werden die ganze Zeit und kontinuierlich per Lüfter gekühlt und sind nicht wärmer als 30 Grad, was ich ab und an kontrolliere. Es macht wirklich keinen Sinn, tagelang zu versuchen knapp 50 MB zu retten. Im Moment heisst es ...scraping failed Blocks und geht nur noch byteweise voran. Ich lass es jetzt nochmal über Nacht laufen, aber morgen würde ich es dann gern abbrechen. Schliesst das Programm mit Ctrl +C den Vorgang auch automatisch richtig ab, oder ist dazu ein anderer Befehl vonnöten?
Klaus B. schrieb: > Die Platten werden die ganze Zeit und kontinuierlich per Lüfter gekühlt > und sind nicht wärmer als 30 Grad Und bei diesen, relativ konstanten Bedingungen geht's halt nicht. Deswegen kann man versuchen, ob es bei davon abweichenden geht. Manchmal geht es. Ist aber eher selten. Ich kann mich nur an zwei Fälle erinnern, wo das mal was gebracht hat. > Schliesst das Programm mit Ctrl > +C den Vorgang auch automatisch richtig ab Ja.
Angehängte Dateien:
-
IMG_4356.JPG
440 KB -
IMG_4357.JPG
410 KB
Mühsam ernährt sich das Eichhörnchen. Immerhin sind es jetzt nur noch 31 MB die zu revitalisieren ausstehen und der Gedanke ist mir auch schon gekommen das eine Temperaturdifferenz ev. hilfreich sein könnte. Das Ganze sieht daher jetzt technisch ungefähr so aus..... und ja ich habe inzwischen ein Tuch untergelegt und Tautropfen weggewischt. ;-) So langsam könnte das Programm aber auch mal wieder probeweise auf backwards schalten. Die Platte machte übrigens nie Geräusche und läuft ganz normal.
:
Bearbeitet durch User
Klaus B. schrieb: > So langsam könnte das Programm aber auch mal wieder > probeweise auf backwards schalten Kann man die nicht unterbrechen, und später weitermachen? Wenn die Kühlschachteln durchkokeln, wird das auch nicht witzig.
ddRescue schreibt nun überraschend finished. Die Logdatei im Viewer geöffnet offenbart erstmal eine "grüne Wiese" mit vereinzelten roten Sprenkeln. Sieht harmlos aus.....dachte ich, aber wehe man zoomt rein.... Nun mach ich die Gerätschaften aus und erstelle morgen einen Spiegel von den geretteten Daten und auf der suche ich dann nach meinen Dateien. Vielen Dank erstmal an alle für die Hilfestellungen.
:
Bearbeitet durch User
Hallo, noch mal eine Aktualisierung. anders als erwartet ist es mir heute gelungen meine Daten nahezu vollständig von allen 3 Partitionen wiederherzustellen. Zuerst habe ich es mit Photorec versucht, aber das Programm hat nicht die gewünschten Resultate gebracht. Wie der Name schon vermuten lässt, hat es sich scheinbar hauptsächlich auf Bilder focussiert. Außerdem kann ich mich immer noch nicht mit diesen rudimentären Kommandozeilentools anfreunden, bei dem jeder kleinste Fehler erneut einen großen Schaden anrichten könnte. Der richtige Durchbruch gelang mir dann mit einem anderen Programm namens DMDE. Das war ein Hinweis aus einem anderen Forum und hat die 3 Partitionen mit Laufwerksnamen die ich vergeben hatte gefunden, alles schön sauber aufgelistet und mir statt kryptische Dateien die nachzubessern wären, die komplette Ordnerstruktur samt Inhalt auf eine andere Platte zurückgeschrieben. Ich will nicht verschweigen dass das Geld gekostet hat und zwar 18 Euro. Ddrescue hat aber zweifellos gute Vorarbeit geleistet. Nun ist wieder alles gut und ich habe mir vorgenommen zumindest die wichtigen Dinge in kleineren Zeitabständen zu sichern.
Dass Deine Platten alle überkopf arbeiten weißt Du aber schon. Das könnte der Grund sein, daas da kein Traffik zustande kommt. Manche Hersteller geben das frei. Aber das möchte ich nicht versuchen. Entweder andrsrum, oder hochkant, wie in einem Nas.
:
Bearbeitet durch User
Hallo Klaus B., Klaus B. schrieb: > anders als erwartet ist es mir heute gelungen meine Daten nahezu > vollständig von allen 3 Partitionen wiederherzustellen. Zuerst habe ich das freut mich zu hören! Damit weiß ich, dass wir beide unsere Zeit nicht umsonst investiert haben und ich Dir helfen konnte, Deine Daten wiederzubekommen. Für die anderen: Wir haben zusammen am Telefon einen idealtypischen Rettungsversuch begonnen. 1. Analyse der Defektplatte und der gebrauchten Kopierzielfestplatte mit smartmontools und CrystalDiskInfo. Befund: C00 hängende Sektoren auf der Kopierquelle. Kopierziel (ordentlich gebrauchte Festplatte) zeigte keine Auffälligkeiten. Klaus hat eine Kopierumgebung (Linux) auf einem nicht verwendeten Zweitrechner fertiggemacht, um "Abbruchdruck" zu vermeiden. 2. Entscheidung gefällt, nicht einen Datenretter zu konsultieren, sondern ddrescue zu benutzen. 3. ddrescue laufen lassen. 4. Imagedatei des Defektkandidaten noch einmal mit ddrescue geklont 5. Mit DMDE Daten gerettet. Klaus als Linux-Anfänger aber auch als besonnener Mensch hat sich mit der Kommandozeile vertraut gemacht. Punkt 1 haben wir zusammen gemacht, Punkt 2 habe ich am Ende des Telefonats erläutert und Punkt 4 empfohlen. Klaus hat dann selbstständig später bei Punkt 2 alleine weitergemacht.
:
Bearbeitet durch User
Thomas S. schrieb: > Dass Deine Platten alle überkopf arbeiten weißt Du aber schon. Das > könnte der Grund sein, daas da kein Traffik zustande kommt. Die Zeiten, wo die Einbaulage einer Festplatte irgendeine Relevanz hatte, sind schon sehr, sehr lange vorbei.
Harald K. schrieb: > Die Zeiten, wo die Einbaulage einer Festplatte irgendeine Relevanz > hatte, sind schon sehr, sehr lange vorbei. Das kann ja ruhig so sein. Wenn aber die HDD seit ewig gewohnt ist im 'normalen' Zustand zu arbeiten, und Du die dann aufs Kreuz legst,so nach vieleicht 10.000 Std., dann ist die diese Lage gewohnt. Plötzliche Lageänderung (ausgeschaltet natürlich) auf Überkopf kann sie dir übel nehmen, da die Lager und die Köpfe es nicht gewohnt sind. Kann sein, dass die sich neu justiert, aber ein Ausfall ist möglich.
Gewiss. Und dann wird eine Festplatte so langsam wie ein Diskettenlaufwerk. Weil sich die Lager eingeschliffen haben, oder die Festplatte das vom Gefühl her so gewöhnt ist. Vielleiht hilft es, den Feng-Shui-Berater hinzuzuziehen, oder eine getrocknete Hasenpfote über einem Beutel Heilerde zu schwenken. Oder die BGAs zu reballen, man weiß es nicht.
Harald, sei doch nicht so garstig ;-) Nun, ich werde demnächst ein paar Festplatten unbrauchbar machen, und bei der Gelegenheit mir die Lager mal ganz genau angucken. Wobei die Arme an denen die R/W Köpfe hängen liegen ja federnd auf der Platte, sodass sie einen möglichen Abrieb der Lager (au Backe) jedenfalls kompensieren könnten. Wo sich der mögliche Abrieb dann aufhält, möchten wir sicher gar nicht wissen. Über was für Toleranzbereiche sprechen wir denn hier überhaupt? Jedenfalls kann man 2 schöne halbrunde starke Magnete recyclen, die sehr gut in den etwas größeren China Antennenfuß (6cm d) passen. Der Originalmagnet darin ist der gleiche wie bei den Antennen mit (3cm d) den man früher meist mit den DVBT Sticks mitbekommen hat. Für das Auto (Lora) sind die jedenfalls nicht gut geeignet, es sei denn man fährt nur Stadtverkehr. Alkohol, oder Messeschnellweg wären jedenfalls tabu. Nicht so bei der HDD Antenne. :-) Ach ja, gute Fahrt dem Peter und viel Erfolg beim Router wiederbeleben.
:
Bearbeitet durch User
Harald K. schrieb: > Oder die BGAs zu reballen, man weiß es nicht. In den Datenblättern steht als Einbauempfehlung immer senkrecht oder flach, ob nach links oder rechts gekippt oder Deckel oben/unten ist egal. Nur schräg sollte sie nicht verbaut sein.
Angehängte Dateien:
-
Unsinn.png
130 KB
Frank D. schrieb: > In den Datenblättern steht als Einbauempfehlung immer senkrecht oder > flach,
Wastl schrieb: > Norbert schrieb: >> Unsinn.png > > Ein Datenblatt gilt für alle? Nein, natürlich nicht. Aber wenn du richtig gelesen hättest: Frank D. schrieb: > steht als Einbauempfehlung *immer* IMMER. Und da reicht eben ein einziges Negativ.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.