Comment vérifier une restauration de Home Assistant avant de mettre l’ancien serveur hors service

Ne mettez pas hors service l’ancien serveur Home Assistant simplement parce que le tableau de bord restauré se charge. Faites-le uniquement après que la nouvelle instance a réussi les vérifications d’identité, d’appareils, d’automatisations, d’historique, de dépendances, de redémarrage et de nouvelle sauvegarde dans des conditions contrôlées.

Gardez l’ancien serveur éteint, mais intact, pendant que vous testez l’hôte restauré sur un réseau isolé ou soigneusement contrôlé. Empêchez les deux instances d’émettre des commandes simultanément, consignez une liste de contrôle de décision établie à partir de l’ancien système et reproduisez les déclencheurs réels du domicile avant d’effacer les disques, de modifier définitivement le DNS ou de réaffecter l’ancien matériel.

Définissez la liste de contrôle d’acceptation de la restauration avant les tests

Notez la version de l’ancienne instance, le type d’installation, le nom d’hôte, l’adresse IP ou le nom DNS, le fuseau horaire, les comptes utilisateur, les intégrations, les appareils, les entités, les automatisations, les tableaux de bord, les modules complémentaires, les destinations de sauvegarde, la base de données externe, les partages, les certificats et les dépendances liées aux secrets. Cet inventaire définit ce qu’une restauration complète signifie pour votre domicile.

Séparez les fonctions critiques des éléments de confort. L’alarme, les serrures, les alertes de fumée, le chauffage, la détection des fuites et l’éclairage essentiel doivent faire l’objet d’une vérification manuelle explicite ; les tableaux de bord décoratifs et l’ancien historique peuvent attendre. La décision de mise hors service doit être négative si une fonction critique manque, même si la plupart des nombres d’entités correspondent.

Notez quelques valeurs d’état connues et plusieurs points d’historique récents avant d’arrêter l’ancien hôte. Ils serviront de repères de comparaison sur l’instance restaurée et aideront à distinguer une sauvegarde incomplète d’un problème d’intégration nouvellement découvert.

Restaurez en isolation et empêchez les commandes en double

Restaurez sur le nouveau serveur tandis que l’ancienne instance Home Assistant est arrêtée. Si les deux doivent être en ligne pour comparer des fichiers, isolez la nouvelle instance des réseaux d’appareils ou désactivez les automatisations et les intégrations sortantes jusqu’à la résolution des conflits d’identité.

Une discussion de la communauté présente explicitement un test de restauration isolé comme la méthode sûre pour valider une migration entre plateformes de virtualisation. Cela confirme la méthode de test, tandis que l’isolation exacte du réseau dépend de votre installation et des protocoles utilisés par vos appareils.

Confirmez la compatibilité entre la version restaurée et la sauvegarde avant de conclure à l’absence de composants. Si la restauration signale des erreurs, n’ajoutez pas de corrections manuelles à un état inconnu. Enregistrez les journaux, déterminez si l’échec concerne l’archive, le chiffrement, la version, le stockage ou une intégration, puis réessayez sur une cible de test propre.

Vérifiez l’état, les dépendances et les actions réelles des appareils

Comparez les utilisateurs, les intégrations, le nombre d’appareils et d’entités, les entités désactivées, les zones, les tableaux de bord, les assistants, les scripts et les automatisations. Ouvrez ensuite l’historique récent et les journaux. Les nombres sont de bons indicateurs de présélection, mais ils ne prouvent pas que les identifiants, les jetons, les webhooks, les adaptateurs radio ou les bases de données externes fonctionnent.

Testez un appareil de chaque protocole important et exécutez des automatisations représentatives avec leurs véritables déclencheurs. Confirmez à la fois l’action et la mise à jour de l’état qui en résulte. Pour les adaptateurs radio dépendant du matériel, vérifiez les chemins d’appareils et les autorisations ; pour les intégrations cloud, vérifiez le renouvellement des jetons ; pour les bases de données externes et les partages, confirmez que l’hôte restauré accède aux bonnes données plutôt qu’à un remplacement vide.

Consultez le guide ZimaSpace sur le chiffrement des sauvegardes et les dépendances de restauration lorsque l’archive existe, mais qu’une clé, un identifiant, une chaîne ou un emplacement externe bloque la récupération.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Prouvez la persistance avec des redémarrages et une nouvelle sauvegarde

Redémarrez Home Assistant deux fois et redémarrez le nouvel hôte une fois. Après chaque cycle, confirmez que les intégrations se rechargent, que les points de montage sont disponibles avant les services, que les chemins des appareils USB ou série restent stables, que les automatisations sont activées comme prévu et que la même base de données d’historique continue d’être utilisée au lieu de repartir de zéro.

Créez une nouvelle sauvegarde depuis le système restauré, copiez-la hors de l’hôte et vérifiez que les composants attendus sont inclus. Une restauration incapable de produire sa propre sauvegarde récupérable n’est pas prête à devenir l’unique instance de production.

Observez le système restauré pendant au moins un cycle domestique normal comprenant des automatisations planifiées, des sauvegardes et des tâches nocturnes. La décision de validation exige un contrôle stable, l’absence d’erreurs répétées liées à la migration ou au stockage, ainsi qu’une procédure de retour arrière vérifiée.

Mettez l’ancien serveur hors service sans détruire la fenêtre de retour arrière

Lorsque la liste de contrôle est validée, transférez le DNS permanent, les réservations d’adresses IP, l’accès distant et les planifications de sauvegarde vers le nouvel hôte. Gardez l’ancien serveur éteint afin qu’il ne puisse pas émettre d’actions en double, mais préservez son disque et sa configuration sans modification pendant une période d’observation définie.

Si le nouveau serveur oublie une automatisation critique, perd son état après un redémarrage, écrit dans la mauvaise base de données ou ne peut pas créer une sauvegarde valide, la décision est négative. Éteignez-le, rétablissez si nécessaire l’ancienne identité réseau et revenez à l’hôte connu comme fonctionnel avant d’enquêter.

N’effacez ou ne réaffectez l’ancien serveur qu’après que le nouvel hôte a traversé la période d’observation et qu’au moins une sauvegarde externe a été vérifiée. Documentez la date de mise hors service, la dernière sauvegarde de l’ancien système, l’identité du nouvel hôte et le résultat du test de restauration afin que la prochaine migration commence sur une base fiable.