Mic13710

Et bien je viens de trouver. J'ai fait la mise à jour de DSM le 14/11. Comme c'est la seule opération du jour, j'en déduis que c'est ce qui a interféré dans le processus de maj journalière. Docker n'est pas si indépendant que ça de DSM et il faut aller vérifier après une mise à jour que tout fonctionne correctement sur Docker et en particulier que le fichier account.conf n'a pas été modifié.

Non, sur le 220 qui est le serveur. Pour la première sauvegarde, il est recommandé de la faire en local (cad, sur le même réseau) pour que ce soit plus rapide. Une fois le NAS installé en distant, on modifie simplement les paramètres de connexion pour reconnecter la sauvegarde sur le NAS source.

Si quickconnect ne fonctionne pas, il ne reste que le VPN. Il faut activer le serveur VPN du 220J. Il y a un tuto dans la partie tutoriel. Vous pouvez choisir soit L2TP/IPSec, soit OpenVPN. Dans les deux cas, il va falloir ouvrir des ports dans le routeur et les autoriser dans le parefeu. Une fois le serveur VPN activé et fonctionnel, il faut créer une connexion dans le 115j. Dans le menu Réseau, onglet Interface réseau, bouton Créer, choisir un profil VPN. L2TP est à mon sens plus adapté car vous n'avez pas à importer de fichier. Il suffit de renseigner les identifiants de connexion : adresse du serveur (votre adresse xxx.synlogy.me), le compte utilisateur, son mdp et la clé pré-partagée. Il ne vous reste plus qu'à paramétrer votre sauvegarde Hyperbackup. J'espère pour vous que vous avez déjà fait une sauvegarde en local car selon la connexion de bout en bout et la quantité de données à sauvegarder, ça risque d'être très très long.

@Keyshan Merci de ne pas citer inutilement la réponse qui vous a été faite. Ca charge le sujet sans aucun apport pour la compréhension. Je viens de supprimer vos citations précédentes. Ce forum comporte une section Présentations dans laquelle on aime bien que les nouveaux inscrits aillent se présenter avant de poster. Il n'est pas trop tard. Je ne pense pas que vous puissiez faire ce que vous souhaitez de manière traditionnelle car il y a fort à parier que la liaison free que vous ne possédez pas ne soit pas full stack, c'est à dire qu'elle n'a pas tous les ports disponibles. On peut utiliser un ndd synology.me et mettre en place le ddns, mais le problème c'est que le VPN se déconnecte au moment du changement d'IP et le client (ici le 115j) a parfois du mal à se reconnecter. Il faudrait pouvoir relancer la liaison à distance. Pas sûr que ça ne soit pas possible. Je vois mal Synology faire un paquet qui ne soit pas exploitable avec son système de connexion externe. Je pense qu'il suffit d'indiquer l'adresse Quickconnect et ça devrait fonctionner. A essayer. Si ça fonctionne, ce sera plus stable à mon avis que le VPN qui risque de tomber. Quickconnect est une bouse, mais parfois ça aide.

Merci pour la mise à jour. Moi c'est le fichier account.conf sur lequel j'ai eu un drôle de truc. En vérifiant acme.sh.log, je me suis rendu compte que le dernier lancement journalier datait du 14 novembre.... Je suis allé voir account.conf et oh surprise, il était pratiquement vide : plus de clés, juste la première ligne LOG_FILE="/acme.sh/acme.sh.log" et UPGRADE_HASH='xxxxxxxxxxxxxxxxxxxxxxxxxxxxx'. Je ne comprends pas ce qui a pu se passer car je n'ai pas souvenir d'avoir fait une quelconque modification depuis l'installation. Et je ne trouve rien dans les logs. Heureusement, j'ai des sauvegardes Hyperbackup et j'ai pu restaurer le fichier. Reste à voir demain si le cron s'est lancé comme prévu.

Rien de bien compliqué. Il suffit de spécifier dans Open VPN le port 443 comme port de connexion. Le fichier OpenVPN qui sera généré indiquera ce port pour le remote. Si Open VPN est actif, on change le port de 1194 à 443 dans la configuration et on fait de même dans le fichier xxxxxx.ovpn Je suis en UDP.

Effectivement, j'utilise le 443 pour mon NAS. Et contrairement à ce que tu dis, on se fatigue moins puisqu'il n'y a pas de port 1194 à ouvrir 😉. Je ne fais pas de transferts de fichiers pour pouvoir juger de la vitesse. Je ne l'utilise pratiquement que pour accéder à DSM, à mon routeur et à Unifi à distance. Je passe aussi par L2TP/IPsec. Mais le plus souvent j'utilise le 1194 lorsque je paramètre les NAS des autres pour que ce soit plus clair pour eux lorsqu'ils font leur maintenance. Honnêtement, je ne vois aucune différence de fonctionnement du VPN entre le 443 et le 1194.

Vous avez des sauvegardes ailleurs, c'est bien si elles sont régulièrement mises à jour. Dans votre cas, je ne vois aucune utilité d'avoir 2 groupes. Un seul groupe avec un seul volume suffit. Pour vos films, vous pouvez envisager l'achat d'un NAS d'occasion pour faire leur backup. Ce n'est pas une obligation, les films n'étant pas à proprement parlé des données vitales.

S'il y avait eu modification, la version ne serait pas la 25426 mais un numéro supérieur.

Sauvegarde de quoi vers quoi. Une règle pour les sauvegardes c'est de les faire sur un appareil dans un autre lieu. Des sauvegardes entre groupes ou volumes d'un même NAS ne sont pas vraiment des sauvegardes. Sauf à ne pas vouloir faire de la sécurisation des données (RAID ou SHR), avoir plusieurs groupes sur un NAS n'a pas vraiment d'intérêt pour un particulier.

