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,
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
Obwohl: kein Backup, kein Mitleid. Gilt trotzdem.
Oliver
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.
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.
Habe Dir eine PM geschickt.
Keine Schreibenden Versuche.
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)
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?
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 ...
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.
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,
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.
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,
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
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.
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?
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!
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
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!
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. ☺
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)
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.
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.
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.
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.
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)
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.
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.
Es ist doch schon mehrmals geschrieben worden, dd/ddrescue
https://wiki.ubuntuusers.de/gddrescue
Beispiel (vorher mit cd ins Zielverzeichnis wechseln)
1 |
|
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.
Besser kapitulieren.
Kann man später immer noch!
Obwohl: kein Backup, kein Mitleid. Gilt trotzdem.
Es ist traurig, wenn man fehlendes Wissen durch Häme kompensieren muss!
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.
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!
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.
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.
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.
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.
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.
Richtig! kein Backup = kein Ärger
kein Alexander -> weniger Hintergrundrauschen auf µc.net
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!
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
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
Die deutsche Übersetzung ist etwas irreführend. Maximale Versuche sind die Leseversuche, es werden keine Fehler behoben.
Hallo Alexander,
Vollversion einer Software verlinkt die auf NTFS ziemlich gut carven
"auf NTFS ziemlich gut carven" Diese Formulierung ist ein Widerspruch in sich.
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:
Außerdem sagt Dir das Mapfile genau, wo die Fehler liegen. Diese Detailinformation liefert Dir die Auswertung der SMART-Parameter nicht.
"auf NTFS ziemlich gut carven" Diese Formulierung ist ein Widerspruch in sich.
Nö, siehe
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
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
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...
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 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
höchstens genau gleich groß (sans Dateisystem Verwaltungsinformation)
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?!
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.
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.
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)
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 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
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 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
Und jetzt deine Version:
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
9 |
|
10 |
|
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)
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…)
Isses denn so schwer zu verstehen?
Anscheinend. Deine Theorie in allen Ehren, bist Du Kernelentwickler?
Nur meine eigenen lsm.
Hier, versuch das einmal…
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
9 |
|
10 |
|
Damit schreibst du vier KiB Daten, vier KiB 0x00(sparse), vier KiB Daten. Und dann ein:
1 |
|
2 |
|
3 |
|
4 |
|
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 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
9 |
|
Was ist jetzt der Unterschied zu
1 |
|
2 |
|
(beides dateisystemabhängig)
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.
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.
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.
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"
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.
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.
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.
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.
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.
Das ist ein Container dessen Inhalt vom Betriebssystem verwaltet wird
Also eine reine Linuxgeschichte. Darwin zähle ich mal dazu.
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.
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.
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.
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?
…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.
Nun kannst du versuchen auf Biegen und Brechen das schlechtest taugliche Betriebssystem dafür zu nutzen…
... oder die bestmögliche NTFS Datenrekonstruktionssoftware empfehlen.
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. ;)
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.
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.
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.
Also eine reine Linuxgeschichte.
https://learn.microsoft.com/en-us/windows/win32/fileio/sparse-files
Darwin zähle ich mal dazu.
Aua.
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.
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.
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)
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?
Darwin zähle ich mal dazu.
Aua.
zeige uns den mount Befehl
- in einer Linux Konsole
- in einer MacOS Konsole
- in einer Windows Konsole
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.
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.
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.
.... 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?
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.
Worauf willst du eigentlich hinaus?
Auf gar nichts. Ist nicht wirklich ein Sinnvolles Argument. Mir war nur gerade langweilig.
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.
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?
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. :-)
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.
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. :)
Ja ja das universelle Dateisystemfeature das unter Linux umd Windows kompatibel ist.
Ist es aus Userland-Sicht tatsächlich.
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.
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.
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:
Norbert schrieb:
Worauf willst du eigentlich hinaus?
Auf gar nichts. Ist nicht wirklich ein Sinnvolles Argument. Mir war nur gerade langweilig.
Erkennbar. <grins>
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
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.
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.
Lies erst ein wenig.
Was denn? Das Linux und Mac von BSD geklaut haben, was wiederum von Unix geklaut hat?
und alle nutzen dasselbe ntfs
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.
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.
verkauft Paragon einen anderen NTFS-Treiber
nun ja anscheinend nicht mehr laut deinem Link
https://www.freebsd.org/ https://www.netbsd.org/ https://www.openbsd.org/ https://illumos.org/ https://www.openindiana.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 |
|
Bist du in der Lage die Quell-Festplatte zu identifizieren?
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,
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
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?
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.
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.
-
IMG_4356.JPG
(440 KB)
-
IMG_4357.JPG
(410 KB)
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.
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.
Hallo Klaus B.,
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.
- 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.
- Entscheidung gefällt, nicht einen Datenretter zu konsultieren, sondern ddrescue zu benutzen.
- ddrescue laufen lassen.
- Imagedatei des Defektkandidaten noch einmal mit ddrescue geklont
- 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.
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.
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.
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.
In den Datenblättern steht als Einbauempfehlung immer senkrecht oder flach,
-
Unsinn.png
(130 KB)
Norbert schrieb:
Unsinn.png
Ein Datenblatt gilt für alle?
Nein, natürlich nicht. Aber wenn du richtig gelesen hättest:
steht als Einbauempfehlung immer
IMMER. Und da reicht eben ein einziges Negativ.
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,
Im Ruhezustand. Sogar mit beeindruckendem Druck. Im Betrieb berühren die Köpfe die Platte nicht; wenn sie /das/ tun, war es das mit 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.
Etwaiger Abrieb (wovon auch immer) wird in einem im Luftstrom untergebrachten Filter aufgefangen. Das ist so ein kleines Kissen, das neben dem Plattenstapel meist lose in einer Halterung steckt. Nicht verwecheln mit dem viel feineren Luftfilter an der Druckausgleichsöffnung.
Den Lagern wirst Du keinerlei Verschleiß ansehen/anmerken, auch denen aus richtig alten Dauerläufern nicht.
Probiere mal Photorec aus. Wähle dort NTFS und welche Dateiendungen du sichern möchtest. So kannst du dann deine Daten, die nicht auf dem alten Backup aus 2024 enthalten sind retten und dann zusammenführen.
Probiere mal Photorec aus.
Wie wäre es, den Thread erstmal zu lesen?
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.