Comment RG 4 Tech crée un cloud privé avec ZimaBoard 2

RG 4 Tech transforme la ZimaBoard 2 en bien plus qu’un serveur de fichiers compact. Sa configuration associe un matériel x86 silencieux, deux disques connectés directement, un pool de stockage RAID 1 sous ZimaOS et Home Assistant au sein d’un même système administré depuis un navigateur. Le résultat constitue une base pratique de cloud privé pour les fichiers et les services de maison connectée, mais il nécessite toujours une sauvegarde indépendante ainsi qu’un plan de déploiement tenant compte des différences entre Home Assistant Container et Home Assistant OS.

Merci à RG 4 Tech d’avoir documenté la configuration complète. Sa vidéo originale présente le matériel, le refroidissement interne, la configuration initiale de ZimaOS, la mise en place d’un RAID 1 à deux disques, l’installation des applications et la prise en main de Home Assistant.

Note sur la source : cet article réorganise la configuration et les observations présentées dans la vidéo de RG 4 Tech. Il ne présume pas que tous les appareils visibles dans la vidéo ont été fournis par ZimaSpace, car aucune affirmation de collaboration de ce type n’a été établie indépendamment ici. Les détails de l’interface, les versions des applications, les packs disponibles, les températures et la compatibilité peuvent changer après la publication.

Résultat : la ZimaBoard 2 fournit à RG 4 Tech une plateforme compacte pour le stockage local et le contrôle de la maison connectée. Le RAID 1 maintient le pool de stockage disponible si l’un des disques tombe en panne, tandis que Home Assistant ajoute une couche d’automatisation locale. Aucune de ces fonctions ne dispense de sauvegarder les données et la configuration importantes en dehors du serveur.

Pourquoi RG 4 Tech commence par un serveur domestique local

L’expression « adieu au cloud » utilisée dans la vidéo ne signifie pas seulement éviter un abonnement mensuel. Un serveur domestique change l’identité de la personne qui contrôle le matériel de stockage, les applications qui traitent les données, la manière dont les services sont exposés au réseau et le moment où la capacité est augmentée. Ces choix deviennent particulièrement importants lorsque les fichiers personnels et l’activité de la maison connectée seraient autrement répartis entre plusieurs fournisseurs.

La gestion locale implique également de nouvelles responsabilités. Le propriétaire doit surveiller l’état des disques, installer les mises à jour, gérer les accès utilisateurs, maintenir les sauvegardes et restaurer les services après une panne. Un cloud privé n’est donc pas un service cloud dont on aurait simplement retiré le fournisseur ; c’est une petite infrastructure qui nécessite un plan d’exploitation.

RG 4 Tech considère la ZimaBoard 2 comme une base flexible plutôt que comme un appareil fermé. La carte peut commencer comme serveur de stockage, puis héberger des applications supplémentaires via ZimaOS, ce qui permet au système d’évoluer en fonction des usages réels du foyer.

Pourquoi la ZimaBoard 2 convient à cette configuration

Le ZimaBoard 2  Mini-serveur domestique  associe un processeur Intel N150, une mémoire et un stockage système intégrés, deux ports 2,5 GbE, deux connexions SATA et une interface d’extension PCIe ouverte. Cette combinaison est importante, car un serveur domestique a besoin de plus que de performances processeur : il lui faut des connexions pratiques pour le stockage et le réseau, ainsi que des possibilités d’évolution matérielle.

Les deux ports SATA permettent de connecter directement une paire de disques durs ou de SSD, sans dépendre d’un pont de stockage USB. Les deux interfaces réseau peuvent prendre en charge une liaison de stockage, un réseau segmenté, un projet de routeur ou une autre topologie dans laquelle un seul port deviendrait limitant. Le port PCIe laisse la place à une extension choisie, comme un stockage NVMe ou un autre adaptateur dédié à une tâche spécifique.

La plateforme reste compacte. Une seule interface PCIe ne peut pas accueillir toutes les extensions simultanément, deux ports SATA ne suffisent pas à créer un NAS à plusieurs baies, et un Intel N150 ne doit pas être considéré comme un processeur de virtualisation doté de nombreux cœurs. La conception fonctionne au mieux lorsque les rôles principaux du serveur sont choisis avant l’ajout d’accessoires.

Ouvrir le boîtier révèle la stratégie de refroidissement

À 08:16, RG 4 Tech ouvre le boîtier du ZimaBoard 2 et montre la disposition interne de la carte ainsi que l’emplacement utilisé pour le refroidissement actif. Cette vue est utile, car l’extérieur une fois assemblé n’explique pas à lui seul comment la chaleur s’évacue du processeur et des composants voisins.

La structure en aluminium contribue à la dissipation thermique, tandis qu’un ventilateur peut augmenter la circulation de l’air lorsque la carte est placée dans un environnement plus chaud ou sollicitée pour des tâches plus intensives. L’activité du stockage, l’indexation des applications, la température de la pièce, la disposition des câbles et les surfaces voisines influencent tous les conditions thermiques autour d’une installation réelle.

