Mic13710

Il y a bien trop de processus qui peuvent empêcher les disques d'hiberner. Cloud Sync en fait partie. Voir la kb synology : https://kb.synology.com/fr-fr/DSM/tutorial/What_stops_my_Synology_NAS_from_entering_System_Hibernation? En clair, il y a tellement de cas qu'on peut se poser la question de l'intérêt de l'hibernation. C'est plus pour répondre à une obligation de mettre en place des mécanismes d'économie d'énergie, tout en sachant que c'est inapplicable dans la grande majorité des cas. Il faudrait que le NAS ne soit utilisé qu'en stockage et sans aucune application en service pour que l'hibernation ait une chance de pouvoir fonctionner.

@CoolRaoul , j'ai peur de ne pas bien comprendre. Hyperbackup Vault permet au nas de destination de pouvoir lire les différentes versions desfichiers hbk. Il ne me semble pas apte à gérer des sauvegardes autres que celles créées via hyperbackup. Cela en tout cas ne résoudrait pas le problème de la sauvegarde d'un usbshare du nas source vers le nas de destination. Ca c'est hyperbackup qui peut s'en charger, moyennant un montage du disque usb.

En faisant cela, c'est le meilleur moyen de bloquer les sauvegardes. Si le disque n'est plus accessible, la sauvegarde va bloquer. Cette opération DOIT être sur une tâche séparée. D'une manière générale, je ne recommande pas des faire une tâche globale mais plusieurs tâches séparées, une par exemple par dossier partagé. On limite ainsi grandement les problèmes et si une tâche est en défaut, elle ne concerne qu'un seul dossier et la création d'une nouvelle tâche sur un seul dossier est beaucoup moins chronophage que sur la totalité des données.

Les boitiers d'extension DX permettent d'étendre un groupe de stockage sur les NAS de la série + compatibles. Le DS920+ permet de monter un groupe de 9 disques, 4 dans le NAS et 5 dans le DX. Il faut savoir que quand un groupe augmente en capacité, les risques de pannes augmentent de manière exponentielle. Il n'est donc pas du tout recommandé de monter un groupe unique de 9 disques de 12To dans un SHR ou RAID1 car la perte d'un disque peut entrainer la perte du groupe lors de la reconstruction à cause du travail intensif sur les disques. Plus problématique encore lorsque vous ajoutez un disque à un groupe existant car tous les disques sont sollicités pour effectuer la nouvelle répartitions des données. Seul le SHR2 (ou RAID6) peut offrir une meilleure sécurité tant en extension qu'en réparation pour des groupes aussi importants. Donc, si vous envisager de peupler l'extension avec des disques de 12To ou plus, il vous faudra passer votre groupe au SHR2. Ca, c'est si les deux unités fonctionnent correctement. Ce qui peut devenir problématique c'est lorsque l'unité d'extension tombe en panne. Le groupe est alors cassé et selon le travail effectué au moment de la panne, c'est la perte assurée des données. Je ne sais pas comment Synology gère ce genre de situation mais il faut absolument que tout le travail en cours soit stoppé instantanément pour éviter de détruire le groupe. Personnellement, je préfère travailler sur 2 groupes séparés, un par unité pour ne pas avoir à être un jour confronté à un groupe unique cassé. Par contre, qui dit groupes séparés dit aussi volumes séparés et dans ce cas il n'est pas possible de conserver une arborescence unique, ce que vous souhaitez. Seule l'option du groupe et volume étendus sur le DX vous assure cela, mais dans ce cas, il faudra envisager de passer en SHR2 et il faudrait le faire dès le premier disque installé dans le DX pour que les futurs ajouts de disques se fassent avec plus de sécurité.

Il n'y a pas un petit problème là ? Je ne vois pas comment vous obtenez seulement 25To avec 4 disques de 12To. En RAID1 ou SHR, vous devriez avoir un peu moins de 33To En RAID6 ou SHR2 vous seriez plutôt être autour de 22To Vous n'auriez pas omis quelques informations sur votre groupe de stockage ?

