Mic13710

Merci @PiwiLAbruti pour cette information. J'utilisais les serveurs FDN et je ne savais pas qu'ils n'étaient plus accessibles en clair. Ca explique les lenteurs que j'observais parfois dans la résolution des URL. J'ai ajouté une note dans le tuto de @Fenrir sur le serveur DNS.

Le seul moyen c'est de passer par un terminal. Il faut que SSH soit autorisé dans DSM (port 22). Vous installez PuTTY si PC windows, vous le lancez et vous vous connectez à l'IP du NAS, login et mot de passe, ceux de votre compte administrateur. Vous lancez cette commande : sudo du -sh /volume1/*Vous donnez le mot de passe administrateur pour pouvoir lancer la commande. c'est long, mais vous aurez la liste de tous les dossiers contenus dans le volume 1 et leurs tailles.

Je suis d'accord que synology devraient être plus explicites sur les limitations entre NAS de générations différentes. Ils parlent bien de migrations de volume > 16To qui doivent se faire vers des modèles pouvant gérer des volumes > 16To. On peut bien entendu migrer un volume <= 16To vers tous les NAS ayant au moins le même nombre de disques que le NAS source mais la migration vers un NAS capable de gérer des volumes supérieurs n'est pas traitée. Or, un groupe construit sur un NAS en volume 16To max ne peut pas gérer des volumes plus gros même si on le migre vers un NAS plus performant. C'est ce qu'il vous arrive. Et si vous migrer d'un modèle de base en ext4 vers un modèle en btrfs, vous ne pourrez pas non plus bénéficier des applications qui nécessitent ce format pour pouvoir fonctionner. Et Synology ne dit rien à ce sujet dans sa kb sur la migration des disques. Enfin, la taille de la partition système qui a changée à partir de DSM7.1 n'est absolument pas abordée. Or, une migration ne permet pas d'étendre la taille de cette partition qui reste à 2.2To. Si ça peut fonctionner encore un temps, il n'est pas dit que les prochaines versions de DSM ne demandent pas plus d'espace, d'où l'importance de repartir de 0 avec réinstallation complète de DSM pour bénéficier d'une partition à 7.9 To sans avoir à devoir le faire plus tard. En règle générale, si les NAS et/ou les versions de DSM sont trop différents, la migration des disques est à éviter. Il est préférable de passer par Hyperbackup pour faire la sauvegarde/restauration des données.

Tous les disques ne se valent pas en terme de bruit. Les 7200 sont plus bruyants que des 5400 et les entreprises de seagate ne brillent pas par leur silence. Si en plus vos disques sont sollicités en permanence, il ne faut pas s'attendre à pouvoir dormir la tête tout près du NAS. Vous pouvez tenter de mettre un matelas anti-vibration entre le NAS et son support histoire de filtrer les vibrations. Si le support est un meuble en bois, les vibrations sont amplifiées par ce dernier. Vous pouvez par exemple acheter en GSB un tapis anti-vibration pour machine à laver que vous découpez aux dimensions du NAS. C'est très efficace. Ceci dit, le bruit n'altère pas le fonctionnement du NAS.

Groupe ou storage pool c'est la même chose. Si vous êtes français, pourquoi ne pas mettre DSM en français, ce serait plus simple pour comprendre de quoi on parle. Donc, un groupe c'est un ensemble de disques qui peut être constitué de 1 à plusieurs disques. Un groupe de plusieurs disques est obligatoirement en RAID. Sur un groupe, on peut monter un ou plusieurs volumes. Dans le cas présent on passe par deux groupes et deux volumes pour faire le transfert des données vers un groupe définitif constitué de 5 disques. Ce que je propose depuis le début et que je répète une dernière fois, c'est d'utiliser un nouveau disque pour créer un nouveau groupe sur lequel vous mettez un nouveau volume. Sur ce volume vous faites vos sauvegardes. Vous sortez vos anciens disques, mettez les 4 nouveaux restants que vous mettez dans un groupe (différent bien évidemment de celui sur lequel vous avez fait vos sauvegardes). Sur ce groupe vous montez un nouveau volume et sur ce volume vous restaurez vos sauvegardes. La suite je l'ai expliquée plus haut. Maintenant, si vous voulez suivre des vidéos qui expliquent des choses qui ne sont pas du tout adaptées à votre cas, faites. Ce sont vos NAS, ce sont vos données. Oui, vous pouvez monter vos vieux disques issus d'un 410J qui date de 2010 sur un 1522+ qui date de 2022. Vous l'avez fait. Seulement, il y a un énorme gouffre entre les deux NAS et en faisant cela vous importez les limitations du 410J dans le 1522+. C'est comme si vous preniez une carrosserie de Ferrari et que vous y montiez un moteur de clio. Ca va marcher, mais.... Vous ne pourrez pas faire des volumes de plus de 16To car c'est une limitation d'un groupe créé avec un 410J et donc vous devrez créer plusieurs volumes pour pouvoir utiliser la totalité du stockage. Pour vos 5 x 10.9To, cela ferait 3 volumes. Pensez-vous que ce soit ce que vous cherchez ? A vous maintenant de choisir entre la clio ou la ferrari.

Non car si vous faites ça, vous ne ferez qu'augmenter le groupe 2 alors que le but c'est de transférer les données du groupe 2 vers le groupe 1. Vous montez un nouveau groupe et un nouveau volume sur le disque 5 sur lequel vous faites vos sauvegardes hyperbackup. Vous conservez le disque avec vos sauvegardes dans le NAS. Vous sortez les 4 disques anciens (mais vous les conservez sous le coude dans le même ordre pour pouvoir vous en servir si besoin). Vous installez vos 4 nouveaux disques sur lesquels vous créez un groupe (qui devrait être le 1) et un volume. Vous restaurez vos sauvegardes du groupe 2 vers le groupe 1. Quand tout est restauré, vous supprimer le groupe 2 et vous associez le disque au groupe 1 pour augmenter sa capacité.

Pour la faire courte, le transfert des disques du 413 vers le 916 a transféré les limitations du groupe. Entre autres choses, la limite de volume à 16To. Le seul moyen de vous en sortir c'est de sauvegarder toutes vos données, de supprimer le groupe et le reconstruire. Je dirais même plus qu'il serait bon d'en profiter pour redémarrer de 0 avec formatage des disques pour que la partition système puisse être recréé à 7.9To au lieu des 2.2To des anciennes versions.

Pour ton adresse nas.ndd.ovh, c'est soit le fichier .htaccess qui fait la conversion vers https, soit c'est le cache de ton navigateur qui récupère la dernière adresse correspondante. Si tu as vidé ton cache et en l'absence de fichier de conversion, il est normal qu'une url qui ne précise pas le protocole prenne http par défaut. Si le ping est lancé à partir du WAN, c'est normal d'avoir l'IP publique comme résultat. Si le ping est lancé côté LAN et à condition bien entendu que ton serveur DNS local ainsi que le reverse proxy soient paramétrés correctement, c'est l'IP du NAS qui doit être retournée. Si ce n'est pas le cas, c'est que tu as un problème de résolution.

La double authentification c'est très bien, à condition que l'horloge du NAS soit synchronisée et d'avoir les bons outils pour la gérer sereinement (gestionnaire de mot de passe, applis OTP et clé sauvegardée). Si les conditions sont réunis, il ne faut pas hésiter à s'en servir. Mais en principe, sauf si l'accès n'est pas sécurisé, il ne faut pas l'appliquer sur des comptes utilisateurs sinon ça devient vite ingérable. Sur des comptes administrateurs directs (j'entends par là les comptes qui servent à l'administration du NAS), c'est un point sécuritaire qu'il ne faut pas négliger.

Peut-être qu'un petit bonjour serait une bonne entrée en matière pour un premier message sur ce forum. Bref. Je n'utilise pas Secure Sign In. Pour recevoir un email, il faut qu'une adresse mail soit paramétrée dans le service de notification et que vous ayez reçu un mail d'essai pour confirmer que les envois fonctionne. Si vous n'avez plus accès au NAS, le seul moyen c'est de faire un reset mode 1 pour réinitialiser le compte admin. https://kb.synology.com/fr-fr/DSM/tutorial/How_to_reset_my_Synology_NAS_7#t1

Que les disques ne soient pas dans la liste peut être la cause. Un NAS est assez capricieux et il y a des incompatibilités avec certains disques, hdd ou ssd. Ce n'est pas parce que les vôtres ont fonctionné un jour qu'ils fonctionneront toujours. Et vous ne pourrez jamais savoir s'ils sont compatibles car Synology ne mettra plus à jour la liste actuelle pour un NAS vieux de 10 ans. Regardez toutefois si vos disques sont acceptés sur des NAS plus récents. Ce n'est pas une garantie, mais ça pourrait donner une idée d'une possible compatibilité avec votre modèle si c'est le cas pour d'autres NAS de la marque. Si votre groupe est en RAID1 ou SHR avec protection des données, pas besoin de sauvegarde pour remplacer des disques. Du moins pour l'opération car une sauvegarde est indispensable en cas de problème, tant en fonctionnement que lors des travaux ponctuels sur le groupe. Bref, tout le temps. Il suffit de remplacer les disques l'un après l'autre, réparation du groupe qui reconstruit le RAID et le groupe augmente une fois le deuxième disque associé au groupe.

Les noms d'hôtes acceptés dans le reverse proxy ne sont que des noms pleins. Vous ne pouvez pas indiquer un service ou un port dans l'url. ndd/photo n'est pas accepté. ndd:port non plus. Le but du reverse proxy c'est de diriger un ndd vers un service. Pour photo station, c'est effectivement avec un ndd/photo qu'on peut joindre l'application. Il n'y a pas besoin de reverse proxy pour ça puisque l'url conduit directement au service. Je sais qu'il y a une astuce pour y parvenir avec un ndd dédié (photo.ndd) et le reverse proxy mais comme ce n'est plus d'actualité avec DSM7.x et Synology Photo, je n'ai plus le souvenir de la manière de procéder. Peut-être avec un .htaccess mais pas sûr.

Tu n'aurais pas une règle du parefeu qui bloque les us ?

Un groupe de stockage n'est pas dégradé avec un secteur endommagé. Le disque a certainement géré le problème en attribuant un secteur de réserve. Si le groupe est dégradé, le gestionnaire devrait vous proposer de le réparer. Si ça fonctionne avec les hdd, de toute évidence ce sont les ssd qui ont un problème. Est-ce qu'ils sont dans la liste des disques approuvés pour votre NAS (dont on ne connait pas le modèle) ? Si l'intérêt pour vous de monter des ssd est de gagner en vitesse, avec un réseau Gb vous pouvez oublier les gains en performance, ils sont quasi nuls. Ce sera le réseau qui coincera. En plus, indépendamment du prix, les ssd ont une fiabilité moindre par rapport aux hdd.

Il semblerait que ce soit cette url qui n'a pas fonctionné. C'est un JSON qui permet de récupérer les liens pour les api et dérouler la suite du script. Tu as ensuite accumulé les time out, le script n'a pas pu aller plus loin et s'est arrêté après plusieurs tentatives. Le site était peut-être indisponible au moment de ta demande. Attends demain pour voir si ça a évolué.