Raid

RAID-Monitoring System - Dokumentation

System-Übersicht

Server: STORE2 (Debian 13)

Zweck: Intelligente Überwachung der RAID-Arrays mit gefilterten Mail-Warnungen

Monitoring-Ansatz: Dual-Layer Überwachung (RAID + SMART)

E-Mail-Integration: GMX-SMTP mit Anti-Spam-Filterung

Hardware-Konfiguration

Überwachte Arrays:

• md125: RAID6 mit 20 Festplatten [20/20] - 52TB
• md126: RAID6 mit 23 Festplatten [23/23] - 61TB
• Gesamt: 43 Festplatten (sda-sdz, sdaa-sdax)

Software-Komponenten

mdadm-Monitoring (RAID-Ebene)

Service: mdmonitor (systemd)

Konfiguration: /etc/mdadm/mdadm.conf

Funktionsweise: Überwacht RAID-Array-Integrität und Festplatten-Status

Trigger: RAID-Degradierung, Festplatten-Ausfälle, Array-Probleme

Konfiguration:

MAILADDR daniel.gareis@gmail.com
PROGRAM /usr/local/sbin/health-alert.sh

smartd-Monitoring (Festplatten-Ebene)

Service: smartmontools.service (systemd)

Konfiguration: /etc/smartd.conf

Funktionsweise: RAID-optimierte SMART-Überwachung mit Spam-Filterung

Überwachungsintervall: Kontinuierlich (alle 30 Minuten Check)

RAID-optimierte Konfiguration:

DEVICESCAN -a -n standby -o on -S on -R 5 -I 197 -I 198 -W 4 -m daniel.gareis@gmail.com -M exec /usr/local/sbin/health-alert.sh

Parameter-Details:

• -a: Alle SMART-Tests aktivieren
• -n standby: Festplatten nicht für Tests aufwecken
• -R 5: Bis zu 5 Reallocated Sectors tolerieren
• -I 197: CurrentPendingSector ignorieren (RAID-normal)
• -I 198: OfflineUncorrectableSector ignorieren (RAID-normal)
• -W 4: Nur Temperaturänderungen >4°C melden

Alert-Management Script

Script: /usr/local/sbin/health-alert.sh

Funktionsweise: Intelligente Filterung zwischen kritischen RAID-Problemen und harmlosen SMART-Events

Logging: /var/log/raid-health.log (alle Events protokolliert)

Filter-Logik:

1. SMART-Spam blockieren: CurrentPendingSector, OfflineUncorrectableSector, Temperatur-Schwankungen
2. RAID-Alerts durchlassen: DEGRADED, FAIL, DeviceDisappeared, SpareActive
3. Alles loggen: Vollständige Nachverfolgung für Diagnose

Grafana-Integration

Dashboard-URL: http://dergagi.changeip.org:3030

Datenquelle: Node Exporter (Docker) + Prometheus

Metriken: RAID-Status (node_md_*), Festplatten-Metriken, System-Performance

Aktualisierung: 15-Sekunden-Intervall

Verfügbare Dashboards:

• Node Exporter Full: CPU/RAM/Disk-Monitoring
• RAID Status: Array-Integrität und Disk-Zähler

Mail-Benachrichtigungen

SMTP-Konfiguration

Provider: GMX (SMTP)

Transport: msmtp (systemweit konfiguriert)

Absender: dergagi@gmx.de

Empfänger: daniel.gareis@gmail.com

Verschlüsselung: TLS (Port 587)

Alert-Kategorien

Kritische RAID-Alerts (sofortige Mail):

• Array-Degradierung oder -Ausfall
• Festplatten-Hardware-Probleme
• RAID-Rebuild-Aktivität
• Array-Synchronisation-Probleme

Gefilterte Events (nur Logging):

• Harmlose SMART-Schwankungen
• Temperaturänderungen <4°C
• CurrentPendingSector/OfflineUncorrectableSector bei gesunden Arrays
• Raw_Read_Error_Rate-Fluktuationen

Monitoring-Logik

Erkennungsmechanismus

1. mdadm-Monitoring: Kontinuierliche Überwachung des Kernel-RAID-Status
2. smartd-Monitoring: Periodische SMART-Attribut-Analyse aller Festplatten
3. Dual-Filter-System: smartd-Ebene + Script-Ebene Spam-Schutz
4. Event-Korrelation: Unterscheidung zwischen RAID-Kritikalität und SMART-Rauschen

Überwachte Parameter

RAID-Ebene:

