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.