Le refroidissement actif doit être considéré comme un choix lié à la charge de travail, et non comme un simple élément décoratif. Un serveur de fichiers peu sollicité peut se comporter différemment de la même carte exécutant simultanément des transferts de stockage, des mises à jour d’applications, l’indexation de médias et des services domotiques. Après l’assemblage, le propriétaire doit vérifier les températures dans les conditions de charge combinée prévues, plutôt que de se fier uniquement aux relevés au repos.

Planifier le stockage physique avant de créer le pool

RG 4 Tech connecte deux disques avant de configurer le stockage dans ZimaOS. Cet ordre peut sembler évident, mais il évite une catégorie importante d’erreurs : créer des partages ou installer des applications avant de décider quel disque hébergera les données actives, quel disque participera à la redondance et où seront stockées les sauvegardes.

Un serveur à deux disques offre plusieurs configurations possibles. Les disques peuvent rester indépendants, être combinés pour améliorer les performances ou augmenter la capacité, ou être mis en miroir pour assurer la redondance. Le bon choix dépend de la priorité : espace utilisable, disponibilité continue après la défaillance d’un disque ou séparation entre différentes catégories de données.

La compatibilité des disques mérite également de l’attention. Un miroir offre normalement une capacité fondée sur le disque membre le plus petit ; associer des disques de tailles très différentes peut donc gaspiller de l’espace. Les deux disques doivent être testés, leur état surveillé et leurs numéros de série consignés avant le transfert de données importantes vers le nouveau pool.

Créer un pool RAID 1 à deux disques dans ZimaOS

À 16:50, RG 4 Tech utilise l’interface de stockage de ZimaOS pour sélectionner les deux disques et configurer le RAID 1. La configuration écrit des copies en miroir sur les disques membres, sacrifiant la moitié de la capacité brute combinée en échange de la possibilité de maintenir le pool disponible lorsqu’un disque tombe en panne.

ZimaOS présente le RAID 1 comme son option axée sur la redondance dans le guide des options RAID de ZimaOS. Le processus graphique facilite l’accès à un premier NAS, car l’utilisateur peut identifier les disques et choisir le mode de stockage sans devoir construire entièrement la matrice en ligne de commande.

L’interface ne dispense pas de vérifier la sélection. La création d’une nouvelle matrice peut effacer les données existantes sur les disques choisis. L’identité et la capacité des disques, ainsi que toute copie nécessaire, doivent être vérifiées avant d’autoriser l’opération finale.

Pourquoi le RAID 1 est utile, sans pour autant constituer une sauvegarde

Le RAID 1 répond à un problème précis : la perte d’un disque membre. Si un disque cesse de fonctionner, l’autre copie peut maintenir le pool accessible pendant le remplacement du périphérique défaillant et la reconstruction de la matrice. Cette disponibilité est précieuse pour un serveur censé rester en ligne.

Le miroir réplique les modifications logiques sur les deux disques. Une suppression accidentelle, un fichier écrasé, une attaque par rançongiciel, un état d’application corrompu ou une commande d’administrateur erronée peut donc affecter les deux copies. Un vol, un dommage électrique ou la perte physique du serveur complet peut supprimer toute la matrice d’un seul coup.

Une conception plus sûre associe le RAID 1 à des sauvegardes versionnées stockées ailleurs. Le guide ZimaSpace sur les configurations RAID et la planification des sauvegardes NAS explique pourquoi la redondance, l’historique des sauvegardes et une copie sur un autre appareil répondent à des risques différents.

ZimaOS transforme le matériel de stockage en plateforme d’applications

Une fois le pool disponible, le serveur n’a pas besoin de rester un simple partage réseau. ZimaOS ajoute une gestion des fichiers via navigateur et un environnement d’applications, afin que le stockage et les services auto-hébergés puissent être gérés depuis la même interface.

C’est ici que le matériel devient plus utile qu’un simple boîtier à deux baies. Les applications peuvent utiliser le pool local pour leurs fichiers persistants, tandis que l’environnement d’exploitation gère leur cycle de vie. Un foyer peut commencer par le stockage de fichiers, puis ajouter un service à la fois au lieu de déployer dès le premier jour une pile complète de laboratoire domestique.

Les données des applications ne doivent pas devenir une infrastructure invisible. Avant d’installer un service, identifiez son répertoire de configuration, sa base de données, ses fichiers importés, ses ports réseau et sa méthode de sauvegarde. Un conteneur en cours d’exécution est facile à recréer ; les données qu’il contient ne le sont pas forcément.

L’installation de Home Assistant ajoute un contrôle domotique local

À 19:07, Home Assistant a démarré et RG 4 Tech accède à son écran de configuration initiale. Cela confirme que le ZimaBoard 2 peut héberger l’application aux côtés de l’environnement de stockage et donne au projet un deuxième rôle clairement défini : coordonner localement les appareils domotiques compatibles et leurs automatisations.

Home Assistant peut conserver de nombreuses décisions au sein du réseau domestique plutôt que d’envoyer chaque automatisation vers le cloud d’un fournisseur. Le degré réel de contrôle local dépend toutefois de chaque appareil et de chaque intégration. Certains produits proposent une API locale, tandis que d’autres continuent d’exiger un compte externe ou une connexion au cloud.

