OMV findet Raid nicht mehr

Hallo zusammen,

ich hoffe Ihr könnt mir weiterhelfen.
Ich wollte diese Woche nun mal meine OMV Installation auf Version 5 heben.

Nach Anleitung Update gemacht. Leider haben die OMV-Extras sich nicht wieder sauber einspielen lassen.
Also was soll es Clean Install was oft einfach das Beste ist.

Erst einmal Proxmox (war bei OMV nicht installiert) installieren und die Platten durchgereicht.
Alle HDDs konnte ich auch sehen doch das Raid war nicht da.

Also die Main SSD Formatiert und OMV direkt installiert. Leider wieder das gleiche Ergebnis.
Alle Platten sind da und lassen sich einbinden.
Einzig das Raid als Mirror ist nicht da. Es lassen sich auch nicht die einzelnen Platten einhängen.

Hat jemand eine Idee, wie ich das Raid nun wieder in OMV sichtbar bekomme und es einbinden kann.

Besten Dank für eure Unterstützung

Hi,

leider kann ich im Syslog nichts finden.

Gruß
DJ

root@openmediavault:~# blkid
/dev/sdc1: LABEL="ServerDockerData" UUID="931296d0-1f39-4775-9ea6-2020a739f52c" UUID_SUB="b5c1581d-c627-4aed-a432-7d8c3aea82e1" TYPE="btrfs" PARTUUID="08bd6617-a0b4-42c6-a7ba-21e426de8691"
/dev/sdd1: LABEL="Seagate4t" UUID="c826f765-a4d3-4891-b65f-1157bb4d7f6f" TYPE="ext4" PARTUUID="dea07398-ee35-480c-a0fc-610523ef2539"
/dev/sdb1: UUID="ee5ac664-9438-4386-87a1-73ff4f8540fb" TYPE="ext4" PARTUUID="5dcdc595-01"
/dev/sdb5: UUID="49be9fa8-16e0-4cef-9c6f-5f02de961e15" TYPE="swap" PARTUUID="5dcdc595-05"
/dev/sde: UUID="9c5e72e6-c6c4-0b22-119a-cf87c5585946" UUID_SUB="8bde0652-d1f8-b83e-b149-d80d964c0648" LABEL="openmediavault:Datenleck" TYPE="linux_raid_member"
/dev/sda: PTUUID="5d248d22-e285-4a06-b7aa-27cbcdd9a51e" PTTYPE="gpt"

root@openmediavault:~# ls -l /dev/disk/by-id
insgesamt 0
lrwxrwxrwx 1 root root 9 Jul 29 13:31 ata-CT250MX500SSD1_1921E2051604 -> ../../sdc
lrwxrwxrwx 1 root root 10 Jul 29 13:31 ata-CT250MX500SSD1_1921E2051604-part1 -> ../../sdc1
lrwxrwxrwx 1 root root 9 Jul 29 13:31 ata-KINGSTON_SA400S37240G_50026B768235DA47 -> ../../sdb
lrwxrwxrwx 1 root root 10 Jul 29 13:31 ata-KINGSTON_SA400S37240G_50026B768235DA47-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Jul 29 13:31 ata-KINGSTON_SA400S37240G_50026B768235DA47-part2 -> ../../sdb2
lrwxrwxrwx 1 root root 10 Jul 29 13:31 ata-KINGSTON_SA400S37240G_50026B768235DA47-part5 -> ../../sdb5
lrwxrwxrwx 1 root root 9 Jul 29 13:31 ata-ST4000DM005-2DP166_WDH23EDS -> ../../sdd
lrwxrwxrwx 1 root root 10 Jul 29 13:32 ata-ST4000DM005-2DP166_WDH23EDS-part1 -> ../../sdd1
lrwxrwxrwx 1 root root 9 Jul 29 13:31 ata-ST4000VN008-2DR166_ZDH7YFWB -> ../../sda
lrwxrwxrwx 1 root root 9 Jul 29 13:31 ata-ST4000VN008-2DR166_ZDH7YW4T -> ../../sde
lrwxrwxrwx 1 root root 9 Jul 29 13:31 wwn-0x5000c500a87a6da9 -> ../../sdd
lrwxrwxrwx 1 root root 10 Jul 29 13:32 wwn-0x5000c500a87a6da9-part1 -> ../../sdd1
lrwxrwxrwx 1 root root 9 Jul 29 13:31 wwn-0x5000c500c362cec7 -> ../../sde
lrwxrwxrwx 1 root root 9 Jul 29 13:31 wwn-0x5000c500c36446d6 -> ../../sda
lrwxrwxrwx 1 root root 9 Jul 29 13:31 wwn-0x50026b768235da47 -> ../../sdb
lrwxrwxrwx 1 root root 10 Jul 29 13:31 wwn-0x50026b768235da47-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Jul 29 13:31 wwn-0x50026b768235da47-part2 -> ../../sdb2
lrwxrwxrwx 1 root root 10 Jul 29 13:31 wwn-0x50026b768235da47-part5 -> ../../sdb5
lrwxrwxrwx 1 root root 9 Jul 29 13:31 wwn-0x500a0751e2051604 -> ../../sdc
lrwxrwxrwx 1 root root 10 Jul 29 13:31 wwn-0x500a0751e2051604-part1 -> ../../sdc1
root@openmediavault:~#

