Mic13710

Ca c'est sûr, Extrêmement compliqué, surtout si c'est le disque qui comporte la table d'allocation qui est vérolé. Et même si ce n'est pas celui-ci, la table a pris un sérieux pet dans le casque et ne sera pas capable de retrouver ses petits. Il y a aussi la fragmentation des données qui peut se faire sur les différents disques, et selon le taux de remplissage, cette fragmentation peut être importante, ce qui augmente de facto les risques de pertes collatérales de données. D'où une possibilité extrêmement limitée de pouvoir récupérer des données exploitables. De plus, JBOD et RAID0 ne sont pas extensibles. Ils sont construits au départ et ne peuvent pas évoluer. Pour qui souhaite un peu sécuriser ses données, c'est le pire des mode de stockage. A réserver uniquement pour ceux qui recherche la vitesse plutôt que la sécurité, avec le RAID0 en tête en ce qui concerne la vélocité. Y'a intérêt a avoir des sauvegardes bien gérées (et le coeur bien accroché) pour utiliser ces types de stockages.

Vous pouvez formater vos disque sur un PC. Un formatage rapide suffit, le but étant de casser les partitions existantes. Il faudra probablement passer par le gestionnaire de stockage pour supprimer les partitions. J'avoue être un peu désorienté par votre organisation et la perte de place qui en découle. Avec vos 4 disques, vous avez fait 2 groupes de 6To chacun. Vous auriez pu construire un SHR qui vous aurait donné un stockage de 18To au lieu des 12To actuels, ou bien, si vous vouliez avoir une tolérance sur 2 disques, construire un SHR2 qui vous aurait donné le même stockage qu'actuellement avec 2 disques de tolérance, mais sur un seul groupe et un seul volume, ce qui est bien plus simple à gérer. Il est encore temps de passer au SHR puisque plutôt que de réparer le groupe 2 avec un nouveau disque, vous rajoutez au groupe 1 le disque qui remplacera celui en panne. Votre groupe passera alors à 12To. Vous transférez ensuite les dossiers partagés du groupe 2 vers le groupe 1 (la capacité sera suffisante puisque ce groupe aura la même capacité que vos deux groupes actuels). Une fois le transfert terminé, vous supprimez le groupe 2 et vous rajoutez son disque au groupe 1 ce qui vous donnera au final un stockage de 18To sur un seul groupe. A voir si cela vous convient.

Vous confondez deux choses, celle que vous pouvez faire à savoir sortir à chaud un disque en panne ou que vous voulez remplacer pour en mettre un nouveau, et dans ce cas le NAS fera la reconstruction, et celle que vous ne pouvez pas faire à savoir sortir à chaud un disque et le remettre dans son emplacement. Lorsque vous sortez un disque, vous le sortez physiquement et informatiquement du groupe. Il est naturellement éjecté. Le groupe passe en dégradé et même si vous voulez le réintroduire, le groupe étant en dégradé, il attend qu'on le répare. Il ne pourra pas récupérer le disque pour l'associer tel quel au groupe. Et c'est tout à fait logique car il s'est passé beaucoup de choses dans le groupe encore actif que le disque extrait n'a pas intégré. Et selon le temps d'extraction que le groupe ne connait pas, ce sera de grosses différences. Il faudra passer par une reconstruction. Alors oui, l'extraction à chaud existe mais ce n'est pas un blanc-seing pour faire tout et n'importe quoi. Cela permet simplement de pouvoir réparer ou agrandir un groupe sans avoir à arrêter le NAS. C'est surtout utile en production mais pour un particulier ce n'est pas de la plus haute importance car l'arrêt du NAS n'affecte pas en principe beaucoup de personne et ce n'est pas vital. Il faut vous dire qu'à chaque fois vous sortez un disque d'un groupe, bon ou mauvais, il n'est plus accepté par le groupe et qu'il faut à chaque fois passer par une reconstruction pour retrouver un groupe sain.

Normalement non. Le disque étant sorti de la grappe, il est considéré comme étant en panne. Il est possible que DSM arrive à réparer, mais je n'y crois pas. Le mieux serait de formater ce disque et de le réintroduire dans le NAS pour reconstruire le groupe. Peut-être qu(un redémarrage du NAS permettrait de considérer le disque comme initialisé sans avoir à le formater. C'est un truc à ne jamais faire à chaud sur un groupe en état normal puisque la conséquence c'est ce qui vous est arrivé. Il faut dans ce cas arrêter le NAS, sortir le disque, le remettre en place et redémarrer.

