SnapRAID Recovery - Récupération Après Défaillance
Procédures complètes de récupération après panne disque avec SnapRAID.
Informations
| Scénario | Durée Récupération | Downtime | Risque Perte Données |
|---|---|---|---|
| 1 disque data | 2-4h | Lecture seule | ✅ Aucun |
| Disque parity | 2-3h (recalcul) | Aucun | ⚠️ Non protégé |
| 2+ disques data | N/A | Total | ❌ Perte irréversible |
Scénarios de Défaillance
Scénario 1: Perte Disque Data (disk1)
Symptômes :
# Disque absent du système
lsblk | grep sdc
# Aucun résultat
# SnapRAID status montre erreur
snapraid status
# ERROR: Disk 'd1' not accessible
Impact :
- ✅ Données disk2 accessibles normalement
- ❌ Données disk1 inaccessibles
- ✅ Récupération possible via parity
Phase 1: Diagnostic
# Vérifier SMART (si disque encore détectable)
smartctl -a /dev/sdc
# Reallocated_Sector_Ct: 245 (FAIL)
# Vérifier logs système
dmesg | grep -i "sdc\|error\|fail"
# [12345.678] ata3: failed command READ FPDMA
# [12346.789] sd 2:0:0:0: [sdc] FAILED Result: hostbyte=DID_OK
Conclusion : Disque physiquement défaillant → Remplacement requis
Phase 2: Préparation Récupération
1. Arrêter applications utilisant données :
# Arrêter conteneurs LXC 100 (Jellyfin, *Arr stack)
pct stop 100
# Ou arrêter services Docker individuellement
docker stop jellyfin sonarr radarr
2. Démonter MergerFS (si applicable) :
3. Préparer disque remplacement :
# Installer physiquement nouveau disque
# Boot système
# Identifier nouveau disque
lsblk
# sdf 8:80 0 931.5G 0 disk ← Nouveau disque
# Partitionner
parted /dev/sdf
(parted) mklabel gpt
(parted) mkpart primary ext4 0% 100%
(parted) quit
# Formater
mkfs.ext4 -L disk1 /dev/sdf1
# Monter temporairement
mount /dev/sdf1 /mnt/disk1-new
Phase 3: Récupération SnapRAID
Commande fix (récupération complète disk1) :
Options :
-d d1: Récupérer disque data d1 complet-f /path/file: Récupérer fichier spécifique uniquement
Sortie typique :
Loading state from /var/snapraid/snapraid.content...
Using 2 data disks
Recovering disk 'd1' from parity...
10%, 48 GB, 2200 files, 85 MB/s, 1h20m remaining
25%, 120 GB, 5500 files, 92 MB/s, 1h05m remaining
50%, 240 GB, 11000 files, 95 MB/s, 50m remaining
75%, 360 GB, 16500 files, 98 MB/s, 25m remaining
100%, 487 GB, 22000 files, 100 MB/s
Recovery completed successfully!
487 GB recovered in 1h25m
0 errors found
Durée : ~1.5-2h pour 500 GB @ 100 MB/s
Pendant récupération :
- Charge I/O élevée (lecture parity + disk2, écriture disk1-new)
- CPU 20-30% (calcul XOR)
- Système utilisable mais lent
Si erreurs pendant fix :
Causes possibles :
- Parity obsolète (sync pas à jour)
- Corruption parity disk
- disk2 également défaillant
Diagnostic :
# Vérifier sync age
snapraid status | grep -i "sync time"
# Last sync: 15 days ago ← Trop ancien!
# Vérifier SMART parity disk
smartctl -H /dev/sdd
# SMART overall-health: PASSED ✓
Phase 4: Validation et Remise en Service
1. Vérifier intégrité récupération :
# Compter fichiers récupérés
find /mnt/disk1-new -type f | wc -l
# 22000 ✓ (matches snapraid status)
# Vérifier quelques fichiers aléatoires
ls -lh /mnt/disk1-new/media/movies/ | head -10
# Fichiers présents ✓
# Test lecture
cat /mnt/disk1-new/media/movies/test.mkv | head -c 1M > /dev/null
# Lecture OK ✓
2. Remplacer ancien disque par nouveau :
# Obtenir UUID nouveau disque
blkid /dev/sdf1
# UUID="abc-def-123"
# Éditer fstab
nano /etc/fstab
# Remplacer UUID ancien disk1 par nouveau
UUID=abc-def-123 /mnt/disk1 ext4 defaults,noatime 0 2
# Démonter temporaire et remonter définitif
umount /mnt/disk1-new
mount /mnt/disk1
# Vérifier
df -h | grep disk1
# /dev/sdf1 916G 487G 429G 54% /mnt/disk1 ✓
3. Sync SnapRAID (mettre à jour state) :
4. Scrub vérification :
5. Remonter MergerFS et redémarrer services :
mount /mnt/storage
pct start 100
# Ou: docker start jellyfin sonarr radarr
# Vérifier applications
curl http://localhost:8096 # Jellyfin
# Réponse OK ✓
Procédure complète : 3-5h (récupération 2h + validation 1h + sync 1h + scrub 2h)
Scénario 2: Perte Disque Parity
Symptômes :
Impact :
- ✅ Données accessibles normalement (disk1 + disk2 OK)
- ❌ Pas de protection parity (risque si 2e panne)
- ✅ Récupération simple (recalcul parity)
Récupération
1. Remplacer disque parity physiquement
# Installer nouveau disque ≥ ancien parity
lsblk
# sdf 931.5G ← Nouveau parity disk
parted /dev/sdf mklabel gpt
parted /dev/sdf mkpart primary ext4 0% 100%
mkfs.ext4 -L parity /dev/sdf1
2. Monter et configurer :
mount /dev/sdf1 /mnt/parity
# Éditer /etc/fstab (remplacer UUID)
# Éditer /etc/snapraid.conf (vérifier path parity)
3. Recalculer parity :
rm /mnt/parity/snapraid.parity # Supprimer ancien (si existe)
snapraid sync
# Recalcule parity complète (durée: 2-3h pour 808 GB)
4. Vérifier :
Durée totale : 2-3h (recalcul parity)
Scénario 3: Corruption Fichier (Sans Panne Disque)
Symptômes :
Cause : Bit rot, corruption mémoire RAM, câble SATA défectueux
Récupération Fichier Individuel
# Récupérer fichier depuis parity
snapraid fix -f /mnt/disk1/media/movie.mkv
# SnapRAID recalcule fichier via XOR
# File recovered: /mnt/disk1/media/movie.mkv
# 8.5 GB recovered in 1m30s
Vérifier réparation :
# Relancer scrub sur ce fichier
snapraid scrub -p 100 -o $(du -sb /mnt/disk1/media/movie.mkv | cut -f1)
# Checksum OK ✓
Scénario 4: Perte 2+ Disques (Irrécupérable)
Symptômes :
# disk1 ET disk2 défaillants simultanément
snapraid status
# ERROR: Disks 'd1' and 'd2' not accessible
Impact :
- ❌ Données irrécupérables (parity 1-disque insuffisante)
- ❌ Perte totale données disques défaillants
Prévention :
- Monitoring SMART régulier (détecter pannes avant total failure)
- Backup offsite critique (3-2-1 rule)
- Remplacer disques proactivement (Reallocated_Sector_Ct > 0)
Si perte 2 disques :
- Récupérer depuis backup offsite externe
- Ou accepter perte données (si médias re-téléchargeables)
Tests de Récupération (Recommandés)
Test 1: Simulation Panne (Dry-Run)
# Simuler perte disk1 (sans le démonter réellement)
snapraid fix -d d1 -t
# -t: Test mode (pas de modification)
# Affiche:
# Simulation: 22000 files would be recovered
# Estimated time: 1h25m
# No actual recovery performed (test mode)
Test 2: Récupération Fichier Test
1. Créer fichier test :
2. Corrompre fichier intentionnellement :
3. Détecter corruption :
4. Récupérer :
5. Vérifier :
6. Nettoyer :
Fréquence tests recommandée : Annuelle (valider procédure)
Checklist Récupération
Avant Panne (Préparation)
- Backup configuration SnapRAID (
/etc/snapraid.conf) - Backup content files (
/var/snapraid/snapraid.content) - Liste UUID disques (
blkid > /root/uuids.txt) - Disque spare disponible (même capacité ou supérieure)
- Documentation procédure accessible offline
- Test récupération annuel effectué
Pendant Panne (Urgence)
- Diagnostic panne (SMART, dmesg logs)
- Arrêt applications (éviter corruptions supplémentaires)
- Vérification intégrité disques restants
- Estimation durée récupération (informer utilisateurs)
- Lancement procédure récupération appropriée
Après Récupération (Validation)
- Vérification intégrité données (
scrub -p 100) - Test applications (Jellyfin, *Arr accessible)
- Sync SnapRAID (state à jour)
- Monitoring SMART (vérifier santé tous disques)
- Documentation incident (cause, durée, leçons)
- Révision fréquence sync/scrub si nécessaire
Ressources
- SnapRAID Recovery Guide - Manuel officiel récupération
- SnapRAID Fix Command - Documentation
fix - Data Recovery Best Practices - FAQ récupération
Voir Aussi
- SnapRAID - Configuration de base
- SnapRAID Automation - Monitoring et alertes
- Disaster Recovery - Procédures backup générales
Dernière mise à jour : 27 janvier 2026