• Array-Integrität ([20/20], [23/23])
• Festplatten-Verfügbarkeit und -Status
• Rebuild/Resync-Aktivitäten
• Spare-Disk-Aktivierung

SMART-Ebene:

• Kritische Attribute (Reallocated Sectors >5)
• Temperatur-Anomalien (>4°C Änderung)
• Pre-Fail-Attribute
• Self-Test-Resultate

Wartung und Debugging

Service-Kontrolle

bash

# RAID-Monitoring Status
systemctl status mdmonitor
cat /proc/mdstat

# SMART-Monitoring Status  
systemctl status smartmontools
journalctl -u smartmontools -n 10

# Alert-System Test
/usr/local/sbin/health-alert.sh "TEST" "Manual Test"

# Check pausieren

echo idle > /sys/block/md125/md/sync_action

# Nach deiner Arbeit: Fortsetzen

echo check > /sys/block/md125/md/sync_action

# Timer-Status prüfen (falls gestoppt)

systemctl start mdcheck_start.timer

Log-Überwachung

RAID-Health-Log:

bash

tail -20 /var/log/raid-health.log

Typische Log-Einträge:

• Normal: EVENT: '-s' | DEVICE: 'Temperature change' (gefiltert)
• Kritisch: CRITICAL RAID-Alert: FAIL on /dev/md125 (gemailt)
• Filtered: SMART-Spam blocked: OfflineUncorrectableSector

Backup-Konfiguration

Backup-Dateien:

• /etc/smartd.conf.backup.YYYYMMDD
• /usr/local/sbin/health-alert.sh.backup.YYYYMMDD
• /etc/mdadm/mdadm.conf (Original-mdadm-Konfiguration)

Integration in Gesamtsystem

Drei-Schicht-Architektur

1. Hardware-RAID: Physische Redundanz (RAID6 mit 2-Disk-Toleranz)
2. Monitoring-Layer: Dual-System (mdadm + smartd) mit intelligenter Filterung
3. Backup-System: NVMe-Backup unter /mnt/nvme_backup

Ressourcen-Verbrauch

CPU-Last: <0.1% (periodic SMART checks)

Memory: <5MB resident (smartd + mdmonitor)

I/O-Impact: Read-only /proc/mdstat und SMART-Queries

Netzwerk: Minimal (nur E-Mail bei Alerts)

Risiko: Null (keine Write-Operationen auf RAID-Arrays)

Das System bietet enterprise-grade RAID-Überwachung durch bewährte Linux-Tools (mdadm, smartd) mit professioneller Spam-Filterung, die false-positive Alerts eliminiert bei maximaler Sicherheit für echte Hardware-Probleme.

STORE2 Heatmap Webdienst - Dokumentation

Überblick

STORE2 HDD-Temperatur Heatmap Generator - Webservice zur visuellen Darstellung der Festplatten-Temperaturen im STORE2-System als interaktive Heatmap.

2025-09-01 23-29-06-STORE2-HDD-Heatmap

Service-Details

• Port: 8020 (HTTP, direkter Zugriff ohne Apache-Proxy)
• URL: http://dergagi.changeip.org:8020/
• Backend: FastAPI + Uvicorn + matplotlib (headless rendering)
• Verzeichnis: /opt/heatmap8020/
• SystemD: heatmap8020.service (enabled, auto-start)
• User: root
• Python: venv unter /opt/heatmap8020/.venv/

Funktionalität

Eingabeformat

Text-Input mit HDD-Daten pro Zeile:

/dev/sdq -> data2 103 21 : WD-WCC7K5THL257 (3TB WD Red) /dev/disk/by-id/... 49°C

Struktur: /dev/<dev> -> <group> <raidpos> <slot> : <serial> (<capacity> <vendor> [extra]) <by-id-path> <temp>°C

Ausgabe-Features

• Layout: 3×15 Grid (45 Slots) für HDDs + Mainboard/PSU-Block + NVMe-Balken
• Farbkodierung: 35-55°C (grün→gelb→rot) mit Colorbar
• Schraffierung: Nur für group="data" (nicht data2)
• Deutsche Zeit: Europe/Berlin Zeitzone im Titel
• PNG-Export: Hochauflösend (17×8.8 Zoll @ 160 DPI)

Feld-Informationen (pro HDD-Slot)

Links (3 Zeilen): Kapazität, Hersteller, Extra-Info Mitte: Temperatur (fett, z.B. 49°C) Rechts (3 Zeilen):