@PiwiLAbruti C'est un bon point. Je n'y avais pas pensé. Cependant, du fait de la technologie à découpage, la mesure à vide de l'alimentation ne garanti pas qu'elle soit capable de supporter la charge. Il faudrait faire des mesures avec le nas connecté, ce qui suppose d'ouvrir la bête et d'aller mesurer sur le PCB. Pas à la portée de tout le monde. La solution d'une autre alimentation similaire est sûrement plus abordable. Par exemple : https://www.amazon.fr/KFD-Adaptateur-Chargeur-DiskStation-Alimentation/dp/B09GP4QR2S

Il n'est pas interdit de monter un groupe sur le NAS et l'extension puisque c'est ce pour quoi cette dernière est conçue. Et le 718 est bien prévu pour ce type de montage. Néanmoins, les risques de perte de groupe sont beaucoup plus importants car si la liaison sata ou l'alimentation de l'extension sont interrompus, le groupe est cassé et il n'est pas garanti qu'il soit rétabli au redémarrage de l'unité du fait des possibilités de corruption des données. C'est à vous de considérer si vous acceptez ce risque, ou pas. Maintenant, il est possible que Synology aient prévu des sécurités pour pallier ces cas de figures, mais ça, seuls Synology sont capables de vous répondre. Le mieux serait de leur poser directement la question. Sinon, vous pouvez monter deux disques en basic ou SHR sans protection des données sur le 718 (comme ce que vous avez en ce moment), et un SHR de 5 disques sur l'extension.

Il semble bien que le contrôleur ait un souci. Si c'est le cas, il faudra envisager le remplacement du NAS. Ceci dit, vu l'état non initialisé de certains disques, il est clair que le groupe a subit des dégâts et ne peut être éventuellement remonté que par l'assistance. Ce qui risque d'être impossible avec un contrôleur défectueux. A moins que ce soit le logiciel de gestion du RAID (mdadm + lvm2) qui est compromis. Auquel cas, il serait peut-être nécessaire de réinstaller DSM. Je vous conseille toutefois d'attendre le retour du support avant de faire toute manip qui pourrait ruiner les possibilités de récupération. Je ne vous cacherai pas que ça sent un peu la pâtée.

Euh, là je ne suis pas d'accord. Le déplacement des dossiers partagés dans le même NAS et son extension se fait directement à partir du menu des dossiers partagés. Il suffit de changer le volume de destination et DSM se charge tout seul des transferts du volume source vers le volume destination sans perdre les liens avec les applications.

Vous voulez dire file station je suppose. Cette option de transfert via file station n'est pas applicable car de ce que j'ai compris il n'y a qu'un NAS et son extension. Et puis cette méthode a ses limites, puisqu'on perd les time code des fichiers ainsi que les paramètres de DSM et des applications. Hyperbackup est certes plus long à finaliser car il oblige à faire l'opération en deux étapes mais plus adapté car il permet de restituer à l'identique les données et paramétrages des applications.

