HDD nach NAS-Crash auf RAW-Type

mehmet_b_90

Lieutenant
Registriert
Aug. 2013
Beiträge
552
Guten Abend liebe Community,

ich habe ein großes Problem, wobei ich noch das Licht am Ende des Tunnels sehe und ich nur nicht weiß wie ich dort hingelange.

Und zwar hatte ich vor ein paar Tagen ein Update auf mein NAS (von WDMyCloud) gezogen und installieren lassen. Nach dem Update fing das Problem direkt an, die HDD machte nur noch ratternde Geräusche in Minutentakt. Ich ließe sie über eine Nacht mal so laufen, da ich dachte, dass eventuell ein Check auf der HDD durchgeführt wird. Als ich am nächsten Morgen bemerkte, dass die Festplatte immer noch die gleichen Geräusche machte, steckte ich sie vom Strom ab und schloss die HDD jetzt per SATA-USB-Adapter an mein Laptop an.

Unter Windows 10 wird die Festplatte mit mehreren Partitionen als RAW gelesen. Daraufhin habe ich mir gleich mal TestDisk 7.0 gezogen und geschaut, ob er irgendwelche Partitionen erkennt, mit den ursprünglichen Dateisystemen. Siehe da, TestDisk erkennt, dass es ext4-Partitionen waren, so wie ich das aus dem Programm gelesen habe.

Meine Frage ist, wie repariere ich die ext4-Partition genau. Habe gegoogelt, finde aber keine Anleitung wie ich ein beschädigtes ext4-Dateisystem reparieren kann. Habe was mit Superblock und Inodes gelesen, komme damit aber nicht weiter. Ich könnte zwar die Daten mit PhotoRec oder Recuva Datei für Datei herstellen. Das ist aber für mich sehr unpraktisch, da die Daten in fast Hunderten von Ordnern organisiert waren.

Habe auch ein paar Screenshots und die Log-Datei von TestDisk mal rangehängt. Es handelt sich übrigens um die PhysicalDrive1.

Code:
Thu Mar 21 23:39:40 2019
Command line: TestDisk

TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
OS: Windows 8 (9200)
Compiler: GCC 4.9, MinGW 3.11
Compilation date: Apr 18 2015 13:02:07
ext2fs lib: none, ntfs lib: 10:0:0, reiserfs lib: none, ewf lib: 20120504, curses lib: pdcurses build  3401
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\PhysicalDrive0)=61865984000
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\PhysicalDrive1)=1801763774464
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\C:)=61238935552
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\D:)=1073741824
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\E:)=1073741824
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\F:)=2147483648
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\G:)=1073741824
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\H:)=1073741824
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\I:)=3992196029952
Hard disk list
Disk \\.\PhysicalDrive0 - 61 GB / 57 GiB - CHS 7521 255 63, sector size=512
Disk \\.\PhysicalDrive1 - 1801 GB / 1678 GiB - CHS 219051 255 63, sector size=512
Drive C: - 61 GB / 57 GiB - CHS 7445 255 63, sector size=512
Drive D: - 1073 MB / 1024 MiB - CHS 130 255 63, sector size=512
Drive F: - 2147 MB / 2048 MiB - CHS 261 255 63, sector size=512
Drive I: - 3992 GB / 3718 GiB - CHS 485356 255 63, sector size=512

Partition table type (auto): None
Drive I: - 3992 GB / 3718 GiB
Partition table type: None

Analyse Drive I: - 3992 GB / 3718 GiB - CHS 485356 255 63
file_win32_pread(192,16,buffer,3502290433(485356/215/45)) read err: read after end of file
file_win32_pread(192,1,buffer,3502290433(485356/215/45)) read err: read after end of file

recover_EXT2: s_block_group_nr=0/29744, s_mnt_count=3/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 974652928
recover_EXT2: part_size 3502256128
Current partition structure:
   P ext4                     0   0  1 485356 217 60 7797257871

search_part()
Drive I: - 3992 GB / 3718 GiB - CHS 485356 255 63

recover_EXT2: s_block_group_nr=0/29744, s_mnt_count=3/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 974652928
recover_EXT2: part_size 3502256128
     ext4                     0   0  1 485354 181 11 7797223424
     ext4 blocksize=4096 Large_file Sparse_SB, 3992 GB / 3718 GiB
file_win32_pread(192,8,buffer,3502256128(485354/181/12)) read err: read after end of file
file_win32_pread(192,8,buffer,3502256136(485354/181/20)) read err: read after end of file
file_win32_pread(192,3,buffer,3502256144(485354/181/28)) read err: read after end of file
[...]

Results
   P ext4                     0   0  1 485354 181 11 7797223424
     ext4 blocksize=4096 Large_file Sparse_SB, 3992 GB / 3718 GiB

