Rapport Migration Cutover — WD Black SN770 NVMe¶

Date : 2026-04-02 → mis à jour 2026-04-03 (session 4)
Rédacteur : GitHub Copilot (relai session agent)
Contexte : Suite de 20260331_PLAN-ARCHITECTURE-NVME.md — Migration complète + phase de nettoyage post-migration

1. ÉTAT D'AVANCEMENT¶

Script post-cutover (/mnt/lxc-data/docker-101/zensical/docs/history/post-cutover-script.sh)¶

État services (17h30 CEST, 2026-04-02) — initial¶

État services (session 2, post-nettoyage, 2026-04-02)¶

État accès SSH distant (session 4, 2026-04-03)¶

Suite à la migration, VS Code Remote SSH redemandait le mot de passe à chaque connexion depuis les PCs clients. Deux causes distinctes identifiées et résolues :

Point important Proxmox : ~/.ssh/authorized_keys sur PVE est un symlink → /etc/pve/priv/authorized_keys (géré par le cluster). ssh-copy-id écrit au bon endroit via le symlink. Ne jamais modifier ~/.ssh/authorized_keys directement.

# Sur chaque PC client (bash/PowerShell) — à faire une seule fois avec mot de passe
ssh-keygen -R 192.168.1.21
ssh-copy-id root@192.168.1.21

# Sur Windows PowerShell (si ssh-copy-id absent)
type $env:USERPROFILE\.ssh\id_rsa.pub | ssh root@192.168.1.21 "cat >> /etc/pve/priv/authorized_keys"

État post-fix : connexion VS Code Remote SSH sans mot de passe ✅

État Uptime Kuma (session 3, 2026-04-02)¶

Suite au redémarrage post-migration, de nombreuses sondes étaient DOWN. Cause : artefacts host PVE perdus à la réinstallation (non couverts par PBS — voir §4).

# Sur le host — vérifier que les disques sont montés
ls /mnt/media /mnt/storage

# Si pas montés :
mkdir -p /mnt/media /mnt/storage
mount UUID=05af2ac5-5cc6-4627-8b00-a908d20d12ff /mnt/media
mount UUID=dcb10492-1c84-497e-a027-6275e9b6d41f /mnt/storage

# Puis redémarrer les LXC affectés
pct restart 100
pct restart 101

2. CHANGEMENTS PAR RAPPORT AU PLAN¶

2.1 Mapping disques — CRITIQUE¶

Le plan supposait sdb = ancien Proxmox LVM. La réalité au moment du boot sur NVMe est :

