S: Hilfe bei LED Anzeige

mega-hz

New member
Hallo,

ich habe einen PI4 mit 4x1TB HDDs als RAID10 als Backup Server aufgebaut.

Nun suche ich jemanden der mir (z.B. mit Python) hilft, den Status der einzelnen Platten sowie den Status des RAID-Verbundes
auszulesen und an 4 GPIOs LEDs anzusteuern. diese sollten dann HI werden eine/die Platte fehlerhaft ist.

Würde mich über Deine Hilfe sehr freuen!

Gruß,
Wolfram.
 
mh über RAID würde ich so was nie machen weil,
wenn mal eine HDD ausfällt ist alles unwiderruflich weg Daten Rettung problematisch falls das überhaupt noch geht ,
lieber 2 x 2 TB laufen lassen .
z.B die 1. als Backup Platte die 2. zur Sicherung der 1. HDD auf HDD 2., doppelt gesichert ist immer besser als nur 1 x ,
wenn man wirklich Wichte Sachen hat ist so was Wichtig .
Wenn du auch mal Filme sichern willst was sich so im laufe der Jahren so ansammelt und man nicht löschen will brauchst mehr als 4 TB , z.b. 2 x 6 TB .
 
Zuletzt bearbeitet:
Selbst bei nur zwei Platten im Raid 1 sind die Daten ja nicht gleich weg, wenn eine HDD aussteigt - das ist die Idee hinter dem Raid, daß selbst bei Totalausfall einer HDD die Datenverfügbarkeit weiter gewährleistet ist und man einfach die defekte Platte herausnehmen und durch eine neue ersetzen kann.
Wichtiger ist die Erkenntnis, daß ein Raid kein Backup ist, sondern die Daten im Raid noch mindestens einmal auf ein nicht dauerhaft damit verbundenes Speichermedium gesichert werden sollten.
 
Zuletzt bearbeitet:
ich habe einen PI4 mit 4x1TB HDDs als RAID10 als Backup Server aufgebaut.
Ganz ehrlich: kann man machen, wenn man gerne bastelt; ein kommerzielles NAS ist zwar teurer, aber kann auch mehr als OpenMediaVault oder was Du da genommen hast. Vor allem ist die Warnung bei Plattenfehlern integriert.
Ich bastele ja gern mit den Pi’s, aber für den NAS setze ich lieber auf eine professionelle Lösung.
Was für Festplatten hast Du da eigentlich genommen?
 
Also die Warnungen und Benachrichtigungen bei Plattenfehlern ist auch bei OMV integriert. An sich steht das kommerziellen Sachen in nichts nach.

Ist aber wie @Stationary sagt halt viel Eigeninitiative dabei. Lief aber jahrelang Rock stable hier.

Und LED anzeigen muss man ja drauf achten, ich würde eher auf Benachrichtigungen setzen, egal welches System man einsetzt.
 
Moinsen,
ich würde mich da auch nicht an den LEDs abarbeiten (oder rennst du immer hin und guckst nach > IT by Turnschuhmanagement?) ;)
Lass dir eine Nachricht senden, wenn die Platten zu viele Fehler aufzeigen, Mail, Pushnachricht...das macht sich in meiner Erfahrung bemerkbarer. OMV sollte das alles können. :)
 
Um mal beim Thema zu bleiben: smartctl wäre wohl erstmal das Tool der Wahl, dann mittels smartd oder einem Bash-Script über einen Cronjob in regelmässigen Intervallen abfragen, ggf. nach bestimmten Werten Ausschau halten und bei Fehler - wie auch immer das funktioniert, von hab ich keine Ahnung - das am Raspi umsetzen, was Du möchtest. Allerdings schliessen ich mich da eher @the other an, eine "aktive Benachrichtigung" wäre vermutlich auffälliger.

smartctl -A /dev/sda
Bash:
=== 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       -       10
  3 Spin_Up_Time            0x0027   171   171   021    Pre-fail  Always       -       6408
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       32
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   100   253   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   035   035   000    Old_age   Always       -       47663
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       30
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       21
193 Load_Cycle_Count        0x0032   001   001   000    Old_age   Always       -       1164199
194 Temperature_Celsius     0x0022   114   099   000    Old_age   Always       -       36
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   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       0

So könnte man ggf. auf gewünschten Zeilen filtern und schauen, was der Wert in der letzten Spalte so hergibt und ab wann man diesbezüglich informiert werden möchte.

Was den Raid-Status angeht, da kommt es darauf an, wie Du den zusammengebastelt hast, aber vermutlich einfach via mdadm. Da könnte man ggf. z.B. die /proc/mdstat überprüfen (ist etwas ausgefallen, wird es i.d.R. via "_" gekennzeichnet, also z.B. "U_" bei 2 Festplatten), wenn es blöd läuft (oder in diesem Fall "genau richtig") sieht es z.B. so aus:

cat /proc/mdstat
Bash:
Personalities : [raid1] [raid0] [linear] [multipath] [raid6] [raid5] [raid4] [raid10]
md5 : active raid1 sdd[0]
      1953513424 blocks super 1.2 [2/1] [U_]