• #<slot> <dev> (z.B. #21 sdq)
• Kurzserial (letzten 8 Zeichen, z.B. YNG4J48A)
• RAID-Position (3-stellig, z.B. 103)

Technische Umsetzung

Kern-Module

• store2_heatmap.py: Rendering-Engine (CLI + Import-Modul)
• app.py: FastAPI-Webapp mit Web-Interface
• Dependencies: fastapi, uvicorn[standard], matplotlib, fonts-dejavu

Webapp-Endpunkte

• /: Web-Interface (Textarea für HDD-Daten)
• /render: POST-Endpoint (generiert PNG)
• /healthz: Health-Check
• /static/<file>: Generierte PNG-Downloads

Deployment & Wartung

Service-Kommandos

bash

systemctl status heatmap8020.service    # Status
systemctl restart heatmap8020.service   # Neustart
journalctl -fu heatmap8020.service      # Live-Logs

CLI-Nutzung (optional)

bash

cd /opt/heatmap8020
python3 store2_heatmap.py < hdd_data.txt
# → Outputs: 2025-08-31_17-34-36-STORE2-HDD-Heatmap.png

Health-Checks

• Lokal: curl http://127.0.0.1:8020/healthz
• Extern: curl http://dergagi.changeip.org:8020/healthz
• Port: ss -ltn | grep :8020

Integration mit STORE2

• Keine Abhängigkeiten zu anderen STORE2-Diensten
• Port 8020 ist für diesen Service reserviert (nicht Apache 443)
• Datenquelle: Manueller Text-Input via Web-Interface
• Ausgabe: PNG-Download + Web-Anzeige

Besonderheiten

• Headless matplotlib: Agg-Backend für Server ohne X11
• Robustes Parsing: Toleriert kleine Format-Abweichungen
• NVMe-Integration: System-Laufwerk als separater grüner Balken
• Backup-Funktion: CLI-Version parallel zur Webapp verfügbar

Raid nach Booten öffnen und mount

Um Auto-Assembly beim Booten zu verhindern muss die Config-Datei /etc/mdadm.conf leer (oder zumindest komplett auskommentiert sein) und "MDADM_SCAN=no" in /etc/sysconfig/mdadm

1.) Checken ob alle Platten da sind:

/root/bin/diskserial_sort.sh 

Müssen im Moment 27 Platten sein.

2.) Raids suchen und assemblen (kein Autostart):

mdadm --assemble --scan 

3.) Cryptsetup:

cryptsetup luksOpen /dev/md124 cr_md125 
cryptsetup luksOpen /dev/md127 cr_md126 

4.) Mounten:

mount -o rw,errors=continue,noatime /dev/mapper/cr_md126 /data2
mount /dev/mapper/cr_md125 /data

Raid-Status

mdadm --detail /dev/md127

Raid-Baustatus

cat /proc/mdstat

automatisch jede Sekunde aktualisiert

watch -n 1 cat /proc/mdstat

Raidgröße

1000000000000

als ext3

auch als ext3

Raid Baubefehl

mdadm --create /dev/md127 --level=raid6 --raid-devices=5 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 

mdadm --create /dev/md127 --chunk=64 --level=raid6 --layout=ls --raid-devices=5 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 

Verschlüssel von Hand (ohne Yast2)

Verschlüsseln:

cryptsetup -v --key-size 256 luksFormat /dev/md127 

Öffnen:

cryptsetup luksOpen /dev/md127 cr_md127 

Filesystem drauf:

mkfs.reiserfs /dev/mapper/cr_md127 

Status:

cryptsetup luksDump /dev/md127

Grown

Festplatte vorbereiten

yast2, neue Primärpartition mit Größe : 1000000000000 als Linux RAID, nicht formatieren oder einhängen

Device zum Raid hinzufügen

mdadm --add /dev/md127 /dev/sdg1

Raid reshapen mit zusätzlichem Device (dauert ca. 2 volle Tage)

mdadm --grow --raid-devices=19 /dev/md127 --backup-file=/home/gagi/mda127backup

 mdadm --grow --raid-devices=6 /dev/md126 --backup-file=/home/gagi/mda126backup_20150911 

um zu sehen, wer/was gerade Zugriff nimmt:

lsof /data 

Samba-Service beenden:

rcsmb stop 

Unmounten:

umount /data 

ReiserFS (Data2)

Filesystem überprüfen:

reiserfsck --check /dev/mapper/cr_md125 

(Falls nötig, mit dm_crypt öffnen:)

(cryptsetup luksOpen /dev/md125 cr_md125)
(schließen übrigens mit cryptsetup luksClose)

