Migration HGST - USB vers SATA

Date prévue : 04-01-2026 matin Status : En attente

Contexte

Les 5 disques HGST 12TB du pool ZFS stock_36to sont actuellement connectés en USB. L'utilisateur va les reconnecter directement sur la carte mère en SATA pour :

Meilleure fiabilité
Meilleures performances
Démarrage automatique avec le système

État avant migration

Pool ZFS stock_36to

Configuration : RAIDZ2 (5x 12TB HGST)
Capacité : ~33TB utilisables
Utilisé : ~18TB (54%)
Montage : /stock_36to

Services dépendants du NFS

Service	Machine	Point de montage
Docker volumes	docker-prod (192.168.1.12)	/mnt/stock_36to
Claude symlinks	claude (192.168.1.11)	/mnt/stock_36to
SMB windows_backup	win11	Z: → \192.168.1.10\stock_36to
AutoFS	nginx, gitlab	/mnt/nfs/*

VMs sur PVE dépendantes

VM	VMID	Dépendance
docker-prod	207	NFS pour volumes Docker
claude	206	NFS pour /home/gouroubleu/{tasks,propositions,backlog}
nginx	107	AutoFS (non critique au boot)

Étapes AVANT déconnexion USB

1. Arrêter les services dépendants

# Sur docker-prod - arrêter tous les containers
ssh gouroubleu@docker-prod.local "docker stop \$(docker ps -q)"

# Vérifier que tout est arrêté
ssh gouroubleu@docker-prod.local "docker ps"

2. Démonter NFS sur les clients

# Sur docker-prod
ssh gouroubleu@docker-prod.local "sudo umount /mnt/stock_36to"

# Sur claude (cette machine)
sudo umount /mnt/stock_36to

3. Arrêter les partages sur PVE

# Sur PVE - arrêter NFS et SMB
ssh gouroubleu@pve.local "sudo systemctl stop nfs-kernel-server"
ssh gouroubleu@pve.local "sudo systemctl stop smbd"

4. Exporter le pool ZFS

# CRITIQUE - à faire avant de débrancher
ssh gouroubleu@pve.local "sudo zpool export stock_36to"

# Vérifier que le pool est exporté
ssh gouroubleu@pve.local "sudo zpool list"
# stock_36to ne doit plus apparaître

5. Éteindre PVE

ssh gouroubleu@pve.local "sudo shutdown now"

Manipulation physique

Éteindre complètement le serveur PVE
Débrancher les 5 câbles USB des disques HGST
Connecter les 5 disques en SATA sur la carte mère
Vérifier les connexions d'alimentation
Rallumer le serveur

Étapes APRÈS reconnexion SATA

1. Vérifier que les disques sont détectés

# Lister les disques
ssh gouroubleu@pve.local "lsblk"

# Ou avec plus de détails
ssh gouroubleu@pve.local "sudo fdisk -l | grep -E 'Disk /dev/sd|HGST'"

# Les 5 HGST doivent apparaître (probablement sda-sde ou similaire)

2. Importer le pool ZFS

# Scanner les pools disponibles
ssh gouroubleu@pve.local "sudo zpool import"

# Importer stock_36to
ssh gouroubleu@pve.local "sudo zpool import stock_36to"

# Vérifier le status
ssh gouroubleu@pve.local "sudo zpool status stock_36to"

3. Vérifier l'intégrité

# Status détaillé
ssh gouroubleu@pve.local "sudo zpool status -v stock_36to"

# Doit afficher : state: ONLINE pour tous les disques
# Si DEGRADED ou erreurs, ne pas continuer et analyser

# Vérifier l'espace
ssh gouroubleu@pve.local "sudo zfs list stock_36to"

4. Redémarrer les services sur PVE

# NFS
ssh gouroubleu@pve.local "sudo systemctl start nfs-kernel-server"
ssh gouroubleu@pve.local "sudo systemctl status nfs-kernel-server"

# SMB
ssh gouroubleu@pve.local "sudo systemctl start smbd"
ssh gouroubleu@pve.local "sudo systemctl status smbd"

# Vérifier les exports NFS
ssh gouroubleu@pve.local "sudo exportfs -v"

5. Remonter NFS sur les clients

# Sur claude (cette machine)
sudo mount /mnt/stock_36to
ls /mnt/stock_36to/data/33800-stack/

# Sur docker-prod
ssh gouroubleu@docker-prod.local "sudo mount /mnt/stock_36to"
ssh gouroubleu@docker-prod.local "ls /mnt/stock_36to/data/33800-stack/"

6. Redémarrer Docker sur docker-prod

# Démarrer les stacks dans l'ordre
ssh gouroubleu@docker-prod.local "cd /mnt/stock_36to/data/33800-stack/docker/stacks/redis-prod && docker compose up -d"

ssh gouroubleu@docker-prod.local "cd /mnt/stock_36to/data/33800-stack/docker/stacks/supabase-prod && docker compose up -d"

ssh gouroubleu@docker-prod.local "cd /mnt/stock_36to/data/33800-stack/docker/stacks/monitoring && docker compose up -d"

ssh gouroubleu@docker-prod.local "cd /mnt/stock_36to/data/33800-stack/docker/stacks/notifications && docker compose up -d"

# HelloCar et autres
ssh gouroubleu@docker-prod.local "docker start hellocar-api-prod hellocar-public-prod hellocar-admin-prod"
ssh gouroubleu@docker-prod.local "docker start notif-logger yolo-api whisper-api"

7. Vérifier tous les services

# Containers
ssh gouroubleu@docker-prod.local "docker ps"

# Redis
ssh gouroubleu@docker-prod.local "docker exec redis-prod redis-cli PING"

# Supabase
curl -s http://192.168.1.12:8200/rest/v1/ | head -1

# Portainer
curl -sk https://192.168.1.12:9443 | head -1

# HelloCar
curl -s http://192.168.1.12:4510/swagger | head -1

8. Tester Windows SMB

# Depuis cette machine
smbclient //192.168.1.10/stock_36to -U smbuser%backup123 -c "ls"
smbclient //192.168.1.10/windows_backup -U smbuser%backup123 -c "ls"

# Ou tester depuis Windows (si allumé)
ssh gouro@win11.local "net use Z: \\\\192.168.1.10\\stock_36to /user:smbuser backup123"

Vérification finale

Checklist

[ ] zpool status stock_36to = ONLINE, pas d'erreurs
[ ] NFS monté sur claude (/mnt/stock_36to)
[ ] NFS monté sur docker-prod (/mnt/stock_36to)
[ ] Portainer accessible (https://192.168.1.12:9443)
[ ] Redis PING = PONG
[ ] Supabase API répond
[ ] HelloCar Swagger accessible
[ ] Grafana accessible
[ ] SMB stock_36to accessible
[ ] SMB windows_backup accessible

Commande de vérification rapide

# Script de vérification tout-en-un
echo "=== ZFS ===" && \
ssh gouroubleu@pve.local "sudo zpool status stock_36to | head -10" && \
echo "=== NFS claude ===" && \
ls /mnt/stock_36to/data/33800-stack/ | head -3 && \
echo "=== NFS docker-prod ===" && \
ssh gouroubleu@docker-prod.local "ls /mnt/stock_36to/data/33800-stack/ | head -3" && \
echo "=== Docker containers ===" && \
ssh gouroubleu@docker-prod.local "docker ps --format 'table {{.Names}}\t{{.Status}}'" && \
echo "=== Redis ===" && \
ssh gouroubleu@docker-prod.local "docker exec redis-prod redis-cli PING" && \
echo "=== Portainer ===" && \
curl -sk https://192.168.1.12:9443 -o /dev/null -w '%{http_code}\n'

En cas de problème

Pool non trouvé à l'import

# Forcer le scan de tous les devices
ssh gouroubleu@pve.local "sudo zpool import -d /dev/disk/by-id"

# Si toujours pas trouvé, lister par ID
ssh gouroubleu@pve.local "ls -la /dev/disk/by-id/ | grep HGST"

Pool DEGRADED

# Voir quel disque pose problème
ssh gouroubleu@pve.local "sudo zpool status stock_36to"

# RAIDZ2 tolère 2 pannes, donc si 1-2 disques DEGRADED, le pool reste utilisable
# Vérifier les connexions SATA du disque concerné

NFS ne monte pas

# Vérifier que le serveur NFS écoute
ssh gouroubleu@pve.local "sudo showmount -e localhost"

# Vérifier connectivité
ping pve.local

# Forcer le montage avec debug
sudo mount -v -t nfs 192.168.1.10:/stock_36to /mnt/stock_36to

Containers ne démarrent pas

# Vérifier les logs
ssh gouroubleu@docker-prod.local "docker logs <container_name>"

# Vérifier que les volumes sont accessibles
ssh gouroubleu@docker-prod.local "ls -la /mnt/stock_36to/data/33800-stack/docker/stacks/"

Identifiants des disques HGST (pour référence)

Les disques du pool stock_36to (à vérifier après migration) :

# Commande pour lister les IDs actuels
ssh gouroubleu@pve.local "sudo zpool status stock_36to" | grep HGST

Notes

Le pool ZFS utilise les IDs de disques, pas les lettres (sda, sdb...)
Donc le changement USB → SATA ne devrait pas poser de problème
ZFS reconnaît les disques par leur UUID/serial number
L'import devrait être transparent

Fichiers de référence

Architecture : /home/gouroubleu/.claude/CLAUDE.md
Session précédente : /home/gouroubleu/tasks/03-01-2026-03-15-reorganisation-vms-docker-claude.md
Windows storage : /home/gouroubleu/tasks/03-01-2026-02-30-session-complete-win11-storage.md