Mic13710

Comment sont montés vos disques : RAID ou SHR ou deux groupes séparés ? Quel est l'état du voyant marche ? Est-ce que le terminal SSH est activé dans DSM ?

Certainement pas. Le NAS passe en mode sécurité mais ne s'éteint pas. Il continue de fonctionner tant que l'UPS ne s'est pas éteint. Ce n'est seulement que si vous avez activé l'extinction de l'UPS par le NAS que l'UPS va s'éteindre et pas voie de conséquence le NAS aussi. Et cette fonctionnalité n'est absolument pas garantie car certains UPS ne traitent pas les ordres de commande d'extinction externes. Drôle de question. Comment voulez vous que votre unité d'extension fonctionne lors d'une coupure si vous ne la connectez pas à l'onduleur ? Si le NAS est connecté à l'usb de l'UPS et que la fonction UPS est activée sur le NAS, la mise en sécurité de l'extension sera assurée par le NAS.

Par défaut, Hyperbackup sauvegarde aussi le fichier système. Sauf si ça a été décoché, vous ne devriez pas avoir besoin du .dss. Tout dépend de ce que vous avez sauvegardé. Si vous avez sauvegardé les paramètres des paquets couverts par hyperbackup, normalement, le paquets et leurs paramètres sont réinstallés automatiquement lors de la restauration. Mais attention, tout n'est pas systématiquement restauré et il va falloir probablement faire quelques ajustements. Les paquets tiers ne sont pas sauvegardés, les scripts utilisateur non plus, et il faudra les réinstaller et les paramétrer. Il faudra aussi renouveler votre ou vos certificats si vous en avez. Je vous conseille de faire des captures d'écrans de vos paramètres, au moins les plus importants, cela facilitera vos réglages. Autre point important : DSM. Le fichier d'installation n'existe plus sur le site officiel de Synology. A moins que vous l'ayez sauvegardé quelque part autre que le NAS, il faudra le récupérer sur un site d'archivage. Vous trouverez un lien dans la section Firmware du forum Synology.

Vous avez raison, en cas de plantage du NAS principal, le reverse proxy est hs. Raison pour laquelle je maintiens les certificats, le serveur DNS ainsi qu'un reverse proxy sur le NAS 2. Dans ce cas, j'ai deux solutions : soit modifier les règles de redirections des ports vers le NAS 2 (j'ai un accès cloud à mon routeur), soit je passe par le VPN du routeur (wireguard) pour me connecter au réseau et accéder là aussi aux paramètres du routeur et/ou aux autres équipements de manière sécurisée. Vous pouvez tout à fait maintenir un accès vers le NAS 2 avec un port dédié, mais rien n'empêche d'utiliser le reverse proxy du NAS 1 pour atteindre le NAS 2. Ainsi, vous n'avez qu'un port (le 443) utilisé dans la vie de tous les jours, tout en maintenant un accès possible par un autre port en cas de panne du reverse proxy. Perso, je préfère l'utilisation d'un port unique (le moins de ports ouverts c'est mieux) et le VPN en cas de panne du NAS principal.

Oui, vous suivez les indications : vous cliquez sur les 3 points en haut à droite du groupe 1. De toute manière, vous n'avez pas d'autre option et si ça ne fonctionne pas vous avez encore votre sauvegarde et le deuxième disque.

Mouais. Ca peut aussi se faire avec le reverse proxy. Et si je comprends bien, dans ce cas vous avez utilisé des ports différents pour joindre chaque NAS. Un peu compliqué non ? Avec le reverse proxy, vous n'utilisez que le port 443 par défaut et selon le ndd, c'est lui qui dispatche vers les applications quelles que soient leurs localisations sur le réseau. Par exemple : si l'application qui correspond à toto.ndd est sur le NAS 2 (ou tout autre équipement, un RPI par exemple) dont l'IP est 192.168.1.25, port http 8080, sur le reverse proxy du NAS 1 vous mettez : origine : https://toto.ndd destination : 192.168.1.25 port 8080. Et dans ce cas, le seul certificat qui est invoqué est celui du NAS 1. Le certificat ne sert à rien sur le NAS 2.

