Datenverlust nach Upgrade auf OMV 4

    • OMV 4.x
    • Resolved

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

    • Datenverlust nach Upgrade auf OMV 4

      Hallo,

      ich habe gestern auf Openmediavault 4 geupdatet, weil ich gelesen hatte das dies schon sehr stabil läuft. Jetzt lese ich hier gerade das es noch eine Alpha ist.
      Jetzt steh ich natürlich wie der dümmste Mensch dar. Das letzte Backup ist 4 Monate her. Ich bekomm gerade ein Herzinfarkt. Ich hoffe jemand kann mir bei der Datenrettung helfen. Da ich leider in der Windowswelt groß geworden bin.

      Folgendermaßen bin ich vorgegangen.

      apt-get update
      apt-get upgrade
      omv-release-upgrade

      Das Setup ist Fehlerfrei durchgelaufen.

      omv-initsystem

      Dies ist nicht fehlerfrei durch gelaufen.

      Jetzt zu meinem Problem.

      Vorher hatte ich ein Raid6 mit 7 Festplatten. Jetzt sieht das Raid folgendermaßen aus. (sdg fehlt und raid 0?)

      Source Code

      1. root@nas:/var/log# mdadm -D /dev/md0
      2. mdadm: Unknown keyword INACTIVE-ARRAY
      3. /dev/md0:
      4. Version : 1.2
      5. Raid Level : raid0
      6. Total Devices : 6
      7. Persistence : Superblock is persistent
      8. State : inactive
      9. Name : nas:0 (local to host nas)
      10. UUID : 1a421ab2:2c0d85c7:8c535973:615e15db
      11. Events : 19035
      12. Number Major Minor RaidDevice
      13. - 8 64 - /dev/sde
      14. - 8 32 - /dev/sdc
      15. - 8 0 - /dev/sda
      16. - 8 80 - /dev/sdf
      17. - 8 48 - /dev/sdd
      18. - 8 16 - /dev/sdb
      Display All

      Beim Start des Servers kommt es zu Fehlermeldungen.


      Source Code

      1. Dez 28 18:44:41 nas kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)
      2. Dez 28 18:44:41 nas kernel: ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT5._GTF] (Node ffff90edab0e1348), AE_NOT_FOUND (20160831/psparse-543)
      3. Dez 28 18:44:41 nas kernel: ata2.00: configured for UDMA/133
      4. Dez 28 18:44:41 nas kernel: ata1.00: configured for UDMA/133
      5. Dez 28 18:44:41 nas kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)
      6. Dez 28 18:44:41 nas kernel: ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT4._GTF] (Node ffff90edab0e17d0), AE_NOT_FOUND (20160831/psparse-543)
      7. Dez 28 18:44:41 nas kernel: ata4.00: configured for UDMA/133
      8. Dez 28 18:44:41 nas kernel: scsi 0:0:0:0: Direct-Access ATA WDC WD40EFRX-68W 0A82 PQ: 0 ANSI: 5
      9. Dez 28 18:44:41 nas kernel: ata6.00: ATA-8: HGST HDN724040ALE640, MJAOA5E0, max UDMA/133
      10. Dez 28 18:44:41 nas kernel: ata6.00: 7814037168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
      11. Dez 28 18:44:41 nas kernel: ata5.00: ATA-8: HGST HDN724040ALE640, MJAOA5E0, max UDMA/133
      12. Dez 28 18:44:41 nas kernel: ata5.00: 7814037168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
      13. Dez 28 18:44:41 nas kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)
      14. Dez 28 18:44:41 nas kernel: ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT5._GTF] (Node ffff90edab0e1348), AE_NOT_FOUND (20160831/psparse-543)
      15. Dez 28 18:44:41 nas kernel: ata6.00: configured for UDMA/133
      16. Dez 28 18:44:41 nas kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)
      17. Dez 28 18:44:41 nas kernel: ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT4._GTF] (Node ffff90edab0e17d0), AE_NOT_FOUND (20160831/psparse-543)
      18. Dez 28 18:44:41 nas kernel: ata5.00: configured for UDMA/133
      Display All
      Dann steht auf dem Bildschirm: A start Job is running for dev-disk-by\x2lable-raid6.device
      Nach 1:30 startet das System

      Kann ich das System neu installieren (OMV3) und hoffen das ich das Raid wieder finde? Oder kann ich damit das Problem noch verschlimmern?
    • Hier noch Informationen die in anderen Threads immer gefragt werden.

      Platten sind:
      4x WDC WD40EFRX-68WT0N0
      3x HGST 4TB H3IKNAS40003272SE NAS SA3

      Source Code

      1. Linux nas 4.9.0-0.bpo.4-amd64 #1 SMP Debian 4.9.65-3+deb9u1~bpo8+1 (2017-12-23)

      Source Code

      1. NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
      2. sda 8:0 0 3,7T 0 disk
      3. └─md0 9:0 0 0 md
      4. sdb 8:16 0 3,7T 0 disk
      5. └─md0 9:0 0 0 md
      6. sdc 8:32 0 3,7T 0 disk
      7. └─md0 9:0 0 0 md
      8. sdd 8:48 0 3,7T 0 disk
      9. └─md0 9:0 0 0 md
      10. sde 8:64 0 3,7T 0 disk
      11. └─md0 9:0 0 0 md
      12. sdf 8:80 0 3,7T 0 disk
      13. └─md0 9:0 0 0 md
      14. sdg 8:96 1 7,5G 0 disk
      15. ├─sdg1 8:97 1 7,1G 0 part /
      16. ├─sdg2 8:98 1 1K 0 part
      17. └─sdg5 8:101 1 359M 0 part [SWAP]
      18. sdh 8:112 0 3,7T 0 disk
      19. └─sdh1 8:113 0 3,7T 0 part
      20. sdi 8:128 1 0 disk
      Display All

      Source Code

      1. /dev/sda: UUID="1a421ab2-2c0d-85c7-8c53-5973615e15db" UUID_SUB="4dc8628e-b364-e534-c23a-836c0b6e9e71" LABEL="nas:0" TYPE="linux_raid_member"
      2. /dev/sdb: UUID="1a421ab2-2c0d-85c7-8c53-5973615e15db" UUID_SUB="077086ae-6fb9-9b1e-9a3c-e45d35c61644" LABEL="nas:0" TYPE="linux_raid_member"
      3. /dev/sdc: UUID="1a421ab2-2c0d-85c7-8c53-5973615e15db" UUID_SUB="07e2a4c2-60c4-7a64-763b-25290ca4e0c1" LABEL="nas:0" TYPE="linux_raid_member"
      4. /dev/sdd: UUID="1a421ab2-2c0d-85c7-8c53-5973615e15db" UUID_SUB="179e2013-88f7-457a-6cba-88d6ea5da4e3" LABEL="nas:0" TYPE="linux_raid_member"
      5. /dev/sde: UUID="1a421ab2-2c0d-85c7-8c53-5973615e15db" UUID_SUB="bd8bc35c-ee87-1f4f-5842-95edc7e90e53" LABEL="nas:0" TYPE="linux_raid_member"
      6. /dev/sdf: UUID="1a421ab2-2c0d-85c7-8c53-5973615e15db" UUID_SUB="62fddb0f-fb19-fa10-2072-1e53630a52c7" LABEL="nas:0" TYPE="linux_raid_member"
      7. /dev/sdg1: UUID="4270c433-2be6-4c9f-a0bb-49cad6418d77" TYPE="ext4" PARTUUID="c25cc456-01"
      8. /dev/sdg5: UUID="7b754f7b-be3a-4474-b24b-db15610ace8c" TYPE="swap" PARTUUID="c25cc456-05"
      9. /dev/sdh1: PARTLABEL="primary" PARTUUID="c461f8ea-6414-4b78-bed1-26d174924a8c"
    • Du musst das RAID einfach via CLI aktivieren. Suche hierzu einfach im Forum wie das geht (es gibt dazu einen Post der erst einparken Tage alt ist) oder benutze Google.
      Absolutely no support through PM!

      I must not fear.
      Fear is the mind-killer.
      Fear is the little-death that brings total obliteration.
      I will face my fear.
      I will permit it to pass over me and through me.
      And when it has gone past I will turn the inner eye to see its path.
      Where the fear has gone there will be nothing.
      Only I will remain.

      Litany against fear by Bene Gesserit
    • Vielen Dank das ihr euch die Zeit nehmt mich zu unterstützen. Ich werde heute nach der Arbeit nach CLI suchen.
      Komisch finde ich nur dass das Laufwerk "sdg" nicht mehr im Raid auftaucht. Es handelt sich um ein HGST 4T. Vorher waren auch 7 Laufwerke im Raidverbund.

      Irgendwas stimmt da nicht. Gestern hatte ich noch folgende Ausgabe.

      Source Code

      1. sdg 8:96 1 7,5G 0 disk
      2. ├─sdg1 8:97 1 7,1G 0 part /
      3. ├─sdg2 8:98 1 1K 0 part
      4. └─sdg5 8:101 1 359M 0 part [SWAP]

      Heute nach einem Neustart scheint wieder alles in Ordnung. Smart meldet heute keine Fehler.

      Source Code

      1. sdg 8:96 0 3,7T 0 disk
      2. └─sdg1 8:97 0 3,7T 0 part

      Trotzdem scheint sie nicht mehr zum Verbund zu gehören.

      Source Code

      1. /dev/sda: UUID="1a421ab2-2c0d-85c7-8c53-5973615e15db" UUID_SUB="4dc8628e-b364-e534-c23a-836c0b6e9e71" LABEL="nas:0" TYPE="linux_raid_member"
      2. /dev/sdd: UUID="1a421ab2-2c0d-85c7-8c53-5973615e15db" UUID_SUB="179e2013-88f7-457a-6cba-88d6ea5da4e3" LABEL="nas:0" TYPE="linux_raid_member"
      3. /dev/sdf: UUID="1a421ab2-2c0d-85c7-8c53-5973615e15db" UUID_SUB="62fddb0f-fb19-fa10-2072-1e53630a52c7" LABEL="nas:0" TYPE="linux_raid_member"
      4. /dev/sde: UUID="1a421ab2-2c0d-85c7-8c53-5973615e15db" UUID_SUB="bd8bc35c-ee87-1f4f-5842-95edc7e90e53" LABEL="nas:0" TYPE="linux_raid_member"
      5. /dev/sdb: UUID="1a421ab2-2c0d-85c7-8c53-5973615e15db" UUID_SUB="077086ae-6fb9-9b1e-9a3c-e45d35c61644" LABEL="nas:0" TYPE="linux_raid_member"
      6. /dev/sdc: UUID="1a421ab2-2c0d-85c7-8c53-5973615e15db" UUID_SUB="07e2a4c2-60c4-7a64-763b-25290ca4e0c1" LABEL="nas:0" TYPE="linux_raid_member"
      7. /dev/sdg1: PARTLABEL="primary" PARTUUID="c461f8ea-6414-4b78-bed1-26d174924a8c"

      Muss ich trotzdem das Raid "einfach" via CLI aktivieren?
    • Hallo,

      das Problem lag wohl an einem inkompatiblen/defekten sata-controller. Die siebte Festplatte war bei jedem zweiten Start nicht verfügbar. Ich hatte nach dem Rebuild noch nie neu gestartet, deshalb trat der Fehler wohl genau bei dem Update auf Version 4 auf. Ich habe jetzt einen SataController eingebaut und die siebte Festplatte hierrüber angeschlossen. Jetzt ist sdg1 wieder bei jedem Neustart verfügbar. Nur leider wird sie nicht als Raidmember angezeigt.

      Source Code

      1. /dev/sda: UUID="1a421ab2-2c0d-85c7-8c53-5973615e15db" UUID_SUB="4dc8628e-b364-e534-c23a-836c0b6e9e71" LABEL="nas:0" TYPE="linux_raid_member"
      2. /dev/sdb: UUID="1a421ab2-2c0d-85c7-8c53-5973615e15db" UUID_SUB="077086ae-6fb9-9b1e-9a3c-e45d35c61644" LABEL="nas:0" TYPE="linux_raid_member"
      3. /dev/sdc: UUID="1a421ab2-2c0d-85c7-8c53-5973615e15db" UUID_SUB="07e2a4c2-60c4-7a64-763b-25290ca4e0c1" LABEL="nas:0" TYPE="linux_raid_member"
      4. /dev/sdd: UUID="1a421ab2-2c0d-85c7-8c53-5973615e15db" UUID_SUB="179e2013-88f7-457a-6cba-88d6ea5da4e3" LABEL="nas:0" TYPE="linux_raid_member"
      5. /dev/sde: UUID="1a421ab2-2c0d-85c7-8c53-5973615e15db" UUID_SUB="bd8bc35c-ee87-1f4f-5842-95edc7e90e53" LABEL="nas:0" TYPE="linux_raid_member"
      6. /dev/sdf: UUID="1a421ab2-2c0d-85c7-8c53-5973615e15db" UUID_SUB="62fddb0f-fb19-fa10-2072-1e53630a52c7" LABEL="nas:0" TYPE="linux_raid_member"
      7. /dev/sdh1: UUID="4270c433-2be6-4c9f-a0bb-49cad6418d77" TYPE="ext4" PARTUUID="c25cc456-01"
      8. /dev/sdh5: UUID="7b754f7b-be3a-4474-b24b-db15610ace8c" TYPE="swap" PARTUUID="c25cc456-05"
      9. /dev/sdg1: PARTLABEL="primary" PARTUUID="c461f8ea-6414-4b78-bed1-26d174924a8c"

      Source Code

      1. root@nas:~# mdadm --detail /dev/md0
      2. mdadm: Unknown keyword INACTIVE-ARRAY
      3. /dev/md0:
      4. Version : 1.2
      5. Raid Level : raid0
      6. Total Devices : 6
      7. Persistence : Superblock is persistent
      8. State : inactive
      9. Name : nas:0 (local to host nas)
      10. UUID : 1a421ab2:2c0d85c7:8c535973:615e15db
      11. Events : 19035
      12. Number Major Minor RaidDevice
      13. - 8 64 - /dev/sde
      14. - 8 32 - /dev/sdc
      15. - 8 0 - /dev/sda
      16. - 8 80 - /dev/sdf
      17. - 8 48 - /dev/sdd
      18. - 8 16 - /dev/sdb
      Display All

      Ich habe zwar schon jede Menge gelesen, aber irgendwie trau ich mich nicht hier einen Befehl einzutippen. Was mich wundert, dass das Raid als Raid0 angezeigt wird. Eigentlich handelt es sich bei dem System um ein Raid6 und eigentlich ich die siebte Platte noch mit in diesem Verbund.

      Muss ich jetzt erst die siebte Festplatte wieder zu dem Raid hinzufügen und dann das Raid reparieren?

      Kann mir bitte jemand einen bzw. mehrere Befehle vortippen? Ich habe zu viel Schiss um von irgendwelchen Seiten Befehle zu kopieren, die nicht 100 prozentig zu meinem Problem passen. Die Hilfe ist ja auch nicht umsonst, sondern gut für das Karma. ;)
    • /dev/sdg1 ist eher das Laufwerk, wo OMV installiert ist, wenn ich das richtig sehe (/dev/sdg1: PARTLABEL="primary")
      In Beitrag #2 wars noch /dev/sdh1: PARTLABEL="primary"

      Zeig mal

      Source Code

      1. fdisk -lu

      May @ryecoaaron will have a look at it?

      Ich würde vermutlich /dev/sdh ins Raid nehmen und den Raidtypen auf 6 ändern. Aber das nur mit nem aktuellen Backup...oder wenns mir jemand mit mehr Wissen bestätigt.
      --
      Get a Rose Tattoo...

      HP t5740 with Expansion and USB3, Inateck Case w/ 3TB WD-Green
      OMV 2.2.14 Stone burner i386|3.2.0-4-686-pae
    • Datenverlust nach Upgrade auf OMV 4

      Ist es nicht möglich Raids auf Basis von /dev/disk/by-id zu erstellen?

      Das wäre dann zumindest für jeden eindeutig und verändert sich auch nicht einfach so. Kenne mich mit Software-RAID nicht wirklich aus, deshalb die Frage.

      Gruß Hoppel
      ---------------------------------------------------------------------------------------------------------------
      frontend software - android tv | libreelec | win10 | kodi krypton
      frontend hardware - nvidia shield tv | odroid c2 | yamaha rx-a1020 | quadral chromium style 5.1 | samsung le40-a789r2 | harmony smart control
      -------------------------------------------
      backend software - debian | kernel 4.4 lts | proxmox | openmediavault | zfs raid-z2 | docker | emby | vdr | vnsi | fhem
      backend hardware - supermicro x11ssh-ctf | xeon E3-1240L-v5 | 64gb ecc | 8x4tb wd red | digital devices max s8
      ---------------------------------------------------------------------------------------------------------------------------------------
    • /dev/sdh looks like it is the OMV install drive since it has swap. No idea why /dev/sdg has a partition but maybe it wasn't wiped before adding it to the array.

      I would:

      mdadm --stop / dev / md0 [/ tt] [tt]mdadm --assemble --force --verbose /dev/md0 /dev/sd[ecafdbh]

      And please remember to backup the array. raid isn't backup.
      omv 4.1.6 arrakis | 64 bit | 4.16 backports kernel | omvextrasorg 4.1.7
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please read this before posting a question.
      Please don't PM for support... Too many PMs!
    • hoppel118 wrote:

      Is not it possible to create raids based on / dev / disk / by-id?

      That would be clear to everyone at least, and it will not change that way either. Do not really know me with RAID software, so the question.
      The drive letters changing aren't typically a problem for mdadm raid and wouldn't have helped here. There is a mdadm signature on each drive so it knows it is a part of an array.
      omv 4.1.6 arrakis | 64 bit | 4.16 backports kernel | omvextrasorg 4.1.7
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please read this before posting a question.
      Please don't PM for support... Too many PMs!
    • Hello,

      Ryecoaaron is right, sdh is my OMV install drive. I tryed to use your command. Sdg is still out of the raid. But now I have access to my data. At the moment I am making backups of the important ones. Thanks for your help. It will be a lessen to me. In the future i promise to backup my data every week. What can I do to add sdg in the right way?

      Source Code

      1. mdadm --stop /dev/md0
      2. mdadm: Unknown keyword INACTIVE-ARRAY
      3. mdadm: stopped /dev/md0
      4. mdadm --assemble --force --verbose /dev/md0 /dev/sd[ecafdbg]
      5. mdadm: Unknown keyword INACTIVE-ARRAY
      6. mdadm: looking for devices for /dev/md0
      7. mdadm: No super block found on /dev/sdg (Expected magic a92b4efc, got 00000000)
      8. mdadm: no RAID superblock on /dev/sdg
      9. mdadm: /dev/sdg has no superblock - assembly aborted
      10. root@nas:~# mdadm --assemble --force --verbose /dev/md0 /dev/sd[ecafdb]
      11. mdadm: Unknown keyword INACTIVE-ARRAY
      12. mdadm: looking for devices for /dev/md0
      13. mdadm: /dev/sda is identified as a member of /dev/md0, slot 0.
      14. mdadm: /dev/sdb is identified as a member of /dev/md0, slot 1.
      15. mdadm: /dev/sdc is identified as a member of /dev/md0, slot 2.
      16. mdadm: /dev/sdd is identified as a member of /dev/md0, slot 3.
      17. mdadm: /dev/sde is identified as a member of /dev/md0, slot 4.
      18. mdadm: /dev/sdf is identified as a member of /dev/md0, slot 5.
      19. mdadm: added /dev/sdb to /dev/md0 as 1
      20. mdadm: added /dev/sdc to /dev/md0 as 2
      21. mdadm: added /dev/sdd to /dev/md0 as 3
      22. mdadm: added /dev/sde to /dev/md0 as 4
      23. mdadm: added /dev/sdf to /dev/md0 as 5
      24. mdadm: no uptodate device for slot 6 of /dev/md0
      25. mdadm: added /dev/sda to /dev/md0 as 0
      26. mdadm: /dev/md0 has been started with 6 drives (out of 7).
      Display All


      Source Code

      1. root@nas:~# cat /proc/mdstat
      2. Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
      3. md0 : active raid6 sda[0] sdf[5] sde[4] sdd[3] sdc[2] sdb[1]
      4. 19534435840 blocks super 1.2 level 6, 512k chunk, algorithm 2 [7/6] [UUUUUU_]
      5. bitmap: 1/30 pages [4KB], 65536KB chunk


      Source Code

      1. root@nas:~# fdisk -lu
      2. Disk /dev/sda: 3,7 TiB, 4000787030016 bytes, 7814037168 sectors
      3. Units: sectors of 1 * 512 = 512 bytes
      4. Sector size (logical/physical): 512 bytes / 4096 bytes
      5. I/O size (minimum/optimal): 4096 bytes / 4096 bytes
      6. Disk /dev/sdb: 3,7 TiB, 4000787030016 bytes, 7814037168 sectors
      7. Units: sectors of 1 * 512 = 512 bytes
      8. Sector size (logical/physical): 512 bytes / 4096 bytes
      9. I/O size (minimum/optimal): 4096 bytes / 4096 bytes
      10. Disk /dev/sdc: 3,7 TiB, 4000787030016 bytes, 7814037168 sectors
      11. Units: sectors of 1 * 512 = 512 bytes
      12. Sector size (logical/physical): 512 bytes / 4096 bytes
      13. I/O size (minimum/optimal): 4096 bytes / 4096 bytes
      14. Disk /dev/sdd: 3,7 TiB, 4000787030016 bytes, 7814037168 sectors
      15. Units: sectors of 1 * 512 = 512 bytes
      16. Sector size (logical/physical): 512 bytes / 4096 bytes
      17. I/O size (minimum/optimal): 4096 bytes / 4096 bytes
      18. Disk /dev/sde: 3,7 TiB, 4000787030016 bytes, 7814037168 sectors
      19. Units: sectors of 1 * 512 = 512 bytes
      20. Sector size (logical/physical): 512 bytes / 4096 bytes
      21. I/O size (minimum/optimal): 4096 bytes / 4096 bytes
      22. Disk /dev/sdf: 3,7 TiB, 4000787030016 bytes, 7814037168 sectors
      23. Units: sectors of 1 * 512 = 512 bytes
      24. Sector size (logical/physical): 512 bytes / 4096 bytes
      25. I/O size (minimum/optimal): 4096 bytes / 4096 bytes
      26. Disk /dev/sdg: 3,7 TiB, 4000787030016 bytes, 7814037168 sectors
      27. Units: sectors of 1 * 512 = 512 bytes
      28. Sector size (logical/physical): 512 bytes / 4096 bytes
      29. I/O size (minimum/optimal): 4096 bytes / 4096 bytes
      30. Disklabel type: gpt
      31. Disk identifier: 79C6CC51-CBD2-40AA-8522-6953629A709C
      32. Device Start End Sectors Size Type
      33. /dev/sdg1 2048 7814035455 7814033408 3,7T Linux filesystem
      34. Disk /dev/sdh: 7,5 GiB, 7988051968 bytes, 15601664 sectors
      35. Units: sectors of 1 * 512 = 512 bytes
      36. Sector size (logical/physical): 512 bytes / 512 bytes
      37. I/O size (minimum/optimal): 512 bytes / 512 bytes
      38. Disklabel type: dos
      39. Disk identifier: 0xc25cc456
      40. Device Boot Start End Sectors Size Id Type
      41. /dev/sdh1 * 2048 14862335 14860288 7,1G 83 Linux
      42. /dev/sdh2 14864382 15599615 735234 359M 5 Extended
      43. /dev/sdh5 14864384 15599615 735232 359M 82 Linux swap / Solaris
      44. Disk /dev/md0: 18,2 TiB, 20003262300160 bytes, 39068871680 sectors
      45. Units: sectors of 1 * 512 = 512 bytes
      46. Sector size (logical/physical): 512 bytes / 4096 bytes
      47. I/O size (minimum/optimal): 524288 bytes / 2621440 bytes
      Display All
    • The superblock is missing. Maybe i did something wrong when i added the drive 3 weeks before. But it worked probably till the reboot.

      Source Code

      1. root@nas:~# mdadm --misc --examine /dev/sdg1
      2. mdadm: Unknown keyword INACTIVE-ARRAY
      3. mdadm: No md superblock detected on /dev/sdg1.

      Is this the right command to repair the raid? Or should I format the drive before?

      Source Code

      1. mdadm --add /dev/md0 /dev/sdg1
    • You are looking at the partition for the superblock. Check the drive - mdadm --misc --examine /dev/sdg

      If the array is working, I would wipe the drive then add it to the array.
      omv 4.1.6 arrakis | 64 bit | 4.16 backports kernel | omvextrasorg 4.1.7
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please read this before posting a question.
      Please don't PM for support... Too many PMs!
    • I formated the disk with fdisk and added it again. Everything works now. Thank you so much. :)

      Source Code

      1. root@nas:~# lsblk -a
      2. NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
      3. sda 8:0 0 3,7T 0 disk
      4. └─md0 9:0 0 18,2T 0 raid6 /srv/dev-disk-by-label-raid6
      5. sdb 8:16 0 3,7T 0 disk
      6. └─md0 9:0 0 18,2T 0 raid6 /srv/dev-disk-by-label-raid6
      7. sdc 8:32 0 3,7T 0 disk
      8. └─md0 9:0 0 18,2T 0 raid6 /srv/dev-disk-by-label-raid6
      9. sdd 8:48 0 3,7T 0 disk
      10. └─md0 9:0 0 18,2T 0 raid6 /srv/dev-disk-by-label-raid6
      11. sde 8:64 0 3,7T 0 disk
      12. └─md0 9:0 0 18,2T 0 raid6 /srv/dev-disk-by-label-raid6
      13. sdf 8:80 0 3,7T 0 disk
      14. └─md0 9:0 0 18,2T 0 raid6 /srv/dev-disk-by-label-raid6
      15. sdg 8:96 1 3,7T 0 disk
      16. └─md0 9:0 0 18,2T 0 raid6 /srv/dev-disk-by-label-raid6
      17. sdh 8:112 1 7,5G 0 disk
      18. ├─sdh1 8:113 1 7,1G 0 part /
      19. ├─sdh2 8:114 1 1K 0 part
      20. └─sdh5 8:117 1 359M 0 part [SWAP]
      21. root@nas:~# cat /proc/mdstat
      22. Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10]
      23. md0 : active raid6 sdg[7] sda[0] sdf[5] sde[4] sdd[3] sdc[2] sdb[1]
      24. 19534435840 blocks super 1.2 level 6, 512k chunk, algorithm 2 [7/7] [UUUUUUU]
      25. bitmap: 0/30 pages [0KB], 65536KB chunk
      Display All