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
- Sur la page Accueil, sélectionnez Sauvegarde. L'onglet Vue d’ensemble s'ouvre.
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é.
(Agrandir)
- 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.
- 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.
- 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.
- 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'état | Contenu |
|---|---|
inventory.redb | L'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.redb | L'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.tomletconfig/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éfaut | Signification |
|---|---|---|
controller_target | dossier controller-backups à côté de data_dir, par exemple /var/lib/kyvernon/controller-backups | Dossier des archives. |
controller_schedule | non défini | Heure du jour en UTC (02:30) ou intervalle (12h). Non défini : uniquement à la demande. |
controller_retention | 7 | Nombre 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 :
kyvernon system controller-backups
kyvernon system controller-backup --waitModifiez 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 :
kyvernon system set-controller-backup --target /var/lib/kyvernon/controller-backups \
--schedule 02:30 --retention 7Pour restaurer depuis une archive, arrêtez le contrôleur, extrayez l'état, copiez la configuration et démarrez le contrôleur :
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 readyDé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 :
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 readyDé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 :
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.tarVérifiez la configuration et démarrez le service :
sudo kyvernon-controller --config /etc/kyvernon/controller.toml check-config
sudo systemctl start kyvernon-controller.service
kyvernon system readyUne 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 :
| Champ | Signification |
|---|---|
enabled | Une planification est définie. |
target, schedule, retention | Les paramètres en vigueur. |
lastRunAt, lastResult, lastSizeBytes, lastError | La dernière exécution. |
nextRunAt | La prochaine exécution planifiée. |
stateDirectory | Le répertoire archivé. |
running | Une exécution est en cours. |
archives | name 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.
Voir aussi
- Configuration pour les paramètres du magasin.
- Mise à niveau, qui commence par une copie du contrôleur.
- Désinstaller, qui supprime le répertoire d'état.
Version 0.1. Dernière modification : 2026-11-14