Le risque est assez contenu puisque vous gardez un des disques au chaud. Si la procédure que je vous propose ne fonctionne pas, vous pourrez toujours soit récupérer les données directement sur le disque restant (ou même sur celui qui n'a pas fonctionné dans la procédure), soit vous avez votre sauvegarde qui contient obligatoirement votre db si vous avez sauvegardé le dossier plex. Donc, même si ça ne se déroule pas bien, vous avez encore deux parachutes (voire 3 si le disque d'essai n'a pas été endommagé) pour vous rattraper. Et perso, je miserai plus sur la sauvegarde hyperbackup.

Une petite question : quel intérêt d'avoir un certificat sur chaque NAS ? Je demande ça parce qu'en général on utilise le reverse proxy d'un des NAS pour atteindre les autres NAS et dans ce cas, seul le certificat du NAS avec le reverse proxy est sollicité, à condition bien entendu que la destination du reverse proxy se fasse en http. Un certificat sur un NAS n'a d'utilité que s'il gère un nom de domaine. Si vous joignez le NAS uniquement avec son IP en local, alors le certificat ne sert ... à rien.

Ce n'était pas assez clair ? Là non plus ce n'était pas assez clair ?

Pour être plus précis, ce n'est pas possible via DSM car la méthode d'obtention du certificat est en http qui nécessite l'ouverture du port 443 vers le NAS. Par la méthode DNS, pas besoin d'ouverture de port et chaque NAS peut obtenir son propre certificat, peu importe le réseau sur lequel il se trouve. Selon que votre NAS est compatible docker (container manager) ou pas, il existe deux manières d'opérer qui toutes deux utilisent le script acme.sh et des clés API : sans docker : https://github.com/acmesh-official/acme.sh/wiki/Synology-NAS-Guide avec docker : https://www.nas-forum.com/forum/topic/68046-tuto-certificat-lets-encrypt-avec-acmesh-api-ovh-en-docker-dsm67-update-070922/ Si vous n'avez pas docker, le plus simple pour la création des clés API c'est de suivre le tuto pour docker. Vous verrez au final que les deux manières fonctionnent sensiblement pareil. Un conseil : dans les deux cas il faut avoir un identifiant administrateur pour effectuer la demande et créer/actualiser le certificat. Le mieux c'est de créer un identifiant administrateur spécifique que vous n'utiliserez que pour cela. Vous lui donnez un mdp long comme le bras, aucun droit sur les applications et les dossiers (sauf le dossier docker si vous utilisez cette méthode) et surtout pas de double authentification qui complique grandement le processus. A noter : vous ne créez qu'un seul jeu de clés API chez OVH que vous utilisez ensuite sur tous vos NAS.

Ah bon ? Je fais ça sans problème sur plusieurs NAS. Avez-vous au moins essayé ?

Oui. Il se peut que DSM détecte que des données existent sur le disque sans toutefois monter le volume. Il faudra me dire quels sont les messages envoyés par DSM. En principe, il est préférable de garder l'emplacement de chaque disque. Toutefois, DSM autorise le mélange des disques. Je n'ai jamais tenté de le faire donc je ne peux pas confirmer. Le risque en débranchant à la sauvage, c'est la corruption des données si les disques sont en activité. Mais comme vos disques ne travaillent pas, il n'y a pas grand risque à le faire. Cependant le risque 0 n'existant pas, là non plus je ne confirme pas. Vous n'avez pas trop le choix de toute façon, c'est ça ou vous n'avancerez pas. Si la sauvegarde est faite via hyperbackup, la restauration sera beaucoup plus simple. Je n'utilise pas plex et je ne sais pas où se trouve la base de donnée que vous voulez récupérer. Si elle est dans le dossier Plex et que vous l'avez sauvegardé, alors il fait partie de votre sauvegarde.

Si votre choix est de rajouter une extension, alors, oui, vous pouvez créer un nouveau groupe en SHR.

Non seulement il va y avoir un conflit entre le volume 1 sur le disque 4To et le volume 1 sur le 2To ce qui risque de conduire à un rejet d'un des volumes, mais aussi un souci au niveau de la partition système qui ne sera pas la même entre les deux disques. Si DSM 7.1 ou plus, le 4To aura une partition à 7.9Go alors que le 2To a certainement une partition en 2.2Go. Ce que vous pouvez tenter c'est de monter le 4To, installer DSM mais sans un groupe dessus. S'il y en a un, vous le supprimez. Vous montez un disque de 2To (celui qui était à l'emplacement vide précédemment) et vous redémarrez le NAS. Vous regardez sur le gestionnaire de stockage si DSM retrouve le groupe et le volume du 2To et vous regardez dans file station si vos dossiers sont présents. Si c'est le cas, alors vous créez un nouveau groupe et volume sur le 4To (ils prendront le numéro 2 mais ça n'a pas d'importance pour la suite) et à partir de DSM, vous modifiez pour chaque dossier partagé le numéro du volume de destination du 1 vers le 2. DSM va automatiquement transférer les dossiers et leur contenu du 2To vers le 4To. Ne faites pas tout d'un coup mais attendez que le dossier soit complètement transféré avant de passer au suivant. Si tout se déroule normalement, vous aurez toutes vos données dispos sur le 4To ainsi que leurs métadonnées. Si le groupe et volume du 2To ne sont pas reconnus, activez le SSH dans DSM (panneau de configuration, terminal), si parefeu activé, autorisez le port 22, lancez la commande donnée plus haut pour avoir une vue correcte des disques dans le NAS et postez le résultat. Vos sauvegardes sont-elles faites via un vrai logiciel de sauvegarde (hyperbackup ou autre) et dans ce cas les métadonnées sont conservées et restituées lors de la restauration ou est-ce une simple copie des dossiers ? S'il s'agit de récupérer la base de données, vous pouvez passer par la procédure de récupération des données (le lien que je vous ai donné). En tout cas, ne faite vos manipulations que sur un seul des disques et gardez l'autre au chaud pour conserver intactes vos données.