interface_write()
   P ext4                     0   0  1 485354 181 11 7797223424
 
Write isn't available because the partition table type "None" has been selected.

TestDisk exited normally.

PS: Ich hätte einfach ein Backup vom Backup machen sollen. 😒

Danke im Vorraus.
MfG
mehmet1990
 

Anhänge

  • Inkedtestdisk_screenshot_2_LI.jpg
    Inkedtestdisk_screenshot_2_LI.jpg
    660,2 KB · Aufrufe: 393
  • Inkedtestdisk_screenshot_3_LI.jpg
    Inkedtestdisk_screenshot_3_LI.jpg
    626,2 KB · Aufrufe: 400
  • Inkedtestdisk_screenshot_LI.jpg
    Inkedtestdisk_screenshot_LI.jpg
    736,5 KB · Aufrufe: 411
Poste zur Sicherheit einen Screen von CrystalDiskInfo, um Probleme mit der Platte selbst ausschließen zu können. Dabei bitte das untere Fenster soweit aufziehen, dass alle Werte sichtbar sind.
 
Die HDD ist mit ext4 eingerichtet. Also nix was Windows von sich aus lesen kann.

Das was Du da treiben willst unter Windows mit testdisk kannst Du tun unter einem Linux was von sich aus mit ext4 klar kommt. Vorausgesetzt die WD hatte keine onboard Verschluesselung.
Wenn es wichtige Sachen sind, ueberlasse das einem Datenretter oder WD selbst.
https://support.wdc.com/warranty/datarecovery.aspx

BFF
 
Morgen,

also falls CrystalDisk sagt dass die HDD noch gut ist und die Werte das bescheinigen, sowie du die Daten nicht mehr benötigst auf der HDD.
Würde ich wie folgt vorgehen:

Code:
0. Download these files:
http://support.wdc.com/downloads.aspx?g=904 (Original firmware)
https://ftp.anionix.ru/WDMyCloud/WDMyCloud-Gen2/usbrecovery.tar.gz (WD Recovery + My miniOS)

1. Use any USB Flash drive, format it to FAT32 (Important!)
2. Unpack usbrecovery.tar.gz to this drive (You will get "boot" folder and 4 files inside)
3. Plug this USB drive to WD MyCloud, turn on power. Wait yellow-red (blinking) light.
4. Connect via Telnet (Search IP in your router, unde DHCP section.)
5. Format HDD if need:
parted /dev/sda
mklabel gpt
mkpart primary 1049kB 2149MB
mkpart primary 8591MB -1MB
mkpart primary 7517MB 8591MB
mkpart primary 2149MB 3222MB
mkpart primary 3222MB 4296MB
mkpart primary 4296MB 6443MB
mkpart primary 6443MB 7517MB
q
mkswap /dev/sda1
mkfs.ext4 /dev/sda3

6. Install original WD recovery and reboot:
mkdir -p /mnt/usb /mnt/root
mount /dev/sda3 /mnt/root
mount /dev/sdb1 /mnt/usb
cp -r /mnt/usb/boot /mnt/root/
cd /mnt/root/boot
rm uImage uRamdisk
mv uImage-wdrecovery uImage
mv uRamdisk-wdrecovery uRamdisk
cd /
umount /mnt/root /mnt/usb
sync
reboot -f

7. After reboot device get old IP address and accessable via Web-GUI (Recovery mode). Use original firmware (.bin file) here.

Done!


Hatte ich erst vor 2 Tagen bei einem bekannten seiner WD MyCloud 3TB gemacht nachdem dessen HDD das zeitliche gesegnet hatte. Kurzerhand eine 2TB HDD eingebaut und nach dieser Anleitung hat sie wieder perfekt funktioniert (dauert keine 10Min bis man die MyCloud wieder übers Webinterface ganz normal wie ein neugerät einrichten kann)
 
mehmet1990 schrieb:
wie repariere ich die ext4-Partition genau.
Wieso willst Du sie reparieren? Beim Retten kopiert man die Dateien immer auf einen anderen Datenträger und repariert nie InPlace, denn wenn das schief geht, hat man keine zweite Chance mehr.
mehmet1990 schrieb:
Ich könnte zwar die Daten mit PhotoRec oder Recuva Datei für Datei herstellen. Das ist aber für mich sehr unpraktisch, da die Daten in fast Hunderten von Ordnern organisiert waren.
Dann probiere es doch zuerst mit Testdisk, dies kann auch die Dateinamen und Ordnerstrukturen wiederherstellen.
mehmet1990 schrieb:
Ich hätte einfach ein Backup vom Backup machen sollen.
Wenn es nur ein Backup ist, also eine Sicherheitskopie von Daten die noch woanders stehen, dann kannst Du doch einfach neue Backups erstellen. Oder war es doch kein Backup? Dann solltest Du Dich nicht selbst betrügen indem Du ein Datengrab als Backup bezeichnest und hättest wirklich ein Backup der Daten auf dem NAS anlegen sollen. Die NAS haben ja extra USB Host Controller und Backupfunktionen um auf USB Platte Backups anzulegen. Die können i.d.R. auch mit NTFS formatiert sein und dann kann man das Backup sogar auf einem Windows Rechner auslesen.
 
