mirror of https://github.com/Alkatrazz24/Funk-lab.git synced 2026-07-08 15:14:43 +02:00

alkatrazz 3cd374630d docs(incidents): 2026-05-29 — migration /srv/data RAID5 → NVMe (sdb ATA bus errors)

- Incident : sdb ATA bus errors sous charge I/O bloquaient le rsync en état D
- Résolution : sdb marqué (F) dans mdadm, rsync relancé (205 MB/s, 35s)
- Fix : version.info corrompu dans segment Qdrant RocksDB (0.D\0 → 0.6.0)
- Architecture : /srv/data bind-monté depuis /home/data (NVMe XFS, 801 GB libres)
- fstab mis à jour, tous les services opérationnels
- CLAUDE.md : venv bootstrap, make --tags invalide, incidents.md dans admin/

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

2026-05-29 14:59:13 +02:00

3.2 KiB

Raw Blame History

2026-05-29 — Migration /srv/data RAID → NVMe

Résumé

Migration complète des données de /srv/data depuis le RAID5 dégradé vers le LV NVMe (almalinux-home). Tous les services opérationnels sur NVMe.

CLAUDE.md — corrections mineures

Trois corrections appliquées au CLAUDE.md du projet :

Bootstrap venv manquant : ajout de python3 -m venv .venv avant make install (le Makefile appelle .venv/bin/pip directement, échoue silencieusement sans venv).
make apply-storage --tags X invalide : GNU make interprète --tags comme une cible. Remplacé par les commandes ansible-playbook directes dans les sections gateway et RAG.
admin/incidents.md : ajouté dans la liste des fichiers admin/.

Évaluation RAID et décision d'architecture

Contexte : RAID5 déjà dégradé [UUU_] après retrait de sdd (incident 2026-05-27).

Analyse de l'état des disques restants :

sda : UDMA_CRC_Error_Count=6 (câble SATA suspect)
sdb : ATA bus errors sous charge I/O (câble/port instable)
sdc, sdd : pas d'erreurs notables

Décision : migrer /srv/data vers le NVMe plutôt que de maintenir les données sur un RAID avec zéro redondance et deux disques à risque.

Plan retenu : utiliser l'espace libre de almalinux-home (LV NVMe, 845 GB, 6 GB utilisés sur 845 GB) — créer /home/data/ et bind-monter sur /srv/data. Zero opération LVM, zero risque sur /home.

Migration — déroulé

Problème : rsync bloqué sur sdb

Premier rsync lancé → bloque immédiatement en état D (uninterruptible sleep). dmesg montre des ATA bus errors sur sdb sous forte I/O. 4 KB copiés en 5 minutes.

Résolution : mdadm --manage /dev/md0 --fail /dev/sdb2 → RAID lit depuis sda/sdc/sdd uniquement.

rsync réussi

Durée  : ~35 secondes
Débit  : 205 MB/s
Fichiers : 5106 transférés (31367 vérifiés)
Exit code : 23 (xattr SELinux — non critique)

Modèles (37 GB, 24 fichiers) : intégrité vérifiée.

Corruption Qdrant corrigée

Un version.info de segment RocksDB était corrompu (octets 0.D\0 au lieu de 0.6.0), copié depuis le RAID pendant la tentative avec sdb actif. Qdrant crashait au démarrage.

printf '0.6.0' | sudo tee /srv/data/qdrant/storage/collections/funk-docs/0/segments/784eab54-.../version.info

Bascule /srv/data

sudo umount /srv/data          # RAID démonté
sudo mount --bind /home/data /srv/data
# fstab : UUID RAID5 commenté → /home/data /srv/data none bind 0 0

État final

Service	État
postgresql-16	✅ active
qdrant	✅ active
litellm	✅ active
hermes-agent	✅ active
hermes-dashboard	✅ active
alertmanager-webhook	✅ active

Stockage	Avant	Après
`/srv/data`	RAID5 ext4 dégradé	NVMe XFS 801 GB libres
RAID5 md0	monté, `[U_UU]` sdb(F)	démonté, non utilisé

Prochaines étapes

Retirer sdb du RAID (mdadm --remove /dev/sdb2) et décider du sort du RAID
Vérifier câble SATA de sdb (ATA bus error = interface, pas plateau)
Relancer rag-ingest pour vérifier l'intégrité de la collection Qdrant funk-docs

3.2 KiB Raw Blame History