Mic13710

Aucune idée car trop de facteurs rentrent en jeu. Attendez vous à quelques (nombreuses) heures.

Tout est ici https://www.synology.com/en-us/knowledgebase/DSM/tutorial/Storage/Why_does_my_Synology_NAS_have_a_single_volume_size_limitation

3 possibilités : bloc alim HS : le remplacer disque(s) HS : sortir un des disques et voir si le NAS démarre, si c'est non, remettre le premier disque, enlever l'autre et refaire l'essai carte mère HS : la remplacer couterait le prix du NAS. Mieux vaut partir sur du neuf avec migration des disques

Encore une fois vous faites une confusion entre système de fichier et données. Si vos disques sont en BTRFS et que vous voulez les migrer sur un NAS qui ne le prend pas en charge, il est évident que ça ne pourra pas fonctionner. C'est ce que signifie le message, ni plus, ni moins. Le système de fichier c'est la manière de stocker et de gérer les données sur le volume. Les données elles, sont identiques quel que soit le système de fichier sur lequel elles sont stockées. Si vous partez avec un NAS neuf et des disques neufs, vous y installez simplement DSM et vos paquets. Vous pouvez ensuite utiliser la méthode via Hyperbackup du tuto sur la migration pour migrer vos données sur le nouveau NAS.

@Pr0TiPx8 Sachant que le serveur VPN (votre NAS) est derrière votre box, encore heureux que l'adresse publique du VPN soit celle de la box ! Vous espériez voir quelle adresse ? Si vous n'indiquez pas le port, la connexion se fera sur le serveur Web s'il est activé. Avez-vous essayé 10.8.0.1:5000 ? ou IPprivéeduNAS192.168.x.x:5000 ?

Non seulement vous pouvez le garder, mais c'est une excellente solution de sauvegarde. BTRFS, EXT4 c'est le format du disque. Les deux formats ne sont pas compatibles mais ça ne change rien aux données. Plutôt par le réseau (on ne connecte pas des nas entre eux) Oui, mais la vitesse dépendra de la vitesse de celle de vos deux liaisons internet. Connexion via le VPN plutôt que Quickconnect

C'est de très loin la meilleure solution. La migration de disques d'un NAS à un autre migre aussi les limitations du NAS sur lequel le groupe a été créé, entre autre la limite maximum de la taille d'un volume (16To pour le 411j, 108To pour le 918+). Vous resteriez en RAID5 et en EXT4 alors que le 918+ est BTRFS et qu'il serait plus judicieux de passer au SHR au lieu du RAID5.

C'est dans la description du produit : WD Red.

C'était même du SECAM L, seulement disponible en France, Luxembourg et Monaco pour rester bien franco-français. Les autres pays qui l'avaient adopté avait une version différente (B/G et D/K). C'est pratiquement abandonné (de même que le PAL) depuis le passage généralisé au DVB-T. Le codage des caméras n'a strictement aucun rapport avec ceux de la télévision. Si le soft sait lire du NTSC (ce que sait faire tout système de vidéo surveillance), il ne faut pas se poser des questions là où il n'y en a pas.

@PiwiLAbruti Et honnêtement, migrer d'un 414J à un 1618+, mieux vaut faire une install propre, d'autant qu'on garderait la limitation de la taille maxi du volume du 414J et on perdrait le BTRFS.

Vous n'avez visiblement rien compris à ce que je vous ai proposé. Je n'ai jamais dit d'utiliser vos sauvegardes mais seulement que vous pouviez faire la manip sans crainte puisque vous aviez des sauvegardes (en chine au pérou ou en alaska ou chez la tante irma, ça n'a pas d'importance) Je vous ai proposé une solution qui évite de faire un volume 3 puisque vous copiez directement les données restantes sur le volume 1 définitif, ce qui est de fait moins chronophage. Mais si vous voulez faire compliqué.... 😊 Pour le transfert de NAS à NAS le plus simple c'est de monter des dossiers distants à partir de File Station.