root@openmediavault:~# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sdb1 during installation
UUID=ee5ac664-9438-4386-87a1-73ff4f8540fb / ext4 errors=remount-ro 0 1
# swap was on /dev/sdb5 during installation
UUID=49be9fa8-16e0-4cef-9c6f-5f02de961e15 none swap sw 0 0
# >>> [openmediavault]
/dev/disk/by-label/ServerDockerData /srv/dev-disk-by-label-ServerDockerData btrfs defaults,nofail,ssd 0 2
/dev/disk/by-label/Seagate4t /srv/dev-disk-by-label-Seagate4t ext4 defaults,nofail,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2
/srv/dev-disk-by-label-Seagate4t/ /export/Media none bind,nofail 0 0
# <<< [openmediavault]

Hi wtuppa

genau Datenleck war/ist das Raid

sde und sda sind die beiden Platten die das Raid bilden.
Werden auch von meiner OMV Installation gesehen.

mdstat:
root@openmediavault:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md127 : inactive sde[2](S)
3906887512 blocks super 1.2

unused devices: <none>
root@openmediavault:~#

Zitat von redjack

Das Raid1 ist offensichtlich defekt, hast Du ein Backup von deinem „Datenleck“?

CU
redjack

Natürlich nicht wirklich
Dafür hab ich doch das Raid damit mir eine Platte Verrauchen kann

Ja Raid ersetzt keine Backups

Ok aber die daten sind ja gespiegelt sollte ich nicht auf die Daten der funktionierenden Platte kommen.

Zitat von wtuppa

noch ein paar Versuche, was sagt mdadm --detail --scan
was mich bei der Ausgabe von "/proc/mdstat" gewundert hat, dass Linux meint, das /dev/sde die 3 Platte (wegen [2]) und als Spare im RAID erkannt wurde.

Es ist ein Raid1.

root@openmediavault:~# mdadm --detail --scan
INACTIVE-ARRAY /dev/md127 metadata=1.2 name=openmediavault:Datenleck UUID=9c5e72e6:c6c40b22:119acf87:c5585946
root@openmediavault:~#

Hi redjack,

was ist den die alternative ein Raid mit Daten ohne Zugriff.

Muß mir aber dann wirklich eine neue Backuplösung überlegen.
Wenn jemand eine Idee hat wie es hierzu gekommen ist, wäre ich und sicher auch andere daran interessiert.

Hi zusammen

So es hat nun etwas gedauert (24404 Sekunden). Ich habe die 2 nicht Raid Platten vom System gedrennt und nun das Backup der Platte gemacht.

