Mon NAS QNAP est mort. Vive mon NAS maison !

2017 : un QNAP pour remplacer l’Asustor

En 2017, je jette mon dévolu sur un QNAP TS-453Bmini flambant neuf. À l’époque, j’avais un Asustor AS1002T. Pas bien vieux, mais soyons honnêtes, ça ramait sévère dès qu’il s’agissait de transcoder quoi que ce soit avec Plex.

Je passais d’un Marvell double cœur avec 512 Mo de RAM à un Intel Celeron J3455 à quatre cœurs, avec 8 Go de RAM dans mon QNAP. Pour mon usage, la différence était nette.

Enfin, je pouvais transcoder à la volée sans que mon NAS se mette à pleurer du sang. La vie était belle. J’aurais peut-être dû en profiter pour m’occuper sérieusement de sa sécurité.

Les premières leçons avec le NAS QNAP

Mon parcours avec ce QNAP m’a aussi appris quelques trucs à la dure. Une sorte de formation accélérée, mais sans le diplôme à la fin.

Un NAS un peu trop exposé

Bon, j’étais jeune, naïf et con. À peine déballé, le NAS se retrouvait exposé sur Internet, avec « admin » comme mot de passe. Avec le recul, je ne recommanderais pas exactement cette configuration à un ami.

La frayeur Qlocker

Quelques années plus tard, le ransomware Qlocker me donne une vraie montée d’adrénaline : mes fichiers me semblent potentiellement menacés. Je parle bien de cette frayeur ; je ne vais pas la transformer en infection confirmée de mon NAS sans éléments permettant de l’établir.

Dans sa déclaration sur Qlocker, QNAP décrit des fichiers de moins de 20 Mo placés dans des archives 7-Zip protégées par mot de passe. Ce n’était donc pas un chiffrement indistinct de tous les fichiers. Mon NAS stockait surtout des ISO Linux — oui, oui, une passion pour les distros obscures — et ces gros fichiers n’ont pas été touchés. Leur taille correspond à ce que QNAP décrit, mais elle ne permet pas, à elle seule, de conclure à ce qui s’est passé sur ma machine.

Après cet épisode, j’ai choisi de réduire les accès publics au strict nécessaire : seul le port de Plex restait ouvert, et l’administration du NAS passait par un VPN. C’était ma nouvelle règle, pas une garantie d’invulnérabilité. Moins de services exposés, ça ne dispense pas de les maintenir à jour. C’est aussi le sujet de mon article sur le suivi des mises à jour des conteneurs Docker.

Fin 2023 : le QNAP tombe en panne

Tout allait bien… jusqu’à fin 2023.

Une soirée, le NAS se met à bipper toutes les cinq minutes. Les voyants clignotent façon sapin de Noël. Rien de très rassurant, même pour la saison.

Impossible d’accéder à l’administration. Sortie HDMI ? Rien non plus.

Mes recherches m’ont orienté vers la piste de l’horloge LPC, évoquée dans des récits de pannes de NAS. Le TS-453Bmini utilise bien un Celeron J3455. Dans la documentation de cette famille de processeurs, Intel décrit l’erratum APL47, lié notamment aux circuits LPC, qui peut empêcher le démarrage sous certaines conditions. Intel précise n’avoir observé ce comportement qu’en simulation et mentionne des atténuations par firmware. Mais cette documentation ne confirme pas la cause de la panne de mon QNAP : pour mon exemplaire, cela reste une hypothèse.

En pratique, le résultat était surtout que je ne pouvais plus utiliser le NAS. Acheté en 2017, en panne fin 2023 : environ six ans de service. J’aurais préféré qu’il dure plus longtemps.

J’ai aussi croisé sur les forums des pistes de réparation impliquant une intervention sur la carte mère. Je ne les ai pas essayées, et je préfère éviter de résumer une opération que je n’ai pas vérifiée à « un pont à souder ». Jouer les MacGyver avec un fer à souder, ce n’était pas le plan.

Récupérer les données du QNAP avec mdadm

Le plan B, c’était de récupérer les données. J’ai acheté quatre adaptateurs SATA vers USB, branché les disques sur une machine sous Ubuntu Server et utilisé mdadm pour réassembler le RAID existant.

Repérer les disques et leurs baies reste utile pour ne pas travailler à l’aveugle. En revanche, je ne présenterais pas l’ordre physique des branchements comme une condition absolue de réussite : les métadonnées d’un ensemble md décrivent sa structure et son état, et mdadm s’appuie sur ces informations pour retrouver ses membres. Ce n’est pas simplement « le troisième câble doit être sur le troisième port USB ».

Dans mon cas, la commande qui a permis de réassembler l’ensemble était :

mdadm --assemble --scan

