Mic13710

Non, que ce soit à la main ou toute autre méthode. Et avant de commencer à poster, il est d'usage sur ce forum de passer par ici : https://www.nas-forum.com/forum/forum/16-présentation/

Rien. Si vous avez une ip fixe, vous n'avez pas besoin du ddns. Et pour info, vous ne pouvez pas à la fois avoir un enregistrement A et un DynHost sur le même domaine. C'est soit l'un, soit l'autre.

Oui @firlin, mais je pense que le plus simple est de créer un certificat par NAS, soit par Docker si compatible, soit par SSH avec la méthode Github qui est quasi identique à celle par Docker et de faire un renouvellement automatique. https://github.com/acmesh-official/acme.sh/wiki/Synology-NAS-Guide J'ai mis en place la méthode de ce tuto sur le 713+ et celle de Github sur le 214+

Qu'on se comprenne bien. Votre NAS est monté en RAID SHR avec protection des données. Ce qui veut dire que vos disques sont donc en miroir, que vous avez ainsi une tolérance de panne d'un disque sans perte de données. Le NAS peut très bien fonctionner avec un seul disque quel qu'il soit car le système est installé sur tous les disques. Vous pouvez donc tout à fait démarrer votre NAS avec un seul des deux disques. Mais dans ce cas, votre groupe de disque sera déclaré comme étant dégradé puisqu'un des deux disques est manquant. Ce qu'il aurait fallu faire c'est enlever l'ancien disque 2 et le remplacer par le nouveau (ce que vous avez fait). Mais après ça, il fallait lancer la réparation du groupe à partir du bouton Action puis Réparer du menu Groupe pour reconstruire le SHR (ce que vous n'avez pas fait). Par contre, la suite me surprend un peu car vous n'auriez pas dû avoir la perte de DSM etc... Ce qui me fait dire que votre nouveau disque est probablement défectueux. Raison pour laquelle nous recommandons ici de systématiquement tester les disques avant de les mettre en production. Vous pouvez le faire au minimum sur un PC à l'aide du logiciel constructeur.

Oui, c'est possible. Une fois que vous aurez reparamétré votre connexion, la sauvegarde reprendra là où elle était avant son déplacement.

@Keyshan réessayez quickconnect. Il semblerait qu'il y ait eu une panne hier, ce qui pourrait expliquer votre problème de connexion.

@Einsteinium j'espère que c'est une simple coïncidence. C'est tout de même étonnant que ça se soit passé juste après la maj de DSM. Je confirme. Je n'ai pas trouvé le moyen de faire un copier/coller dans le terminal. Il a fallu tout rentrer à la mano. Mais bon, on ne le fait pas tous les jours non plus. Ceci dit, une saisie via ssh serait plus facile en effet.

Si vous l'aviez suivi, vous auriez ouvert les ports 500 et 4500 sur le routeur, qui, de ce que je comprends, n'est pas faisable pour le moment car vous n'avez pas accès au dit routeur. Le problème avec DSCloud et Drive client c'est que si la synchro n'est pas active, vos fichiers s'affichent quand même comme étant synchronisés.

C'est pourtant bien expliqué dans le tuto : ouvrir les ports 500, 1701 et 4500 dans le parefeu du NAS ET diriger le 500 et le 4500 dans le routeur vers l'IP du NAS, mais surtout pas le 1701. Je ne vois pas de rapport entre Quickconnect et le serveur VPN. Si votre NAS n'est plus joignable c'est soit que Quickconnect est momentanément hors service, soit que vous avez réellement fait une bêtise. Et comme je ne suis pas devin, je ne sais pas ce que vous avez fait et ne peux vous donner de solution. De ce que je comprends, vous faite les manips à distance. Dans ce cas, pas d'autre solution que d'attendre d'être sur place pour faire des investigations. Vous pouvez toujours lancer la connexion sur le 115. Au pire, il dira qu'il ne peut pas se connecter.

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.

Parce que tu laisses faire les maj automatiquement ? Perso, je préfère que le NAS me signale qu'il y a des maj disponibles. A moi ensuite de les appliquer, ou pas, et de le faire quand je le décide, et surtout quand je suis près du NAS pour pouvoir agir rapidement en cas de problème.

C'était pourtant ce qu'il fallait faire. Si vous ne dites pas au système ce que vous voulez faire du disque que vous avez mis, il ne fera rien. Je vous conseille dans un premier temps d'enlever le disque neuf et de le formater sur un PC (peu importe le format). Vous redémarrez le NAS avec le disque 1. S'il ne démarre pas normalement, vous lancez synology assistant. Vous devriez avoir un message du genre migration possible. Il vous faudra réinstaller DSM pour pouvoir accéder à vos données.

Je peux me tromper mais à mon avis, ce n'est pas possible. Vous ne pouvez pas avoir deux groupes 1 dans un même NAS. Et en plus, vous aurez des conflits avec les applications. Le mieux serait de poser la question au support.

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.