Procédure Pour: administrateurs

Sauvegarder le contrôleur

Sauvegarder l'état du contrôleur depuis la console, à la demande ou planifié, et le restaurer sur la même machine ou sur une nouvelle.

Le contrôleur garde son état dans un seul répertoire, /var/lib/kyvernon/controller. Il contient l'inventaire, les utilisateurs, rôles et autorisations, les tâches, événements et enregistrements d'audit, la licence, les clés de l'installation et le certificat TLS auquel les hôtes font confiance. Une copie de ce répertoire et de la configuration restaure le contrôleur.

La copie ne contient ni les disques des machines virtuelles ni les fichiers des datastores : ils se trouvent sur les hôtes et sur le stockage qui les soutient. Sauvegardez-les comme décrit dans Sauvegarder une machine virtuelle. Lancer une copie demande le privilège Global.Settings.

Dans la console

  1. Sur la page Accueil, sélectionnez Sauvegarde. L'onglet Vue d’ensemble s'ouvre.
  2. Lisez la carte Sauvegarde du contrôleur. État vaut En bon état, La dernière sauvegarde a échoué ou Désactivé. La carte affiche aussi Dernière sauvegarde, Taille de la dernière copie, Prochaine sauvegarde, Planification, Copies conservées, le répertoire Destination des copies et le répertoire Répertoire d’état copié.

    Vue d'ensemble des sauvegardes avec la sauvegarde du contrôleur (Agrandir)
  3. Sélectionnez Sauvegarder le contrôleur maintenant. La tâche est dans Tâches, et la carte affiche la nouvelle heure et la taille à la fin.
  4. Lorsque la dernière copie a échoué, la carte affiche l'erreur. Corrigez la cause, par exemple un disque plein à la cible, et sélectionnez à nouveau Sauvegarder le contrôleur maintenant.
  5. Pour changer le moment des copies, sélectionnez Modifier la planification. Activez ou désactivez Sauvegarder le contrôleur, saisissez le dossier sous Destination des copies, la Planification sous la forme d'une heure du jour en UTC comme 03:15 ou d'un intervalle comme 6h, et le nombre de copies sous Archives conservées, puis sélectionnez Enregistrer la planification. La plus ancienne copie est supprimée quand une nouvelle est faite.
  6. Déplacez régulièrement les copies hors de la machine. Une copie sur la même machine ne protège pas contre la perte de cette machine.

Modifier la planification exige le privilège Global.Settings. Un contrôleur qui ne peut pas la modifier depuis la console le dit dans la boîte de dialogue ; l'opérateur définit alors la planification, la cible et le nombre de copies conservées dans la configuration du contrôleur, voir Configuration.

Résultat

La carte Sauvegarde du contrôleur affiche En bon état, l'heure de la copie et sa taille. Les modifications faites après la copie n'y figurent pas.

Contenu de la copie

Chemin sous le répertoire d'étatContenu
inventory.redbL'inventaire, les utilisateurs, les autorisations, les tâches, les événements et les enregistrements d'audit, les groupes locaux et la politique de mots de passe et de verrouillage
metrics.redbL'historique de performance et le registre de consommation
keys/La clé d'identité (scelle les secrets de la validation en deux étapes et l'intégrité des jetons d'API) et la clé de signature du service de jetons vSphere
tls/Le certificat et la clé d'amorçage que les hôtes et les clients épinglent
licence/Les fichiers de licence installés
identity/Uniquement des fichiers d'une version antérieure. Les groupes locaux et la politique de mots de passe et de verrouillage sont désormais dans inventory.redb.
backup/Les sessions de sauvegarde et leurs identifiants de modification
content/, customization/Les bibliothèques de contenu et les profils de personnalisation

Sans la clé d'identité, les secrets de la validation en deux étapes et les jetons d'API ne sont plus utilisables. Gardez la copie là où seuls les administrateurs peuvent la lire. La copie demande autant d'espace libre que le répertoire, et une mise à niveau qui déplace l'historique sur disque demande de la place pour une seconde copie du magasin (Mise à niveau).

Archives prises par le contrôleur

Le contrôleur écrit une archive de son propre état, selon une planification ou à la demande, sans s'arrêter. Le contrôleur leader l'exécute pour son propre état. La console lance une archive et règle sa planification comme décrit ci-dessus.

Contenu d'une archive

Une archive est un fichier tar simple nommé controller-<heure UTC>.tar, par exemple controller-20261114T023000Z.tar. Le fichier a le mode 0600 et le dossier 0700. Elle contient :

  • controller-backup.json, une description avec un SHA-256 pour chaque fichier.
  • controller/inventory.redb, une copie cohérente du magasin, faite à partir d'une seule transaction de lecture pendant que le contrôleur fonctionne.
  • controller/metrics.redb, une copie cohérente des métriques et du registre de consommation.
  • Tous les autres fichiers du répertoire d'état.
  • config/controller.toml et config/join-token, lorsque le contrôleur les connaît.

Le contrôleur écrit l'archive sous forme de fichier .partial, la relit et vérifie chaque fichier par rapport à son SHA-256 avant de la conserver. Il supprime ensuite les archives les plus anciennes au-delà de la rétention.

