Mic13710

FPS = Frame Per Second ou en Français IPS (Images Par Seconde). Les caractéristiques sont données pour le maximum que peut traiter le NAS. Par exemple, si vous avez 2 caméras 5M en 2591x1944, le nombre maximum d'images par seconde que votre NAS pourra traiter sera de 270, ce qui pour chaque caméra autorise jusqu'à 270/2 = 135 FPS. Ces valeurs ne sont possibles que si le nas est peu sollicité. Dans votre cas, avec 2 caméras, ça ne devrait pas poser de problème pour le NAS sur un réseau local. Par contre, même avec la fibre, vous êtes assujetti aux aléas du réseau publique et il est possible que les paquets envoyés soient parfois bloqués quelque part dans les tuyaux. Vous avez ajouté une caméra et augmenté la résolution des deux. Vous n’êtes plus du tout dans les mêmes conditions. Essayez de jouer avec les résolutions et les FPS (IPS) de chaque caméra afin de trouver le point d'équilibre.

Regardez peut-être au niveau des résolutions de vos caméras viz les capacités FPS de votre NAS. Si la résolution est trop importante et que vous êtes aux limites FPS du nas, vous pouvez avoir des déconnexions. Vous pouvez tenter de diminuer votre résolution. Autre piste, le switch. Celui des box (orange notamment) est assez médiocre et peut provoquer ce genre de problème.

C'est sans doute que vos caméras sont connectées en wifi et qu'elles perdent le signal. Il est préférable de les connecter en filaire et si ce n'est pas possible, avoir un bon wifi et un signal fort pour avoir un meilleur taux de transfert. Il se peut en effet que ce soit votre wifi qui pose problème (ceux des box sont loin d'être de qualité) et provoque des déconnexions. Il n'y a pas à ma connaissance de possibilité de retarder ou d'inhiber l'alerte. De toute manière, s'il y a alerte c'est qu'il y a un soucis et c'est ça qu'il faut corriger.

Le SHR fonctionne très bien. A mon avis, c'est un problème de taille de disque et de bande. Vouloir jumeler un disque de 80Go avec un 2To, ça ne doit pas être possible tout simplement, que ce soit pour un RAID classique et un SHR. Si les bandes qui doivent être créées sont supérieures à 80Go, ce qui est probablement le cas, il sera impossible de monter un RAID avec un disque de taille supérieure.

Tu veux dire, dans la même situation ? Pas tout à fait. Un 216+ t'apporterait plus qu'à moi. Les caractéristiques et les performances d'un 212, même si elles sont honorables, sont tout de même inférieures à celles d'un 214+. Pour ma part, ce serait plus un coup de coeur, mais alors c'est plutôt du côté du 716+ que je me tournerais.

C'est sûr que le deal est devenu moins intéressant. @CoolRaoul alors, tu as franchi le pas ?

Effectivement. C'est seulement si j'achète un 716+ (mon préféré) ou si j'attends l’hypothétique 217+. Pour l'instant je n'ai aucune urgence. Ce serait plutôt un coup de coeur (et un trou dans le porte monnaie).

@EinsteiniumSauf erreur, pour Virtual DSM il faut docker. Il n'y a pas docker sur le 214+. C'est réservé je crois aux proc intel et le 214 a un marvell armada.

Utilisation exclusivement familiale et ludique (pour moi). Ca ne se bouscule pas beaucoup au niveau du seul lien en activité .

Les 2 cartes réseaux c'est bien, à condition d'en avoir l'utilité. J'ai bien 2 cartes sur le 214 et je ne m'en sert que d'une. Ce n'est donc pas un critère pour moi.

Je n'ai pas vu de différence notable entre DSM5.2 et 6 sur le 214+. CPU entre 5 et 60%, RAM entre 25 et 50%, il a encore de la marge le bougre. Après effectivement, c'est plutôt le 716 qui m'intéresse. Pas tellement pour ses performances qui sont à peine supérieures à celles du 216, mais plutôt pour ses capacités pour la vidéo surveillance où il enterre le 216.

@EinsteiniumUn 214+. Il est bien suffisant pour moi et je suis loin de l'avoir poussé dans ses derniers retranchements, quoiqu'un peu limite pour surveillance station et mes 6 caméras. C'est surtout Docker et le BTRFS qui m'attirent dans le 216+II et accessoirement de pouvoir booster SS. J'ai aussi un 710+ qui ne me sert que pour les sauvegardes.

