Comment tester si les sauvegardes de Home Assistant sont réellement restaurables

Une sauvegarde de Home Assistant n’est considérée comme éprouvée que lorsqu’une instance distincte peut la restaurer et fournir les identités, la configuration, les intégrations, l’historique et le délai de récupération requis par le foyer.

Une tâche d’archivage réussie vérifie la création, pas la récupération. Utilisez une machine virtuelle isolée, un appareil de secours ou un segment réseau déconnecté ; laissez la production fonctionner ; préparez la clé de chiffrement et le chemin d’installation correspondant ; puis testez à la fois le démarrage technique et les fonctions réelles du foyer. Arrêtez-vous avant que des automatisations clonées, des appareils radio ou des webhooks puissent agir sur les appareils de production.

Choisir la sauvegarde et définir les critères de réussite

Sélectionnez une sauvegarde planifiée récente et un point de récupération plus ancien, puis notez leur taille, leur date de création, leurs composants inclus, leur emplacement de stockage, leur état de chiffrement et leur somme de contrôle si elle est disponible. Définissez le délai maximal de récupération ainsi que la configuration exacte, les utilisateurs, les automatisations, les historiques, les modules complémentaires et les secrets qui doivent être restaurés.

La réussite ne peut pas se résumer à l’apparition de la page de connexion. Elle doit préciser les fonctions du foyer qui comptent, comme le contrôle local de l’éclairage, une automatisation critique, les tableaux de bord destinés aux utilisateurs habituels, la durée de conservation de la base de données et l’accès à tout courtier ou toute base de données externe.

Échouez la phase de préparation si l’archive ou la clé de récupération n’existe que sur le disque de production, si le type d’installation ne peut pas restaurer directement cet artefact ou si aucune cible isolée ne peut empêcher les actions en double. Corrigez ces conditions avant d’intervenir sur la production.

Restaurer dans une cible isolée

Créez une cible vierge dotée d’une architecture compatible et de suffisamment d’espace de stockage, isolez son réseau des chemins menant aux appareils de production et conservez un accès à la console pour le dépannage. Lancez la restauration à partir d’une copie de l’archive, et non de l’unique sauvegarde conservée.

Même un test de restauration isolé peut nécessiter un accès réseau au superviseur. Concevez l’isolation de sorte que les ressources d’installation requises restent accessibles sans exposer les appareils de production.

Si la restauration échoue avant le démarrage, notez l’étape exacte, l’erreur d’archive, le résultat de la clé, l’espace libre, la version de la cible et le type d’installation. Ne téléversez pas plusieurs fois la seule copie et ne la modifiez pas ; préservez-la et testez une deuxième sauvegarde connue afin de distinguer une archive endommagée d’une incompatibilité de la cible.

Vérifier l’état, les dépendances et les fonctions du foyer

Après le démarrage, comparez les utilisateurs, les tableaux de bord, les entités, les automatisations, les assistants, les références aux secrets, l’historique de la base de données, les modules complémentaires et l’état des intégrations avec la liste des critères de réussite. Gardez les appareils radio déconnectés ou utilisez des substituts sûrs jusqu’à ce que l’instance clonée ne puisse plus transmettre de commandes en double.

La possibilité de restaurer sur un matériel temporaire prouve davantage que le simple stockage de copies à plusieurs endroits sans véritable tentative de récupération.

L’absence d’une base de données externe, d’un courtier, d’un enregistrement DNS, d’un certificat ou d’un partage réseau fait partie du résultat de la restauration, et non d’un désagrément sans rapport. Documentez la dépendance et l’ordre requis pour la récupérer.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Mesurer la récupération et clôturer l’exercice

Exécutez les contrôles définis du pilotage local et des automatisations, redémarrez deux fois l’instance de test et confirmez que l’état restauré persiste. Notez le temps écoulé entre une cible vierge et un service utilisable, les étapes manuelles, les fonctions indisponibles ainsi que chaque identifiant ou dépendance qui a dû être récupéré séparément.

Comparez le résultat avec le contrôle de restauration préalable à la mise hors service avant de modifier le matériel ou de retirer le système source.

Ne validez la restauration que lorsque les fonctions et les données requises survivent à un redémarrage dans le délai de récupération prévu. Détruisez ou mettez en quarantaine le clone après avoir recueilli les preuves, corrigez la portée de la sauvegarde ou le stockage de la clé, créez une nouvelle sauvegarde et répétez l’exercice avant de déclarer sûre la voie de récupération de la production.

Planifier la prochaine vérification avant toute modification du système

Notez l’identifiant de la sauvegarde testée, la version source, le type de cible, la durée de récupération, les dépendances manquantes et la conclusion finale. Conservez ces preuves avec la procédure de récupération plutôt que dans l’instance de production qu’elles pourraient devoir remplacer.

Planifiez l’exercice suivant après toute modification importante du stockage, de l’installation, du chiffrement, de la base de données ou d’un module complémentaire, ainsi qu’à intervalles réguliers adaptés à la tolérance du foyer en matière de récupération. Un fichier créé après l’exercice n’est pas automatiquement couvert par le résultat précédent.

Le prochain test peut utiliser une cible représentative plus petite, mais il doit toujours prouver le déchiffrement, le démarrage, les identités critiques et une fonction du foyer de bout en bout. Une simple inspection de l’archive ne peut pas remplacer cette vérification au niveau du service.