On aime bien sur ce forum que les nouveaux arrivants passent par la section présentation avant de poster 😉 Sauf erreur, les seules caméras Dericam supportées ne sont que 3 et ce sont des modèles assez anciens. https://www.synology.com/fr-fr/compatibility/camera?brand=Dericam La P2 n'est pas dans la liste, il n'est donc pas étonnant qu'elle ne soit pas totalement prise en charge par SS. Il faudrait aller bidouiller dans les paramétrages pour tenter de la faire fonctionner mais ça dépasse mes compétences. Si vous voulez avoir un jour la chance de voir votre caméra prise en charge, il faut le suggérer à Synology https://www.synology.com/fr-fr/form/suggest_device#camera

Normalement avec un nombre de version à 0, il n'y a pas d'historique et donc pas de dossier volumineux pour les versions. Mais à ce moment là, vous n'avez pas de possibilité de retrouver un fichier supprimé. Et je rejoins tout à fait la remarque de firlin : Cloud Station avec ou sans version n'est pas et n'a jamais été une solution de sauvegarde.

Ce n'est pas un scoop. Pour pouvoir restaurer des données, il faut bien qu'elles soient disponibles quelque part avec leur historique. Si vous ne voulez pas de versionning, il faut passer le nombre de versions à 0 et effacer les historiques.

Je ne vois pas l'intérêt de construire le volume 3 avec un disque de 4To. Une fois les données copiées sur le volume 2 (disque qui sera monté dans la dernière baie), autant supprimer le volume 1 et monter directement le 4To dans la baie 1 pour y créer un nouveau volume 1. Vous y installez votre dossier de conf préalablement sauvegardé du 414 ainsi que vos paquets afin de retrouver tous vos comptes et la majorité des réglages que vous aviez sur l'ancien NAS. Vous y recopiez les données restantes du 414. Pour la suite, vous formatez les autres 4To avant de les monter dans le NAS, vous les installez tous à la fois et vous faites une extension du volume 1 en une seule fois. Mieux vaut lancer une seule extension que plusieurs car chaque extension fait beaucoup travailler les disques. Recopie des données du volume 2 sur le volume 1, formatage du 8To et extension du volume 1 avec ce disque. A noter que ceci n'est faisable que si vos sauvegardes externes sont à jour. Il faut en effet être conscient qu'une telle opération comporte de forts risques de pertes de données à chaque étape et que le seul parachute, ce sont vos sauvegardes. Il ne faut pas non plus perdre de vue que vos disques de 4To ont des heures de vol et qu'à ce titre, ils peuvent très bien ne pas aimer le traitement.

C'est votre choix au départ (votre premier post). Le 443 est le port HTTPS par défaut, cad que sans spécifier de port, vos requêtes sont dirigées vers ce port. Le routeur dirige ensuite les requêtes sur ce port vers le 443 du NAS. Le reverse proxy analyse la requête et la dirige vers le port affecté au service. C'est vous qui voyez. oui Les SAN ce sont ce qu'on appelle les "Autres noms" du certificat. Il faut faire effectivement la différence entre un certificat nominatif et un certificat Wildcard. Perso, contrairement à Zeus, je n'aime pas utiliser les wildcard. Chacun fait selon ses besoins. Ceci étant dit, rien n'empêche d'avoir un wildcard côté registar et un certificat SAN côté NAS. Oui. En fait j'ai employé à tord le mot adresse. J'aurais dû plutôt dire domaine. Pour le certificat Synology, je l'ai gardé car pour certaines applications, le changement de certificat tous les 3 mois n'est pas viable. Serveur VPN par exemple.