Bienvenue sur le forum. Vous trouverez des tutos utiles dans la section tutorials du forum, notamment celui sur la sécurisation des accès qui est un must si vous voulez vous connecter à distance.

C'était pour bolcho qui l'a payé au prix fort il y a une semaine . C'est sûr que c'est un excellent NAS. Il y en a encore chez Amazon. Si je n'étais pas raisonnable, j'en prendrais bien un. Je ne sais pas si je vais rester longtemps raisonnable....

C'est la loose !

Frais de livraison : out ? Ca veut dire inclus ?

Je t'avais bien dit que je ferais un "petit" retour . Bon, d'accord, je suis allé un peu loin, mais je pense que ça peut en aider certains après la mise en place de leur serveur DNS. C'est une bonne suite à ton tuto.

Edition du 11/01/2023 : Veillez noter que ce fil à été créé il y a 5 ans. Certains chapitres sont maintenant obsolètes, notamment la partie concernant le certificat qui accepte le wildcard ce qui simplifie grandement sa mise en oeuvre. Les images ne sont plus accessibles car l'hébergeur a fermé ses portes. Ce descriptif étant ancien et quelque peu dépassé, je les mettrai à jour seulement si quelqu'un m'en fait la demande. J'ai conservé l'hébergement de ma zone publique à titre de test pendant quelque temps. Aujourd'hui cet hébergement est à nouveau chez OVH. Pour info, lors du rapatriement de ma zone chez OVH, je n'ai pas réussi à supprimer l'enregistrement GLUE à partir de mon interface client. Il a fallu pour cela que je contacte OVH. Mic13710 ________________________________________ Après quelques semaines d’utilisation, je viens vous faire part de ma petite expérience pour la mise en place de mon serveur DNS et de ce qui en a découlé. Tout d'abord je remercie Fenrir pour cet excellent tuto, et aussi (et surtout) pour son assistance lors de sa mise en oeuvre sans laquelle j'aurais sûrement abandonné. Il lui aura fallu beaucoup de patience et de bienveillance pour supporter un boulet tel que moi. Il est vrai que le sujet n'est pas des plus faciles quand on n'est pas de la partie. C'est mon cas. Bref, j'ai voulu aller au bout de la démarche. Possédant un nom de domaine chez OVH et une IP fixe (Free), j'avais les ingrédients nécessaires pour me lancer dans l'aventure. Mon objectif était de : pouvoir utiliser les mêmes url côté WAN et côté LAN, héberger mon propre serveur DNS, par la suite pouvoir m'affranchir des contraintes de ports en utilisant le reverse proxy qui est dispo en natif sur nos NAS depuis DSM 6.0. Il ne me restait plus qu'à trouver le courage et le temps, puis je me suis lancé. Je ne vais pas m'étendre sur la zone DNS locale qui est largement documentée sur le tuto (mais j'y reviendrai plus loin) pour passer sur la partie publique. L'idée étant de tester le tuto jusqu'au bout, j'ai opté pour la troisième possibilité : Être à la fois serveur SOA et NS c'est à dire le point 2 de mon objectif. Tant qu'à être dans la mouise, autant s'y mettre carrément. Mon compte chez OVH étant très basique (juste le nom de domaine) je n’ai pas la possibilité de créer un DNS secondaire. Et comme je n'ai pas non plus la possibilité de l'héberger ailleurs, c'est Fenrir qui m’a permis d'utiliser temporairement son domaine, le temps de la mise en place de mon serveur. Merci à lui. Après quelques errements sur des problèmes de NS, A et CNAME qui bloquaient le processus (Fenrir saura de quoi je parle), j’ai enfin réussi à passer le test Zonemaster pour nos deux serveurs DNS. Ne restait plus qu’à officialiser ces serveurs pour les faire connaître au monde entier. Pour ceux qui sont chez OVH, il suffit d’aller dans l’onglet Serveurs DNS du domaine, de cliquer sur "Ajouter un serveur DNS", de rentrer l’adresse du serveur principal (c’est l’adresse de l’enregistrement NS de la zone publique), d’indiquer son IP publique fixe puis de valider. Faire de même pour le serveur DNS secondaire. La procédure devrait être similaire chez les autres fournisseurs. Personnellement, j’ai rencontré un problème pour la mise en place du serveur de Fenrir. En effet, je n’ai pas pu faire l’enregistrement avec le nom du DNS et son adresse IP, chaque tentative se soldant par un échec. Il m’a fallu faire l’enregistrement en utilisant uniquement le DNS (sans l’adresse IP) et là c’est passé. Je n'ai pas compris pourquoi, mais si ça vous arrive vous pouvez essayer de faire de même. Enfin, j’ai fait un enregistrement GLUE de mon serveur DNS pour qu’il soit diffusé all over the world. Chez OVH, onglet GLUE, bouton "DNS Ajouter". On renseigne les informations du DNS principal (les mêmes que précédemment) et on valide. Une fois les serveurs DNS actifs, je n’avais plus besoin ni des enregistrements de zone que j’avais créé chez OVH ni des serveurs DNS d’OVH. Pour ces derniers, il m’a suffi de les supprimer dans l’onglet DNS (dans mon cas, il s’agissait de ns200.anycast.me et dns200.anycast.me). J’ai tout de même conservé les enregistrements de zone (juste au cas où j’aurais besoin de revenir en arrière ). Mes enregistrements Serveurs DNS ressemblent maintenant à ça : Pour info : puisque j’ai gardé mes anciens enregistrements, j’ai aussi un message dans la page Zone DNS qui m’informe gentiment que j'utilise les serveurs DNS que je viens d’activer (c’est rassurant) et que la zone que j’ai conservée n'est utilisable que si j’active les serveurs DNS d’OVH. A noter que la mise en place définitive des serveurs est quasi immédiate chez OVH mais peut prendre quelques jours pour être diffusée. J’ai dû attendre 3 à 4 jours pour qu’ils soient enregistrés partout. A ce stade, le tuto a été testé, le serveur DNS est fonctionnel et les points 1 (utilisation des mêmes url) et 2 (hébergement de mon serveur DNS) de mon objectif sont atteints. Premières conclusions Tout ça c’est très bien et à condition d’avoir correctement fait les redirections de ports du NAS et du routeur, ça fonctionne à merveille. Mais ça m’avance à quoi par rapport au loopback en natif chez free ? Certes, je ne passe plus par le routeur (loopback) pour mes requêtes sur le LAN (qui se limitaient en réalité à CloudStation), mais en pratique ça n’a rien changé côté utilisation. Si j’indique mondomaine:5001 de l’intérieur ou de l’extérieur j’accède bien en https à mon NAS, comme avant. Pareil pour CloudStation et toutes les autres applis. J'utilise les mêmes url qu'avant et je suis toujours obligé d’indiquer des ports pour accéder aux différents services. Oublier Quickconnect ? Je ne m’en servais pas de toute façon, donc sans intérêt pour moi. Bref, il n'y a aucune différence palpable sur l'utilisation de mon NAS. En l’état, et exception faite qu'il s'agissait aussi de tester le tuto, le serveur DNS ne me sert à rien. Pour que tout ce travail puisse avoir un impact concret sur mon utilisation de tous les jours, il fallait pousser plus loin la démarche en s'affranchissant notamment des contraintes de ports (point 3 de mon objectif). En parallèle, j’avais aussi un soucis à résoudre avec les certificats Domoticz de mes deux Raspberry qui ne sont pas bien reconnus par mon navigateur, ce qui m'obligeait à faire des exceptions pour pouvoir m'y connecter. Et tant qu'à faire, c’eut été bien de pouvoir aussi y apporter une solution. Et c‘est là qu’intervient le reverse proxy. Reverse proxy Une version simplifiée du proxy inversé (reverse proxy) est incluse dans DSM depuis la version 6.0. Elle se trouve dans le portail des Applications et elle est bien suffisante pour mon utilisation. Pour commencer, j’ai modifié et complété mes enregistrements DNS pour y intégrer un certain nombre de domaines. Voici une partie de ces enregistrements. DNS local : DNS publique : Je n’ai pas mis tous mes enregistrements publiques car ça n’apporte rien pour la suite. A noter : hormis le premier enregistrement NS dans la zone publique qui est l’adresse du DNS secondaire (Fenrir), tout ce qui est caché correspond à mon nom de domaine chez OVH. Pour ceux qui suivraient ce tuto et qui utilisent le DNS publique de leur bureau d'enregistrement (points 1 et 2 du DNS publique du tuto de Fenrir), la démarche est la même : les enregistrements sont à faire dans la zone DNS du bureau d'enregistrement (internet). Quelques explications sur les noms de domaine : audio, video, file, cam, get sont les noms que j’ai attribués pour accéder aux applications du NAS. Pour que ces noms soient utilisables à la fois sur le LAN et le WAN, ils sont enregistrés dans les deux zones DNS. domo accède à Domoticz sur le NAS, domo.s1 et domo.s2 à mes deux Raspberry sur lesquels tourne Domoticz. Ces noms sont enregistrés eux aussi dans les deux zones DNS pour être accessibles côté LAN et côté WAN. cam.bureau, cam.cuisine etc… sont les adresses pour accéder à mes caméras. Elles ne sont accessibles que sur le LAN (enregistrements dans le DNS local uniquement). sauvegarde c’est pour mon NAS de sauvegarde, routeur est suffisamment explicite, nas aussi, quant à tv1 c’est ma télé. Ces noms ne sont enregistrés que dans le DNS local. A noter que domo.s1 et domo.s2 ne pointent pas vers des adresses IP de mon LAN mais vers mon nom de domaine. C’est important pour la suite. Dans le portail des applications, j’utilisais jusqu'à présent les alias côté LAN (très pratique) mais c’est incompatible avec le DNS et le reverse proxy de DSM qui n'acceptent que des noms de domaine ou des IP. Je les ai donc désactivés et j’ai activé les ports DSM par défaut pour chaque application. J'aurais pu les modifier, mais ça n'aurait rien apporté en terme de sécurité, d'autant qu'ils ne sont pas accessibles de l'extérieur. A noter qu’il n’est pas utile d’activer les ports https pour le proxy inversé comme nous le verrons par la suite. Puis j’ai rempli les sources et destinations du proxy inversé comme ceci : Côté source, exception faite de video, toutes les adresses en http sont uniquement sur le LAN. Elles utilisent le port standard (80). Les autres (https) sont dispos des deux côtés, LAN et WAN. Elles utilisent le port standard (443). Côté destination, les adresses sont exclusivement en http vers les IP et les ports correspondants aux applications du NAS et aux autres équipements du réseau local (NAS de sauvegarde, Raspberry). Il est en effet inutile et contreproductif de doubler les chiffrements (une fois à la source, une autre fois à la destination). Et pour que ça puisse fonctionner, j’ai dirigé dans le routeur le port 443 vers le NAS, et je l’ai ouvert dans le pare-feu du NAS. Et là j’ai rempli mon dernier objectif : plus besoin d’indiquer des ports puisque tout passe par les ports standards http (80) ou https (443). Maintenant, quand je rentre par exemple https:\\file.mondomaine côté LAN ou WAN, j’accède à File Station via l’adresse http:\\localhost:7000. De même, avec https:\\audio.mondomaine, j’accède à Audio Station via l’adresse http:\\localhost:8800. Mais un des gros avantages que j’ai trouvé au serveur DNS combiné au reverse proxy c’est la possibilité d'accéder à mes Rasp en https sans utiliser leurs certificats. En effet, si je rentre https:\\domo.s1.mondomaine, j’accède bien à Domoticz sur mon Raspberry 1, sans passer par le certificat Domoticz puisque le reverse proxy communique avec lui via une adresse en http. Le serveur DNS transfère l’adresse https non pas vers le Rasp mais vers le NAS comme on l’a vu plus haut et de là, c’est le reverse proxy qui met en relation le NAS avec le Rasp. C’est donc le certificat du NAS qui est sollicité. Et voilà, tout devrait maintenant fonctionner comme prévu. Hélas non. Il reste encore une dernière action à mener, c’est justement sur les certificats : ils ne fonctionnent pas correctement ! Certificats Comme beaucoup ici, je suis chez Let’s Encrypt via le NAS et on ne peut pas dire que la documentation Synology soit foisonnante sur la manière de gérer ces certificats. Il faut d'abord commencer par comprendre comment se comporte DSM avec les noms de domaine nouvellement créés. Lorsqu’une nouvelle source en https est créée dans le proxy inversé, DSM inscrit automatiquement le nom du domaine dans la rubrique "Pour" du certificat par défaut. On pourrait croire que ce nouveau domaine est pris en compte par le certificat, or il n’en n’est rien. Il s'agit seulement pour DSM d'associer un domaine à un certificat et en l'occurrence, c'est celui défini par défaut qui est choisi. Ce n'est en aucun cas une validation. Les seuls domaines couverts par le certificats restent le domaine principal et ceux inscrits dans le SAN (rubrique "Autre nom de l’objet"). Il n'y a aucun changement ni sur la validité, ni sur le périmètre de couverture du certificat. Il faut donc éditer le certificat existant pour y inclure les nouveaux domaines, et comme DSM6.0 et au-delà permet de faire cohabiter plusieurs certificats, il sera peut-être nécessaire d’en rajouter. En effet, alors que chaque certificat Let’s Encrypt peut gérer jusqu’à 100 SAN en natif, la rubrique "Autre nom de l’objet" du NAS n'accepte pas plus de 256 caractères ce qui peut être rapidement atteint selon le nombre de noms à saisir et leurs longueurs. D’où la nécessité de devoir créer plusieurs certificats. Cette limite est semble t'il contournable mais il faut pour cela passer en SSH pour modifier les paramétrages. Je ne le conseille pas. On peut aussi les créer en externe (PC, MAC, Rasp, autre) et les importer dans le NAS, mais on perd du même coup le renouvellement automatique et il faudra alors le faire manuellement tous les 3 mois ou moins. Pour ma part, j’ai utilisé ceux proposés par DSM. Et puisque c'est possible et pour que ce soit plus clair, j’ai créé 3 certificats : un par défaut que j'ai appelé "Principal" qui couvre les applis de base (CloudStation, VPN, mail serveur, ..), un autre que j'ai appelé "Applications" qui couvre les applis DS (audio, video, file, cam, get ...), et un autre que j'ai appelé "Domoticz" pour la domotique. A partir de l'onglet "Certificats" du module "Sécurité" du panneau de configuration (vue ci-dessus), on peut soit créer un certificat, soit éditer un certificat existant. Dans les deux cas, il faut cliquer sur le bouton "Ajouter" et dans la page qui apparait on choisit soit "Ajouter un certificat", soit "Remplacer un certificat" et on sélectionne celui à remplacer. Selon le choix, sur la page suivante on rempli ou on modifie la description du certificat puis on choisi "Procurez-vous un certificat auprès de Let’s Encrypt". Dans l’exemple ci-dessous, j’ai choisi de modifier mon certificat Domoticz. En cliquant sur suivant, on arrive à la page des paramétrages. C’est la même, que ce soit pour une création ou une modification (les champs ne sont pas renseignés avec les données de l’ancien certificat). Après avoir complété le nom de domaine (mondomaine) et l’adresse email valide, il faut renseigner la rubrique "Autre nom de l’objet" (le fameux SAN) avec tous les noms de domaine complets à couvrir, séparés par des " ; " . Exemple pour mon certificat Domoticz : domo.mondomaine;domo.s1.mondomaine;domo.s2.mondomaine Important : il faut que tous les noms de domaine soient valides. Pour cela, ils doivent impérativement avoir un enregistrement A ou CNAME dans le serveur DNS publique car Let's Encrypt vérifie l'existence de chaque nom. Si on indique dans le SAN un nom de domaine qui n’existe pas ou pas encore, le certificat ne sera pas créé. A ce sujet, le message renvoyé par DSM en cas d’échec est assez déroutant. Au lieu de signaler qu'il y a un ou plusieurs domaine(s) qui n'existe(nt) pas, le message indique qu’il y a un problème sur le port 80 qui n'est pas ouvert. Comprend qui peut. Une fois tous les certificats créés, il reste une ultime étape : leur attribution pour chaque nom de domaine et chaque application. Pour cela, dans la page des certificats, il suffit de cliquer sur le bouton "Configurer", de choisir pour chaque ligne quel certificat est applicable puis de valider. Cette opération terminée, tout fonctionne correctement, je n’ai plus de soucis avec mes connexions https. Conclusion La mise en oeuvre a été longue et laborieuse, avec beaucoup d'erreurs de ma part, d'incompréhensions parfois car le sujet est assez complexe, mais au final je suis très satisfait du résultat. Objectif atteint. Voilà. Je suis sûr qu’il y a beaucoup à redire sur ce que j’ai fait, qu’il y a certainement mieux à faire. Certes, je suis ouvert à toute proposition d’amélioration. Je souhaite en tout cas que ça puisse aider la communauté.

