Incus OS : sauvegarder et superviser sans shell

Sur un serveur classique, on sauvegarde et on supervise avec un agent installé et un accès SSH. Sur Incus OS, il n'y a ni shell ni agent tiers : tout passe par l'API et le client de confiance. Ce guide montre comment sauvegarder les instances (snapshots, export), sauvegarder le nœud lui-même (clés de récupération), et superviser un cluster Incus OS avec un Prometheus externe et des logs centralisés. Public visé : administrateurs qui exploitent Incus OS en production, pas seulement en test.

Ce que vous allez apprendre

• Sauvegarder les instances par snapshot et par export portable.
• Sauvegarder le nœud : récupérer ses clés de chiffrement.
• Brancher un Prometheus externe sur les métriques d'Incus.
• Centraliser les logs vers un serveur syslog distant.
• Surveiller la santé du cluster par l'API.

Prérequis

• Un cluster Incus OS en service. Voir Incus OS sans interface.
• Un client Incus de confiance avec un remote vers un membre (node1:).
• Un serveur de sauvegarde ou un Prometheus joignable depuis le réseau d'administration.

Le modèle sans shell

L'absence de shell ferme les habitudes classiques : pas d'ssh pour lancer un dump, pas de node_exporter posé à la main sur le nœud. Ce n'est pas un oubli, c'est le modèle d'Incus OS. Tout ce qui suit se pilote à distance, depuis le poste d'administration, via l'API Incus et l'API système préfixée par /os. Rien n'est installé sur le nœud.

Sauvegarder les instances

La sauvegarde la plus rapide est le snapshot : une copie figée de l'instance, conservée dans le pool, utile avant une opération risquée. On la crée et on la liste à distance :

incus snapshot create node1:app1 snap-avant-maj
incus snapshot list node1:app1

+----------------+-----------------------+------------+----------+
|      NAME      |       TAKEN AT        | EXPIRES AT | STATEFUL |
+----------------+-----------------------+------------+----------+
| snap-avant-maj | 2026/07/03 09:27 CEST |            | NO       |
+----------------+-----------------------+------------+----------+

Un snapshot reste sur le nœud : il protège d'une fausse manipulation, pas d'une perte du nœud. Pour une sauvegarde hors site, l'export produit une archive portable que l'on stocke où l'on veut :

incus export node1:app1 /chemin/app1.tar.gz --instance-only