Est-ce que le port 22 (ssh) ou 21 (telnet) est ouvert ? Si oui, il faudrait lancer la commande : cat /proc/mdstatPoster le résultat. Est-ce que vous avez conservé le disque qui a été retiré ? Est-ce que vous avez tenté de démarrer sur un seul disque de l'ancien groupe (sans le 4To) ? Si vous pensez que le problème vient de DSM, vous pouvez tenter un reset mode 2 pour lancer sa réinstallation : https://kb.synology.com/fr-fr/DSM/tutorial/How_to_reset_my_Synology_NAS_7 Ne JAMAIS brancher un disque sur un NAS (ou un PC ou autre) en marche s'il n'est pas explicitement construit avec cette fonction. Votre 218play ne l'a pas et le risque serait de griller le disque et peut être créer quelques dommages au contrôleur. En ultime recourt il existe un kb synology pour la récupération des données à l'aide d'une distribution linux sur un PC : https://kb.synology.com/fr-fr/DSM/tutorial/How_to_fix_hard_drive_failure_and_retrieve_the_data_from_your_hard_drives Mais avant de faire tout cela, postez le résultat de la commande ci-dessus.

Je suppose que c'est là : https://archive.synology.com/download/Package/MediaServer Reste à trouver la version pour le 710+ parce que c'est bien un x86 mais rien ne dit si la dernière version est compatible avec DSM5.2

Je ne comprends pas comment il est possible d'avoir des extensions différentes si vous êtes connectés sur vos dossiers soit par des lecteurs réseaux soit par des applications telles que drive. Avez-vous essayé de redémarrer le NAS ?

Le NAS n'est qu'un simple espace de stockage. Les extensions ne se modifient pas sans une cause externe, ransomware, script sur un PC. Ce n'est pas DSM le fautif mais probablement un virus, ransomware ou script qui proviennent d'un PC connecté au NAS. Est-ce que tous les fichiers de tous les utilisateurs sont affectés ou seulement ceux de votre compte utilisateur et/ou des dossiers partagés auxquels vous avez accès ? Est-ce que ce sont les extensions qui ont été modifiées (toto.xlsx vers toto.k9sx) ou bien est-ce que .k9sx a été rajouté comme extension au nom du fichier (toto.xlsx.k9sx) ?

Une nouvelle version 9.3.0-12143 vient d'être mise en ligne et sauf erreur, il n'y a toujours pas la possibilité de faire des suppressions groupées.