Non. Pour fusionner les disques, il faudrait détruire le groupe 1 (donc perte des données plus quelques nombreuses autres pertes) pour l'intégrer au groupe 3. Je suppose que ce n'est pas ce que vous souhaitez. Vous ne pouvez pas non plus ajouter le disque du groupe 3 (après destruction du groupe et donc là aussi perte des données) avec le groupe 1 car il faut que le disque soit au moins de capacité équivalente au disque le plus petit avec lequel le groupe 1 a été constitué à l'origine. A moins que le groupe de départ ait était créé avec des 1To, ce ne sera pas possible.

Oui, vous pouvez rajouter un 2To pour réparer le deuxième groupe dégradé, mais votre stockage sera toujours de 1To. Les 1To restants ne seront pas utilisables. Vous ne pourrez les utiliser que si vous remplacez par la suite le 1To par un 2To.

Et moi qui vient de faire la maj ce week-end ! Indépendamment de l'inquiétude que cela peut susciter, aggravée par le manque de communication de la part de Synology, c'est étonnant qu'ils aient mis tant de temps pour la supprimer. En général, ça arrive dans la semaine qui suit la mise en ligne. Attendons de voir la suite qui sera donnée. Il se peut que ce soit un simple bug de leur côté.

@pompone vous y mettez un peu de mauvaise volonté. Votre groupe initial comportait 2 disques. Vous en avez retiré un pour une raison qui vous regarde. Dès lors, la seule option possible c'est de réparer ce qui a été cassé. Le message de votre capture était pourtant assez clair. Je le reproduis ci-dessous. Il ne dit rien d'autre que de remplacer le disque défaillant et de cliquer sur réparer pour lancer la réparation du groupe. Quand vous dites je cite : "ce n'est pas une incitation a aller plus loin", c'est bien évidemment tout le contraire puisqu'on vous dit fort justement de procéder rapidement à la réparation sinon vous risquez de perdre vos données si le disque restant tombe lui aussi en panne.

Il ne s'agit pas d'ajouter un disque mais de réparer le groupe. Cliquez sur Réparer et ça devrait le faire. Cette opération ne changera pas votre capacité de stockage. Elle réparera le groupe en restaurant la protection des données.

Je n'utilise CMS que pour de la supervision. J'effectue toutes les opérations directement sur les NAS.

Ca veut dire simplement que le disque est en attente d'affectation. Si vous allez dans groupe de stockage, vous sélectionnez le groupe 1 et à l'aide du bouton action, vous devriez pouvoir réparer le groupe en sélectionnant le disque 1.

Disque SMR, qui plus est non officiellement reconnu comme compatible par Synology, je pense que vous avez là les ingrédients d'un potentiel problème. Un peu de lecture : https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/Storage/PMR_SMR_hard_disk_drives Je ne saurais trop vous conseiller de retourner votre disque s'il est encore temps. Et pour les présentations, il n'est pas trop tard 😃

Bonjour Mikymike, soyez le bienvenu dans la communauté

Il est d'usage sur ce forum que les nouveaux arrivants passent par la section des présentations avant de poster. Est-ce que vous avez vérifié que votre nouveau disque st bien dans la liste des disques compatibles, et si oui, est-ce que vous avez choisi un disque dont la technologie et les caractéristiques sont proches de ceux qui sont en place ? https://www.synology.com/fr-fr/compatibility?search_by=products&model=DS211j&category=hdds_no_ssd_trim&p=1

@Jeff777 Tu as tout à fait raison, d'autant que nous avons tout les deux la même installation. Cependant, je ne recommanderais pas @MilesTEG1 cette solution qui s'adresse plutôt à un public averti et dont l'interface est tout de même moins "user friendly" que celle de SRM. J'ai par contre un sérieux doute sur le VLAN. Il me semblait que les routeurs Synology ne le permettaient pas. D'après @oracle7 ce serait possible si je comprends bien. A confirmer.

Aucune importance, l'essentiel étant de simplement détruire les partitions existantes

Non, vrai. Je n'ai jamais eu de virus sur mes PC.

Le disque 3 est marqué comme désactivé. Il faut le sortir du NAS et le formater sur un PC pour casser les partitions existantes. Vous le remontez et normalement vous devriez pouvoir réparer votre groupe 1. Attention : comme vous avez 2 groupes dégradés, il faudra bien associer le disque sur le groupe 1.

Je n'avais pas tout lu. Donc, effectivement, vous avez tenté d'ajouter le disque de 3To au disque de 1To. En fait, ça avait fonctionné mais c'est votre méconnaissance du RAID qui vous a fait croire le contraire. En rajoutant un disque dans un SHR sans protection des données (ce que vous aviez à l'origine) ça n'augmente pas la capacité du groupe. Ca le transforme en un groupe SHR avec protection des données. Vous aviez donc au final le même stockage de 1To avec un disque de 1To et un autre de 3To dont seulement 1To était utilisé, les 2To restants n'étaient pas exploitables puisque impossible à mettre en miroir. Il n'y avait rien d'anormal à cette situation. Il aurait fallu ensuite remplacer le 1To par un 3To pour pouvoir exploiter la totalité du stockage, soit 3To. Maintenant que votre groupe est passé en SHR avec protection des données, la seule solution officielle est de tout reconstruire. A moins que vous rajoutiez un autre disque de 1To ou plus pour reconstruire le groupe. C'est au contraire ce que vous devez faire le plus vite possible (reconstruire votre SHR avec protection des données), car comme vous le dites, vous n'avez plus de filet. Si le seul disque sain tombe en panne, vous perdrez toutes vos données.