[NAS/Réseau] Besoin de conseils

[Anard]

Bonjour,

Sur mon PC, j'utilise un disque qui sert de partage réseau (principalement musique et vidéos). Ayant des PC sous macOS dans mon réseau domestique, j'avais fait le choix d'un formattage HFS+ qui fonctionne relativement bien en lecture/écriture sous linux et macOS.
Ceci dit, ce disque rencontre de plus en plus d'erreurs, bien que je ne sois pas tout à fait convaincu qu'il soit le coupable. Rien ne me le dit explicitement.

[Anard]

Bien, je me rends compte en lisant ce que je trouve par-ci par-là que je ne comprends pas bien le fonctionnement de tout ça

Si je comprends bien, concernant le réseau local, peu importe le système de fichiers utilisé puisque c'est mon serveur qui aura besoin d'y accéder pour servir les fichiers demandés par le PC du réseau. Donc seul le serveur doit être en mesure de lire le système de fichiers. (Dites-moi si je me trompe)
Ceci-dit, mon serveur pouvant booter sous macOS, ça pourrait rester intéressant d'utiliser un système qui soit compatible, malgré que je n'utilise quasiment plus cet OS (il n'y a plus qu'une application qui me contraigne à le conserver).

Je regarde actuellement plutôt du côté de BtrFS, qui semble désigné comme "l'avenir" sous Linux.

Concernant le RAID, comme je disais plus haut, je veux me diriger dans l'avenir vers un RAID5 sur 3 disques de 2To. Je peux lire un peu partout que BtrFS n'est pas encore fiable sur ce type de configuration (RAID 5 ou 6). Mais j'ai cru comprendre également que l'on parlait là de l'utilisation de BtrFS pour créer un RAID logiciel. Étant donné que je voudrais faire confiance à ma carte PCI pour la gestion du RAID (bien que je ne sache pas encore bien si ce sera possible), est-ce que BtrFS pourra gérer ce volume virtuel normalement comme un disque unique ou est-ce que ça posera effectivement problème ?

Je dispose aussi d'un disque externe ext4 faisant des sauvegardes régulières de l'ensemble de mes disques Linux (/ /home et ce disque partagé qui va être remplacé) via app-backup/backintime. Est-ce qu'il serait pertinent de convertir ce disque de sauvegarde également sous BtrFS ?

Qu'en est-il de ZFS ? Avantages/Inconvénients. À la lecture, j'ai l'impression que ZFS est bien plus complexe à mettre en place mais semble selon certains témoignages le système "ultime". Donc je ne sais pas bien quoi penser...

Bref, comme vous pouvez le voir, je ne sais pas encore bien où je vais
_________________
"iMack" : GA-H97M-D3H, Intel i5 4460, 16Go DDR3, Intel HD4600, 2x SSD 256Go, HDD 500Go+2To / Clover - macOS Mojave / Gentoo-Xfce
"Portable" : HP 350G3, HDD 500Go / rEFInd - Xubuntu 20.04 / Windows 10

[El_Goretto]

Une configuration avec du RAID et un système de fichier robuste qui soit multi-boot Linux et MacOS... pas sûr que ce soit faisable.
Il va probablement falloir faire un choix, et prioriser ce qui est disponible sous Linux.

Si tu comptes vraiment y mettre de la donnée qui a de la valeur pour toi, ce n'est peut être pas à cette occasion qu'il faut tester/bricoler . Je te conseille plutôt de te faire un labo à côté, mais de déployer une solution solide (et simple par rapport à tes connaissances actuelles) pour tes besoins courants. Ensuite, tu pourras la faire évoluer.
ZFS est top, mais je sais que je n'ai pas le temps de monter en expertise dessus pour éviter de faire des boulettes en CLI. Donc je suis passé par une solution "managée" sur du TrueNAS, dispo en parfum "FreeBSD" (CORE) ou "Linux" (la version SCALE).

Et règle d'or: pense à faire des sauvegardes (externes à ton NAS, évidemment).
_________________
-TrueNAS & jails: µ-serv Gen8 E3-1260L, 16Go ECC + µ-serv N40L, 10Go ECC
-Réseau: APU2C4 (OpenWRT) + GS726Tv3 + 2x GS108Tv2 + Archer C5v1 (OpenWRT)

[Anard]

Merci pour ta réponse Goretto.
Pour ce qui est de MacOS, je l'oublie : si j'en ai besoin, je chercherai une solution pour qu'il puisse accéder au volume en lecture et ça ira bien.

Je viens de recevoir (et d'installer) le matériel. Concernant la sécurité des données, oui j'y tiens beaucoup mais je prends les devants. J'ai des sauvegardes régulières sur un disque externe (USB), donc même si la tour venait à se casser la gueule (passage d'un chat ou d'un chien, autre évènement incontrôlable), les données seraient sécurisée. Ce serait encore mieux avec un Cloud, mais pour le moment ce n'est pas le cas.

Pour le moment j'ai installé la carte PCI dans le PC avec le disque neuf branché dessus (quand je dis neuf, il l'est réellement, encore emballé à la livraison, WD Red). Installé un ZFS standard dessus (stripped) en ligne de commande et j'ai pu y copier mes données d'origine dessus. J'ai donc maintenant 3 copies distinctes : le nouveau DD ZFS, l'ancien en HFS (que j'utilise tjrs comme base, monté par fstab) et la sauvegarde externe de secours.
Je vais commencer à modifier mon système quand j'aurais un peu e temps pour utiliser le ZFS en priorité sur le HFS et voir comment ça se passe.

Après quoi (si ça se passe bien), je voudrais agréger mon HFS comme copie en ZFS "mirror". Problème, je n'arrive pas à accéder aux paramètres de ma carte RAID (j'ai abandonné l'idée d'un RAID matériel). Je voudrais être certain qu'elle ne mette pas mes disques en RAID avant de connecter l'ancien disque à la carte. J'ai essayé de la visualiser avec une VM Windows et le driver sur le CD fourni, mais je ne vois rien (et je ne connais pas du tout cet OS).

