Aktuelle Zeit: Mi 18. Jul 2018, 18:32



Ein neues Thema erstellen Auf das Thema antworten  [ 3 Beiträge ] 
 Nach Stromausfall LS-W2.0TGL/R1-EU mit RAID 1 defekt, wie Daten retten? 
Autor Nachricht
Foren-Neuling
Foren-Neuling

Registriert: Di 19. Jun 2018, 11:14
Beiträge: 2


Bedankte sich: 0 mal
Erhielt: 0 Danksagungen in 0 Beiträgen

Bedanke dich für den Beitrag 
Beitrag Nach Stromausfall LS-W2.0TGL/R1-EU mit RAID 1 defekt, wie Daten retten?
Hallo liebe Freunde der Daten-Redundanz,

nach dem letzten Stromausfall vor ca. 10 Tagen macht meine LS-W2.0TGL/R1-EU keinen Muks mehr.
Da das Netzteil keinen Startpin hat, sondern nur die 3 AC Leitungen und die 6 DC Leitungen ( 1x 5V 2x 12V 3x GND) konnte ich recht schnell verifizieren, dass auf jedenfall mal das Netzteil seinen Geist aufgegeben hat.
Das Netzteil wurde dann temporär durch ein Labornetzteil ersetzt und siehe da die NAS startet, jedoch fehlerhaft. Die rote LED blinkt 7 mal also muss noch irgendas am Mainboard defekt sein.

Nun bin ich schon mehrere Tage am rumsuchen und habe auch schon einige nützliche Beiträge gefunden jedoch komme ich nicht wirklich weiter.

Die NAS wurde als RAID 1 konfiguriert und benutzt das XFS Dateisystem.

Vorgehen:

Festplatte 1 der NAS mittels USB 2.0 to SATA/IDE Converter per USB an ein Ubuntu 14.04.2 LTS System angeschlossen.

Die Festplatte scheint soweit erstmal in Ordung zu sein laut smartctl
Code:
sudo smartctl -A /dev/sdb
Code:
=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   181   159   021    Pre-fail  Always       -       5933
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       87
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   051    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   001   001   000    Old_age   Always       -       80216
10 Spin_Retry_Count        0x0032   100   253   051    Old_age   Always       -       0
11 Calibration_Retry_Count 0x0032   100   253   051    Old_age   Always       -       0
12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       87
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       9
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       87
194 Temperature_Celsius     0x0022   127   103   000    Old_age   Always       -       23
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       193
200 Multi_Zone_Error_Rate   0x0008   100   253   051    Old_age   Offline      -       0


Nun wollte ich mir mal die Partitionen anschauen:
Code:
cat /proc/partitions
Code:
major minor  #blocks  name

  11        0    1048575 sr0
   8        0  976762584 sda
   8        1     102400 sda1
   8        2  204697600 sda2
   8        3          1 sda3
   8        5  770125824 sda5
   8        6    1832960 sda6
   8       16  976762584 sdb
   8       17    1004031 sdb1
   8       18    5004247 sdb2
   8       20          1 sdb4
   8       21    1004031 sdb5
   8       22  968759631 sdb6

Was mir hierbei schon auffällt, es fehlt sdb3. Das System benutzt die sda Platte.

Jetzt mal die Dateisysteme von der Raid-Platte anschauen:
Code:
sudo file -s /dev/sdb
/dev/sdb: x86 boot sector
sudo file -s /dev/sdb1
/dev/sdb1: Linux rev 1.0 ext3 filesystem data, UUID=891d4352-664b-49cd-a786-d9d6785f60a9 (needs journal recovery)
sudo file -s /dev/sdb2
/dev/sdb2: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs)
sudo file -s /dev/sdb4
/dev/sdb4: x86 boot sector
sudo file -s /dev/sdb5
/dev/sdb5: Linux/i386 swap file (new style), version 1 (4K pages), size 250975 pages, no label, UUID=00000000-0000-0000-0000-000000000000
sudo file -s /dev/sdb6
/dev/sdb6: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs)


Zudem wollte ich mir noch weitere Informationen über die Platte anschauen.
Code:
sudo fdisk -l

Die Daten für sda kommen direkt:
Code:
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 Köpfe, 63 Sektoren/Spur, 121601 Zylinder, zusammen 1953525168 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Festplattenidentifikation: 0x0fbe847c

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sda1   *        2048      206847      102400    7  HPFS/NTFS/exFAT
/dev/sda2          206848   409602047   204697600    7  HPFS/NTFS/exFAT
/dev/sda3       409604094  1953523711   771959809    5  Erweiterte
Partition 3 beginnt nicht an einer physikalischen Sektorgrenze.
/dev/sda5       409604096  1949855743   770125824   83  Linux
/dev/sda6      1949857792  1953523711     1832960   82  Linux Swap / Solaris

