CoolRaoul

Donc ton DDNS est géré par le NAS! Que la livebox ne connaisse pas le fournisseur n'a dans ce cas *aucune* importance. La fonction DDNS sur la Livebox (ou le routeur qui la remplace) fait double emploi avec celle du Synology. ??? Mais Il n'y a *rien* à faire. Tu remet la Livebox à la place du routeur, sous DSM tu vérifie que le DDNS est toujours actif. Ca doit ressembler à ceci: (panneau de configuration -> accès externe -> DDNS) Si le statut est "normal" c'est que c'est bon Ensuite ce qui peut coincer ce sont les redirections dans la box, pense à vérifier.

Non, ceci est tout a fait indépendant du DYNDNS. Ce dont tu parle sont les redirections de ports. Au temps pour moi, c'est parce que ce genre de config a été abordée a deux reprises recemment dans le forum que j'ai été induit en erreur, et ton message laissait un peu une place au doute également. Mais sinon, remettre la Livebox et utiliser la config DYNDNS via le NAS tu ne veux pas essayer? PS: je ne comprend pas cette phrase: "Synology chez qui j'ai déclarer mon nom de domaine" Tu l'a faites *ou* cette déclaration exactement?

Pour pousser le test jusqu'au bout serait intéressant de faire un backup suivi de restauration d'un partage avec ACLs activées et vérifier si elles sont bien conservées dans l'opération.

Ah non il y a de l'espoir: https://www.dedikam.com/content/synology tu testes?

Apparemment ils offrent l'acces rsync en mode "rsync over ssh" et pas en mode client/serveur (nécessaire pour l'outil de sauvegarde intégré syno) On pourra toujours faire des sauvegardes par script (rsync -e "ssh -i <chemin clé privée>" -av /dossierlocal/ user@dedicam:/dossierdistant/) mais faudra oublier la sauvegarde des ACLs et métadonnées

Leurs forums semblent bien déserts non?

J'y ai pensé (et google drive aussi a des tarifs compétitifs) mais ce n'est pas demain la veille que ces services supporteront rsync et donc sauvegarde et restauration "native" de DSM.

Juste un bémol: dans un réseau perso, deux serveurs DHCP, pour peu qu'on veuille mettre en place de pré-allocation d'IP en fonction de la MAC, ça peut être ch** à gérer (faut dupliquer les confs, mais ça fonctionne). C'est surtout utile dans un réseau "pro" ou on souhaite assurer une redondance entre deux serveurs DHCP (bien que la aussi, une approche de type failover soit sans doute aussi efficace). Faut juste retenir c'est que ça fonctionne, le protocole est "étudié pour".

Pour de la sauvegarde il ne me semble pas important de bénéficier d'un gros débit . Par contre faudrait pouvoir garantir, à la demande et au coup par coup, une "fenetre" à haut débit pour une grosse restauration.

Oui, je le pense aussi: deux niveaux de tarifs en utilisant les quotas réseau Syno par utilisateur ça pourrait se justifier. Attention aussi bien étudier les tarifs de la concurrence pour rester compétitif.

Intéressant, mais ne faudait-il pas aussi moduler le tarif en fonction de la bande passante utilisée? Un gus qui te sauvegarde 1G par jour, même pour une volumétrie totale cible faible, n'aura pas le même impact que celui qui fait de la synchro avec peu de données modifiées ? Et je ne suis pas sur que les quotas réseau DSM soit une réponse à cette problématique. Mais je conviens que ca risque d'être pas évident à mesurer et par suite à facturer.

Me semble qu'il aurait été plus simple d'utiliser la fonction DYNDNS intégré au syno que partir dans ces galères avec ces routeurs en cascade derrière la BOX (il est encore temps remarque mais faudra laisser tomber tes routeurs)