J'aimerais m'assurer que le RAID ne passe absolument pas par la carte pour ne faire plus confiance qu'à ZFS avant d'y agréger d'autres disques. L'idée est de finir par 3 disques en ZRaid (==RAID5) voire plus pour gagner à la fois en sécurité et en volume.
Mais il est bien précisé dans le Wiki Gentoo de ne pas utiliser ZFS pour agréger des disques sur une carte RAID, ce qui semble logique, on ne sait plus trop qui gère quoi, et encore moins comment. J'aimerais en fin de compte être certain que quand je connecterai un autre disque à ma carte, il sera simplement vu comme un DD supplémentaire et indépendant, ZFS faisant le reste. Mais comment ?
_________________
"iMack" : GA-H97M-D3H, Intel i5 4460, 16Go DDR3, Intel HD4600, 2x SSD 256Go, HDD 500Go+2To / Clover - macOS Mojave / Gentoo-Xfce
"Portable" : HP 350G3, HDD 500Go / rEFInd - Xubuntu 20.04 / Windows 10

[El_Goretto]

Je vois, je t'invite en effet à regarder un peu la littérature comparant les dispositifs de RAID matériel (une carte) vs du RAID logiciel (que ce soit dm, ou via le système de fichiers).
Le TL;DR est que le RAID matériel te rend dépendant dudit matériel, donc si tu n'as pas de spare en cas de panne, bye, tu ne peux plus exploiter les données sur les disques
_________________
-TrueNAS & jails: µ-serv Gen8 E3-1260L, 16Go ECC + µ-serv N40L, 10Go ECC
-Réseau: APU2C4 (OpenWRT) + GS726Tv3 + 2x GS108Tv2 + Archer C5v1 (OpenWRT)

[Anard]

[roscop]

Salut,

Les remarques d'El_Goretto sont judicieuses, je me permet d'apporter ma petite pierre à l'édifice. C'est un avis personnel que j'essayerais d'argumenter, sans tirer trop en longueur, n'hésites pas à demander des précisions si besoin

disclaimer : Si des fondus du sujet passent par ici, oui je vais employer le terme de "systèmes de fichiers" à outrance, y compris pour des choses qui sont bien plus que ça. Ceci pour des questions de simplification dans le vocabulaire. Je suis venu en paix


En considérant un accès pluriel (Windows/Linux/Mac) pour des données que tu souhaites partager entre différentes machines et auxquelles tu tiens, la première chose que je te dirais c'est qu'elles ne devraient pas être sur ton pc, mais sur une machine dédiée.

Déjà parce qu'un pc et un nas sont deux systèmes qui vont avoir des impératifs différents, exemple :
pc : machine plutôt véloce où on peut faire aussi bien de la navigation web, que du dev, des jeux, regarder des films, bref, un usage pluriel du quotidien. Dans le cas d'un poste sous Gentoo, il ne faut pas oublier non plus l'évolution régulière et la multitudes de packages qu'on a le plus souvent sur nos machines.
nas : mettre à disposition des données pour différentes machines, via (potentiellement) différents protocoles de manière fiable et rapide OU économe.

Un nas n'a pas le même besoin d'évolution de son software qu'un pc, il n'a pas la même complexité non plus à ce sujet et c'est voulu, pour accroître sa fiabilité.

Tout de suite, tu pourrais me dire : "oui mais je ne peux/veux pas multiplier les machines pour X ou Y raisons"
Je te répondrais que c'est compréhensible, mais le cas d'un nas est suffisamment particulier pour justifier une seconde machine dédiée.

Déjà un NAS peut avoir des caractéristiques très variables et surtout très modestes. Une machine de récup avec quelques Go de ram, un vaillant petit celeron (ou raspberry) et une paire de disques, posé dans un coin, peut faire l'affaire.
Pas d'écran, pas de clavier/souris, juste un câble d'alimentation et un câble réseau (ou du wifi) et ça roule.

J'ai évoqué le cas des raspberry, on peut tout à fait avoir un nas avec cette plateforme vu les impératifs cités ci dessus, quelques exemples :
https://pibox.io/
https://www.waveshare.com/cm4-nvme-nas-box.htm
https://www.kickstarter.com/projects/argonforty/argon-eon-4-bay-network-storage-powered-by-raspberry-pi-4/description

Deux de ces modèles n'acceptent pas tes disques actuels (qui sont des 3.5" si je ne me trompe pas), mais c'est à titre d'illustration.
Tu peux aussi envisager en mode diy avec 2 adaptateurs USB, mais là pour le coup je ne recommande pas. La fiabilité des connexions USB dans le temps est à géométrie (très) variable et les retours sont nombreux pour raconter de tristes histoires de raids (logiciels) ou pool (zfs) qui ont été corrompus avec ce genre de solution.

Point important, si le matériel qui compose ton nas peut être fait de récup', il ne faut pas ergoter sur les disques, jamais. Un disque qui commence à flancher, c'est un disque qu'il ne faut plus utiliser pour des données importantes.
Si tu devais faire faire une récupération de données sur un disque HS, le coût serait généralement bien plus élevé que le coût d'un disque neuf. On peut aisément parler d'un cout x10 pour la récupération, ces chiffres se vérifient facilement auprès de société spécialisés.
Là aussi, les tristes histoires de gens qui ont perdus des photos ou des vidéos précieuses à leurs yeux (enfants, mariage, etc) et n'avaient pas conscience du coût d'une récupération vs un changement de disque.

