.Shad.

Il n'y a pas vraiiment d'outil de "sauvegarde" d'un conteneur. Par essence, Docker est à la base un outil pratique pour isoler une application et se passer des problèmes liés aux dépendances. Même si c'est de moins en moins le cas, tu trouveras encore beaucoup de dev qui estiment que Docker c'est bien la partie développement, mais qu'en production une installation native est préférable, c'est aussi moins de boulot pour eux. 😄 Bon attention ça a tendance à disparaître, surtout avec l'avènement de soft comme Kubernetes et autres logiciels d'orchestration de déploiement. Une grande partie des soft ont des images Docker fonctionnelles, officielles ou non officielles. C'était pour la petite parenthèse culture. Maintenant, pour sauvegarder tes conteneurs, ce qui est important : Les paramètres du conteneur : c'est ce que tu exportes si tu te sers de l'interface DSM, ça peut également être la ligne de commande servant à créer/lancer le conteneur,ou le fichier YAML pour docker-compose. Les données : si une image est bien faite, les données importantes pour la restitution d'un conteneur sont localisées dans les volumes exposés par l'image. Donc si tu as monté ces volumes sur le NAS, les données persisteront à la suppression du conteneur. Donc il te suffit de sauvegarder ces données. Ca peut être via un bête script qui chaque jour copie le contenu des dossiers dans un dossier partagé du PC monté via Filestation, mais ça peut aussi être via rsync, une ligne de commande à lancer sur le NAS et un logiciel de type Cygwin sur Windows. Et pourquoi pas, suviant la taille des données, une sauvegarde sur un Google Drive ? Bref, à toi de voir la solution qui te convient le plus.

Salut, Tout dépend de l'adresse que tu vas utiliser dans Synology Drive pour joindre ton NAS. Solution facile mais moins idéale (d'un point de vue sécurité et débit) : utiliser l'identifiant QuickConnect Solution idéale mais moins facile : mettre en place un accès distant via nom de domaine ou IP fixe publique Si tu décides de te passer de QuickConnect, ce que je conseille, sache que ça te demandera d'investir un peu de temps.

Bienvenue parmi nous !

Bienvenue parmi nous !

@Chnoups Salut, tu te rends compte que les informations prodiguées dans ta demande étaient clairement insuffisantes ? Ca aurait effectivement pu être n'importe quoi, à commencer par la translation de ports. Tant mieux si tu as trouvé la solution, c'est formateur. 🙂

Salut @Nono-77 Pas de solution simple à ma connaissance, tu peux passer par Duo, mais il te faudra installer le proxy Duo sur un Windows, qui lui pointera sur l'AD Synology. Confirmé ici : https://community.duo.com/t/will-duo-work-with-synology-nas-as-active-directory-server-in-local-domain/5710/2 Peut-être trop usine à gaz pour ton besoin ? Concernant Duo, je l'utilise depuis 2 ans pour mes authentifications 2FA, c'est du bon et fiable. Gratuit jusqu'à 10 utilisateurs de surcroît.

C'est ce que je conseillerais, attention cela dit au niveau des changements majeurs induits avec DSM 7, je pense notamment à l'abandon de Photostation au profit de Synology Photos, successeur de Moments sur DSM 6, et également à l'abandon du support de la plupart des dongle nativement dans DSM. Si tu étais sur les dernières versions de DSM 6, le changement était déjà d'actualité. Et si tu veux repartir de 0, je te conseillerais aussi de prendre des impressions d'écran de tes réglages pour pouvoir les refaire a posteriori. Ainsi tu pars vraiment sur une base saine.

105 MB/s c'est la vitesse réelle d'une bonne connexion gigabit, que dit Windows ? Si tu as aussi 1000/1000 Mbps, c'est qu'un de tes éléments sur le chemin entre client et serveur ne dépasse pas 1 Gbps. Donc vérifier : Câble Carte réseau PC (pilotes ok?) Si tu atteins les 10 Gbps en liaison directe Si tu atteins les 10 Gbps avec les switchs éventuels entre tes deux périphériques L'élement qui viendra ensuite limité c'est la vitesse d'écriture sur les disques du NAS et du PC. Les HDD sont limités par rapport aux SSD en terme de debit, ce sera le prochain facteur limitant (la vitesse de rotation a une petite influence). Mais tu seras déjà à beaucoup plus que 100 Mo/s.

@Mic13710 Bon à savoir, c'est vrai qu'on a vite tendance à utiliser un certificat auto-signé pour un serveur VPN. 😉 @Kris-I Vu que ton NAS est utilisé en tant que client VPN, je ne pense pas que ce soit lié. Car ton prestataire VPN te fournit normalemet tout ce dont tu as besoin. Ce n'est pas lié au certificat de Synology.