Cette commande sert à assembler un ensemble existant en recherchant ses composants. Je la cite parce qu’elle a fonctionné dans mon cas, pas comme une procédure de récupération valable pour n’importe quel NAS ou n’importe quel état des disques.

J’ai retrouvé l’accès à mes données. Gros soulagement. À l’époque, mon RAID comptait quatre disques de 4 To et n’était pas plein. J’ai pu copier les données sur deux autres disques, un de 3 To et un de 4 To, avant de préparer le nouvel ensemble.

Remplacer le NAS : trois options

Une fois mes données récupérées, il a fallu décider de la suite.

J’avais trois chemins devant moi :

• Racheter un NAS tout fait, mais je n’avais plus très envie de reprendre un QNAP.
• Monter mon propre NAS, avec les choix et la configuration qui vont avec.
• Utiliser un PC existant et un DAS — Direct Attached Storage — pour y brancher les disques.

À ce stade, la troisième option me semblait la plus pragmatique. J’avais déjà un mini PC équipé d’un AMD Ryzen 5 5600H et de 32 Go de DDR4 qui me servait de homelab. Autant essayer de partir de ce que j’avais.

Le détour par un DAS Yottamaster

J’ai donc cherché un boîtier USB pour mes disques. J’ai choisi un Yottamaster FS5C3 à cinq baies, présenté comme dépourvu de RAID matériel : l’idée était de garder le RAID géré par mdadm, pour ne pas le lier à une fonction RAID du boîtier. L’aluminium et les tiroirs façon Synology ou QNAP m’avaient fait bonne impression.

Je le reçois, je branche tout et les disques sont bien listés. Je formate, configure le RAID avec mdadm et lance la création du RAID 5. Avec cinq disques de 4 To, cela représente 20 To bruts. En RAID 5, la capacité correspond à l’équivalent de quatre disques : environ 16 To nominaux utilisables avant les métadonnées, le système de fichiers et les autres surcoûts. Pas 20 To d’espace disponible.

La création mouline toute la nuit. Le lendemain matin, tout semble OK ; je commence à importer mes données, puis je laisse le PC bosser et pars vaquer à mes occupations.

Un disque déclaré défaillant

L’après-midi, je vérifie l’état du RAID : un disque est déclaré défaillant. Il est pourtant plutôt récent. Je consulte les informations SMART, qui ne me rassurent pas. Je sors le disque, le branche sur mon PC avec un adaptateur SATA vers USB et relance un test SMART. Cette fois, aucun souci signalé.

Deux résultats différents pour le même disque, ça ne m’aidait pas beaucoup à avoir confiance dans le montage. Mais ça ne suffisait pas non plus à désigner un coupable : je n’ai pas établi la cause exacte de l’erreur, ni démontré que le contrôleur du Yottamaster était responsable.

J’avais aussi remarqué que les disques semblaient se mettre en veille après environ cinq minutes d’inactivité. Je me suis demandé si cela pouvait jouer, sans pouvoir faire le lien avec l’incident.

En cherchant des retours sur les DAS USB, j’ai trouvé de quoi nourrir mes doutes. Je ne vais pas en déduire que tous ces boîtiers sont mauvais ou que tous leurs contrôleurs se valent. Ce que je peux dire, c’est que ce Yottamaster, dans mon montage, ne m’a pas inspiré confiance.

Bref, retour Amazon. Next.

Mon NAS maison : le choix du matériel

Après cet essai, mes deux autres options étaient de nouveau sur la table. Racheter un NAS tout fait ? Après ces aventures, je n’en avais pas très envie. Je voulais davantage choisir les composants et les outils que j’allais utiliser.

Restait à le monter moi-même. Le hardware et le software ne me faisaient pas peur. Au début, je pensais partir sur une configuration Ryzen. Puis, en discutant avec un collègue — s’il me lit, il se reconnaîtra —, il m’a rappelé l’intérêt d’Intel Quick Sync pour le transcodage.

Ça tombait bien : ma tour de gaming avait un Intel i5-10600K, avec un circuit graphique intégré UHD 630 et la prise en charge de Quick Sync Video. Je pouvais réutiliser ce processeur pour le serveur, tout en donnant un coup de jeune à ma machine principale.

Mes recherches m’avaient fait espérer une dizaine de transcodages 1080p simultanés. Ce n’était pas un résultat mesuré sur ma configuration. Le nombre réel dépend des fichiers sources, des codecs, des débits, des sous-titres et des réglages ; Plex précise aussi que les possibilités de transcodage matériel dépendent du matériel et des formats. J’ai surtout retenu l’intérêt de Quick Sync pour mon usage, pas une promesse de dix flux garantis.

La configuration de mon NAS maison