Probablement en ssh par lignes de commande. Je ne m'aventurerai pas à vous donner quoi que ce soit car je serais bien capable de vous faire effacer tout le disque et c'est pas ce que vous cherchez . Il y a des cadors de linux sur le forum qui pourront sûrement vous donner une solution. je pense @Gaetan Cambiernotamment. Il est averti par une notification.

Il semblerait qu'il faille effectivement des vis sur ce modèle de rack. Vous pouvez en récupérer dans un vieux PC au rebut ou bien dans les boutiques d'informatique.

Je pense que c'est un bon plan si tu veux remplacer ton 213J . Il se peut aussi qu'il y ait un 217+ dans les tuyaux et que Syno veuillent écouler rapidement les stocks avant sa mise sur le marché. Si c'est le cas, le nouveau modèle devrait être à un prix approchant l'ancien prix du 216+II. Ceci dit, à 268€ c'est une bonne affaire pour un NAS de cette qualité car je ne pense pas qu'un éventuel 217+ (si tant est qu'il y en ait un) soit beaucoup plus performant. Difficile en tout cas de trouver moins cher. Dommage, mon 214+ n'est pas encore assez vieux pour passer à la trappe et mon 710 est encore très bien pour les sauvegardes.

L'initialisation du disque va se faire une fois que les partitions seront crées et que le système sera installé (RAID1 avec le disque restant. Après cela, le disque sera marqué "initialisé" dans le gestionnaire de stockage. Il faudra alors choisir la création d'un nouveau volume et non l'augmentation de l'existant. Il devrait en principe créer un nouveau volume 1. C'est la création du volume qui devrait être longue car le NAS doit procèder à une vérification du disque.

@EinsteiniumC'est sûr que les Seagate ont parfois des valeurs qui font peur . Pour la 197, c'est bien ce que j'ai dit. C'est une valeur temporaire. Le disque a détecté un secteur instable et il va lancer des tests dessus pour vérifier son état. Si les tests confirment qu'il est mort, il va puiser dans sa réserve pour le substituer. Dans le cas contraire il va le déclarer bon et diminuer la valeur 197. Une valeur à 1 est à mon avis très loin d'être critique puisqu'elle n'est que temporaire et peut se retrouver à 0 lors du prochain test. Vraiment pas de quoi s'alarmer. @glyceria31, si WD vous remplace le disque sans poser de question, tant mieux pour vous. A moins que l'ID 3 soit vraiment hors des limites, je suis tout de même étonné qu'ils ne demandent pas des tests complémentaires. Les mise en veille et hibernations sont plus des tuent disques qu'autre chose. Il ne faut pas espérer faire des économies d'énergie vraiment quantifiables entre un fonctionnement 24/7 ou en veille. Tout ce que je peux vous dire c'est qu'un NAS 2 baies comme le votre consomme environ 20W en fonctionnement. Le coût total de l'électricité consommée est d'environ 30€ par an. En mode veille hibernation, c'est difficile à estimer mais disons que 20€/an serait un montant raisonnable. Il n'est donc pas vraiment judicieux de faire subir des contraintes électrodynamiques à des disques pour réaliser une économie de 10€ qui ne suffira pas à compenser la mort prématurée des disques. Sauf si vous ne vous en servez pas pendant des tranches horaires relativement longues (minimum 5à 8h) auquel cas vous pouvez planifier des arrêts et démarrages du NAS, il est préférable de ne pas activer la mise en veille et l'hibernation. Un NAS fonctionnant en 24/7 se porte beaucoup mieux qu'un autre sur lequel ces fonctions sont activées. Votre procédure de remplacement est correcte, à ceci près qu'il va falloir attendre quelques heures entre le moment ou le disque sera initialisé et celui où vous pourrez y stocker des données.

Bienvenue sur le forum. Même (et je dirais surtout) avec un NAS, la première chose à mettre en place c'est une sauvegarde régulière sérieuse. Et si vous avez fait un volume en RAID ou SHR, il est fortement conseillé (en clair : impératif) d'alimenter le NAS avec un onduleur compatible. Sans cela, vos données sont en danger.

J'ai mon 710 qui est en DSM5.1. Il est arrêté pour la semaine et reprend du service dimanche à h0. Je regarderai les valeurs id1 et id3 pour comparer. En attendant, les ID1 des seagate de mon 214+ sont à 144651616 et 7850912. Tu penses que j'ai des dizaines de milliers de raisons de m’inquiéter ? En réalité cette valeur n'est pas très significative puisque c'est une donnée constructeur. Extrait de Wikipedia : (Vendor specific raw value.) Stores data related to the rate of hardware read errors that occurred when reading data from a disk surface. The raw value has different structure for different vendors and is often not meaningful as a decimal number. En clair, ça ne donne qu'une information que seul le constructeur peut interpréter. Et juste pour le fun, les Seek_Error_Rate (ID7) sont à 4752270797 et 4751949445. Ici aussi les valeurs ne sont pas significatives car elles sont propres à Seagate. Bref, il n'y a pas de standard vraiment établi sur les valeurs SMART entre les différents constructeurs. Chacun est libre d'interpréter certaines données à sa guise et donc chacun y va de sa petite cuisine.