Paramètres

La cible, la planification et le nombre de copies sont ces clés de la section [backup] de controller.toml :

CléPar défautSignification
controller_targetdossier controller-backups à côté de data_dir, par exemple /var/lib/kyvernon/controller-backupsDossier des archives.
controller_schedulenon définiHeure du jour en UTC (02:30) ou intervalle (12h). Non défini : uniquement à la demande.
controller_retention7Nombre d'archives conservées.

La cible par défaut se trouve sur la même machine que l'état. Faites pointer controller_target vers un stockage ailleurs, ou déplacez les archives hors de la machine.

Restauration

La console n'est pas disponible tant que le contrôleur est arrêté : une restauration se fait donc sur la machine ; les étapes sont dans Automatisation. Restaurez vers la même version de Kyvernon que celle de la copie, ou vers une plus récente. Une version plus ancienne ne peut pas ouvrir un magasin qu'une version plus récente a modifié ; voir Mise à niveau.

Lorsque le contrôleur fonctionne à nouveau, ouvrez la console et vérifiez les hôtes sur l'onglet Hôtes de chaque cluster. Un hôte qui ne se connecte pas est décrit dans Dépannage.

Automatisation

Avec la CLI

Lisez les sauvegardes du contrôleur et lancez-en une maintenant. controller-backups affiche l'état et les archives. controller-backup lance une exécution maintenant ; --wait attend la fin de la tâche :

Shell
kyvernon system controller-backups
kyvernon system controller-backup --wait

Modifiez le dossier, la planification et le nombre d'archives conservées. La modification est conservée dans le stockage répliqué, au-dessus des clés [backup], et chaque contrôleur l'applique ; --disabled garde la planification sans prendre d'archives :

Shell
kyvernon system set-controller-backup --target /var/lib/kyvernon/controller-backups \
  --schedule 02:30 --retention 7

Pour restaurer depuis une archive, arrêtez le contrôleur, extrayez l'état, copiez la configuration et démarrez le contrôleur :

Shell
sudo systemctl stop kyvernon-controller.service
sudo tar --numeric-owner -C /var/lib/kyvernon -xpf controller-<time>.tar controller
mkdir -p /tmp/kyv
sudo tar -C /tmp/kyv -xpf controller-<time>.tar config
sudo cp /tmp/kyv/config/* /etc/kyvernon/
sudo systemctl start kyvernon-controller.service
kyvernon system ready

Déplacez les archives hors de la machine. Les autres étapes de la restauration manuelle ci-dessous s'appliquent à une machine installée à neuf.

Copie manuelle

Une copie manuelle demande une courte pause du contrôleur : tant qu'il est arrêté, aucune tâche ne s'exécute et la console et les API ne répondent pas. L'arrêter n'arrête pas les machines virtuelles. Arrêtez le contrôleur pour que le magasin soit copié dans un état cohérent, copiez le répertoire et la configuration, puis redémarrez-le :

Shell
sudo systemctl stop kyvernon-controller.service
sudo tar --numeric-owner -C /var/lib/kyvernon -cpf controller-state.tar controller
sudo tar --numeric-owner -C /etc/kyvernon -cpf controller-config.tar controller.toml join-token
sudo systemctl start kyvernon-controller.service
kyvernon system ready

Déplacez les deux archives hors de la machine. Ne les modifiez pas.

Pour restaurer, installez le paquet du contrôleur sur la machine (Installer depuis un dépôt hors ligne) et ne démarrez pas le service. Décompressez la configuration et l'état :

Shell
sudo tar -C /etc/kyvernon -xpf controller-config.tar
sudo mkdir -p /var/lib/kyvernon
sudo tar --numeric-owner -C /var/lib/kyvernon -xpf controller-state.tar

Vérifiez la configuration et démarrez le service :

Shell
sudo kyvernon-controller --config /etc/kyvernon/controller.toml check-config
sudo systemctl start kyvernon-controller.service
kyvernon system ready

Une machine qui a un autre nom ou une autre adresse demande ses noms dans le paramètre san de la section [tls] de controller.toml, et les agents demandent la nouvelle adresse dans le paramètre endpoint de agent.toml.

Avec l'API

GET /v1/backup/controller exige System.Read. Il affiche :

ChampSignification
enabledUne planification est définie.
target, schedule, retentionLes paramètres en vigueur.
lastRunAt, lastResult, lastSizeBytes, lastErrorLa dernière exécution.
nextRunAtLa prochaine exécution planifiée.
stateDirectoryLe répertoire archivé.
runningUne exécution est en cours.
archivesname et sizeBytes de chaque archive, la plus récente d'abord.

PUT /v1/backup/controller exige Global.Settings et prend enabled, target (un dossier absolu que le contrôleur peut créer), schedule (nécessaire avec enabled) et retention (1 à 365). Il répond l'état comme GET.

POST /v1/backup/controller/run exige Global.Settings. Il lance la tâche ServiceInstance.backupControllerState, une copie maintenant.

Version 0.1. Dernière modification : 2026-11-14