Incus 7.4 réduit les données d’un conteneur restant à transférer lors d’un déplacement. Il ne préserve pas les processus en cours : le conteneur redémarre à destination. Cette distinction compte davantage pour une maintenance que l’expression near-live.
Le stockage migre, la mémoire des processus ne suit pas
L’annonce du 28 août décrit des snapshots successifs pendant l’exécution, puis un dernier transfert à l’arrêt et un redémarrage à destination. Ce mécanisme concerne les conteneurs sur stockage local ZFS ou Btrfs, pas tous les pilotes de stockage ni la migration de mémoire des VM.
Le guide de migration présente les déplacements entre serveurs. Pour ce nouveau mode, l’annonce utilise incus move avec --stateless et --refresh ; une évacuation de cluster peut choisir refresh-migrate. Le caractère stateless a un effet concret : une file en mémoire ou une connexion client ouverte ne doit pas être supposée conservée.
Inclure la reprise applicative dans l’interruption
Un modèle de préparation utile est :
Indisponibilité ≈ arrêt et vidage + dernier transfert + démarrage du conteneur + reprise applicative + validation de santé.
Dans un exemple entièrement fictif, 2 Gio restant à copier à un débit effectif de 100 Mio/s demandent environ 20,5 secondes pour ce seul transfert. Avec 5 secondes d’arrêt, 8 de démarrage, 20 de reprise de base de données et 3 de validation, le total prévisionnel atteint environ 56,5 secondes. Ce sont des hypothèses de calcul, pas un benchmark Incus ni une borne maximale. Des écritures soutenues peuvent grossir le dernier delta ; la reprise peut dominer même avec un petit delta.
Mesurez ces étapes sur une copie jetable de votre service. Relevez la dernière requête externe réussie et le retour durable de réponses correctes après redémarrage. La durée de copie du stockage ne mesure pas toute la panne.
Vérifier ce qui dépend du serveur d’origine
Inventoriez les disques attachés, chemins de l’hôte, périphériques, adresses réseau et secrets fournis par le serveur source. Une copie réussie du volume racine ne prouve pas qu’une base externe, un partage ou un périphérique sera accessible à destination. Testez démarrage et reconnexion avec le réseau réellement prévu.
Conservez une sauvegarde indépendante et définissez quelle instance fait autorité après la bascule. Redémarrer une ancienne copie de base après que la nouvelle a accepté des écritures n’est pas un retour arrière anodin.
Deux autres raisons d’examiner la mise à niveau
La version 7.4 corrige aussi une traversée de chemins lors de l’export d’images côté client et un accès restreint aux images privées entre projets. Les avis détaillent versions touchées et branches corrigées ; ces correctifs sont distincts de la compatibilité du stockage avec la migration near-live.
Sources
- Annonce Incus 7.4
- Déplacement des instances entre serveurs
- Avis concernant l’export d’images
- Avis concernant les images privées
Vérification de l’annonce et de la documentation ; redémarrage et reprise applicative inclus dans l’interruption, limites du stockage et avis de sécurité précisés.