Smurfy1982 schrieb:
Poste zur Sicherheit einen Screen von CrystalDiskInfo, um Probleme mit der Platte selbst ausschließen zu können. Dabei bitte das untere Fenster soweit aufziehen, dass alle Werte sichtbar sind.
Die Daten mit CrystalDiskInfo hatte ich bereits ausgelesen. Da war nichts auffälliges. Aber ich poste es heute Abend, nach der Arbeit trotzdem mal.
BFF schrieb:
Die HDD ist mit ext4 eingerichtet. Also nix was Windows von sich aus lesen kann.

Das was Du da treiben willst unter Windows mit testdisk kannst Du tun unter einem Linux was von sich aus mit ext4 klar kommt. Vorausgesetzt die WD hatte keine onboard Verschluesselung.
Ja weiß ich, dachte nur, dass TestDisk da was mit an Bord hat. Ich hatte es bereits auch unter Linux versucht einzulesen, aber nicht mit TestDisk. Das werde ich auch testen.
Key³ schrieb:
Morgen,

also falls CrystalDisk sagt dass die HDD noch gut ist und die Werte das bescheinigen, sowie du die Daten nicht mehr benötigst auf der HDD.
Würde ich wie folgt vorgehen:

[...]

Hatte ich erst vor 2 Tagen bei einem bekannten seiner WD MyCloud 3TB gemacht nachdem dessen HDD das zeitliche gesegnet hatte. Kurzerhand eine 2TB HDD eingebaut und nach dieser Anleitung hat sie wieder perfekt funktioniert (dauert keine 10Min bis man die MyCloud wieder übers Webinterface ganz normal wie ein neugerät einrichten kann)
Danke für den Tipp. Nach dem ich die Daten von der Festplatte retten konnte, werde ich mich sowieso an die NAS selbst machen und versuchen die auch wieder zum laufen zu bringen.
Holt schrieb:
Wieso willst Du sie reparieren? Beim Retten kopiert man die Dateien immer auf einen anderen Datenträger und repariert nie InPlace, denn wenn das schief geht, hat man keine zweite Chance mehr.
Ich möchte ja das Dateisystem versuchen zu reparieren.
Holt schrieb:
Dann probiere es doch zuerst mit Testdisk, dies kann auch die Dateinamen und Ordnerstrukturen wiederherstellen.
Mit TestDisk bin ich ja dran, weiß aber nicht genau wie ich vorgehen soll. Trotz Anleitungen auf der Homepage.
Holt schrieb:
Wenn es nur ein Backup ist, also eine Sicherheitskopie von Daten die noch woanders stehen, dann kannst Du doch einfach neue Backups erstellen. Oder war es doch kein Backup? Dann solltest Du Dich nicht selbst betrügen indem Du ein Datengrab als Backup bezeichnest und hättest wirklich ein Backup der Daten auf dem NAS anlegen sollen. Die NAS haben ja extra USB Host Controller und Backupfunktionen um auf USB Platte Backups anzulegen. Die können i.d.R. auch mit NTFS formatiert sein und dann kann man das Backup sogar auf einem Windows Rechner auslesen.
Vielleicht habe ich mich falsch ausgedrückt. Nein die Daten waren lediglich auf dem NAS. Und nein ich betrüge mich nicht selbst. Ich sehe meinen Fehler ein. Ich wollte seit Wochen die Daten vom NAS via USB-Port auf eine weitere ext. HDD kopieren, damit ich wirklich ein Backup habe. Habe es aber, wie es halt so oft ist, immer wieder hinausgezögert.
 
Zuletzt bearbeitet:
mehmet1990 schrieb:
Ich möchte ja das Dateisystem versuchen zu reparieren.
Das solltest Du aber nicht, wenn Du die Daten wirklich retten willst.
mehmet1990 schrieb:
Vielleicht habe ich mich falsch ausgedrückt. Nein die Daten waren lediglich auf dem NAS.
Wenn die Daten nur auf dem NAS standen, hast Du Dich falsch ausgedrückt und damit wohl auch selbst betrogen, denn Du hast es ja wohl für ein Backup gehalten. Es war aber keines. Das ich da so drauf rumreite hat den Grund, dass dies vielen Leuten so geht und am Ende sind nur die Leute selbst die Gearschten.
 
Zurück
Oben