Et utiliser le serveur DHCP du NAS ouvre la porte à des développement intéressants (quoiqu'un poil intrusifs ) Surveiller les messages "DHCPDISCOVER" dans /var/log/messages, pour peu que tu connaisses l'adresse MAC Wifi des téléphones respectifs de ta progéniture, va te permettre de générer un rapport des heures d'arrivées dans la maison de chacun.

Ben oui: le message d'erreur laissait le doute entre un problème de permission et cette erreur de majuscule. Heureusement que Bud à le coup d'oeil!

"c'est le matin, il est encore tôt"

Sans doute l'est-il déjà (que donne "ls -l /volume1/partage/liste.sh" ?)

Oui et alors??? Ca n’empêche pas que le script *doit* être exécutable. Essaie de faire ce que j'ai dit au lieu de temporiser, tu verra bien. **EDIT** Y a un truc que je ne comprend pas: le script c'est "/Volume1/System/PhotoStation_DB_copy.sh" ou "/volume1/partage/liste.sh"? ***EDIT#2** Oups je croyais répondre au premier posteur

Commencer par: chmod +x /Volume1/System/PhotoStation_DB_copy.sh Et ça ira bien mieux

Pas d'accord sur le DHCP. Le protocole est conçu pour supporter plusieurs serveurs DHCP sur le LAN (détail). Le principe est que tous les serveurs répondent (DHCPOFFER) à la requête initiale effectuée en broadcast (DHCPDISCOVER), c'est ensuite le client qui va choisir *l'un d'entre eux* et lui demander (DHCPREQUEST, toujours en broadcast pour que les autres serveurs soient au courant) l'allocation d’adresse . Le serveur répond par une confirmation (DHCPACK) En outre, a partir du moment ou le réseau wifi et le réseau filaire partagent le même subnet (ce qui est le cas par défaut des box) n'importe quel serveur DHCP du réseau saura répondre aux requêtes de n'importe quel appareil, qu'il soit connecté en wifi ou en ethernet. Pas besoin de mettre une clé WIFI sur le NAS. Pour info c'est la configuration que j'utilise: serveur DHCP actif sur mon NAS, celui de la box désactivé (j'aurais pu le laisser actif mais ça aurait été moins pratique pour les allocation d’adresses prédéfinies) et WIFI sur la box.

Pareil pour moi sur DSVideo sur ma tablette Nexus10 (CTD systématique). Depuis le 20 juillet j'ai un dossier de support ouvert chez Syno à ce sujet Peu après, ils m'ont demandé des logs système (logcat, pour temporiser j’imagine). Le 28 juillet; je leur ai envoyé un stack dump ou ont voit clairement l'erreur: "java.Iang.RuntimeException: Canvas: trying to use a recycled bitmap" Ca été le dernier contact sur ce dossier, depuis c'est le black out de leur part. Pas top le support Syno pour les appli Android NB: J'avais déjà eu affaire à eux pour DSCloud. Ils avaient péniblement fini par reconnaître le dysfonctionnement, un trafic réseau entre le NAS et les clients Android toutes les 5 secondes (qu'il y ait eu des modifs ou pas!), avec pour effet de bord des accès réguliers au disque local. La réponse à mon étonnement qu'ait été utilisée une approche par polling plutôt quévénementielle, sachant qu'on dispose d'une connexion permanente bidirectionnelle entre client et serveur, a juste été que c'était une "amélioration" qui serait "suggérée" aux développeurs pour une version future. J'ai laissé tombé DSCloud depuis lors.

Non, cela ne concerne que la sauvegarde de *configuration*, pas les fichiers (pouquoi donc est-ce indiqué en chinois sur ton screenshot? tu aurais percuté sinon) Exemple en V5 (au look pres c'est pareil qu'en V4): Cela ne permet que de conserver un exemplaire de la dernière version d'un fichier *effacé*. Par contre la sauvegarde d'un fichier *modifié* écrasera sa version sauvegardée précédente

Ah ok, je comprend mieux. Mes filtres RSS ont tiltés a a cause des clés "Synlogy" et "Synlocker" présents dans l'article, et comme on m'attendais pour déjeuner je n'ai pas pris le temps d'approfondir. Désolé pour la fausse joie.

Ah ok alors, si il y a déjà des témoignages négatifs évidemment. Je croyais que c'était un nouveau service vu que la news venait juste d'être postée peu avant midi sur pcworld, ce qui m'a induit en erreur. **EDIT** En fait ca ne concerne meme pas le ransomware Syno, me suis fourvoyé! explications ici:

Scoop: Le ransomware CryptoLocker n'est plus une fatalité : un site Web pour connaître sa clé de déchiffrement sans payer

C'est ainsi que fonctionne le backup Syno, que ce soit en local ou de NAS à NAS, d'ou ma remarque. Pour conserver un historique nécessite faut soit utiliser un volume dédié en cible, soit utiliser Time Backup (dans les deux cas avec les problemes de volumétrie sur la cible lorsque tous les fichiers sources sont modifiés comme tu l'as fait remarquer) ***EDIT** Je viens de tomber sur cet article: Le ransomware CryptoLocker n'est plus une fatalité : un site Web pour connaître sa clé de déchiffrement sans payer Je sens qu'il y en a certains qui vont être soulagés!