Die Daten für sdb kommen erst nach ca. 4-6 Sekunden:
Code:
Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 Köpfe, 63 Sektoren/Spur, 121601 Zylinder, zusammen 1953525168 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Festplattenidentifikation: 0x00000000

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sdb1              63     2008124     1004031   83  Linux
/dev/sdb2         2008125    12016619     5004247+  83  Linux
/dev/sdb4        12016620  1953520064   970751722+   5  Erweiterte
/dev/sdb5        12016683    14024744     1004031   82  Linux Swap / Solaris
/dev/sdb6        14024808  1951544069   968759631   83  Linux

Was mich hier stuzig macht, die Festplattenidentifikation: 0x00000000

Zu diesem Zeitpunkt spuckt mir mdstat das folgende aus:
Code:
sudo cat /proc/mdstat

Code:
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : inactive sdb2[0](S)
      5004160 blocks

md2 : inactive sdb6[0](S)
      968759552 blocks

md0 : inactive sdb1[0](S)
      1003904 blocks

md10 : inactive sdb5[0](S)
      1003904 blocks

unused devices: <none>

Dies sieht doch nun schon so aus als wäre das Raid bereits eingebunden aber noch inactive.

Hier noch weitere Informationen zu der sdb-Platte von mdadm:
Code:
sudo mdadm -E /dev/sdb

Code:
/dev/sdb:
   MBR Magic : aa55
Partition[0] :      2008062 sectors at           63 (type 83)
Partition[1] :     10008495 sectors at      2008125 (type 83)
Partition[3] :   1941503445 sectors at     12016620 (type 05)


Nun dachte ich ich könnte direkt /dev/md2 mounten:
Code:
sudo mkdir /mnt/raid
sudo mount -o ro /dev/md2 /mnt/raid

Beim mounten bekomme ich nun aber den Fehler:
Code:
mount: /dev/md2: Superblock konnte nicht gelesen werden

Dies liegt wahrscheinlich nun daran, das die Partition noch inactive ist, schätze ich mal.

Also versuche ich das Raid zu starten:
Code:
sudo mdadm --run /dev/md2
mdadm: started /dev/md2


Soweit so gut, also muss ich nun nochmal versuchen zu mounten:
Code:
sudo mount -o ro /dev/md2 /mnt/raid


Nun kommt zwar kein Fehler mehr aber der Befehl hängt und wird nicht mehr ausgeführt, die Console hängt so lange bis ich die Festplatte vom USB trenne.

Versuch 2 mittels manuellem assemblieren über die UUID

Code:
sudo mdadm --examine --scan
dauert recht lange gibt dann aber folgendes aus:
Code:
ARRAY /dev/md0 UUID=5d31407e:fdc096fb:b0b16801:9dcb29c1
ARRAY /dev/md1 UUID=2306d520:0b0c7440:6ab8aa7a:38df1956
ARRAY /dev/md10 UUID=3c4ca605:9c34a2cd:84aeaf8d:ef2298d0
ARRAY /dev/md2 UUID=81a4ff0d:ffd2e734:22cb26b5:7646a3fe


Diese Zeilen sind auch schon in /etc/mdadm/mdadm.conf enthalten.

Als nächstes wollte ich manuell assemblieren lassen, dazu habe ich die ARRAY Zeilen in /etc/mdadm/mdadm.conf mittels # auskommentiert, das System neu gestartet und die Platte erneut per USB angebunden, nun wurden keine /dev/mdX automatisch angelegt.

Wenn ich dann
Code:
sudo mdadm --assemble /dev/md0 /dev/sdb6

ausführe bekomme ich folgenden Fehler:
Code:
mdadm: /dev/md0 assembled from 1 drive - need all 2 to start it (use --run to insist).

Das Raid sollte/muss eigentlich ein RAID 1 sein, also sollte doch 1 Platte ausreichend sein?!

Code:
sudo cat /proc/mdstat
gibt dann wie zu erwarten folgendes aus:
Code:
md0 : inactive sdb6[0](S)
      968759552 blocks

unused devices: <none>


Also versuch ich es nun mal über die UUID.
Code:
sudo mdadm -S /dev/md0
sudo mdadm --assemble /dev/md2 --uuid=81a4ff0d:ffd2e734:22cb26b5:7646a3fe

mdadm: /dev/md2 has been started with 1 drive (out of 2).

Code:
sudo cat /proc/mdstat

Code:
md2 : active raid1 sdb6[0]
      968759552 blocks [2/1] [U_]

unused devices: <none>

So wie es nun aussieht ist das RAID nun direkt active.

Nun versuche ich zu mounten:
Code:
sudo mount -o ro /dev/md2 /mnt/raid


Beim Mounten gibt es nun aber die selben Probleme wie zuvor, der Befehl wird ewig ausgeführt und ich kann ihn auch nicht mit mit CTRL+C beenden. Erst wenn ich die Festplatte vom USB abstecke reagiert das System wieder.