Le groupe c'est l'ensemble des disques constituant un RAID (ou SHR). Le volume c'est une zone de stockage créée sur un groupe. Le volume peut être en ext4 ou btrfs et peut occuper tout ou partie d'un groupe. Pour faire un parallèle avec un simple disque sur un PC, le groupe c'est le disque physique, le volume c'est le ou les lecteurs créés sur des partitions de ce disque. Comme le volume sur un NAS, il n'y a majoritairement qu'une seule partition, la C::, mais rien n'interdit de créer plus de partitions sur le disque physique pour n'utiliser qu'une partie pour le lecteur C: et rajouter d'autres disques D:, E: etc..selon les besoins. Ces partitions sont comparables du point de vue physique aux volumes de votre NAS. La comparaison s'arrête là car leur fonctionnement est radicalement différent. Pour le type de RAID, je vous conseille de choisir le SHR qui est plus flexible que le RAID classique.

Bonjour @jeremyc , soyez le bienvenu sur le forum.

C'est écrire des 0 sur chaque secteur d'un disque. Ceci permet de les tester. Cependant, le test se fait généralement à partir du NAS et comme toutes vos baies sont occupées, il faudrait le réaliser après avoir introduit le nouveau disque dans le NAS ce qui augmente considérablement le temps total jusqu'à la réparation. Il vous faudrait une distribution linux pour pouvoir lancer le test sur un PC. Le plus simple pour vous sera alors de tester chaque disque à l'aide du logiciel constructeur. Faire les tests approfondis. Si vous faites une extension du groupe du NAS vers le DX, seulement 6To sera utilisé sur chaque disque. Si vous voulez utiliser la totalité de la capacité des disques, il faudra créer un nouveau groupe sur le DX.

Le problème est maintenant résolu. N'hésitez pas à ouvrir un nouveau message en cas de problème. Ceci est une réponse automatique.

Absolument pas. Cette opération se fait même avec le nas en service. Ce qui ne veut pas dire qu'il n'y ait aucun risque. Le risque 0 n'existe pas et il se peut que l'opération ne se déroule pas correctement. Mais généralement, il s'agit d'un disque réputé neuf qui ne fonctionne pas. Raison pour laquelle il faut toujours avoir une sauvegarde, au moins des données les plus importantes (c'est valable tout le temps....). Et donc pour commencer, je vous conseille de tester vos nouveaux disques, a minima avec le logiciel du constructeur. Sinon, une écriture de 0 est un bon test (c'est celui que j'utilise). Certains plus frileux passent par badblocks. Vous trouverez un tuto badblocks dans la section des tutoriels. Une fois les disques testés et validés, vous mettez à jour vos sauvegardes. Vous remplacez un des disques par un plus gros. Cette opération peut se faire à chaud (NAS en fonctionnement), mais certains (les mêmes frileux) préfèrent arrêter le NAS avant d'extraire le disque. C'est vous qui voyez. Le NAS va bipper (groupe dégradé). C'est normal puisqu'il manque un disque dans le groupe. Vous reconstruisez le RAID à partir du gestionnaire de stockage. Une fois la reconstruction terminée (de très nombreuses heures), vous faite la même chose avec le suivant et ainsi de suite jusqu'au dernier. Le remplacement des 4 disques va occuper le NAS pendant quelques jours selon la taille des disques. Une fois les 4 disques remplacés, vous étendez le groupe et le volume à partir du gestionnaire de stockage pour utiliser la totalité du stockage disponible. En remplaçant vos 4 disques par des 12To, vous doublez votre stockage actuel pour avoir un volume de 36To théorique.

RAID 5 ou SHR ? Si SHR, vous pouvez simplement augmenter votre stockage en remplaçant 2 disques par de plus gros. En RAID 5 pur, il faudrait changer les 4 disques. L'option de l'extension est possible, mais le prix de l'unité est assez dissuasif (pratiquement le prix d'un NAS). On peut tout à fait n'y monter qu'un seul disque. Je pense cependant qu'il est préférable de changer les disques (2 ou 4 selon le montage du groupe) plutôt que d'investir dans une unité d'extension.