Donc là pour ton disque (avec des seek error) il faudrait voir le reste des infos issues du smart pour se faire une idée.
D'autres indicateurs sont sans appel et même avec une seule erreur il faut se décider à changer un disque.

Et là, tu pourrais avoir des voix s'élevant en disant, pas de problème j'ai un raid, je suis protégé. Et bien non.
Le seul système de fichiers qui peut réellement compenser des problèmes sur un disque dans sa grappe, c'est ZFS. Le raid (quel que soit son niveau) est connu pour ne pas être capable de détecter (et corriger par lui même) un bit rot.
Qu'est ce que le bit rot : https://getprostorage.com/blog/bit-rot-stop-destroying-your-data/

La citation concernant NetApp est à nuancer, il s'agit d'un constructeur de systèmes de stockage qui utilise un système propriétaire ayant beaucoup de similitudes avec ZFS et dont les contraintes n'ont aucune comparaison possible avec un petit nas comme nous le concevons ici

(j'exclue dm-integrity de ma réponse car sa mise en oeuvre et son maintiens sont complexe à mon sens, trop pour quelqu'un qui débute. Par ailleurs cette solution est loin d'être mature)

Au milieu de tout ceci, tu auras aussi peut être remarqué que j'ai complètement éludé BTRFS. La raison est simple, ce système de fichiers a une histoire tumultueuse et les mode d'agrégation (RAID) 5 et 6 sont toujours considérés comme instables ( https://btrfs.readthedocs.io/en/latest/Status.html ). Certaines distributions l'abandonnent (la galaxie Redhat) et d'autres en font un usage par défaut (Suse). Et surtout, son maintiens n'est pas trivial.
BTRFS n'est pas totalement à exclure, certains y trouveront leur compte, mais ce n'est clairement pas celui que je recommanderais de prime abord et plutôt pour des cas très particuliers.

Tu auras peut être entendu parler aussi de stratis (https://stratis-storage.github.io/), alias "club sandwich", le projet a son intérêt, mais là encore, le manque de maturité et le public visé (actuellement) par ce projet ne sont pas en phase avec tes attentes, il me semble.

Si on exclu ZFS, qui pourrait ne pas te convenir (appréhension, impression de complexité, etc) un raid logiciel (MDADM ou LVM) avec un ext4 fait bien le job. La solution est plutôt robuste (si on exclu les problèmes de bit rot, ou qu'on cherche à s'en prémunir autant que faire se peut), simple à mettre en oeuvre, mais assez vite pauvre et contraignante en terme de fonctionnalités.

Les snapshots sont un aspect TRES important sur un NAS, pour les systèmes de fichiers qui le proposent.
LVM permet de prendre des snapshots, mais ceux ci peuvent rapidement avoir un impact sur les performances (notamment du fait de la fragmentation induite, qui est mal gérée par les FS utilisés en coordination avec LVM) et leur usage est plus limité qu'avec ZFS ou BTRFS.
https://www.percona.com/blog/disaster-lvm-performance-in-snapshot-mode/

(Ami fondu de stockage, oui le post est ancien, oui les choses ont bien évoluées depuis notamment avec les snapshots en thin provisioning, mais ce post explique plutôt bien en quoi les snapshots LVM posent problème et je rappelle que le but ici est d'avoir une solution simple à mettre en oeuvre).

Une petite parenthèse justement sur le thin provisioning, aussi appelé NAS à crédit. En thin provisioning (par opposition au thick provisioning), on ne réserve pas l'espace dans un volume (LV, dataset, sub-volume, etc) et on peut donc créer de multiples volumes de différentes tailles, dépassent (si on les additionne) la capacité totale de ton espace de stockage OU, carrément créer un/des volumes, prétendant avoir bien plus d'espace que ce dont on dispose en réalité.
Comme toujours, pour un usage personnel, tout dépend de qui ou comment est utilisé cet espace. Si tu es tout seul aux commandes, en principe tu arriveras à t'entendre avec toi même. Dès l'instant où plusieurs personnes peuvent utiliser ce stockage, les ennuis peuvent pointer le bout de leur nez car tout un chacun n'aura pas forcément conscience du danger qui rôde.
Remplir à 100% un stockage (en thick comme en thin), c'est le mettre dans une condition extrême que certains ne digèrent pas et cela peut mal finir (corruption de données).
Là où en thick provisioning on a facilement en vue l'espace restant, en thin provisioning on peut ne pas voir le mur vers lequel on fonce.

D'une manière générale, il est recommandé d'avoir un monitoring en place sur du stockage en thin provisioning, justement pour avoir une alerte si on approche de la capacité totale du stockage.
Dans un objectif de simplicité et parce qu'au final le thin apporte peu de choses (pour un cas d'usage privé) le thin est plutôt à éviter.

(Ami fondu de stockage, oui une simple alerte par mail dans TrueNAS ou OMV permet d'avoir cette info, j'y reviendrais plus loin )

Maintenant une question qui pourrait crisper ou fâcher, est ce que Gentoo est bien l'OS le plus adapté pour faire un NAS ?
A mon humble avis, pour quelqu'un qui débute, je dirais non.
Fervent partisan de Gentoo depuis maintenant 2 décennies, c’est une réponse qui me pince d’autant plus le cœur que fondamentalement on peut tout à fait faire un NAS sur gentoo.
Mais quand nous avons tous commencé avec cette distribution, la courbe d’apprentissage est importante et là où on peut se permettre de flinguer une install où de galérer avec un noyau qui ne démarre pas, si les données que tu veux stocker sont importantes, il me semble raisonnable de se tourner vers une solution plus simple à mettre en œuvre pour commencer.

Truenas cité par El_Goretto est un acteur majeur des solutions NAS accessibles au grand public, il y a aussi OpenMediaVault, ou Unraid pour compléter le tableau de ce qui est communément évoqué.

Je vais écarter Unraid car la philosophie de ce système est assez différente et elle ne me semble pas correspondre à tes attentes, mais je peux me tromper.

OpenMediaVault et Truenas on chacun leurs avantages et inconvénients, cet article plutôt récent trace les grandes lignes :
https://www.wundertech.net/openmediavault-vs-truenas/
Il y a aussi cet article, il donne une liste assez synthétiques de différences, mais il y a quelques remarques qui sont un peu de parti pris :
https://optimizeddocs.com/blogs/backups/backup%20hardware/truenas%20vs%20openmediavault

Pour éviter de faire (vraiment) trop long je n’irais pas plus loin sur ce segment, libre à toi de poser des questions

Enfin, tu peux te rapprocher de ce que nous connaissons avec Gentoo en partant from scratch, mais avec une simplicité de mise en œuvre plutôt intéressante sur la partie OS, pour te concentrer ensuite sur la partie stockage et services.
La doc d’OpenZFS en la matière est assez bien faite et l’installation from scratch sur une debian (par exemple) est très simple :
https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Bookworm%20Root%20on%20ZFS.html

(Ami Gentooiste, oui sacrilège, je viens ici de poser un lien vers une doc d’install Debian ! Mais ceci n’est pas une fin, juste un début:))

Et là je rejoins ce que disais El_Goretto avec un lab, mais disons que tu fais juste une petite install sur une machine quelconque où le cpu peut être à peu près ce que tu veux (un 64 bits facilitera les choses, mais tu peux te contenter d’un 32 bits pour démarrer), quelques Go de ram, un port réseau (les chip Intel fonctionnent plutôt mieux que ceux des autres fabricants pour un usage soutenu comme sur un NAS), deux disques, ils peuvent même être de taille différente (2.5, 3.5), de techno différente (sas, sata, scsi …) et de capacité différente (dans ce cas il faudra utiliser des partitions dans ton/tes aggrégations). Tout ceci pour des tests, une fois décidé sur ton archi logicielle, tu pourras envisager le matériel qui convient.

Puis un rapide setup de l’OS, pour te concentrer sur la partie vraiment importance ici, bien construire ton service de données pour répondre à tes besoins:)

J’ai cité Debian car tu gardes un peu la main sur l’installation et tu fais quand même quelques choix en mettant un peu les mains dedans pour que tout ne soit pas en mode automatique.
A noter que si à ce niveau tu optes pour TrueNAS ou OMV, le premier permet de faire des choses en CLI (et donc d’être un peu plus au coeur de ta découverte) mais cela peut parfois amener des bizarreries.
OMV permet davantage d’aller en CLI mais demande un peu plus de mise en œuvre parfois en rajoutant des « briques » à l’installation de base (OMV extras).

(Ami fondu de stockage, je parle de ZFS Et j’omet la sacro-sainte règle de la RAM ECC ??? https://arstechnica.com/civis/threads/ars-walkthrough-using-the-zfs-next-gen-filesystem-on-linux.1235679/page-4#post-26303271)
Et pour ceux qui ne connaissent pas Matthew Ahrens, il faisait parti du quatuor de développeurs à l’origine de ZFS, il a été un des fondateurs d’OpenZFS et travaille aujourd’hui chez Delphix:)
https://www.delphix.com/blog/wearedelphix-matt-ahrens

Sans aller jusqu’à parler de lab (qui en général couvre un spectre d’utilisation plus large) tu as un petit bac à sable pour découvrir au choix lvm, mdadm, zfs, btrfs, ou ce que tu voudras tester.

Si tu optes pour une base de Debian et OpenZFS, la doc de ce dernier fourmille d’infos très utiles pour débuter.

OpenZFS intègre aussi le service des données via NFS (Linux, MacOS) et SMB (Windows, MacOS).

Une fois que tu auras pu tester un peu plus avant les différents concepts de ces différentes solutions, tu seras en meilleure situation pour envisager de migrer tes données vers un NAS, qui pourra tout à fait être sous Gentoo, ou pas.
Faciliter les maintenances, rester au plus près de l’objectif (conserver efficacement et servir des données), de préférence avec une petite machine qui sera dans son coin sans nécessiter de grosses maintenance et te laisser vaquer à tes occupations.

Si tu en viens à définir tes besoins matériels pour un nas, il sera bien temps de poser d’autres questions, mais d’abord, amuses toi avec le concept sans stress par rapport à tes données.

Souhaitant que ces infos te soient utiles, que tu ai eu la ténacité de lire ce petit pavé (vaste sujet ...), à ta dispo si tu veux élargir le débat, dans la limite des règles du forum

Bonne découverte !

Ps : dernière remarque sur les posts d’El_Goretto, je le rejoins à 200 % sur l’importance cruciale d’un backup.
Qu’est ce qu’un backup, c’est une copie asynchrone de tes données, stockée dans un autre endroit que celui où se trouve ton NAS. Le cas le plus simple que j’évoque le plus souvent est celui de 2 disques en USB (ou autre) que tu utilises en rotation. Tu synchronises tes données dessus périodiquement puis tu emmènes ce disque chez un parent, ou un lieu sûr et tu prend celui que tu avais laissé pour faire la rotation.
Un snapshot n’est pas un backup, un disque connecté au NAS n’est pas non plus un (vrai) backup.
Et là aussi, on peut parler coût, mais rappelles toi qu’en cas de crash, la récupération de données te couterait bien plus qu’un disque neuf.
En plus sophistiqué tu peux aussi avoir 2 machines en réseau qui se synchronisent périodiquement, mais là, on attaque un autre chapitre que tu ouvriras, si tu le souhaites:)