L'archive contient l'instance et ses snapshots (ou l'instance seule avec --instance-only). On la restaure sur n'importe quel membre du cluster, ou sur un autre cluster, par l'opération inverse :

incus import node1:/chemin/app1.tar.gz

Automatiser depuis l'hôte d'administration

Comme tout passe par le client, un simple cron sur le poste d'administration de confiance suffit à programmer snapshots et exports. Le nœud Incus OS n'a rien à exécuter ni à héberger pour cela.

Sauvegarder le nœud lui-même

Sauvegarder les instances ne suffit pas : un nœud Incus OS chiffre ses disques (racine, swap, pool), et sans les clés de récupération, un disque rescapé reste illisible. L'API système expose une sauvegarde dédiée qui rassemble ces secrets :

incus query -X POST node1:/os/1.0/system/:backup > node1-backup.tar.gz
tar tzf node1-backup.tar.gz

recovery.root.key
recovery.swap.key
state.txt
zpool.local.key

L'archive contient les clés de déchiffrement (recovery.root.key, recovery.swap.key, zpool.local.key) et un state.txt décrivant l'état du système. C'est court mais critique : à conserver dans un coffre, hors du nœud, pour chaque membre du cluster. La restauration se fait par l'endpoint symétrique /os/1.0/system/:restore.

Ces clés déverrouillent le nœud

Le contenu de cette sauvegarde permet de déchiffrer les disques du nœud. Traitez-la comme un secret de plus haute sensibilité : stockage chiffré, accès restreint, jamais dans un dépôt Git ni un partage ouvert.

Superviser avec un Prometheus externe

Incus expose ses métriques au format OpenMetrics sur l'endpoint /1.0/metrics, servi en HTTPS avec authentification par certificat. Un Prometheus externe les collecte sans rien installer sur le nœud :

curl -sk --cert client.crt --key client.key \
  https://192.168.10.131:8443/1.0/metrics

# HELP incus_cpu_seconds_total The total number of CPU time used in seconds.
# TYPE incus_cpu_seconds_total counter
incus_cpu_seconds_total{cpu="0",mode="user",name="app1",project="default",type="container"} 0.84
# HELP incus_disk_read_bytes_total The total number of bytes read.
# TYPE incus_disk_read_bytes_total counter
incus_disk_read_bytes_total{device="sda",name="app1",project="default",type="container"} 28672

Chaque série porte le nom de l'instance, son projet et son type, ce qui permet de suivre CPU, disque, mémoire et réseau par charge. Côté Prometheus, on configure un job qui pointe sur chaque membre avec le certificat en tls_config.

Un certificat limité aux métriques

Plutôt que le certificat d'administration, les versions récentes d'Incus acceptent un certificat dédié aux métriques, sans droit de gestion. Utilisez-le pour le scraping Prometheus : si ce certificat fuite, il n'expose que des mesures en lecture, pas le contrôle du cluster.

Centraliser les logs

Sans shell, on ne consulte pas journalctl sur le nœud. L'API système permet de renvoyer les logs vers un serveur syslog distant. L'endpoint expose la configuration attendue :

incus query node1:/os/1.0/system/logging

{
  "config": {
    "syslog": {
      "address": "",
      "log_format": "",
      "protocol": ""
    }
  }
}

En renseignant l'adresse du collecteur, le protocole et le format, chaque nœud pousse ses journaux vers votre pile de logs centralisée (par exemple un serveur syslog ou une stack de collecte). C'est la contrepartie logique du modèle sans shell : le nœud n'archive pas localement, il émet vers l'extérieur.

Surveiller la santé du cluster

Au-delà des métriques, deux points de contrôle rapides renseignent sur l'état général. La racine de l'API système indique si un nœud a fini de démarrer et se tient prêt :

incus query node1:/os/1.0

Le champ system_is_ready à true confirme qu'il est opérationnel. Au niveau du cluster, incus cluster list reste la vue de référence : la colonne STATUS doit afficher ONLINE et Fully operational pour chaque membre. Un OFFLINE inattendu est le premier signal à surveiller, en lien avec le seuil décrit dans le guide rôles et haute disponibilité.

Dépannage

Symptôme	Cause probable	Solution
/1.0/metrics renvoie 403	Certificat non approuvé	Ajouter le certificat au trust du cluster
L'export d'instance échoue faute de place	Archive volumineuse sur le poste	Exporter vers un stockage distant monté
Pas de logs côté collecteur	Configuration syslog incomplète	Renseigner adresse, protocole et format
Sauvegarde du nœud jugée « vide »	On attend les instances	:backup sauvegarde les clés, pas les instances ; les instances passent par export

Glissez pour voir

À retenir

• Sur Incus OS, sauvegarde et supervision se pilotent à distance, par l'API.
• Les instances se sauvegardent par snapshot (local) et export (portable, hors site).
• La sauvegarde du nœud (:backup) rassemble les clés de récupération : un secret critique à conserver au coffre.
• La supervision passe par un Prometheus externe sur /1.0/metrics, idéalement avec un certificat limité aux métriques.
• Les logs se centralisent vers un syslog distant via l'API système.
• system_is_ready et incus cluster list donnent la santé immédiate du cluster.

Prochaines étapes

Rôles, quorum et haute disponibilité Quorum, évacuation et santé du cluster.

Mises à jour A/B et rollback Mettre à jour le cluster sans coupure.

Stockage partagé CephFS Des volumes qui survivent à la perte d'un nœud.

Incus OS sans interface Le modèle sans shell, tout par API.

×

📖 Voir la documentation →