Le premier écran marque le début du déploiement, pas sa fin. Le propriétaire doit encore créer un compte administrateur, définir l’emplacement du domicile, examiner les appareils détectés, sécuriser l’accès à distance, tester les automatisations et mettre en place une planification des sauvegardes avant que le système ne devienne fiable.

Home Assistant Container et Home Assistant OS sont deux choix différents

Installer Home Assistant via une plateforme d’applications existante signifie généralement exécuter Home Assistant Container. L’aperçu des méthodes d’installation officielles de Home Assistant explique que cette approche utilise un hôte et un environnement de conteneurs gérés par l’utilisateur. Elle n’inclut pas non plus le système d’applications disponible dans Home Assistant OS.

Le déploiement en conteneur convient à un serveur ZimaOS polyvalent, car Home Assistant peut coexister avec le stockage et d’autres applications. Home Assistant OS est le choix le plus proche d’un appareil dédié lorsque la machine entière est consacrée à Home Assistant et que l’utilisateur souhaite bénéficier de son expérience de gestion intégrée.

L’approche de RG 4 Tech est attrayante, car elle regroupe les rôles. Cette commodité doit être mise en balance avec l’étendue des défaillances : le redémarrage ou la réparation du serveur partagé peut affecter temporairement à la fois l’accès aux fichiers et le contrôle domotique.

Le stockage et les services domotiques nécessitent des plans de récupération distincts

Un pool de stockage en miroir et une instance Home Assistant en fonctionnement protègent des éléments différents. Le RAID 1 aide le pool à survivre à la défaillance d’un disque membre. Une sauvegarde Home Assistant préserve la configuration, les automatisations et l’état pris en charge de l’application. Ni l’un ni l’autre ne produit automatiquement une copie sûre en dehors du serveur.

Home Assistant permet désormais de créer et de restaurer des sauvegardes pour différents types d’installation, comme l’explique sa documentation sur l’intégration de sauvegarde. Ces sauvegardes doivent être copiées vers une destination qui ne dépend ni de la même grappe à deux disques ni de la même machine physique.

Un test de récupération pratique pose séparément deux questions : le foyer peut-il restaurer ses fichiers après la perte du NAS, et peut-il restaurer Home Assistant après la perte de l’hôte applicatif ? Si les deux réponses dépendent du maintien en fonctionnement du même serveur, le système possède toujours un domaine de défaillance unique.

Ce que ce serveur consolidé fait bien

À qui s’adresse un serveur ZimaBoard 2 de ce type ?

Cette configuration convient à ceux qui souhaitent créer un premier cloud privé, un NAS familial à deux disques, un contrôleur local pour maison connectée ou un hôte d’applications compact sans consacrer un ordinateur distinct à chaque rôle. Elle est particulièrement séduisante lorsque le fonctionnement silencieux et l’extensibilité matérielle ouverte comptent davantage qu’un design d’appareil fermé et parfaitement intégré.

Un appareil Home Assistant dédié peut être préférable lorsque les automatisations doivent rester disponibles pendant la maintenance du NAS. Un NAS plus grand à plusieurs baies convient aux utilisateurs qui ont besoin de plusieurs niveaux de capacité, de plusieurs pools indépendants ou d’une meilleure tolérance aux pannes de disques. Un serveur doté de davantage de cœurs est plus adapté à de nombreuses machines virtuelles lourdes ou à des charges de calcul soutenues.

La décision doit commencer par les domaines de défaillance, et pas seulement par le nombre d’applications que le matériel peut exécuter. La centralisation permet d’économiser de l’espace, de l’énergie et des efforts de gestion, mais elle signifie aussi qu’un seul redémarrage ou problème matériel peut interrompre plusieurs services domestiques simultanément.

RG 4 Tech bâtit un cloud privé autour de tâches domestiques clairement définies

Le projet de RG 4 Tech réussit parce que chaque étape importante a une utilité. L’ouverture du boîtier explique le circuit thermique et les possibilités de maintenance. La connexion de deux disques crée une base de stockage. Le RAID 1 améliore la disponibilité après une défaillance de disque. ZimaOS simplifie la gestion de ce stockage, tandis que Home Assistant transforme la machine en plateforme d’automatisation locale.

Cette configuration est d’autant plus intéressante que ses avantages sont décrits avec précision. Le RAID 1 assure une redondance, pas une sauvegarde. Un conteneur Home Assistant n’est pas identique à Home Assistant OS. Un serveur silencieux unique peut regrouper des tâches utiles, mais il centralise aussi les risques, à moins que les sauvegardes et les plans de récupération soient externalisés.

Regardez la vidéo complète de RG 4 Tech pour découvrir l’inspection du matériel interne, la configuration du stockage sous ZimaOS, le fonctionnement du RAID 1 et l’installation de Home Assistant. Pour une autre approche du déploiement local d’une maison connectée, découvrez comment exécuter Home Assistant sur ZimaBoard, ou rejoignez la communauté ZimaSpace sur Discord pour comparer votre configuration de serveur domestique avec celle d’autres utilisateurs.