Une note de Zima
Merci, King_Arda, d’avoir partagé ce à quoi peut ressembler un premier NAS lorsque la confidentialité, l’expérimentation et l’apprentissage pratique comptent autant que la commodité. Votre ZimaBlade est devenue un espace pour Immich, Jellyfin, Duplicati, les sauvegardes chiffrées et l’accès à distance grâce à la configuration WireGuard que vous utilisiez déjà sur votre réseau.
Nous apprécions tout particulièrement que vous ayez documenté aussi ouvertement les difficultés que les éléments qui fonctionnaient — de la configuration Docker et de la confusion autour des chemins de stockage au comportement des sauvegardes et à la planification de l’alimentation nécessaire pour un second disque. Ces détails donnent aux autres passionnés de homelab une vision plus utile de ce que signifie réellement faire évoluer un petit NAS DIY au fil du temps.
— Zima
À la rencontre de King_Arda
King_Arda est un passionné de homelab sur Reddit qui s’est décrit dans sa publication originale comme étudiant la cybersécurité et disposant de connaissances en réseau acquises avec le Cisco CCNA. Il ne cherchait pas seulement un boîtier capable de stocker des fichiers. Il voulait un NAS qui puisse aussi devenir un espace pratique pour expérimenter l’auto-hébergement de services, le réseau, les sauvegardes et le stockage.
Avant d’acheter la ZimaBlade, il a comparé des options NAS plus classiques avec la réutilisation d’un ancien PC. Il a finalement choisi ce système x86 plus compact, car son prix, sa flexibilité, son apparence et les possibilités de personnalisation correspondaient à ce qu’il attendait d’un premier NAS de homelab.
Vous pouvez suivre King_Arda sur Reddit pour découvrir le profil du créateur à l’origine de cette histoire d’utilisateur.
Divulgation : Dans sa publication Reddit originale, King_Arda a indiqué avoir contacté l’assistance Zima après avoir découvert que son alimentation existante n’était pas assez puissante pour la configuration de stockage souhaitée. Il a précisé que l’assistance lui avait offert la livraison gratuite en échange de la publication sur Reddit, tout en indiquant qu’il était libre de partager son propre avis. Cette histoire d’utilisateur conserve cette divulgation ainsi que ses critiques concernant l’expérience de configuration.
De la recherche d’un NAS à la ZimaBlade
Avant de choisir la ZimaBlade, King_Arda a envisagé deux points de départ familiers : acheter un NAS Synology ou réutiliser un ancien PC. Ses recherches l’ont finalement orienté vers une plateforme DIY plus compacte, capable de servir à la fois de stockage et de serveur domestique polyvalent.
Il a décrit ce choix principalement en termes de rapport qualité-prix et de flexibilité. Il appréciait également l’idée plus large des logiciels open source et le fait de mieux contrôler les services exécutés sur la machine. C’était important, car le NAS n’avait jamais vocation à rester un appareil à usage unique.
La documentation actuelle de la ZimaBlade décrit la plateforme comme un serveur monocarte x86 doté de deux connexions SATA 3.0, d’un port Ethernet Gigabit et d’une extension PCIe. La publication de King_Arda ne précise pas si sa carte est le modèle 3760 ou 7700 ; cette histoire n’en attribue donc aucun.
Pourquoi ZimaOS est resté au centre de la configuration
King_Arda a conservé ZimaOS sur le système au lieu de le remplacer immédiatement par Windows, Proxmox ou un autre système d’exploitation serveur. Il appréciait l’expérience de gestion des fichiers dans le navigateur ainsi que l’App Store, qui facilitaient la découverte et le déploiement d’applications Docker sans transformer chaque expérimentation en projet en ligne de commande.
Trois applications sont devenues centrales dans la configuration : Immich pour les photos, Jellyfin pour les contenus multimédias et Duplicati pour les processus de sauvegarde. Il a également testé d’autres applications en cours de route, et la machine a alors commencé à se comporter moins comme un simple NAS que comme un véritable nœud de homelab.
La confidentialité sans renoncer à la sauvegarde hors site
Les photos constituaient l’une des principales raisons pour lesquelles King_Arda souhaitait s’auto-héberger. Il a expliqué qu’il était mal à l’aise à l’idée de confier entièrement sa photothèque à Google, notamment en raison de ses inquiétudes quant à l’utilisation possible des photos hébergées dans le cloud en lien avec l’IA.
Sa solution n’a pas été d’abandonner complètement le stockage cloud. Immich lui a fourni un service photo sur du matériel qu’il contrôlait, tandis que Duplicati envoyait une sauvegarde chiffrée de ses images vers Google Drive. Il a également expliqué qu’il rapatriait des fichiers de Drive vers la ZimaBlade afin qu’aucun des deux emplacements ne constitue l’unique copie.
Le projet est ainsi devenu hybride plutôt qu’une décision de confidentialité tout ou rien : des services locaux pour le contrôle quotidien, avec un stockage chiffré hors site conservé comme couche de sauvegarde supplémentaire.
Utiliser WireGuard plutôt que d’ajouter une autre couche d’accès à distance
Pour l’accès à distance, King_Arda a envisagé Tailscale, mais a choisi WireGuard parce que son routeur le prenait déjà en charge. Il pouvait ainsi utiliser une voie réseau qu’il connaissait au lieu d’ajouter un autre service d’accès à distance uniquement pour le NAS.
Les versions actuelles de ZimaOS documentent également l’accès à distance via ZimaClient, mais la configuration de King_Arda illustre une autre approche de l’auto-hébergement : les utilisateurs qui administrent déjà leur propre réseau peuvent choisir la couche d’accès qui s’intègre le mieux au reste de leur infrastructure.
Le guide actuel d’accès à distance de ZimaOS couvre la solution ZimaClient ; la publication Reddit originale décrit le choix distinct de King_Arda en faveur de WireGuard.
Quand la voie facile a cessé de l’être
L’App Store était pratique, mais King_Arda n’a pas décrit toutes les installations comme entièrement automatisées. Il a expliqué qu’il devait parfois modifier certaines parties d’un fichier Docker avant qu’une application fonctionne comme il le souhaitait.
Il a également signalé un problème plus préoccupant concernant les chemins de stockage : certaines données semblaient être écrites sur le stockage interne de la ZimaBlade alors qu’il pensait avoir sélectionné le disque dur. Les tâches de sauvegarde qu’il s’attendait à voir récupérer automatiquement ne se comportaient pas toujours comme prévu non plus.
Ces problèmes ne l’ont pas conduit à abandonner le système, mais ils ont changé le type d’utilisateur à qui il le recommanderait. Son expérience était bien plus positive pour quelqu’un prêt à examiner la configuration et à résoudre les problèmes que pour une personne qui s’attend à utiliser un appareil ne révélant jamais son modèle sous-jacent de conteneurs ou de stockage.
Les recommandations actuelles de ZimaOS clarifient davantage les chemins des données des applications
La documentation actuelle de ZimaOS fournit désormais des indications spécifiques concernant le stockage des applications. Le guide des chemins de stockage des applications recommande de placer les données des applications dans un espace de stockage principal plutôt que de laisser d’importants ensembles de données persistantes sur le disque système. Il cite notamment les photothèques telles qu’Immich, qui peuvent rapidement remplir un petit disque système.
Cela ne prouve pas que le problème précis rencontré par King_Arda a été résolu sur sa machine. En revanche, cela fournit des recommandations actuelles plus claires pour le même type de problème auquel il a été confronté en découvrant le fonctionnement conjoint de la persistance de ZimaOS et de Docker.
Un NAS recommandé aux bricoleurs, pas à tout le monde
La recommandation globale de King_Arda était volontairement conditionnelle. Il appréciait l’appareil et estimait qu’il répondait à ses besoins, mais il ne proposerait pas la même expérience à un débutant complet qui s’attendrait à ce que chaque service fonctionne sans configuration ni investigation.
Pour quelqu’un prêt à modifier les paramètres, à comprendre où se trouvent les données et à résoudre les problèmes d’un conteneur si nécessaire, sa conclusion était bien plus positive. En ce sens, la ZimaBlade fonctionnait non seulement comme un espace de stockage, mais aussi comme une plateforme d’apprentissage.
Un premier disque, puis un second
Au moment de la publication originale, le NAS fonctionnait avec un seul disque dur. King_Arda prévoyait d’ajouter un second disque et d’utiliser le RAID, mais il n’a pas indiqué le niveau de RAID envisagé.
Avec deux disques, la documentation actuelle de ZimaOS présente le RAID 1 comme l’option en miroir, tandis que le RAID 5 nécessite au moins trois disques. C’est un contexte utile pour les lecteurs, mais il ne faut pas en déduire que King_Arda a personnellement choisi le RAID 1. Sa mise à jour publique s’arrête au projet d’ajouter un autre disque.
Les différents choix sont documentés dans la référence RAID actuelle de ZimaOS.
La planification de l’alimentation est devenue partie intégrante du plan de stockage
Le passage à un second disque a révélé une autre contrainte pratique : l’alimentation de la configuration de King_Arda n’était pas assez puissante pour ce qu’il souhaitait faire fonctionner. C’est ce problème qui l’a conduit à contacter l’assistance et qui a donné lieu à l’accord de livraison gratuite divulgué dans la publication Reddit.
Les recommandations actuelles de configuration d’une ZimaBlade NAS conseillent également d’envisager une alimentation externe pour une utilisation prolongée avec des disques durs. La publication originale ne fournit ni le modèle du disque, ni le courant de démarrage, ni les caractéristiques de l’adaptateur, ni le modèle de ZimaBlade ; cette histoire ne tente donc pas de diagnostiquer la limite électrique exacte de sa configuration.
Un petit NAS devenu un homelab pratique
Lorsque King_Arda a écrit à propos du projet, la ZimaBlade faisait bien plus que stocker des fichiers. Elle était devenue un serveur photo privé, un serveur Jellyfin, un nœud de sauvegarde et un espace où mettre en pratique les connaissances en réseau et en cybersécurité qu’il étudiait déjà.
L’intérêt de cette histoire réside dans le fait que l’apprentissage est venu autant des réussites que des difficultés. Il a dû décider où stocker les données des conteneurs, quelle couche d’accès à distance était la plus adaptée, comment conserver une copie chiffrée hors site et ce qui changeait lorsque l’extension du stockage augmentait les besoins en alimentation.
L’histoire continue de s’écrire
L’histoire de King_Arda et de Zima continue de s’écrire. La publication Reddit du 31 janvier 2026 décrit un système déjà utile, mais encore en expansion : un disque dur assurait des tâches réelles, un second disque et le RAID étaient prévus, Immich et Jellyfin étaient devenus des services utilisés au quotidien, Duplicati gérait les sauvegardes et WireGuard fournissait l’accès à distance.
Dans les éléments vérifiés pour cette page, aucun suivi public ne confirme la mise à niveau avec un second disque, la configuration RAID finale ni la résolution ultérieure des problèmes liés aux données des applications et aux sauvegardes. Ces points doivent rester ouverts jusqu’à ce que King_Arda documente lui-même la prochaine étape.
Pour suivre la source à l’origine de cette histoire, lisez la publication originale sur la ZimaBlade NAS ou consultez le profil Reddit de King_Arda.