• Processeur : Intel i5-10600K.
• Carte mère : Gigabyte H510M H V2.
• Mémoire : 32 Go de DDR4.
• Stockage : un SSD NVMe de 512 Go et 5 × 4 To Seagate IronWolf.
• Boîtier : Fractal Node 804.
• Alimentation : Fractal Design Ion+ 560 W Platinum.
• Carte contrôleur SAS/SATA : LSI 9240-8i, vendue déjà flashée en mode IT.

La connectique SATA a fait partie des questions à régler : ma carte mère possède bien quatre ports SATA et deux emplacements PCIe, un x16 et un x1. C’est aussi ce qu’indiquent les fiches Gigabyte des révisions 1.0 et 2.0 de la H510M H V2. Avec mes cinq disques durs à raccorder, j’avais besoin de connectique supplémentaire.

Pour raccorder davantage de disques, j’ai acheté sur AliExpress une LSI 9240-8i, vendue déjà flashée en mode IT. C’est la référence indiquée sur ma commande ; sous Ubuntu, elle s’identifie comme une SAS9211-8i à puce LSI SAS2008, avec un identifiant matériel Fujitsu D2607. Ubuntu voit les disques individuellement. Je n’ai donc pas eu à sortir les outils de flash pour cette partie-là non plus.

Je n’ai finalement pas ajouté de carte Wi-Fi/Bluetooth dédiée. Le NAS est branché en Ethernet ; pour le Bluetooth, un dongle USB faisait l’affaire. Et depuis, je n’utilise de toute façon plus d’appareils Bluetooth avec le NAS.

Pourquoi Ubuntu Server plutôt qu’Unraid ou TrueNAS ?

Pour le système, j’ai hésité entre Unraid, TrueNAS et Ubuntu Server. La licence d’Unraid me freinait un peu. Surtout, j’avais envie de choisir mes services et de les configurer moi-même, plutôt que de partir d’une solution qui organise déjà une grande partie de l’administration.

Ubuntu me permettait de construire ce dont j’avais besoin : le stockage, mes conteneurs et les services autour. Cela ne signifie pas qu’il reproduit à l’identique les fonctions ou la logique de stockage d’Unraid, ni que TrueNAS aurait été un mauvais choix. C’était surtout la façon de travailler qui me convenait.

J’ai donc choisi Ubuntu Server. Je le connaissais déjà grâce au mini PC, et je pouvais reprendre mes conteneurs Docker sur le nouveau serveur.

Si vous voulez creuser la partie services, j’ai aussi détaillé Plex et le transcodage matériel dans mon guide Media Server, ainsi qu’Arcane pour gérer les conteneurs Docker.

Plus de choses à gérer, mais plus simple pour moi

Avant, mon installation reposait sur le QNAP et des petites machines à côté : NUC, Raspberry Pi… QTS prenait en charge une partie du travail sur le NAS. En passant au serveur maison, j’ai aussi dû trouver des alternatives aux fonctions qui étaient incluses chez QNAP. Le changement allait donc bien au-delà du choix du boîtier et du processeur.

Sur le papier, ça pouvait sembler plus compliqué. À l’usage, pour moi, c’est plutôt l’inverse. Quand je veux faire quelque chose sur Ubuntu, j’installe le paquet ou le conteneur adapté, je le configure et je sais ce que j’ai mis en place. Sur le QNAP, je devais souvent chercher le bon paramètre dans les menus de QTS, puis comprendre ce qu’il faisait derrière. Et franchement, la gestion de Docker sur QNAP, je ne la trouvais pas très pratique.

Je pouvais déjà me connecter au NAS en SSH. Mais une fois dans le terminal, l’organisation des dossiers me paraissait bizarre, peu claire. Je ne savais pas toujours où chercher ni ce qui dépendait de QTS. L’accès était là, mais je n’avais pas pour autant le sentiment de maîtriser toute la machine.

Aujourd’hui, je maîtrise mon installation de bout en bout. Je choisis mes outils, je sais où je mets leurs configurations et je comprends mieux comment les services s’articulent. Il y a de l’entretien, des erreurs et du dépannage, évidemment. Mais cette façon de travailler me correspond beaucoup mieux.

Et surtout, j’apprends beaucoup plus de choses. Remplacer une fonction de QTS m’amène à chercher une solution, à la configurer et à comprendre son fonctionnement. Chaque besoin devient une occasion de creuser un sujet : stockage, Docker, sauvegardes, supervision ou accès distant.

Et maintenant ?

Avec le recul, la panne du QNAP explique une bonne partie de ce blog. Je cherchais d’abord à remplacer mon NAS. J’ai fini par construire une installation que je peux faire évoluer à ma façon, et dont les essais, les galères et les découvertes me donnent régulièrement matière à écrire.

Les stacks Docker, les outils de monitoring et les choix de services dont je parle ici prolongent cette histoire. Il y a du Prometheus, du Grafana, du Restic… et derrière chacun de ces noms, un besoin concret et quelque chose que j’ai appris en chemin.