Conséquence plan §5.2 : sdc dans le plan = PBS secondary. Or sdc1 = disque media (HGST 4TB). Le vrai candidat PBS secondary est sda (Samsung 850 EVO 250GB — l'ancien disque Proxmox) une fois les LV LXC inutiles supprimés.

2.2 lxc-data — ZFS mountpoint, pas bind mount¶

Le plan et le script prévoyaient un bind mount /rpool/lxc-data → /mnt/lxc-data. En pratique, la configuration a été faite via :

zfs set mountpoint=/mnt/lxc-data rpool/lxc-data

→ /mnt/lxc-data est monté directement par ZFS, pas via fstab bind mount.
Les lignes echo "/rpool/lxc-data /mnt/lxc-data zfs bind 0 0" >> /etc/fstab et echo "/rpool/scratch /mnt/scratch zfs bind 0 0" >> /etc/fstab ont probablement été écrites dans le fstab — à vérifier et nettoyer.

# Vérifier et corriger fstab
grep -n "rpool\|lxc-data\|scratch" /etc/fstab
# Supprimer les lignes bind mount ZFS si présentes (ZFS les monte lui-même)

2.3 fstab media/storage — UUIDs requis, pas /dev/sddX¶

Le script d'origine utilisait /dev/sdd1 et /dev/sde1. Ces noms peuvent changer au reboot. Les UUIDs stables sont :

# À ajouter dans /etc/fstab (remplacer ou compléter)
UUID=05af2ac5-5cc6-4627-8b00-a908d20d12ff  /mnt/media    ext4  defaults,nofail  0  2
UUID=dcb10492-1c84-497e-a027-6275e9b6d41f  /mnt/storage  ext4  defaults,nofail  0  2

Si des lignes /dev/sdc1 ou /dev/sdd1 existent déjà dans fstab suite à l'étape 13 — les remplacer par les UUIDs ci-dessus.

2.4 Timestamps PBS réels (différent du script initial)¶

2.5 Format volid PBS — préfixe backup/ requis¶

pct restore nécessite le format : pbs-local:backup/ct/NNN/TIMESTAMP
(pas pbs-local:ct/NNN/TIMESTAMP)

2.6 ashift — 12 (pas 13)¶

Le plan recommandait ashift=13 (SN770 secteurs 4K natifs). L'installeur Proxmox a créé le pool avec ashift=12. Le pool est ONLINE, ne pas modifier — ashift=12 fonctionne correctement (performance non critique).

3. OBSTACLES RENCONTRÉS ET RÉSOLUTIONS¶

Phase 1 — Boot sur SN770¶

Phase 2 — APT et PBS¶

Phase 2 — Storage PBS dans PVE¶

Phase 2 — Restauration LXC¶

4. CONFIGURATION ACTUELLE DU SERVEUR¶

Réseau¶

Interface : enp4s0 (physique) ← vmbr0 (bridge Proxmox)
IP host   : 192.168.1.21 / 24
Gateway   : 192.168.1.254
DNS       : configuré dans /etc/resolv.conf

ZFS¶

rpool      ONLINE  nvme0n1p3 (WD Black SN770)
├── ROOT/pve-1     ~10GB  OS Proxmox
├── data/          quota=200G  LXC rootfs (vm-NNN-disk-0)
├── pbs/           quota=450G  recordsize=1M  Datastore PBS
├── lxc-data/      quota=80G   mountpoint=/mnt/lxc-data
└── scratch/       quota=120G  sync=disabled

Disques non-NVMe (état post-nettoyage, session 2)¶

sda        Samsung 850 EVO 250GB — ext4 label=pbs-secondary ✅ (reformaté session 2)
           UUID=0318e50f-7d84-497e-b914-198df22ef827
           Monté sur /mnt/pbs-secondary (229GB disponible)
           Rsync nightly 02h30 : /rpool/pbs/ → /mnt/pbs-secondary/pbs/

sdb1       ext4 label=lxc-storage — SMART PASSED, non monté
           UUID=2b18b88e-a498-4429-9a02-f22315d7b1fb
           Rôle : spare froid (candidat second PBS backup ou SnapRAID)

sdc1       ext4 label=media — HGST 4TB media Jellyfin
           UUID=05af2ac5-5cc6-4627-8b00-a908d20d12ff
           Monté sur /mnt/media

sdd1       ext4 label=storage-cloud — IronWolf 4TB
           UUID=dcb10492-1c84-497e-a027-6275e9b6d41f
           Monté sur /mnt/storage

PBS — LXC 102 (configuration finale ✅)¶

LXC 102    : 192.168.1.102, unprivileged=0, 2c/2GB
Service    : proxmox-backup.service + proxmox-backup-proxy.service — ACTIFS
Datastore  : backup → /mnt/datastore (bind mount mp0=/rpool/pbs)
API token  : root@pam!pve-token = 25f2915a-67d7-4a05-9f4f-a9f14d3fed02
Fingerprint: 36:97:a9:56:f1:ab:2b:aa:a6:11:cd:e4:d7:de:66:07:d1:44:88:9f:7a:27:99:08:8f:a3:4d:8a:cb:56:94:a4
Storage PVE: pbs-backups — 192.168.1.102, datastore=backup, 471GB total / 38GB utilisé
Job backup : 2d447659-7185-4945-a691-5bed3b42aebc — 6 LXC, 23h00, zstd
PBS host   : DÉSACTIVÉ (systemctl disable proxmox-backup proxmox-backup-proxy)

LXC restaurés¶

102 — pbs        — 192.168.1.102  unprivileged=0  2c/2GB  mp0=/rpool/pbs→/mnt/datastore
100 — docker-media — 192.168.1.100  unprivileged=1  6c/8GB
101 — management   — 192.168.1.101  unprivileged=1  2c/1GB
103 — network-gateway — 192.168.1.103  unprivileged=1  2c/2GB
104 — services     — 192.168.1.104  unprivileged=1  2c/2GB
105 — web          — 192.168.1.105  unprivileged=1  2c/2GB

5. TÂCHES RESTANTES¶

✅ MIGRATION COMPLÈTE — Toutes les tâches ont été réalisées en session 1 et session 2.

Éléments non critiques (décision différée)¶

• sdb (232GB, lxc-storage) : spare froid, aucune action requise
• SnapRAID sur sdd/sde : voir plan §4 Phase 4 — non prioritaire
• Uptime Kuma rétention 30 jours : réglage UI uniquement

6. INFORMATIONS TECHNIQUES CRITIQUES POUR L'AGENT¶

APT — Format deb822 obligatoire sur trixie¶

Ne jamais ajouter de repos dans /etc/apt/sources.list (coexistence avec debian.sources → doublons).
Utiliser /etc/apt/sources.list.d/*.sources (format deb822) :

# Exemple : /etc/apt/sources.list.d/pbs.sources
Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription

Fichiers enterprise à garder vides (pas supprimés) :

• /etc/apt/sources.list.d/pve-enterprise.sources
• /etc/apt/sources.list.d/ceph.sources

PBS — Pièges connus¶

1. /etc/proxmox-backup → chmod 700 + chown backup:backup obligatoire
2. datastore.cfg → indentation tabulation (\t), jamais espaces
3. proxy.pem doit exister avant démarrage
4. Authentification PVE→PBS : ne pas utiliser root@pam direct (401 PAM) → API token PBS
5. pvesm add pbs : passer --password explicitement, le .pw n'est pas lu à la création

Bash — Pièges copier-coller¶

• Le ! dans root@pam!pve-token déclenche l'expansion d'historique en bash interactif → toujours guillemets simples
• Les commandes multilignes avec \ collées depuis le script peuvent se concaténer → copier-coller ligne par ligne ou via fichier temporaire
• set -e dans le script original → si une commande échoue, tout s'arrête → exécution étape par étape recommandée

ZFS — Commandes utiles¶

zpool status rpool                              # santé pool
zfs list -o name,used,avail,quota              # usage datasets
zpool get autotrim rpool                       # vérifier autotrim
zfs get compression,atime,recordsize rpool/pbs # paramètres PBS dataset

7. FICHIERS MODIFIÉS SUR LE SERVEUR (changelog)¶

4. ARTEFACTS HOST PVE — LACUNE DU PROCESS DE BACKUP¶

Contexte¶

La migration impliquait une réinstallation fraîche de Proxmox VE sur NVMe. Les backups PBS ne couvrent que les rootfs LXC — jamais le rootfs du host (rpool/ROOT/pve-1). Trois catégories d'artefacts ont donc été perdues et ont causé des sondes Uptime Kuma DOWN en session 3.

Ce qui est dans rpool/ROOT (perdu à la réinstall)¶

Ce qui est dans rpool/lxc-data (survit)¶

• kuma.db avec les push tokens des monitors → les tokens survivent, mais sans les scripts cron pour les alimenter, les monitors passent DOWN
• Tous les configs Docker des LXC (docker-compose.yml, etc.)
• Les scripts source Python (setup-*.py, restore-host-artefacts.sh)

Pourquoi ces artefacts n'étaient pas dans le plan¶

Le plan 20260331_PLAN-ARCHITECTURE-NVME.md était centré sur la migration data (ZFS, PBS, LXC). Les artefacts host PVE ont été implicitement supposés "automatiquement présents" car ils avaient été créés manuellement lors de la mise en place initiale du monitoring — sans procédure documentée de re-déploiement.

Résolution systémique¶

Un unique script de restauration a été créé :

bash /mnt/lxc-data/docker-101/uptime-kuma/restore-host-artefacts.sh

Ce script est idempotent et doit être ajouté au post-cutover de toute future migration PVE (après l'étape de démarrage des LXC).

6. SCRIPTS BACKUP HOST — PERTE ET RESTAURATION (session 5, 2026-04-03)¶

Constat¶

Les scripts de backup quotidiens (backup-proxmox-host.sh, backup-docker-configs.sh) et leur configuration associée ont été perdus lors de la migration : ils résidaient dans le rootfs de l'ancien Proxmox (sdb) et n'ont pas été restaurés en session ½ car la procédure de restauration couvrait uniquement les LXC (PBS) et les artefacts de monitoring (session 3).

Conséquence : depuis le 2026-04-02 (migration), aucun backup configs host ni lxc-data ne s'était exécuté.

Diagnostic¶

Vérification immédiate : ni backup-proxmox-host.sh, ni backup-docker-configs.sh présents dans /usr/local/bin/, crontab -l vide, rclone absent du PATH, /root/.config/rclone/ inexistant.

Récupération¶

Les scripts étaient récupérables : le backup du 2026-04-02 05:00 (tourné sur l'ancien système avant le cutover) est présent sur Google Drive et contient les deux scripts.

# Extraction depuis GDrive via rclone de LXC 102 (déjà configuré)
pct exec 102 -- rclone cat "gdrive:backup/homeserver/proxmox/proxmox-host-config-20260402-050001.tar.gz" \
  | tar -xzvf - --strip-components=0 \
    usr/local/bin/backup-proxmox-host.sh \
    usr/local/bin/backup-docker-configs.sh \
    -C /

# Installer rclone v1.73.x (apt fournit v1.60 — trop ancien)
curl https://rclone.org/install.sh | bash

# Copier le token OAuth depuis LXC 102 (déjà valide)
mkdir -p /root/.config/rclone
pct exec 102 -- cat /root/.config/rclone/rclone.conf > /root/.config/rclone/rclone.conf
chmod 600 /root/.config/rclone/rclone.conf

# Restaurer les crons
( crontab -l 2>/dev/null; \
  echo "0 5 * * * /usr/local/bin/backup-proxmox-host.sh"; \
  echo "0 5 * * * /usr/local/bin/backup-docker-configs.sh" ) | crontab -

Fix lacune du script de backup¶

backup-proxmox-host.sh ne sauvegardait pas /var/spool/cron/crontabs/ (user crontab root) ni /root/.config/rclone/ — deux éléments indispensables à la restauration. Corrigé dans le script restauré :

# Ajouté dans le tar de backup-proxmox-host.sh
/root/.config/rclone/ \
/var/spool/cron/crontabs/ \

État post-restauration (2026-04-03 22:59 CEST)¶

Leçon pour futures migrations¶

Le crontab -l de root et /root/.config/rclone/ doivent impérativement figurer dans le périmètre du script de backup host. Une migration fraîche de Proxmox ne restaure aucun de ces éléments — et sans rclone + crontab, la chaîne de backup configs s'interrompt silencieusement.