Avant de poster, il faudrait lire ce que j'ai écrit. Je ne vous ai jamais dit de fermer le 443. Vous pouvez le restreindre géographiquement (ce que vous avez fait) mais pas le fermer sinon comment espérez vous atteindre le NAS ? Il faudrait aussi dans le parefeu remplir les 2 règles pour les IP LE pour le renouvellement du certificat (cf : mon tuto cité plus haut). Et pour que ça fonctionne : diriger le port 80 du routeur vers le NAS (je ne sais pas pourquoi vous l'avez supprimé). Si vous accédez à DSM de l'extérieur c'est que vous avez autorisé l'adresse ndd à accéder au port 5000 ou 5001 du NAS. Revoyez vos réglages. Je n'utilise pas le wildcard qui est pour moi une fausse bonne idée car vous ne contrôlez pas les accès. toto.ndd ou tata.ndd ou toto.tata.ndd ou video.ndd arriveront sur votre routeur. Les CNAME individuels permettent de filtrer ce qui doit arriver sur le routeur. Mais il faut pour cela que chaque adresse soit inclue dans le SAN (cf mon tuto) Si vous aviez lu mon tuto, vous auriez compris que les "pour" du certificat sont à configurer. Lorsque vous spécifiez un certificat comme étant par défaut, toutes les applis prendront ce certificat, ce qui ne signifie pas que le dit certificat fonctionnera avec la dite appli si son nom n'est pas couvert dans les SAN. Si vous avez supprimé le certificat Synology par défaut (ce qui n'est pas une bonne idée), vous n'avez qu'un seul certificat dans le NAS, et ce sera bien évidemment le seul utilisable puisqu'il n'y a pas le choix. Drive a son propre schéma de cryptage qui n'a rien à voir avec le certificat LE. Pour cette raison votre url drive.ndd n'a guère d'intérêt. L'accès à drive devrait uniquement se faire par ndd:6690

2. Drive n'a rien à voir avec la redirection http vers https, le 6690 est https. Ensuite, vous pouvez très bien être en HTTP en local et HTTPS de l'extérieur (il vaut mieux). Ce sont vos paramètres qui dicteront. Si vous n'ouvrez que le 443 et le 6690, vos échanges externes ne pourront être qu'en HTTPS. 3. Il n'y a pas d'inconvénient particulier. Vous rajoutez simplement une couche de sécurité supplémentaire, qui ne devrait avoir aucune utilité sur votre réseau privé, à moins que ce soit une vrai passoire. 4. Est-ce que je vous ai parlé de translation ? Vous ouvrez le 6690 que vous dirigez vers le 6690 du NAS. A ce sujet, je viens de voir que Drive utilise aussi les 5000 et 5001. Ce n'était pas le cas avec son ancienne mouture Cloud Station que j'utilise (pas encore passé à Drive et pas pressé de le faire). Restez sur le 6690 qui est un port spécifique au Cloud Synology. 5. Bien évidemment ! la règle du 80 vers la France et Suisse n'a pas de raison d'être. Comme je vous l'ai écrit, seuls les 2 ports LEncrypt doivent être autorisés dans la parefeu. Hormis celles vers LE, absolument toutes les connexions devraient être uniquement en HTTPS. ne JAMAIS passer par des ports HTTP, c'est une règle élémentaire de sécurité. S'il faut du HTTP, alors le VPN s'impose. 6. Rien de compliqué à comprendre, le service Drive du NAS passe par le 6690, comme file Station par le 7000/7001 etc... C'est très certainement dans la doc, vu que c'est un point vital pour pouvoir utiliser Drive sans passer par Quickconnect. Si ça n'y est pas, vous pouvez trouver tous les ports utilisés par Synology ici : https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/Network/What_network_ports_are_used_by_Synology_services 7. Il est totalement inutile de doubler le cryptage des échanges. Ce qui est important c'est la protection des échanges externes. Remettre une couche de cryptage du Reverse proxy (NAS) vers le paquet (NAS aussi) ne présente que l'intérêt de ralentir les échanges par un cryptage/décryptage inutile.