Verschlüsselten Container wachsen:

cryptsetup --verbose resize cr_md125

Reiser-Filesystem wachsen:

resize_reiserfs /dev/mapper/cr_md125

Filesystem überprüfen:

reiserfsck --check /dev/mapper/cr_md125

XFS (Data)

XFS checken (ungemountet)

xfs_repair -n -o bhash=1024 /dev/mapper/cr_md125 

Cryptcontainer wachsen

cryptsetup --verbose resize cr_md125 

Mounten:

mount /dev/mapper/cr_md125 /data

XFS vergrößern

xfs_growfs /data 

XFS checken (ungemountet)

xfs_repair -n -o bhash=1024 /dev/mapper/cr_md125 

Read-Only Mounten:

mount -o ro /dev/mapper/cr_md125 /data

Mounten über Samba

mount //192.168.0.1/alte_Q /mnt

RAID6 aufblasen auf 1,5TB

Software-Raid-Dienst unster OpenSuse starten:

/etc/init.d/boot.md start 

0. UUID kaputt machen und Partitionstabelle zerstören für 1TB Platteninhalt dd-t auf 1,5TB Platte

dd if=/dev/zero bs=1024 count=2000 of=/dev/sdi

1. Farbikneue Festplatten über MB-SATA-Anschluss in Opensuse mit Partition (komplette Platte) und Filesystem (RAID) versehen

Dann für jede Platte sukzessive:

2. Platte failed setzen und aus Raidverbund rausnehmen:

 mdadm --set-faulty /dev/md127 /dev/sdo1
 mdadm --remove /dev/md127 /dev/sdo1

3. Plattenpartition maximiert (komplette Platte) mit Yast2 -> Partitioner neu anlegen als Linux Raid FD (formatieren nicht nötig) -> Dieser Schritt DOCH nötig! -> Legacy

4. Wieder ins Raid reinnehmen

 mdadm --add /dev/md127 /dev/sdo1 (mit "1", NICHT direkt als sdo)
 

5. Bauen lassen

6. Nächste Platte

7. Wenn die 5 1TB-Platten "befreit" sind, aus denen ein neues Raid5 aufsetzen (siehe Anleitung) und darauf das alte Raid5 verschieben.

8. Wenn alle 14 1,5TB Platten im Raid6 sind, dann das Raid6 grown lassen

mdadm --grow /dev/md127 --size=max

9. Unmounten, Filesystem-Check, Cryptcontainer wachsen, ReiserFS wachsen (wie sonst auch, siehe oben).

RAID Layout mit Serials

01  : 1SWX1JSK292519 (1.5T)
02  : 1S6Y1JSK175967 (1.5T)
03  : 1S6Y1JSK175957 (1.5T)
04  : WD-WCAU40406122 (1.0T)
05  : 9VS0CVSE (1.5T)
06  : WD-WCAU40497763 (1.0T)
07  : 

08  : 9VS0CTFS (1.5T)
09  : 9VS0CWXA (1.5T)
10  : 9VS0HDNS (1.5T)
11  : W_-DCWUA54200342 (1.0T)
12  : W_-DCWUA54003755 (1.0T)
13  : 1SWX9JZC0C4152 (1.5T) NEU, LEER
14  : V91S44W6 (1.5T)
15  : WD-WMAM9DKR6107 (80G)

-------------------------------------------

16  :
17  : S1XWJ90ZC11894 (1.5T), NAGELNEU, Amazon-Austausch
18  : S1XWJ90ZC11752 (1.5T), NAGELNEU, Amazon-Austausch, keine bb
19  : S1VSJDWZ606579 (1.0T)
20  : 1SWX1JSK292509 (1.5T) 
21  : 1SWX1JSK2C4676 (1.5T)
22  :

23  : 1SWX1JSK2C4853 (1.5T)
24  : S1XWJ1KSC28441 (1.5T)
25  : 1SWX9JZC0C9984 (1.5T)
26  : 1SWX9JZC0C2157 (1.5T)
27  : 1SWX1JSL0C1584 (1.5T)
28  : S1XWJ1KSC26485 (1.5T)
29  : 1SWX1JSK2C7604 (1.5T)
30  : 1SWX9JS00C7742 (1.5T)

TOTAL ACTIVE: 27

Festplatten Seriennummern auslesen

/root/bin/diskserial.sh | sort +2 -3 -n

oder

/root/bin/diskserial_sort.sh

Serials auslesen

Für RAID-Stauts einer einzelnen Platte:

mdadm --examine /dev/sdi

Zum Serial auslesen:

udevadm info --query=all --name=/dev/sdi

bzw.

udevadm info --query=all --name=/dev/sdi | grep ID_SERIAL_SHORT

oder

hdparm -i /dev/sdi

HPT RAID Management Server

läuft auf Port 7402 (wegen Putty SSH Tunnel und so) -> https://localhost:7402/

Lokal: -> https://192.168.1.66:7402/arrman.cgi?userid=RAID_4ba433e6

Start: /etc/init.d/hptdaemon start

Login: RAID

Pass: hpt

Raid wieder assemblen

Raid5 (5 x 1TB)

mdadm --assemble /dev/md125 /dev/sda1 /dev/sdb1 /dev/sdq1 /dev/sdr1 /dev/sds1

Raid6 (14 x 1,5TB)

mdadm --assemble /dev/md127 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdh1 /dev/sdi1 /dev/sdj1 /dev/sdk1 /dev/sdl1 /dev/sdm1 /dev/sdn1 /dev/sdo1 /dev/sdp1 /dev/sdt1

SMART Test

Starten

smartctl -t offline /dev/sda 

Auslesen

smartctl -l selftest /dev/sda

Ideen

ddn von sdg (Platz 28, SC06051 oder verdreht) -> dd_rescue

SpinRite

reiserfsck evtl. mit badblocks liste, aber: dev sda ist Grundlage für badblocks-Liste, nicht md127!

mdadm --create zusammen mit "missing"'

In short: Especially if you run a RAID5 array, trigger an active bad block check on a regular basis, or there is a high chance of hidden bad blocks making your RAID unusable during reconstruction. Normally, RAID passively detects bad blocks. If a read error occurs, the data is reconstructed from the rest of the array, and the bad block is rewritten. If the block can not be rewritten, the defective disk is kicked out of the active array. Once the defective drive is replaced, reconstruction will cause all blocks of the remaining drives to be read. If this process runs across a previously undetected bad block on the remaining drives, another drive will be marked as failed, making RAID5 unusable. The larger the disks, the higher the odds that passive bad block detection will be inadaquate. Therefore, with today's large disks it is important to actively perform data scrubbing on your array. With a modern (>=2.6.16) kernel, this command will initiate a data consistency and bad block check, reading all blocks, checking them for consistency, and attempting to rewrite inconsistent blocks and bad blocks.

echo check >> /sys/block/mdX/md/sync_action 

You can monitor the progress of the check with:

watch -n .1 cat /proc/mdstat

You should have your array checked daily or weekly by adding the appropriate command to /etc/crontab.

If you find yourself needlessly checking your array (like I was) and want to stop it safely, you can either stop the entire array, or:

echo idle >> /sys/block/mdX/md/sync_action

mdadm --detail --scan --verbose > /etc/mdadm.conf

Force-Mount zum Wegkopieren

mdadm --assemble -f /dev/md127 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdi1 /dev/sdk1 /dev/sda1 /dev/sdm1 /dev/sdn1 /dev/sdo1 /dev/sdp1 /dev/sdq1

cryptsetup luksOpen /dev/md127 cr_md127

mount -o ro /dev/mapper/cr_md127 /data

Bad Blocks

badblocks -vs -o sdy-badblock-test /dev/sdy

verbose, show progress, output-file (log) badblocks sucht nur nach bad blocks, zerstört aber keine Daten

Identifikationen während Rettungsversuch

sda:

die mit ca. 1500 Bad Blocks; kann mit --update=summaries -f als 12. Platte reingeforced werden, hat aber bad blocks. nachh dd_rescue evtl. Reparaturversuch mit SpinRite

/dev/sda -> 28  : S1XWJ1LSC06051 (1.5T)

kommt auf

/dev/sdi ->  29  : S1XWJ1KSC31145 (1.5T)

sdn:

aus dem Raid rausgeflogen, war bis zur Hälfte gebaut, bis sda als 12. Platte flog -> Raid weg -> Rebuild abgebrochen

Superblock für mdadm auf sdl vorhanden, NICHT auf sdl1 -> evtl. auch mal ohne "1" eingebunden, aus Logfile aber nicht direkt nachvollziehbar

/dev/sdn -> 23 : 1SWX1JSK2C4853 (1.5T) 

sdl:

war wohl als sdj nicht als sdj1 eingebunden (damals sdb statt sdb1); enthält evtl. noch sinnvolle Raid-Daten, könnte defekte sda als 12. Platte im Raid ersetzen, um wieder rebuilden zu können. Hat wohl ein Problem mit der Partitionsinfo/Superblock (Hexeditoraktion mit JoJo)