[Anard]

D'abord merci beaucoup pour ce "pavé" comme tu dis. De mon point de vue, j'appelerai plutôt ça une "mine"
Et je vais y revenir et continuer à me documenter sur tous (ou une grande partie) des points que tu soulève ici.

Après une première lecture, dans laquelle beaucoup d'aspects m'échappent encore, vu mon niveau actuel, je tiens à préciser où j'en suis actuellement.
Concernant la sauvegarde d'abord, ma solution n'est pas "sans risque" puisque j'utilise un disque de backup USB externe, toujours posé sur mon bureau (un incendie aura raison de tout le monde à coup sûr). Cette sauvegarde se fait sur un système de fichiers éprouvé (ext4) de manières régulière par rsync (backintime plus précisément) et j'essaie de le garder d'une capacité d'environ 2x mon disque partagé (que j'appelle NAS plus haut mais qui n'en est pas vraiment encore un ). Je considère que mes autres données sauvegardées sont négligeables (en terme d'espace disque) par rapport à celui-ci.

• /boot/efi (sda1 sur SSD) : 9Mo / 197Mo
  
• / (sda2 sur SSD) : 75Go / 229Go
  
• /home (sdb sur HDD) : 115Go / 217Go
  
• /media/Medias ("NAS" sur HDDs) : 1562Go / 1800Go
  
• /media/Saver (sauvergardes USB sur HDD) : 95% de 4To
  

Actuellement mon disque partagé fonctionne en ZFS sur 2 disques mirroir de 2To chacun dont l'un est celui qui me fait peur. J'utilise des disques de marque/modèles/années différentes. Pour le moment un Seagate Video et un WD Red.
Pour ce qui est du rapport SMART complet :

[roscop]

Salut,

Un backup sur un disque externe usb à côté de ta machine vaut tjr mieux que pas de backup du tout
Dans ce domaine comme dans d'autres, c'est toujours un équilibre entre le coût, les performances et la fiabilité.

C'est judicieux aussi de mettre ton disque de sauvegarde dans un autre modèle (de fonctionnement) que ton stockage principal, dans un premier temps du moins.
Lorsque tu seras plus en confiance avec tes choix et leurs usage, il est probable que tu remettes pas mal de choses en phase.

Ah, ton disque sur lequel tu as des seek error est un Seagate, je comprend mieux
Petite explication si tu veux en savoir plus :
https://web.archive.org/web/20190202110342/http://www.users.on.net/~fzabkar/HDD/Seagate_SER_RRER_HEC.html

Par contre on voit bien que c'est un disque qui est dans une machine qui s'arrête régulièrement. C'est là quelque chose de déconseillé pour un NAS.
Les choses qui usent le plus un disque dur (pas un SSD !) sont :
- les démarrages du disque (cela inclus le parcage des têtes lorsqu'un disque lorsque l'APM est activé)
- les fortes variations de températures
- les températures très élevées en continu (au dessus de 45°c relevé sur le disque on perd en durabilité sur le long terme)
Il y a pas mal de papiers sur ce sujet, avec beaucoup de choses intéressantes dans celui ci dessous, même si selon les constructeurs (et les types de disques), ces informations sont parfois à nuancer.
https://research.google.com/archive/disk_failures.pdf

(note, les papiers de Backblaze sont à prendre avec des pincettes géantes, leur mode de fonctionnement et les contraintes qu'ils imposent à leurs systèmes sont loin des communs...)

Ton disque Seagate ne semble pas en mauvais état, il a un peu d'heures de vol au compteur mais rien de catastrophique, les arrêts répétés sont par contre néfastes.
Je ne sais pas si tu le fais, et du fait que éteins ton pc, je pense que ce n'est pas le cas, mais tu peux planifier une vérification smart approfondie (et/ou rapide) régulièrement sur tes disques :
https://wiki.gentoo.org/wiki/Smartmontools#smartd.conf_Configuration
https://dan.langille.org/2018/11/04/using-smartd-to-automatically-run-tests-on-your-drives/

Un test rapide régulièrement et un test approfondi de temps en temps. Cela n'a aucune incidence sur la performance ou la fiabilité de ton disque et tu retrouves les résultats de ces tests à la fin du smartctl --all /dev/sdX
Cela permet de détecter plus facilement des secteurs défectueux, par exemple.
Je note aussi la température très stable de ton disque (Seagate) c'est bien, cela suggère que tu ai un ventilateur performant qui souffle dessus un air plutôt frais. Attention aux vibrations tout de même.
Les vibrations, il ne faut pas se mettre en tête un marteau piqueur à 2M de son pc, une vidéo qui a pas mal éveillé les consciences est celle de Brendan Gregg :
https://www.youtube.com/watch?v=tDacjrSCeq4
Et ce n'est pas un canular, Brendan Gregg est quelqu'un d'exceptionnel qui a pu expliquer ce constat à maintes reprises :
https://www.youtube.com/watch?v=lMPozJFC8g0

Pour rebondir sur backintime, mais sur le pendant zfs, je t'invite à regarder znapzend (https://www.znapzend.org/). Pas pour la situation actuelle où tu te trouves, mais peut être y trouveras tu un intérêt ultérieur.
Faire du snapshot de son homedir à interval court, en garder un certain nombre en local et avoir une copie distante en toute transparence est un luxe très très appréciable

L'ajout de disques en ZFS est un gros point noir en effet, c'est avant tout une affaire de choix dans le design initial et son évolutivité.
D'ailleurs, la "conversion" d'un mirror en z1 n'est pas triviale et souvent basée sur des approches un peu bancales. Car de base, ce n'est pas supporté.
Les choses évoluent à ce sujet, mais ZFS profite aussi d'un transfert complet d'un pool à l'autre, pour de multiples raisons (compression, défragmentation, etc).

Les probabilités de pannes entraînant une perte de données en Z1 sont plus élevées qu'en mirror.

Tu peux vérifier cela via différents calculateurs en ligne, tels que :
https://wintelguy.com/raidmttdl.pl
https://www.servethehome.com/raid-calculator/raid-reliability-calculator-simple-mttdl-model/


En prenant les specs du disque RED 2T (WD20EFAX) et celles du Seagate (ST2000VM003), qui se trouvent être les même, il faut prendre en compte ces caractéristiques :
Unrecoverable Error Rate (URE) : 10^14
Mean Time Between Failure (MTBF) : 1000000 Heures (en général ces calculateurs ont des seuils fixes, vu le mtbf annoncé, cela les placera dans une classe comparable à des disques type desktop)

(Le WD purple que tu attends, si c'est bien un 2T, les specs sont les même. On est sur la même mécanique de base, mais firmware au comportement différent)

Et tu devrais avoir un rapport de l'ordre de 1 pour 3 en faveur du mirror.
Ces résultats varient forcément en fonction du nombre de disques, y compris en mirror vu que dans cette configuration on créé des vdev de deux disques (en général) et qu'on agrège ces vdev pour former le pool.
Mais un pool ne peut pas survivre à la perte d'un vdev entier. Donc le rapport évolue à mesure qu'on rajoute des vdev.
Le MTBF seul ne veut rien dire, c'est un indicateur synthétique issu d'une projection de vieillissement accéléré de composants formant un système (ici le disque dur).
C'est pour cela que tu observeras des différences dans les résultats en fonction de la vitesse de reconstruction et d'autres paramètres, plus le temps de reconstruction est long, plus les risques sont élevés, idem pour un URE moyen (ce qui est malheureusement le cas sur des disques "grand public") et d'autres facteurs. Ces calculateurs sont publics et réputés fiables pour des disques placés dans des conditions stables de systèmes de stockage.

Bref ceci pour dire que dans la phase actuelle où tu es, il te faut réfléchir à l'évolution de ton NAS en terme de volumétrie et de durée de vie. C'est aussi là où PC et NAS divergent.

Tu peux donc aussi envisager d'avoir 2 vdev en mirroir pour atteindre la même capacité que ton Z1, certes cela te coûte un disque de plus.
Le Z1 (comme le raid5) sont vraiment déconseillés sur de nouveaux systèmes aujourd'hui, principalement pour des NAS avec des disques beaucoup plus capacitifs.
Au delà de disques de 4To, le raid5/z1 devient une option à rejeter.

On pourrait dire quantité de choses sur ce sujet, mais si l'on veut aller à l'essentiel, penses ton NAS pour "demain", pas aujourd'hui.

En ZFS, il faudra aussi prendre en compte la taille des secteurs (512e ?) : https://www.delphix.com/blog/4k-sectors-and-zfs
Mais aussi le nombre de disques par vdev : https://www.truenas.com/community/threads/raidz-suggested-number-of-drives-for-maximum-performance.9990/ (sur ce point, la performance sera d'autant plus importante durant les rebuilds et les scrubs)
Et les choses plus exotiques (pour un petit NAS à la maison) dont tu pourrais entendre parler (ZIL, L2ARC, DRAID) : https://klarasystems.com/articles/openzfs-understanding-zfs-vdev-types/

Pour du NAS, il faut absolument fuir les disques SMR. Même des constructeurs qui l'acceptaient avant n'en veulent plus.
https://www.cachem.fr/smr-synology-incompatible-nas/

WD a été au coeur d'une grosse polémique il y a quelques années à cause de cela.
https://www.silicon.fr/smrgate-disques-durs-339085.html
https://support-fr.wd.com/app/answers/detailweb/a_id/50755/~/d%C3%A9terminer-si-un-disque-interne-utilise-la-technologie-cmr-ou-smr

(Bon Seagate, Samsung, Conner et d'autres ont aussi eu leurs lots de casseroles )

Ceci ne remet pas en cause la fiabilité des disques, uniquement leurs performances (pour des SMR) lorsqu'ils sont utilisés sur des systèmes qui ne sont pas prévus pour le prendre en charge.

(je donne quelques liens mais n'hésites pas à en chercher d'autres par toi même, il n'est pas rare que le point de vue évoqué ai un parti pris, selon le public visé).

Evites aussi la déduplication. Elle fonctionne très bien mais réclame beaucoup de RAM. BTRFS s'en sort mieux, mais ce n'est pas une déduplication à la volée et quand ça le sera, il faudra là aussi beaucoup de RAM.

Je te suggère aussi d'éviter les flags exotiques et tuning ZFS sans avoir une vraie compréhension des conséquences. On voit assez souvent des paramètres balancés sans trop d'explication et parfois il faut aussi remettre dans le contexte du moment où ces paramètres ont été fournis. OpenZFS évolue beaucoup et comme pour d'autres logiciels, les développeurs apportent des changements qui peuvent avoir une interaction différente avec une option au fil du temps.

Dans mes message, je fourni avant tout un avis personnel. Certains points sont factuellement vérifiables, d'autres laissés à ton appréciation. En aucune manière il ne faut y voir de critique, si tel a été ton ressenti, je te prie de m'en excuser.
L'intérêt d'une machine annexe pour un NAS vient de différents aspects que j'ai partiellement abordé (usure prématurée des disques, simplification de la maintenance, objectif distincts de ce système, etc).
Après, on peut comprendre, pour tout un tas de raisons que ce ne soit pas voulu/possible.
Par contre, Gentoo est tout à fait capable d'être l'OS pour un NAS. Il n'a qu'à voir la profusion de projets annexes et de variations autour de Gentoo pour s'en convaincre. Si j'ai évoqué une alternative c'est pour un bac à sable, où tu pourrais faire différents essais et ne pas craindre pour tes données.
Ici et là tu verras peut être des exemples à base de fichiers créés avec dd ou de X partitions sur un disque connecté en USB, c'est valable pour un POC ou un essai sur le coin de la table (no offense) mais ce serait oublier que ZFS se comporte très différemment quand il gère un disque vs un périphérique virtuel.
Donc Gentoo à terme, oui bien sûr, ou pas, tu verras
A qui veut maîtriser son NAS je ne recommande pas - à terme - d'aller vers TrueNAS ou consort qui apportent un énorme confort d'utilisation, mais nous dépouille de ce genre de connaissances parfois durement acquises en installant notre première Gentoo

A+

ps : M. Torvald a dit beaucoup de choses, comme celle ci aussi :
“Publicly making fun of people is half the fun of open source programming. In fact the main reason to eschew programming in closed environments is that you can't embarrass people in public.”

... qui était d'ailleurs en rebond d'une moquerie de GKH (Greg Kroak-Hartman) envers un contributeur ...

Certains s'en sont émus, ou on pris ces propos hors contexte :
https://lwn.net/Articles/559521/

Mais il faut se rappeler que le noyau de Linux est un projet vieux de 32 ans dont l'objectif initial a été très (très) largement dépassé.
Les contributions sont très nombreuses et d'une qualité très variable (tant dans le code que dans sa présentation).
Il est au cœur de nombreux systèmes aujourd'hui et d'enjeux financiers considérables (il ne faut pas oublier qu'une bonne partie des top développeurs du noyau sont payés par des sociétés telles qu'Intel, IBM ou Google).
Qui pourrait rester d'un calme olympien lorsqu'on lui amène pour la Xième fois en une matinée, un travail bâclé à vérifier ? ... pendant plus de 30 ans

Cependant, si l'on prend en compte les code of conduct mis en place dans beaucoup de projets (de dev) communautaires aujourd'hui et sans aller (parfois) sur des dérives pour le moins discutables, est ce que ces mots sont vraiment acceptables ?

M. Torvald est un personnage public ce qui inclus son lot de drama (Alan Cox, Con Kovilas, etc) et de polémiques (Nvidia, sa décision de 2018 de se mettre à l'écart quelques temps). Les problèmes de licences autour du noyau sont un sujet parfois explosif (ex : GNU Linux vs Linux). Il y a clairement des tentatives nauséabondes qui - fort heureusement - sont rabrouées, mais parfois chacun aurait pu faire un bout de chemin ... Bref, à chacun de décider ce qu'il veut faire, sur la base d'arguments factuels
Le projet OpenZFS est effectivement controversé, mais est ce encore pour des questions techniques ou juridiques ?
https://arstechnica.com/gadgets/2020/01/linus-torvalds-zfs-statements-arent-right-heres-the-straight-dope/

[Anard]

Salut,

[roscop]

Salut,

Réponse un peu dans le désordre, car certains points se regroupent les uns les autres

L'arrêt intempestif d'un serveur avec un pool ZFS n'est en effet pas recommandé. C'est davantage valable pour un pool très actif car c'est lié aux I/O non acquittées.

On réduit - normalement - les risques en ayant un SLOG, mais dans les faits c'est plus incertain et source d'autres problèmes.
https://www.servethehome.com/what-is-the-zfs-zil-slog-and-what-makes-a-good-one/
https://www.truenas.com/docs/references/zilandslog/

Je dis - normalement - car le SLOG fait parti intégrante du pool et au même titre qu'un autre vdev, si on perd le slog, on perd le pool. Et une fois ajouté ... on ne peut plus le retirer
Dans les faits, pour être pertinent (par rapport aux disques durs eux même) le slog est en flash (voir mieux) et l'usure sera alors un point critique.
Le plus souvent le slog est un mirror sur 2 ssd de très grande capacité, dont on alloue qu'une faible portion. Pas du ssd bas de gamme, et la faible allocation est destinée à améliorer la durée de vie (plus de cellules=plus d'écritures supportées)

Du coup, est ce qu'un petit onduleur tenant le coup 5 minutes n'est il pas plus approprié qu'un slog pour un petit NAS à la maison, de mon point de vue si car l'onduleur a bien d'autres bienfaits que prévenir un arrêt intempestif. Mais cela reste une option.

Si je reprend l'exemple des quelques modèles raspberry que j'avais listé dans mon premier message, on y met (préférablement) du ssd, du coup on a déjà un stockage rapide.
Est ce qu'un onduleur aurait son intérêt ? C'est toujours mieux, mais l'intérêt s'amenuise.
Est ce qu'un slog a son intérêt (dans ce cas particulier) ? A mon avis non. Les risques d'une écriture manquée, entraînant une corruption, avec un stockage flash, sur un nas maison sont très faibles. Le risque zéro n'existe pas, après il faut placer la barre où l'on veut/peut.

Sur onduleur tu peux contrôler l'arrêt de la machine (avec NUTS dans ton actuel je suppose) et sur un NAS point de mise en veille. Sur le principe soit c'est une micro coupure et l'onduleur fait le job pour tenir une petite trentaine de secondes, soit c'est plus long et on ne maîtrise alors plus grand chose, il vaut mieux éteindre et aviser manuellement de la reprise.
Les contraintes entre un pc et un nas/serveur sont différentes


Le furieux débat sur les disques, leur approvisionnement et les risques d'un modèle unique.
Vaste, très vaste sujet, on va essayer de rester TRES synthétique
Les remarques qui viennent s'appliquent plutôt à du matériel grand public ou assimilable. Pour du pro la réflexion est toute autre.

Oui un modèle unique de disque peut présenter plus de risque.
Mais on peut réduire ce risque en prenant des disques de batchs différents (en les achetant à différents revendeurs ou à différentes époques par exemple)
Réciproquement, multiplier les modèles c'est avoir des caractéristiques parfois très différentes entre chacun d'eux.
Parfois on a des choses assez homogènes, parfois non.
On peut avoir des disques qui chauffent davantage que d'autres - à vitesse égale - ce qui dans le cas de ta thermorégulation peut avoir un impact par exemple.
On peut avoir des disques qui vont tourner à des vitesses différentes, et donc engendrer plus ou moins de vibrations/bruits/chaleur
On peut avoir des disques qui vont se comporter différemment avec les vibrations justement (certains ont un capteur et parmi ceux là, la gestion de la vibration est différente selon les modèles. D'autres n'ont tout simplement pas de capteur car ils ne sont pas prévus pour tourner en grappe ou pour des raisons de gamme)

Pour ma part je suis partisan d'avoir un seul modèle de disques par pool, en variant le batch et surtout, en les testant bien avant usage.

Les conditions de transport sont parfois très mouvementées.
On ne sait pas ce que le disque a vécu avant d'arriver dans nos mains.

Construire un NAS c'est aussi bien préparer le matériel.

Pour ma part, à réception les disques sont déballés et posés dans la pièce où ils vont être utilisés pendant 48h minimum. Pour stabiliser leur température.
Ensuite, le matériel est identifié (date de fabrication, usine, firmware, etc)
Après montage, un premier smartctl --all pour avoir une première info sur les disques
Puis un test de surface (badblocks) en 4 passes en lecture écriture (badblocks -wvs /dev/sdX). 4 passes pour un test en RW plus exhaustif et repasser plusieurs fois sur chaque secteur.
smartctl --all régulièrement sur les disques et un test smart long après la moitié du test.

C'est parfois plusieurs jours de tests pour des disques de qq To.

Mais si un disque a envie de lâcher c'est statistiquement plutôt au tout début ou après 3 / 4 ans d'utilisation. Cela peut arriver entre temps, mais en faisant un bon stress test dès le début, on sait si le disque à des secteurs défectueux ou d'autres défauts assez vite.

Je n'ai rien inventé, cette approche est régulièrement évoquée dans de multiples posts dans les forums et communautés NAS. Elle fait sens selon moi, libre à chacun de faire de faire ce qu'il veut

Parmi ceux encore en service, j'ai des WD Red qui ont plus de 8 ans, on tournés pratiquement H24 et un seul a flanché.




Les accès NFS se gèrent effectivement par la propriété sharenfs, mais tu peux être très fin dans les réglages, petit exemple une règle en ro et rw :

user@host ~# zfs set sharenfs="ro=192.168.10.11/32,ro=172.20.10.0/24,rw=172.22.25.144/32,no_root_squash" pool4/mirror/git
user@host ~# zfs get sharenfs pool4/mirror/git
NAME PROPERTY VALUE SOURCE
pool4/mirror/git sharenfs ro=192.168.10.11/32,ro=172.20.10.0/24,rw=172.22.25.144/32,no_root_squash local

En alternative des ip, tu peux utiliser un fqdn, un sous domaine, etc.
Le no_root_squash est facultatif. Cependant il faut tenir compte du bug 3860 d'OpenZFS.
Tu n'es pas obligé de l'utiliser (il est même judicieux de bien en cerner l'intérêt), je l'ai mis aussi à titre d'exemple pour l'illustrer qu'on peut spécifier d'autres options

https://openzfs.github.io/openzfs-docs/man/master/7/zfsprops.7.html#sharenfs

Sur les aspects exports, OpenZFS reprend grosso modo les options disponibles sur un share NFS classique.

On s'écarte un peu du sujet initial, mais que ce soit sur ton pc ou sur un serveur, pour NFS il est judicieux de restreindre les ports pour appliquer des règles de firewall efficaces. Il y a un très bon topic sur le sujet :
https://forums.gentoo.org/viewtopic-t-77748-start-0.html

En principe c'est plutôt pour NFSv3 (et antérieur, mais utiliser NFSv2 aujourd'hui relève du masochisme ou d'une obligation lié à un équipement qui ne peut pas faire mieux).
Pour NFSv4, tout est sensé passer par le port 2049. Tu monteras probablement par NFSv4 si tu ne l'exclu pas explicitement.
https://wiki.gentoo.org/wiki/Nfs-utils#Daemon

D'une manière générale il est toujours préférable d'exclure/désactiver tout ce qu'on ne veut pas, et cela de manière explicite.
C'est un peu ce que nous (Gentooistes) faisons (entre autre) en configurant notre noyau aux petits oignons



Pour la température des disques, attention tout de même, un disque dur (et l'électronique en général) n'aime pas les extrêmes (chaud ou froid) ni les grosses variations.
On ne va pas rentrer dans le détail mais disons qu'en dessous d'un seuil (qui varie selon la nature du composant) les caractéristiques vont varier et peuvent être hors limite pour un fonctionnement nominal.
Un cas plutôt connu de dégradation par la température avait surgi au début des années 2000 avec le "capacitor plague" (peste des condensateurs) le passage le plus en rapport de l'article wikipedia est ici :
https://en.wikipedia.org/wiki/Capacitor_plague#Premature_failure

Pour un disque (HDD), je dirais que 35 est une température proche de l'idéal, 30 à minima, 40 à maxima (pour les meilleures conditions). Le rapport de Google est intéressant à ce sujet, il y a d'autres sources d'infos valables bien sûr.
Certains disques peuvent encaisser davantage de manière durable, mais disons que c'est une plage qui convient le plus souvent.
Pour les SSD c'est une autre paire de manche, tu n'en a pas dans ta conf, donc si la curiosité te pique sur ce sujet, tu le diras ou tu te feras ta propre opinion en ligne.


Tu parles de zraid, peut être est il question de draid plutôt ? Si c'est le cas, prend le temps de bien lire la doc à ce sujet, c'est un concept assez différent des raidz et mirror.

A+