@ekke Si vous avez parcouru le forum, vous avez sans doute remarqué une section intitulée "Présentation". Merci d'y déposer votre contribution. Inutile puisque votre IP est fixe DSM c'est l'OS et son interface. La redirection est au choix de chacun. Si vous n'exposez pas directement le NAS à l'extérieur et/ou que vous avez fait les réglages corrects au niveau parefeu, routeur et éventuellement Reverse Proxy, la redirection n'est pas indispensable. Je ne la fais pas sur mon NAS car cela me poserait des problèmes au niveau de mon Reverse Proxy à cause d'un bug de DSM. On peut très bien accéder par le port 5000 (http) lorsqu'on est sur son réseau privé. Le reverse proxy permet aussi d'utiliser les ports http du NAS pour chaque application. Cette option (HSTS) est généralement plus source de problème qu'autre chose. Je ne l'ai pas activée sur mon NAS. Si vous utilisez drive, il faut aussi forwarder le port 6690. Je suppose que le 80 est redirigé sur le NAS pour le renouvellement du certificat. C'est bien mais il faut alors dans le parefeu en limiter l'accès aux seules adresses de Let's Encrypt (il y en a deux que vous trouverez facilement en parcourant le forum) Justement non pour le port 80 (voir §4). Supprimez la règle 80 ouvert pour tous les ports car même si elle n'est pas active, elle ne devrait pas être présente. Drive n'a pas besoin d'une adresse spécifique. Il ne doit pas non plus passer par le Reverse Proxy. Il utilise seulement le ndd qui permet de rejoindre votre box via l'adresse ndd:6690 (inutile de préciser le 6690 lors du paramétrage du client puisque c'est le port par défaut de Drive). Le reverse proxy c'est pour diriger une url vers un des ports du NAS. Par exemple, pour rejoindre DSM en https avec l'adresse nas.ndd, la source est donc https - nas.ndd - port 443, et la destination http - localhost - 5000 Si vous utilisez le Reverse Proxy, inutile de paramétrer les adresses HTTPS. Vous n'utiliserez normalement que les ports http dans les destinations (inutile en effet de sécuriser des transactions internes au NAS) Essayez de vider le cache de votre navigateur. Vous trouverez une bonne partie des réponses dans le tuto sur le serveur DNS et pour le reverse proxy et le certificat, je vous conseille d'aller lire mon retour en page 2 du dit tuto. A bientôt dans la section présentation 😉

C'est fou comme parfois certains prennent la mouche pour un rien. Je rejoins tout à fait les solutions données par Lucien77 et mes petits camarades modérateurs qui sont la meilleure réponse technique au problème posé dans la demande initiale. La solution de passer par un script existe aussi mais n'est pas simple à mettre en oeuvre et certainement pas la meilleure approche (on surcharge le lien principal en lui faisant supporter le trafic du lien secondaire). Il eut été nécessaire d'étayer le propos pour qu'il soit crédible.

C'est surtout que vous pouvez éloigner et isoler la sauvegarde de la source, ce que vous ne pouvez pas faire avec un DX. Le DX est fait pour augmenter la capacité de stockage sur un NAS de travail. Il est donc une partie intégrante du NAS et faire une sauvegarde des données du NAS sur l'extension revient à faire une sauvegarde en interne, ce qui ne correspond pas au critère d'éloignement et de sécurisation d'une sauvegarde. C'est la même chose si vous prenez un autre NAS pour le mettre à côté du NAS principal car en cas de problème externe (vol, incendie, dégâts des eaux, ....) vous perdez tout. Pensez à délocaliser vos sauvegardes pour qu'elles soient véritablement des sauvegardes sur lesquelles vous pouvez compter en toutes circonstances.

Bonjour i-Moi, soyez le bienvenu dans la communauté. Question : que vient faire le Chili dans tout ça ?

D'accord avec Jeff777 sur la cause probable de cette vérification. Ce n'est par pour rien qu'il est très fortement recommandé d'alimenter un NAS en raid avec un onduleur compatible, faute de quoi on s'expose à ce genre de situation qui peut à l’extrême conduire à la perte totale d'un volume.

Malheureusement, je crains fort que ce disque ait un soucis au niveau de la partition système. Avant de le mettre en place, je ferais un test approfondi sur un PC avec le logiciel du constructeur histoire d'avoir une information plus précise de son état. Ce serait ballot de le monter pour s’apercevoir dans quelques jours que le NAS est à nouveau en défaut.

Désolé @deville62, mais cette section ne concerne que les présentations. Si vous avez des questions, il faut les poser dans les forums appropriés.