J'ai cru comprendre que vous aviez un autre 718 ! Si ce n'est pas le cas, la méthode que j'ai proposée n'est pas valable et il faudra composer différemment en utilisant un ou plusieurs disques externes pour vider les deux volumes existants sur le 718. Le problème c'est que votre groupe 1 qui contient les applications est en basic. Il ne peut évoluer que vers du RAID classique. Je vous propose alors de migrer vos données et vos applications du disque 1 vers un disque externe en utilisant Hyperbackup. Vous pouvez pour cela utiliser un de vos 10To. Vous remplacez le disque 1 par un 10To. DSM va se réinstaller automatiquement à partir des autres disques. Vous construisez dessus un nouveau groupe en SHR sans protection des données sur lequel vous restaurez vos sauvegardes hyperbackup. Vous déplacez ensuite les dossiers partagés du disque 2 du NAS (qui devrait en toute logique être le volume 2) vers le disque 1. Vous remplacez le disque 2 par l'autre 10To et vous l'associez au disque 1 pour agrandir le groupe et former un SHR avec protection des données. Vous pourrez par la suite faire de même avec l'extension en migrant les volumes vers le volume du NAS et en remplaçant progressivement les disques par des 10To que vous associerez au groupe du NAS (bien que comme je l'ai écrit je ne sois pas favorable aux groupes répartis sur des unités physiques différentes). Pour la migration des données, il y a la kb Synology : https://kb.synology.com/fr-fr/DSM/tutorial/How_to_migrate_between_Synology_NAS_DSM_6_0_Hyper_Backup

Il faut leur envoyer un ticket directement à partir de DSM et ..... patienter.

Ca va être très compliqué de construire un SHR avec des disques de tailles différentes car l'ordre de construction a son importance. Vous ne pouvez pas rajouter à un SHR existant un disque plus petit que le plus petit disque avec lequel il a été construit. En clair, si vous créez votre SHR avec des disques de 8To, vous ne pourrez pas y rajouter des disques plus petits que 8To. Ce qui veut dire que si dans votre NAS actuel vous avez des disques de 2To, il faudra commencer votre SHR avec au moins un disque de 2To puis augmenter progressivement la taille des disques que vous rajoutez. Attention toutefois, pour que toutes les capacités puissent être exploitées, il faut au moins 2 disques de même capacité dans la grappe. Par exemple, si vous n'avez qu'un seul disque de 6To dans la grappe coincé entre des disques de 4To et de 8To, seuls 4To seront utilisés sur ce disque, les 2To restants n'étant pas exploitables. Il faudra attendre l'ajout d'un autre 6To pour que cette espace puisse être exploité. Il est sans doute possible de faire la mutation si vous avez un autre 718, mais l'opération risque d'être très complexe voire impossible compte tenu des différences de capacités de vos disques et du remplissage actuel de vos volumes. Je pense qu'il serait préférable de repartir sur des disques de plus grosse capacité pour pouvoir espérer migrer vos données, ce qui veut dire que vos disques actuels ne pourraient plus être utilisés, à moins de remonter un deuxième groupe dans l'extension avec ces derniers plutôt que d'étendre le groupe de l'unité principale, ce que je ne saurais trop vous conseiller. En effet, je ne suis pas très favorable à des groupes répartis sur des unités physiques différentes du fait des risques inhérents aux potentiels déconnexions qui peuvent conduire à une perte partielle ou totale des données. A vous de voir comment combiner ces informations pour effectuer au mieux votre migration.

A moins que vous ayez touché le NAS avant l'incident, je ne pense pas que ça puisse venir de poussières sur les connecteurs. Ceci dit, un bon nettoyage ne peut pas faire de tord. S'il y a de la poussière sur les connecteurs, il y en a aussi à l'intérieur. Normalement, c'est possible avec les versions récentes de DSM, mais votre NAS étant ancien, la gestion du RAID peut très bien ne pas avoir évolué de votre version DSM d'origine ce qui pourrait empêcher la manip. Repérez l'ordre de vos disques avant de les sortir pour pouvoir les remettre dans leurs emplacements d'origine au cas où.

Aucune des deux solutions ne vous permettra d'augmenter le débit. L'agrégation n'ira jamais plus vite que ce que peut supporter le port ethernet du NAS : 1Gb. Même remarque pour l'adaptateur puisque le débit sera celui que peut accepter le NAS : 1Gb.

Les seuls à pouvoir vous aider c'est Synology themselves. Le mieux serait de contacter l'assistance pour voir s'ils peuvent remonter votre SHR. Sinon, c'est perdu. Vos sauvegardes sont-elles à jour ? Et aussi, ce nas est-il secouru par un onduleur, et si oui, est-ce que les batteries sont OK pour assurer l'autonomie en cas de coupure ?

@PierU Tout à fait. Il est évident que le critère technologique est devenu un point important. Ma remarque vient de constatations passées et des nombreuses discussions sur ce forum, y compris avec les représentants des constructeurs, lorsque les disques dits NAS sont apparus sur le marché. A l'époque, cette histoire de SMR et CMR n'était pas du tout à l'ordre du jour. Et c'est vrai qu'il est aujourd'hui difficile de trouver des disques desktop en techno CMR, ce qui naturellement incite à se tourner vers les modèles estampillés NAS qui sont plus nombreux en CMR.

@Alain51 Tant mieux si votre problème a été résolu. Cependant, le but de ce forum est l'entraide et les réponses qui sont apportées doivent aussi aider ceux qui viendraient à lire ce fil. Là, on ne peut pas dire que la votre puisse aider qui que ce soit puisque vous ne dites pas comment vous avez résolu votre problème. Un peu de développement ne ferait pas de tord vous ne croyez pas ?

La principale différence entre les deux est le mode de stockage des données. Avec deux disques, les données sont en miroir, c'est à dire qu'elles sont identiques sur les deux disques (RAID1) alors qu'elles sont réparties sur les trois disques (RAID5). En cas de panne du NAS, il est bien plus simple de récupérer des données d'un RAID1 par rapport à un RAID5 puisqu'un seul disque suffit en RAID1 alors qu'il faut au minimum N-1 disques pour un RAID5. Plus il y a de disques, plus les risques de perte augmentent et la consommation aussi ce qui, par les temps qui courent, n'est pas négligeable sur le long terme. Côté protection électrique, un onduleur est indispensable sur un RAID5, il l'est moins sur un RAID1 car les risques d'erreurs d'écriture en cas de coupure sont moindre et plus facilement récupérables. Il est clair pour moi que le RAID1 est beaucoup plus solide que le RAID5. Il suffit de regarder le nombre d'intervenants arriver avec des problèmes sur des groupes en RAID5 alors qu'ils se font très rares si ce n'est inexistants sur des RAID1. Mais cela à un prix puisque la protection exige le double de capacité. Je ne suis pas vraiment d'accord avec ce que dit @bliz à propos de l'utilisation des disques. Certes, à capacités égales, il y plus de données par disques mais les disques travaillent tous et tout autant, si ce n'est plus, que des disques en RAID1 car il y a non seulement les données réparties, mais aussi la zone de parité qui se rajoute par rapport au RAID1. Mais ceci est infime en terme d'utilisation de stockage comparé aux données elles-mêmes. Et si on prend l'exemple de départ de 2x12To par rapport à 3x6To, le taux de remplissage des disques sera le même dans les deux cas.

Je sais @Jeff777 que je peux installer en manuel la dernière version de DSM, mais je ne suis pas chez moi en ce moment, et faire une mise à jour si je ne suis pas à proximité du NAS, j'évite. J'espère que d'ici mon retour, cette foutue version sera proposée dans mes deux NAS. Ce que je trouvais bizarre c'est que la version minimum de DSM pour faire tourner l'agent Synology Backup for Business n'est je présume qu'une version de développement qui n'existe pas dans les faits. Mais on s'éloigne du sujet.....

Ca ne fait pas de bruit dans la fibre les soirs de fiesta ?

Chez moi pas encore, ni sur le 718+, ni sur le 220+, ni sur d'autres NAS dont je m'occupe. Quand on l'aura, je suppose qu'on ira directement sur l'update 1. Hors sujet, quoique, j'ai voulu installer hier Synology Backup for Business à des fins de test et je voulais commencer pas tester des sauvegardes croisées de mes deux NAS. Impossible car pour cela il faut l'agent qui n'est pas disponible sous DSM 7.1-42661U4. J'ai donc chargé la version béta et là, j'ai un superbe message m'annonçant que cette version est trop ancienne et que ma version de DSM doit être au minimum 7.1-42952 pour pouvoir charger la nouvelle version de l'agent. Sauf que cette version de DSM n'a pas été diffusée ! Trop forts chez Synology !

Chez moi aussi la fibre est à 50m depuis deux ans et le lotissement de l'autre côté de la rue est raccordé depuis mi 2020. Excepté Free qui, il y a bien 18 mois m'ont dit que je serai bientôt raccordé, rien ne bouge. Sur le site de l'arcep, je suis passé à "en cours de déploiement" depuis le deuxième trimestre de 2021. En cours de déploiement...... j'hallucine. J'avais un temps caressé l'espoir d'un raccordement rapide. Que nenni. Ils ont autre chose à faire de plus productif que de tirer un câble au bout d'un chemin pour connecter 2 péquins qui ne sont pas chez l'agrume. Lorsque la France entière sera totalement fibrée et la fibre devenue obsolète, peut-être qu'alors ils viendront enfin chez moi pour me raccorder, dans le seul but de pouvoir démonter le dernier dslam encore en service. Tu vois @Jeff777, je garde espoir qu'un jour, dans très longtemps, ceux qui habiteront ma maison après ma mort auront la fibre. Ou pas.

Si tu invoques le port 5000 mais qu'il n'est pas ouvert dans le routeur et redirigé vers le NAS, il y a aucune chance qu'il atteigne DSM. De plus, tu dis à qui veut bien l'entendre, et j'approuve, qu'on ouvre pas un port http vers le NAS., surtout le 5000 .. Là, ce n'est pas la même chose ! Que ton toto.synlogy.me (qui en passant est très certainement en https) soit redirigé vers le 5000 du NAS via le reverse proxy, je suis d'accord. Mais il ne faut pas dire à @Alain51 qu'en invoquant le http://toto.synology.me:5000 de l'extérieur, on atteint le NAS, ce n'est pas possible avec seulement le 80 et le 443 ouverts. Par contre, je t'accorde volontiers qu'avec une URL Quickconnect du genre https://toto.quickconnect.to, c'est possible puisque ce truc est une vraie passoire !

T'es sûr ?

Je ne comprends pas bien cette comparaison. Un PC portable est secouru par une batterie, un NAS non. Ce sont donc deux fonctionnements bien différents. Relisez ce que je vous ai dit : un NAS a vraiment besoin d'un onduleur que lorsqu'il contient des groupes de disques en RAID. Un NAS monobaie n'est pas concerné puisqu'il est par essence dépourvu de RAID. Après, rien ne vous empêche d'équiper votre NAS d'un onduleur. C'est un choix qui vous appartient en fonction de votre utilisation, de votre budget et aussi de votre envie mais certainement pas pour protéger vos données.