root@openmediavault:~# ls -l /dev/disk/by-id
insgesamt 0
lrwxrwxrwx 1 root root 9 Jul 30 11:23 ata-KINGSTON_SA400S37240G_50026B768235DA47 -> ../../sdc
lrwxrwxrwx 1 root root 10 Jul 30 11:23 ata-KINGSTON_SA400S37240G_50026B768235DA47-part1 -> ../../sdc1
lrwxrwxrwx 1 root root 10 Jul 30 11:23 ata-KINGSTON_SA400S37240G_50026B768235DA47-part2 -> ../../sdc2
lrwxrwxrwx 1 root root 10 Jul 30 11:23 ata-KINGSTON_SA400S37240G_50026B768235DA47-part5 -> ../../sdc5
lrwxrwxrwx 1 root root 9 Jul 30 11:23 ata-ST4000VN008-2DR166_ZDH7YFWB -> ../../sda
lrwxrwxrwx 1 root root 9 Jul 30 11:23 ata-ST4000VN008-2DR166_ZDH7YW4T -> ../../sdb
lrwxrwxrwx 1 root root 9 Jul 30 11:23 wwn-0x5000c500c362cec7 -> ../../sdb
lrwxrwxrwx 1 root root 9 Jul 30 11:23 wwn-0x5000c500c36446d6 -> ../../sda
lrwxrwxrwx 1 root root 9 Jul 30 11:23 wwn-0x50026b768235da47 -> ../../sdc
lrwxrwxrwx 1 root root 10 Jul 30 11:23 wwn-0x50026b768235da47-part1 -> ../../sdc1
lrwxrwxrwx 1 root root 10 Jul 30 11:23 wwn-0x50026b768235da47-part2 -> ../../sdc2
lrwxrwxrwx 1 root root 10 Jul 30 11:23 wwn-0x50026b768235da47-part5 -> ../../sdc5
root@openmediavault:~# dd if=/dev/sdb of=/dev/sda bs=1M status=progress
4000716947456 bytes (4,0 TB, 3,6 TiB) copied, 24396 s, 164 MB/s
3815447+1 Datensätze ein
3815447+1 Datensätze aus
4000787030016 bytes (4,0 TB, 3,6 TiB) copied, 24404,1 s, 164 MB/s
root@openmediavault:~#

Zitat von redjack

Wir können gerne versuchen, die Erklärung zu finden, was in deinem Fall passiert ist. Dazu sind alle Vorgänge ab Installation nötig. Diese Infos findet man in diversen Logfiles.

Hast Du Dich schon entschieden, ob es ohne Backup weitergehen soll?

Ein nicht funktionierendes Raid mit Daten aber ohne Zugriff hast Du schon, die Alternativen sind

1. Ein funktionierendes Raid mit Daten.
2. Ein funktionierendes Raid ohne Daten.

Das Ziel ist natürlich Punkt 1.

Auch ich empfehle Dir ein Backup, wie von wtuppa empfohlen, zu erstellen.

Ein Raid schützt Dich gegen Hardwareausfälle, nicht mehr und nicht weniger. Aus diesem Grund kann ein RAID keine Backuplösung sein. Mach Dir bei deiner Backuplösung mal Gedanken über:

1. versehentliches löschen von Daten
2. Verschlüsselungs-Tojaner

dagegen schützt Dich kein Raid.

Und jetzt erneut die Frage, mit oder ohne Backup weitermachen?

CU
redjack

Alles anzeigen

Es muss dann wohl bei dem Update per Script aus dem OMV Forum passiert sein. Bei einer neuen Installation setze ich alle Platten die nicht benötigt werden Spannungsfrei.

Es wäre also schon bei einem Update der OMV Version zu empfehlen das Raid zu deaktivieren.?!

______________

_{@ All jetzt einfach die beiden letzten Punkte aus dem Link vonwtuppa ausführen oder empfihlt Ihr mir einen anderen Weg?}

Leider aktuell keine weitere 4TB Platte da. Kann aber auch eine bestellen.
Brauche ja noch eine für die Backups

Hallo ich habe versucht das Raid zu mounten nach der Anleitung

Creation Time : Mon Dec 30 10:04:35 2019
Raid Level : raid1
Raid Devices : 2

Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB)
Array Size : 3906887488 (3725.90 GiB 4000.65 GB)
Used Dev Size : 7813774976 (3725.90 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=48 sectors
State : clean
Device UUID : 8bde0652:d1f8b83e:b149d80d:964c0648

Internal Bitmap : 8 sectors from superblock
Update Time : Wed Jul 22 13:13:53 2020
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 32484136 - correct
Events : 30908

Device Role : Active device 0
Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
root@openmediavault:~# sudo mdadm -A -R /dev/md9 /dev/sdb

root@openmediavault:~# sudo mdadm -A -R /dev/md9 /dev/sdb
mdadm: /dev/sdb is busy - skipping
root@openmediavault:~#