Raid 5 clean, degraded kann aber keine Dateien davon wegholen

    • OMV 4.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Raid 5 clean, degraded kann aber keine Dateien davon wegholen

      MEin Raid 5 besteht laut OMV auf SDB,SDC,SDD ein SDA habe ich aber auch. Es wird also immer mit 3 out of 4 gestartet. Ich gehe nun davon aus das eine Festplatte kaputt gegangen ist und ich nun meine Daten eigentlich wiederhaben möchte. Dafür müsste doch die SDA angezogen werden oder sehe ich das falsch. Was muss ich machen um wieder ein funbktionierendes Raid zu haben und meine Daten wegzusichern?
    • Eine von deinen Platten müsste die Systemplatte sein. Die ist dann kein Member des Raid-Verbundes. Solange nur eine Platte davon den Geist aufgegeben hat, ist der Status zwar "Degraded", trotzdem solltest du in der Lage sein, deine Daten noch vom Raid auf einen anderen Datenträger zu kopieren. Erst wenn das erfolgt ist, würde ich versuchen, das Raid zu reparieren.

      Wie viele Threads hier im Forum belegen, ist das nicht so trivial und schon mancher hat dann seine Daten dabei endgültig ins IT-Nirvana geschickt.
      OMV 3.0.90 (Gray style)
      ASRock Rack C2550D4I - 16GB ECC - 6x WD RED 3TB (ZFS 2x3 Striped RaidZ1)- Fractal Design Node 304
    • Ich habe eine seperate Festplatte für das System und eigentlich die vier Platten (sda-d) für das Raid 5 angedacht. Da wundert es mich halt das b-c angezeigt werden aber a nicht. Im Log steht dann aber started with 3 of 4 drives (ungefähr so) Es ist halt so das sich einige Dateien noch kopieren lassen viele aber nicht mehr und deswegen bin ich halt schon jetzt aufgeschmissen ... hoffentlich nicht ganz.

      The post was edited 2 times, last by Drake008 ().

    • Hi,
      also wenn bei einem Raid5 nur eine Platte ausfällt, dann hast du noch vollen Zugriff auf alle Daten, da die defekte Platte durch die Redundanzinformation auf den anderen Platten ersetzt wird.
      Wenn sich trotzdem bestimmte Dateien nicht (mehr) kopieren lassen, dann muss das andere Gründe haben. Ggf. war die Datei vorher schon korrupt. Raid 5 hat keine Funktionalität zur Überprüfung der Datenintegrietät.
      OMV 3.0.90 (Gray style)
      ASRock Rack C2550D4I - 16GB ECC - 6x WD RED 3TB (ZFS 2x3 Striped RaidZ1)- Fractal Design Node 304
    • Es wird dir jetzt nicht helfen. Wenn Sie jedoch E-Mail-Informationen in System, Benachrichtigung eingeben und die entsprechende Auswahl auf der Registerkarte "Benachrichtigungen" (Dateisystem, Software-RAID und SMART) treffen, wird das System Sie benachrichtigen, bevor die Dinge außer Kontrolle geraten. (Aktivieren Sie auch Storage, SMART und planen Sie kurze Tests für drehende Laufwerke.)

      Das System wird Ihnen helfen, aber Sie müssen es zulassen.

      Bedauert den Datenverlust.
      Good backup takes the "drama" out of computing
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
      2nd Data Backup: OMV 3.0.99, R-PI 2B, 16GB boot, 4TB WD USB MyPassport - direct connect (no hub)
    • Drake008 wrote:

      Dann bin ich woihl aufgeschmissen. Scheinen ja dann zwei Platten kaputt zu sein :(
      Hi,

      nein - wenn zwei Platten kaputt wären, dann könntest Du das Filesystem überhaupt nicht mehr mounten.

      Ich weiß nicht, seit wann das so ist - aber früher war das mal so, daß einem OMV immer ein degraded Array hingestellt hat. Das war ein bissl unglücklich war aber glaub ich noch in OMV 1 ...

      Die Frage wäre für mich, warum die vierte Platte aus dem Raid geflogen ist.

      Automatisch baut er nur eine Hot Spare ein - die Du aber mit vier Platten sicher nicht hast.

      Gruß
      Ser
      Everything is possible, sometimes it requires Google to find out how.
    • Nein das denke ich auch.

      ICh versuche euch mal zu erklären wie komisch das NAS sich verhält.

      Ich kann ein paar Dateien runterladen. Kommt das NAS anscheinend an eine kaputte Datei bleibt es dort hängen und nach kurzer Zeit hängt es sich total ab. ICh sehe dann die Verzeichnisse und Dateien kann aber keine Dateien mehr kopieren. So ist der Status bei mir momentan. Ich habe die Platten seperat mal an einem Rechner mit den Seatools getestet (es sind Samsung und Seagate Platten). Die Samsung Platten laufen gut durch. Die Seagateplatten klacken immer als ob der Strom weggeht und dann wiederkommt.


      img105.imagevenue.com/img.php?…7_laufwerke_122_441lo.jpg
      img121.imagevenue.com/img.php?…_laufwerke2_122_383lo.jpg

      Kann ich das RAID irgendwie komplett löschen per Commandkonsole und dann wieder ein neues erstellen?

      The post was edited 3 times, last by Drake008 ().

    • SO ich habe jetzt mal alle Platten mit deren Testprogramm durchgeprüft und die haben alle keine Fehler. Wie kommt es dann, dass das Raid5 nicht aktiviert wird bzw. degraded ist? Es ist ahlt merkwürdig wenn ich mir den Status anzeigen lasse dann habe ich SDB,SDC,SDD. SDA ist nirgends zusehen nur ein removed steht da noch.

      Source Code

      1. root@Schrank:~# cat /proc/mdstat
      2. Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
      3. md127 : active raid5 sdb[1] sdd[3] sda[2]
      4. 2929893888 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [_UUU]
      5. unused devices: <none>



      Source Code

      1. root@Schrank:~# blkid
      2. /dev/sdd: UUID="79d94d6c-7030-af53-7c7b-1956c4564987" UUID_SUB="cec25e6e-e6f8-bc06-f4c7-d33148c0f9bd" LABEL="NAS:Datengrab" TYPE="linux_raid_member"
      3. /dev/sdb: UUID="79d94d6c-7030-af53-7c7b-1956c4564987" UUID_SUB="175ea7f3-8e75-caaa-a728-75435266c481" LABEL="NAS:Datengrab" TYPE="linux_raid_member"
      4. /dev/sdc: UUID="79d94d6c-7030-af53-7c7b-1956c4564987" UUID_SUB="5c0b0f88-e883-6acd-ce5d-bb2b95a4bb9b" LABEL="NAS:Datengrab" TYPE="linux_raid_member"
      5. /dev/sde1: UUID="17309ced-091b-40a7-881b-67a91d431041" TYPE="ext4" PARTUUID="c34922aa-01"
      6. /dev/sde5: UUID="b78acade-134e-4bd7-89ff-b1da69fc43db" TYPE="swap" PARTUUID="c34922aa-05"
      7. /dev/sda: UUID="79d94d6c-7030-af53-7c7b-1956c4564987" UUID_SUB="5366aea8-9876-f78d-a23e-99e6ad6fea31" LABEL="NAS:Datengrab" TYPE="linux_raid_member"
      8. /dev/md127: LABEL="Daten" UUID="3cefb1ab-440e-4d2f-8aec-9e1c7ee6b79a" TYPE="ext4"

      Source Code

      1. root@Schrank:~# mdadm --detail --scan --verbose
      2. ARRAY /dev/md127 level=raid5 num-devices=4 metadata=1.2 name=NAS:Datengrab UUID=79d94d6c:7030af53:7c7b1956:c4564987
      3. devices=/dev/sda,/dev/sdb,/dev/sdd

      Source Code

      1. root@Schrank:~# fdisk -l | grep "Disk "
      2. Disk /dev/sdd: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
      3. Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
      4. Disk /dev/sdc: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
      5. Disk /dev/sde: 29.3 GiB, 31488000000 bytes, 61500000 sectors
      6. Disk identifier: 0xc34922aa
      7. Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
      8. Disk /dev/md127: 2.7 TiB, 3000211341312 bytes, 5859787776 sectors
      9. root@Schrank:~#

      The post was edited 2 times, last by Drake008 ().