Superblock für mdadm auf sdj vorhanden, NICHT auf sdj1

/dev/sdl -> 25 : 1SWX1JSL0C9558 (1.5T)

kommt auf

/dev/sdw -> 26  : S1XWJ1KSC31152 (1.5T)

dd-Kopieraktion

L 25 nach W 26 (ohne Bad Blocks (hoffentlich)) :

dd if=/dev/sdl of=/dev/sdw bs=2k

A 28 nach I 29 (mit Bad Blocks)

dd_rescue -v -A -l logddav.log -o bbfileav.log /dev/sda /dev/sdi

pv (pipeviewer) zur Fortschrittsanzeige

pv /dev/sdl >/dev/sdw  und  pv /dev/sda >/dev/sdi

oder mit "echtem" Fortschrittsbalken bei bekannter Datengröße

dd if=/dev/sdl bs=2k | pv -s 1500G | dd of=/dev/sdw
dd if=/dev/sdl | bar -s 1.5T | dd of=/dev/sdw 

bei -v bei dd_rescue stehts auch direkt dabei, für dd gibts aus einer anderen Konsole noch:

pkill -USR1 dd
pidof dd
pkill -USR1 pid-von-dd sonst wird z.B. auch der dd_rescue abgeschossen, der startet dann aber nicht mehr :-(

oder automatisch alle 5 Sekunden aktualisieren lassen mit

watch --interval=5 "pkill -USR1 pid-von-dd"

RAID 5 Probem (schon wieder "no Superblock" *ARRRRRGH*)

Layout für Zuordnung

Raiddevice	14.3. 18:40	Platz in Towern	16.3. 23:50
0	sdg1	04	sdh1
1	sdb1	06	sdb1
2	sdr1	11	sdt1
3	sds1	12	sdu1
4	sdt1	13	sdv1

Superblock und Reihenfolge RAID6

Superblock am Ende der Partition?

Raiddevice	13.3. 18:16	19.3. 20:40, OK	Platz in Towern	Serial (evtl. twisted)	20.3. 16:00 Full Rebuilt	Serial (evtl. twisted)	Towerplatz
0	sdc1 active	sdc1	05	9VS0CVSE (1.5T)	sdc1	9VS0CVSE (1.5T)	05
1	sdd1 active	sdd1	08	9VS0CTFS (1.5T)	sdd1	9VS0CTFS (1.5T)	08
2	sde1 active	sde1	09	9VS0CWXA (1.5T)	sde1	9VS0CWXA (1.5T)	09
3	sdf1 active	sdf1	10	9VS0HDNS (1.5T)	sdf1	9VS0HDNS (1.5T)	10
4	sdm1 active	sdp1	24	S1XWJ1KSC28441 (1.5T)	sdp1	S1XWJ1KSC28441	24
5	sdi1 active	sdn1	23	S1XWJ1KSC28435 (1.5T)	sdn1	1SWX1JSK2C4853 (1.5T)	23
6	sdk1 active	missing	28	S1XWJ1LSC06051 (1.5T)	sdl1	1SWX1JSL0C9558 (1.5T) -> 25	25
7	sdj1 active	sdm1	27	S1XWJ1LSC05148 (1.5T)	sdm1	1SWX1JSL0C1584	27
8	sdt1 active	missing	25	S1XWJ1LSC05985 (1.5T)	sdw1	1SWX1JSK3C1125 (1.5T) -> 26	26
9	sdp1 active	sds1	14	9VS1446W (1.5T)	sds1	V91S44W6	14
10	sdn1 active	sdq1	01	S1XWJ1KS925291 (1.5T)	sdq1	1SWX1JSK292519	01
11	sdo1 active	sdr1	03	S1Y6J1KS719575 (1.5T)	sdr1	1S6Y1JSK175957	03
12	sdh1 active	sdk1	07	S1XWJ1KS925290 (1.5T)	sdk1	1SWX1JSK292509	07
13	sdl1 active	sdo1	02	S1Y6J1KS719576 (1.5T)	sdo1	1S6Y1JSK175967	02

Erfolgreiches Create am Freitag Abend mit JoJo

mdadm --create /dev/md127 --chunk=64 --level=raid6 --layout=ls --raid-devices=14 --assume-clean /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdp1 /dev/sdn1 missing /dev/sdm1 missing /dev/sds1 /dev/sdq1 /dev/sdr1 /dev/sdk1 /dev/sdo1 

       Version : 0.90
 Creation Time : Fri Mar 19 20:20:57 2010
    Raid Level : raid6
    Array Size : 11718709248 (11175.83 GiB 11999.96 GB)
 Used Dev Size : 976559104 (931.32 GiB 1000.00 GB)
  Raid Devices : 14
 Total Devices : 12

Preferred Minor : 127

   Persistence : Superblock is persistent

   Update Time : Fri Mar 19 20:31:46 2010
         State : clean, degraded
Active Devices : 12

Working Devices : 12

Failed Devices : 0
 Spare Devices : 0

    Chunk Size : 64K

          UUID : 214bffe6:d954a41b:5d29213a:eb263c81 (local to host store)
        Events : 0.7

   Number   Major   Minor   RaidDevice State
      0       8       33        0      active sync   /dev/sdc1
      1       8       49        1      active sync   /dev/sdd1
      2       8       65        2      active sync   /dev/sde1
      3       8       81        3      active sync   /dev/sdf1
      4       8      241        4      active sync   /dev/sdp1
      5       8      209        5      active sync   /dev/sdn1
      6       0        0        6      removed
      7       8      193        7      active sync   /dev/sdm1
      8       0        0        8      removed
      9      65       33        9      active sync   /dev/sds1
     10      65        1       10      active sync   /dev/sdq1
     11      65       17       11      active sync   /dev/sdr1
     12       8      161       12      active sync   /dev/sdk1
     13       8      225       13      active sync   /dev/sdo1

Erfolgreiches Create am 6.2.2011

mdadm --create /dev/md127 --chunk=64 --level=raid6 --layout=ls --raid-devices=18 --assume-clean /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdg1 /dev/sds1 /dev/sdq1 /dev/sdv1 /dev/sdp1 /dev/sdx1 /dev/sdn1 /dev/sdo1 /dev/sdm1 /dev/sdl1 /dev/sdw1 missing /dev/sdu1 missing

dd-Rescue am 8.2.2011 von sdq auf sdh

screen -S dd
dd_rescue -v -A -l logddav.log -o bbfileav.log /dev/sdq /dev/sdh
Strg-a d

Mail-Benachrichtigung

Beim mdadm Paket kann man zumindestins ins mdadm.conf eine mailadresse eintragen:

Code:

MAILADDR ghostadmin@irgendwo.net

Da werden dann Events an diese mailadresse gesendet. In Deinem Fall wäre ein 'degraded raid' event mail an Dich gesendet worden.

Allerdings muss mdadm im monitor mode gestartet sein: z.B.: /sbin/mdadm --monitor --scan

ReiserFS -> XFS

partitionstabelle "erzeugen"

dd if=/dev/zero of=partitionstabelle bs=512 count=63 

in table-test:

0 63 linear /dev/loop0 0

63 2930277168 linear /dev/sdt 0

losetup /dev/loop0 partitionstabelle

losetup /dev/loop1 raid-test

cryptsetup -v --key-size 256 luksFormat /dev/loop1

dmsetup -v create part-test table-test

fdisk /dev/mapper/cr_mdloop1
u
p 

fdisk
p
n
w

( kpartx -a /dev/mapper/part-test oder

partprobe)

Wieder entfernen (falls nötig)

dmsetup remove part-test1

Anzahl der Sektoren rausbekommen

cfdisk -P s /dev/mapper/cr_sdv

366264048 blocks

resize_reiserfs 750108770304

Cryptcontainer-Größe cr_sdv 2930112504s

Cryptcontainer-Größe cr_md127 35047206392s -> 17944169672704 Bytes

 parted /dev/mapper/cr_sdv 

 resize 1 63 1000000000

ReiserFS -> XFS actually done

Masterplan Nr. 4

Cryptcontainer nur für vorderes ReiserFS verkleinern

cryptsetup --verbose resize cr_md127 --size=21550000000 (in Sektoren) 

raid6 Mapper-Device mit Partitionstabelle anlegen

 dd if=/dev/zero of=partitionstabelle bs=512 count=63

touch table-test

darin Sektoren für md127 aus

fdisk /dev/mapper/cr_md127
u
p

vi table-test und paste

0 63 linear /dev/loop0 0
63 43809010560 linear /dev/md127 0
43809010623 63 linear /dev/loop2 0

Loop-Device erzeugen, das Partitionstablle enthält

losetup /dev/loop0 partitionstabelle1
losetup /dev/loop2 partitionstabelle2

Zusammengesetztes Device erzeugen

dmsetup -v create raid6 table-test

Erzeugt Partitonseintrag für aktuelles ReiserFS (erstes FS in Raid6)

Mit Parted Partitionen für verschlüsselte Partition vorne und entschlüsselte Kopie hinten anlegen

parted /dev/mapper/raid6
mktable gpt
unit
s
mkpart primary 63 21560000000
mkpart primary 21600000000 43200000000
(Start 63, Ende aus df von gemountetem /data
 df ergibt in 1K Blöcken: 10586246076 mal 2 + Reserve -> 21500000000
n (Start 21600000000 bis Ende für neue Partition für dd-job)
w

Legt devices für Partitionen an raid61 und raid62

kpartx -a /dev/mapper/raid6

Verschlüsselte Partition öffnen

cryptsetup luksOpen /dev/mapper/raid6p1 cr_raid6p1 

dd vom entschlüsselten cr_raid6p1 nach raid6p2

dd if=/dev/mapper/cr_raid6p1 of=/dev/mapper/raid6p2 bs=1G oflag=direct iflag=direct 

__________________________________________________________________________________________________________________________________

ReiserFS auf raid6p2 checken

reiserfsck --check /dev/mapper/raid6p2
manueller Film-anschau-Check (minimum 2h, FullHD)

xfs auf Raid62

mkfs.xfs -f /dev/mapper/cr_raid6p1 

Copy-Job vorbereiten

mount /dev/mapper/cr_raid6p1 /xfs
mount /dev/mapper/raid6p2 /data

Umfachreicher Copy-Job mit tar und Buffer

(cd /data/ && tar pcf - *) | buffer -m 20m -p 99.999 | pv -s 11T | (cd /xfs/ && tar pxf -)

ODER : Umfangreicher Copy-Job mit Fortschritt über rsync (eher nur zum Abgleich/Synchronisation)

rsync -rpP /data/* /xfs
rsync -rpP --times --size-only --block-size=128000 /data/ /xfs/

Test auf erfolgreiches Kopieren

umount /xfs
xfs_check /dev/mapper/cr_raid6p1 (sehr langsam und schnell "out of memory")
xfs_repair -n /dev/mapper/cr_raid6p1 ("-n" ist der "no-modify-mode")
und manueller Filetest

umount /data
umount /xfs

Cryptcontainer für virtuelle Partitionen schließen

cryptsetup luksClose cr_raid6p1

Loopdevices platt machen

dmsetup remove raid6p1
dmsetup remove raid6p2
dmsetup remove raid6

Eigentlichen großen Cryptcontainer öffnen

cryptsetup luksOpen /dev/md127 cr_md127

Cryptcontainer wachsen auf 22TB

cryptsetup --verbose resize cr_md127

Fertiges XFS nach Data mounten

mount /dev/mapper/cr_md127 /data

Endlich, XFS groß machen (23TB)

xfs_growfs /data

XFS checken (ungemountet!)

umount /data
xfs_repair -n -o bhash=1024 /dev/mapper/cr_md127

ReiserFS -> XFS alter Plan, hinfällig

dd if=/dev/zero of=partitionstabelle bs=512 count=63

touch table-test

darin Sektoren für md127 aus

fdisk /dev/mapper/cr_md127
u
p

vi table-test und paste

0 63 linear /dev/loop0 0
63 43809008504 linear /dev/mapper/cr_md127 0 

Loop-Device erzeugen, das Partitionstablle enthält

losetup /dev/loop0 partitionstabelle

Zusammengesetztes Device erzeugen

dmsetup -v create raid6 table-test

Erzeugt Partitonseintrag für aktuelles ReiserFS (erstes FS in Raid6)

fdisk /dev/mapper/raid6
u
p
n 
(Start 63, Ende aus df von gemountetem /data
 df ergibt in 1K Blöcken: 10586246076 mal 2 + Reserve -> 21500000000
n (Start 21600000000 bis Ende für neue Partition für dd-job)
w

Legt devices für Partitionen an raid61 und raid62

kpartx -a /dev/mapper/raid6

1:1 Kopie des ReiserFS Raid6 nach hinten auf die anderen (restlichen) 11TB in der zweiten Partition

dd if=/dev/mapper/raid61 bs=4K | pv -s 10T | dd of=/dev/mapper/raid62 bs=4K

Check nach dd

reiserfs_check /dev/mapper/raid62

In Ursprungs-Partition xfs erzeugen

mkfs.xfs /dev/mapper/raid61