md10 : active raid0 md5[0] md6[1]
      3907023872 blocks super 1.2 512k chunks

md6 : active raid1 sda[0]
      1953513424 blocks super 1.2 [2/1] [U_]

md1 : active raid1 sdb2[2] sdc2[1]
      61996984 blocks super 1.2 [2/2] [UU]

md0 : active raid1 sdb1[2] sdc1[1]
      523252 blocks super 1.2 [2/2] [UU]

unused devices: <none>

Eventuell auch die Verbünde via mdadm --detail /dev/<verbund> in Augenschein nehmen, das sieht dann so aus:

mdadm --detail /dev/md10 (in Ordnung)
Bash:
/dev/md10:
           Version : 1.2
     Creation Time : Sat Aug 25 14:09:51 2012
        Raid Level : raid0
        Array Size : 3907023872 (3726.03 GiB 4000.79 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

       Update Time : Sat Aug 25 14:09:51 2012
             State : clean
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

            Layout : -unknown-
        Chunk Size : 512K

Consistency Policy : none

              Name : dedu0s001:10  (local to host dedu0s001)
              UUID : 03e6aaba:93999e06:c0cae74e:a3354019
            Events : 0

    Number   Major   Minor   RaidDevice State
       0       9        5        0      active sync   /dev/md/5
       1       9        6        1      active sync   /dev/md/6

mdadm --detail /dev/md5 (defekt)
Bash:
/dev/md5:
           Version : 1.2
     Creation Time : Sat Aug 25 14:09:17 2012
        Raid Level : raid1
        Array Size : 1953513424 (1863.02 GiB 2000.40 GB)
     Used Dev Size : 1953513424 (1863.02 GiB 2000.40 GB)
      Raid Devices : 2
     Total Devices : 1
       Persistence : Superblock is persistent

       Update Time : Fri Feb  2 05:14:09 2024
             State : clean, degraded
    Active Devices : 1
   Working Devices : 1
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : resync

              Name : dedu0s001:5  (local to host dedu0s001)
              UUID : a1283447:9d7c6dcd:555ef2f7:16fd9046
            Events : 63252848

    Number   Major   Minor   RaidDevice State
       0       8       48        0      active sync   /dev/sdd
       -       0        0        1      removed

Wie man sieht, werden hier die defekten Platten auch als "removed" gekennzeichnet bzw. sind die nicht nur "generell defekt", sondern auch schon "ausgestiegen".

Ich persönlich würde es vermutlich irgendwie versuchen via Bashscript zu lösen, weil ich davon noch am meisten Ahnung habe (was trotzdem nicht "viel" ist, aber immerhin mehr, als von allem anderen 😅). Wenn Du Python kannst, macht es sicherlich Sinn, wenn Du es darüber machst. Nur wie gesagt, bei den Raspi-spezifischen Ansteuerung kann ich eher nicht helfen.

mh über RAID würde ich so was nie machen weil
Guckst Du hier: https://de.wikipedia.org/wiki/RAID...

Raid erhöht grundsätzlich die "Verfügbarkeit" und ist - wie bereits erwähnt - kein Backup. Ein Raid10 (1+0) erhöht indes auch die Performance (Raid1: Mirror (1:1 Kopie), Raid0: Striping (Daten werden über 2 Festplatten "verteilt", dadurch die Performance-Steigerung).

EDIT: Hier gibt es natürlich auch noch 2 leicht verständliche Artikel zu den Themen Backup/Raid ;)

Backup: https://www.heimnetz.de/anleitungen/theorie/sicherheit-virtuell/backups-im-heimnetz-eine-uebersicht/
Raid: https://www.heimnetz.de/anleitungen/theorie/speichermedien/raid-allgemeine-informationen/
 
Zuletzt bearbeitet:
Das RAID10 besteht aus 4x Seagate Barracuda Sata HDDs.
Es dient als zusätzliches File-Backup, "richtige" Backups laufen per Acronis auf einer anderen Platte und anderem System.

Push Benachrichtigungen usw. möchte ich ausdrücklich NICHT und da wo der PI steht sehe ich ihn jeden Tag.
Daher ist es für mich am praktischen, wenn ich sehe, ob da alles "grün" ist oder rot.

Die GPIOs per Python ansteuern ist für mich kein Problem, jedoch Ausgaben filtern und auswerten schon.

OMV kommt für mich nicht mehr in Frage, das versaut mir das ganze System viel zu sehr. (spreche aus Erfahrungen)
Auf dem PI ist Cockpit installiert damit kann man das was man so braucht auch problemlos machen.

Das RAID selber habe ich per fdisk/mdadm angelegt.
 

Zurzeit aktive Besucher

Keine Mitglieder online.

Letzte Anleitungen

Statistik des Forums

Themen
4.575
Beiträge
46.847
Mitglieder
4.211
Neuestes Mitglied
Maze007
Zurück
Oben