Pas de problème de techno pour les deux modèles. Ils sont CMR. Difficile de trouver l'information, mais il se peut que le pro ait quelques secteurs de moins que les +, ce qui pourrait bloquer le processus d'intégration. Si vous pouvez encore changer votre disque pour un + identique à ceux installés, faites le. Vous serez sûr que les disques auront le même nombre de secteurs et si ça bloque encore, c'est qu'il y a un autre problème. Et puis le + est moins bruyant que le pro 😉.

Quelles sont les références de vos disques, ceux installés et le nouveau ? La techno des disques a son importance.

Les ports personnalisés sont les ports pour les applications. Ce sont ceux par défaut qui s'affichent et c'est là que tu peux les changer, ce qui ne sert à rien mais certains pensent que ça les protège. On se rassure comme on peut. D'autant qu'en passant par le revers proxy, le port de destination n'a vraiment plus aucune importance. A travers cette interface, tu as 2 méthodes pour accéder à l'application : soit par l'alias et à ce moment là ton url est https://ndd/alias, soit par un nom de domaine défini dans le domaine personnalisé et dans ce cas ton url est simplement https://tondomainepersonnalisé. Dans ton cas ton domaine personnalisé c'est cam.ndd. Perso je n'utilise pas cette interface. Je passe par le reverse proxy uniquement.

Aucune. C'est une version plus user friendly. Cependant elle ne concerne que les applications du NAS. Pour les autres, c'est le reverse proxy de l'onglet avancé qu'il faut utiliser. Par exemple, ma domotique sur RPI est joignable via domo.ndd vers l'IP et le port du RPI. Idem pour pi-hole.

Si j'ai bonne mémoire, il est dit dans le tuto de ne pas activer le http vers le https car cela pose (posait) des problèmes de redirection dans le reverse proxy. Je crois que c'est aussi dans ce même tuto qu'on parle d'un fichier .htaccess pour réaliser cette redirection. Mais comme les choses évoluent entre chaque version de DSM, il est possible que ce dysfonctionnement ait été résolu par Synology. Je ne comprends pas bien ta question. Si tu veux utiliser le reverse proxy pour joindre DSM, tu peux par exemple créer une ligne https:\\nas.ndd qui pointe vers localhost:5000. Perso, je ne suis pas friand d'un accès à DSM par le web. Aussi, j'ai rajouté un profil de contrôle d'accès limité aux seules IP privées et en secours à un nombre très limité d'adresses publiques que je possède. Je fais un accès à distance via wireguard sur mon routeur pour ensuite me connecter à DSM.

Rien d'étonnant. Déchiffrer puis re-chiffrer pour re-déchiffrer ça demande des ressources. Sauf si ton réseau local n'est pas sur, il ne sert à rien de passer en https en interne. Tout ceci est expliqué dans le tuto sur le reverse proxy. Alors ça a changé car jusqu'à présent les applications DS utilisaient le port de l'application par défaut. Si le port était différent, il fallait le préciser dans l'url. Et du coup, je me demande comment l'application DS sait qu'il faut passer par le 443 si le port n'est pas précisé. Peut-être que les deux sont testés : si le port par défaut ne passe pas, alors DS bascule sur le 443 (ou le 80 si http).

Si tu ne précises pas le port, l'application DS Cam utilise le port par défaut : 9901. Ton ndd est normalement liée à ton IP publique. Donc, en ne mettant pas le 443, DS utilise par défaut https:\\cam.ndd:9901. Comme le port est ouvert dans ton routeur, il est normal que ça fonctionne. Et par la même occasion, tu ne passes pas par le reverse proxy ce qui exclu de facto toute probabilité de ralentissement de sa part 😀

Je ne crois pas que le reverse proxy soit la source de ton problème. Est-ce que tu as bien spécifié le port dans DSCam ? Même si tu utilises le 443, il faut le préciser dans les applications DS. https:\\cam.ndd:443

Oui

Essaie d'activer les websocket dans les en-têtes personnalisées.