J'essaie d'attendre toujours quelques semaines avant de faire une mise à jour, ça évite parfois les déconvenues de ce genre. 🙂 Après rien ne prouve que la màj est fautive, mais bon, ça y ressemble un peu quand même. 😉

@Mic13710 On voit fleurir sur le forum des problèmes de connectivité avec OpenVPN depuis quelques heures, il y a sûrement un bug sous-jacent d'OpenVPN ou d'une dépendance. @Arian Que disent les logs du conteneur ? Vaultwarden ne consomme que très peu, donc difficile à dire. Si c'est un problème de synchronisation, vérifie que le port dédié à celles-ci (je ne sais plus lequel) est toujours bien autorisé dans le pare-feu du NAS et également correctement translaté du NAS au conteneur si en mode bridge.

Voir le message de @Mic13710, je ne dis pas que c'est lié, je dis que ça commence à faire pas mal de retours concernant des problèmes avec OpenVPN depuis l'update 5. En l'état je t'invite à suivre le sujet et le forum officiel Synology : https://community.synology.com/enu/forum/1

Très intéressant, merci @maxou56 !

Tiens-nous au courant du résultat final, je suis étonné de voir qu'en supprimant récursivement dans / tu arrives à réinstaller DSM, c'est donc que la partition de démarrage est dans une partition autre, bonne nouvelle.

@baz1ga Salut, c'est bien tu te poses les bonnes questions ! Première remarque, ne pas jeter ton DS212+, il est encore tout à fait viable pour : - être un simple stockage - être une destination de sauvegarde Tu peux effectivement partir sur un NAS plus récent compatible Docker/VMM, vérifier si tu as besoin d'un iGPU ou pas (utilisation de plex/emby/... en transcodage par exemple). Tu devras alors faire une sauvegarde Hyper Backup de tes données pour ne pas simplement migrer mais reconfigurer ton système, afin de profiter des fonctionnalités apportées par le système de fichiers BTRFS vs EXT3 ou EXT4. Ou alors, tu achètes un mini-pc genre celui que je vends 😄 : https://www.nas-forum.com/forum/topic/76704-mini-pc-qotom-i3-pfsense-opnsense-etc/) ou bien sûr un autre type NUC, qui hébergera tes applications, et utilisera des montages réseau pour accéder aux données stockées sur les disques de ton NAS. C'est ce que je fais depuis plusieurs années maintenantavec un DIY sous Debian, j'en suis très satisfait. Attention qu'il faudra réfléchir à ta stratégie de sauvegarde, sachant qu'en DIY tu n'auras pas le même confort de configuration que sur DSM. Après, une fois que c'est en place, ça fonctionne tout aussi bien, ça demande juste de mettre un peu plus les mains dans le cambouis. Et tes Rpi pourront tout à fait servir pour faire la redondance des services hébergés sur ton nouveau NAS ou mini-pc, Pi-hole par exemple. 😉

Bienvenue par nous, je te conseille de jeter un oeil au sujet dédié à la sécurisation des accès au NAS :

En partant de quelle version ? Tu peux déjà essayer de modifier les DNS utilisés par le NAS, c'est dans Panneau de configuration -> Réseau -> Cocher Configurer manuellement le serveur DNS et tu peux mettre par exemple ces deux adresses : 9.9.9.9 1.0.0.1 Vérifier ensuite si tu as toujours des problèmes de connectivité.

C'est une erreur de résolution DNS. Le port 59999 c'est a priori le port sortant, tu n'as pas à t'en soucier, un périphérique choisi généralement le port sortant qu'il souhaite, plutôt dans les valeurs hautes que basses (qui sont réservées à des applications système et/ou bien définies). Je veux bien qu'on décortique ensemble en TeamViewer, Discord, Teams, etc... (envoie moi un MP avec tes dispos) mais t'expliquer ce que j'ai fait ne mènera pas à grand chose. Je pense que s'il y a un problème je le verrai bien plus rapidement de visu, qu'en échangeant encore X messages pour tenter de trouver l'aiguille dans la botte de foin. Et parce que c'est un forum, il faudra faire un debrief de la résolution du problème, histoire que ça profite au plus grand nombre.

Synology recommande de ne pas utiliser de bond avec le SMB Multichannel, visiblement ça marche quand même, au moins avec une seule autre connexion. Je ne vois pas l'intérêt de garder l'agrégation de liens avec le multichannel. L'activation des jumbo frames est à double tranchant, voir cet article : https://netcraftsmen.com/just-say-no-to-jumbo-frames/ Les disques et le schéma de RAID utilisé sont en effet des éléments limitants, un RAID 0 (ou 10) offira les meilleures performances car on écrit en // sur les disques. Un SHR2 sera le plus handicapant. Avec des disques mécaniques tu seras limité, sachant qu'un HDD suivant sa vitesse de rotation et sa qualité, acceptera entre 100 et 200 Mo/s en vitesse de transfert. Au-delà, il faudra utiliser des SSD à la place des HDD.