Nun gäbe es ja noch die Möglichkeit mit xfs_repair die Partition reparieren zu lassen, aber da werden dann ja Daten auf die Platte geschrieben und das möchte ich zum jetzigen Zeitpunkt erstmal noch vermeiden.
Alternativ have ich auch schon etwas von Ddrescue gelesen, mit dem man dann die Festplate clonen kann und dann die Reparatur auf der geklonten Festplatte durchführen lassen kann.

Habe ich in meinem Vorgehen den grundlegend etwas falsch gemacht, falls ja wäre es wirklich super falls ihr mir auf die Sprünge helfen könntet und noch weitere Tipps für mich habt wie ich da nun am Besten weiter vorgehen kann.

Ich würde nun fast eine neue 1TB Platte kaufen und erstmal eine der Platten clonen und dann mit dem Clone weiter arbeiten?!
Bin für jeden Tipp dankbar!

Herzlichen Dank im Voraus,
Thomas


Mi 20. Jun 2018, 11:33
Profil
Dieser Werbeblock wird nur bei Gästen angezeigt
Globaler Moderator

Registriert: Mo 5. Apr 2010, 23:32
Beiträge: 6536
Bilder: 389

Bedankte sich: 174 mal
Erhielt: 849 Danksagungen in 786 Beiträgen

Bedanke dich für den Beitrag 
Beitrag Re: Nach Stromausfall LS-W2.0TGL/R1-EU mit RAID 1 defekt, wie Daten retten?
(S) steht für Spare

Die Platte wurde aus dem Raidverband geworfen.
Ich hatte mit der anderen Platte weitergetestet.
So richtig fit bin ich mit mdadm aber auch nicht.
Der UFSExplorer hat schon Dinge hinbekommen, an denen ich gescheitert bin.
Test den mal.


Mi 20. Jun 2018, 15:25
Profil Persönliches Album 
Foren-Neuling
Foren-Neuling

Registriert: Di 19. Jun 2018, 11:14
Beiträge: 2


Bedankte sich: 0 mal
Erhielt: 0 Danksagungen in 0 Beiträgen

Bedanke dich für den Beitrag 
Beitrag Re: Nach Stromausfall LS-W2.0TGL/R1-EU mit RAID 1 defekt, wie Daten retten?
Ich hatte von dem UFS Explorer auch schon gelesen, dachte mir aber das ich das mit Linux und mdadm auch hinbekommen sollte zumal die verschiedenen UFS Explorer ja kostenpflichtig sind, zwar nicht sehr teuer, je nach Version ohne Steuer zwischen 21,95€ und 199,95€.

Habe nun also trotzdem mal die verschiedenen Versionen von UFS Explorer (Standard Recovery, RAID Recovery, Professional Recovery) getestet und die Platte wird anstandslos erkannt und ich kann OHNE vorherige Raid-Konstruktion direkt auf die SGI XFS Partition zugreifen und die Daten auslesen. Wichtige kleinere Dokumente (< 768 kb [RAID Recovery]) konnte ich somit schon mal sichern, was mir eine deutlich bessere Nacht verschafft hat :)

Ich würde nun aber trotzdem gerne dem Problem noch auf die Schliche kommen, es muss doch möglich sein mit Linux auf die Partition zugreifen zu können...
Vielleicht hat ja noch jemand einen Tipp ich werde auch mal noch weiter testen.
Schönen Tag noch.


Do 21. Jun 2018, 11:43
Profil
Beiträge der letzten Zeit anzeigen:  Sortiere nach  

Ein neues Thema erstellen Auf das Thema antworten  [ 3 Beiträge ] 





Suche nach:

Ähnliche Beiträge

LS-WX2.0TL/R1 nach Stromausfall defekt?
Forum: Buffalo Linkstation Duo
Autor: johannes-e
Antworten: 17
Linkstation Live Daten retten !!
Forum: Buffalo Linkstation Pro/Live mit BitTorrent
Autor: oxygen8
Antworten: 3
Daten trotz EM-Status retten?
Forum: Buffalo Linkstation Pro/Live mit BitTorrent
Autor: oxygen8
Antworten: 3
LS-QVL läßt sich nicht einschalten - Daten retten???
Forum: Buffalo Linkstation Quad
Autor: oxygen8
Antworten: 23
RAID 1 verschwunden - wie komme ich an meine Daten?
Forum: Buffalo Linkstation Pro Duo
Autor: oxygen8
Antworten: 10

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 22 Gäste


Deine Berechtigungen

 Du darfst keine neuen Themen in diesem Forum erstellen.
 Du darfst keine Antworten zu Themen in diesem Forum erstellen.
 Du darfst deine Beiträge in diesem Forum nicht ändern.
 Du darfst deine Beiträge in diesem Forum nicht löschen.
 Du darfst keine Dateianhänge in diesem Forum erstellen.

Gehe zu:  


| NAS-Hilfe.de - die deutsche Buffalo NAS-Hilfe Seite | Mein Blog - Bloggen Querbeet... | Powered by phpBB © phpBB Group. | Deutsche Übersetzung durch phpBB.de | Impressum |