Tu peux faire une impression d'écran de ton pare-feu ? Tu n'as besoin que d'une règle, celle qui autorise Hyper Backup Vault : C'est encore mieux si tu peux limiter à une seule IP si tu as la chance d'avoir une IP fixe sur la connexion de ton NAS principal. Là je parle en IPv4. Si tu veux fonctionner en IPv6, et que le préfixe de ta connexion IPv6 est fixe (les xx premiers octets de ton adresse IP, également appelé le préfixe), tu peux autoriser l'IPv6 du NAS principal, exemple : Je ne veux pas t'embrouiller avec le préfixe qui permet d'identifier ton réseau IPv6 sur le réseau de ton NAS principal, sache juste que si tu autorises ce réseau, c'est un fonctionnement équivalent à l'IPv4 et ton IP publique au niveau de la box. En revanche, dans ton cas présent, si tu essaies d'atteindre ton NAS distant via son IPv6, tu dois être certain que : - tu aies une connectivité IPv6 au niveau de ton NAS principal - que le pare-feu de la box du réseau distant autorise les connexions entrantes sur le NAS en IPv6 Suivant les box, tu auras plus ou moins la possibilité de modifier le pare-feu IPv6 (qui se contente parfois d'avoir uniquement un niveau de réglage Faible - Moyen - Fort plutôt que de donner la possibilité d'ajouter des règles personnalisées). Si ton pare-feu IPv6 n'est pas configurable sur ta box, tu devras passer par l'IPv4, pas le choix. @Mic13710 Le port 6281 d'HBK s'expose de façon chiffrée si on a un certificat valide associé au service Hyper Backup Vault dans DSM.

Hello ! Bienvenue parmi nous 🙂

@Dimebag Darrell Ah ? moi, même en root (quand je ne précise pas de user dans le fichier compose), ça ne fonctionne pas. En revanche j'ai procédé autrement, pour éviter de devoir toucher aux permissions du socket docker. J'ai utilisé l'image https://github.com/sjawhar/docker-socket-proxy qui permet d'exposer via un conteneur un socket docker. Et ce conteneur est dans un réseau uniquement composé de telegraf et lui-même. Ainsi Telegraf accède au socket via les permissions natives, et je n'utilise pas de certificat TLS (contrairement à ce que je fais dans ce tutoriel) car seul Telegraf peut avoir accès au socket, ce que j'estime ne pas représenter de danger outre-mesure. Mon fichier compose pour le proxy : version: "2.1" services: docker-socket-proxy: image: sjawhar/docker-socket-proxy container_name: docker-socket-proxy hostname: docker-socket-proxy networks: - net-dsp environment: - LISTEN_SECURE=false - LISTEN_PORT=2375 volumes: - /var/run/docker.sock:/var/run/docker.sock:ro labels: - "com.centurylinklabs.watchtower.enable=true" restart: unless-stopped networks: net-dsp: external: true net-dsp est le réseau qui accueille également Telegraf, dont le compose est le suivant chez moi : version: "2.1" services: telegraf: image: telegraf container_name: telegraf networks: - net-dsp # non-root user needed since 1.20.3 user: telegraf:65536 volumes: # config - /volume1/docker/telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro # additional MIBs - /usr/share/snmp/mibs:/usr/share/snmp/mibs:ro # local time preset - /etc/localtime:/etc/localtime:ro - /etc/TZ:/etc/timezone:ro # docker socket mounting - /var/run/docker.sock:/var/run/docker.sock:ro labels: # watchtower label only monitoring - "com.centurylinklabs.watchtower.enable=true" restart: unless-stopped networks: net-dsp: external: true Remarque : C'est normal que Telegraf ne partage pas de réseau commun avec InfluxDB et Grafana, ces derniers sont sur un VPS dans mon cas, il accède donc à InfluxDB via son entrée de proxy inversé sur le VPS directement.

Je serais étonné qu'un reset fonctionne si tu as vraiment supprimé tout le contenu de ta racine. Car je pense que la partition de boot est incluse dans / A vérifier mais j'ai des gros doutes...

Le résultat est le même, c'est l'accessibilité qui change. L'avantage d'avoir une authentification par clé, c'est que ça exclut d'emblée tous les périphériques dont les clés publiques n'ont pas été ajoutées au fichier authorized_keys. L'autre intérêt d'une clé (mais sans mot de passe) est de permettre l'exécution de scripts à distance.

Welcome !