PiwiLAbruti

De quels témoins parles-tu ? Statut, réseau, disque ?

Ça n’a rien à voir avec DNS. Modifie la configuration du routeur afin que le service de gestion de ce dernier ne soit pas accessible depuis internet (et utilise surtout un mot de passe fort).

Plex ne supporte plus l'architecture QoriQ depuis fin 2016. Il n'y a donc plus de paquet Plex pour DS213+ (et DS413). Il vous reste deux solutions : Chercher un paquet Plex archivé pour cette architecture. Compiler vous-même le paquet avec spksrc (la toolchain QoriQ existe pour DSM 6.1), mais c'est malheureusement beaucoup plus technique.

Le support du 10GbE est justement la différence entre le Cat6 et le Cat6a : https://fr.m.wikipedia.org/wiki/Paire_torsadée#Les_spécifications_des_paires_torsadées

Je ne vois pas de goulot d'étranglement particulier. Est-ce que l'adressage est différent entre le réseau de la box, et celui entre le Mac et le NAS (192.168.2/24) ? SMB 3 est plus performant que AFP. Vérifie que SMB 3 est bien activé sur le NAS dans les options avancées des services de partage : https://www.synology.com/fr-fr/knowledgebase/DSM/help/DSM/AdminCenter/file_winmacnfs_win

Combien de disques sont installés dans le NAS ? Quel est le type de RAID configuré ? Quel protocole est utilisé pour la copie de fichiers ? Quel type de contenu est utilisé pour la copie ? (vidéo, photos, ...) Quelle est la vitesse max en écriture du SSD du Mac ?

Oui, si tu as déjà du matériel compatible 802.3ad autant en profiter. Il n’y aura aucune augmentation réelle (ce sera toujours basé sur du 1Gbit/s), ça permettra juste à deux clients de profiter en simultané d’un débit de 1Gbit/s. Il faut donc voir le débit en LACP comme 2x1Gbit/s plutôt que 2Gbit/s.

Une machine n’envoie du trafic à destination de sa passerelle (un routeur dans le cas présent) uniquement si la destination se trouve sur un autre réseau que le réseau local (pour simplifier). Le switch n’a pas besoin de supporter le protocole d’agrégation 802.3ad (LACP), un lien ALB suffit amplement. Donc un switch 24 ports sans aucune intelligence particulière (L1) est suffisant. Et honnêtement, vu tes besoins, tu n’en as pas besoin. 😉

Ce n'est pas parce que les services du NAS sont uniquement ouverts aux adresse IP françaises qu'il ne peut pas y avoir d'attaques depuis ces dernières. Si la cible rsync est connue, autant créer une règle dédiée qui n'autorise que cette adresse IP plutôt que d'ouvrir le service rsync à toute la France.

IPv6 n’est pas vraiment "forcé". C’est juste que la couche IPv4 a disparu du côté WAN des Freebox et est maintenant encapsulée dans IPv6, d’où l’impossibilité de désactiver IPv6. Mais Free ne propose toujours pas de pare-feu IPv6... 😕

Si par "miroir" tu entends un équivalent du RAID1, la réponse est non. Je n’utilise pas les outils de réplication de Synology, et du peu que j’en sais ça s’applique surtout aux LUN iSCSI. Je sais qu’il existe la synchronisation de dossiers partagés, à voir si ça correspondrait à ton besoin.

Le nom de domaine est à acheter auprès d’un registrar. Il y en a pour moins de 10€/an (je recommande OVH pour les fonctionnalités supplémentaires comme DDNS). Tu peux utiliser DNS Server pour configurer une zone locale, ça te permet d’utiliser le même nom d’hôte pour les accès au NAS que ce soit à l’intérieur ou à l’extérieur De ton réseau local. Il y a un tutoriel DNS Server à sujet.

Il ne pas faut pas confondre "attribution dynamique" et "adresse IP pas fixe". Ce n'est pas parce que l'adresse IP est attribuée dynamiquement qu'elle ne peut pas être fixe. Ce que veut dire @Fenrir, c'est qu'afin d'avoir une adresse IP qui ne change pas (pour le bon fonctionnement de certains services qui y sont sensibles) il faut soit la configurer manuellement dans le NAS (1ère option), soit attribuer un bail statique au niveau du serveur DHCP (2ème option, recommandée). Oui, sachant que les 4 règles dont tu parles ne permettent d'accéder au NAS que depuis le réseau local et non depuis internet. Plus généralement, il vaut mieux comprendre à quoi sert chacune de ces règles plutôt que des les recopier sans réfléchir (je sais, ce n'est jamais évident pour un novice). Tu peux parfaitement te contenter de https, mais je conseillerais fortement de disposer d'un nom de domaine et de configurer ce type d'accès avec un reverse proxy (intégré à DSM). Ce n'est pas réellement de la sécurité, mais ça a l'avantage de fortement limiter les tentatives d'intrusion. S'il n'y a que toi qui puisse te connecter depuis l'extérieur, il n'y a théoriquement aucun risque. Mais comme tu n'es pas seule à utiliser internet dans la pratique, il y a toujours un risque (qu'il est possible de diminuer). Donc la réponse à ta question est oui, il y a un risque. Non, la seule porte ouvert est celle vers le NAS. Ton ordi n'est pas affecté (si son pare-feu est activé et bien configuré).

Vu l'incident rencontré et la solution envisagée, je conseillerais d'abord de mettre en place un plan de sauvegarde robuste avant de s'attaquer à ce qui semble être un PRA d'après ce que tu décris. Donc avant de répondre à ta question, je vais te poser celle-ci : Quel était le plan de sauvegarde avant l'incident, et quel est celui envisagé à l'avenir ?

Petite remarque concernant cette partie du tuto : L'intérêt d'un nom de domaine est également de l'utiliser aussi bien en local que depuis l'extérieur, tel qu'expliqué dans le tutoriel DNS de @Fenrir. Pour faire simple, j'utilise https://sub.domain.tld/ aussi bien en interne qu'en externe pour me connecter à DSM (avec des restrictions IP depuis l'extérieur). Idem pour les applications mobiles (DS *), j'utilise un nom d'hôte unique sub.domain.tld:443. Bien sûr, cela fonctionne sans loopback.

Expiration du délai détectée ! (Connexion de données) Le problème ne serait pas lié à la plage de ports passifs ? (et/ou PASV)

Tu peux créer un script en PHP : #!/bin/env php <?php echo 'Hello World !'; ?> et l'exécuter via les tâches planifiées de DSM. Tu peux choisir l'environnement PHP à utiliser en remplaçant 'php' par 'php56', 'php70' ou 'php72' selon les versions installées via le Centre de paquets.

Ce n'est pas une si mauvaise idée que ça, au moins ton NAS n'aurait pas besoin de transcoder. Tu as déjà essayé ?

Ah oui c’est vrai, le fameux transcodage. Ce n’est pas un processeur plus puissant qu’il faudrait, mais une unité de transcodage matérielle dédiée (GPU ?). Maintenant, est-ce qu’on appellerait toujours cet équipement un NAS ou est-c’est un nouveau type d’appareil à inventer ? C’est bien ce que je dis, c’est abstrait (même pour toi). Il m'étonnerait que la longueur du câble représente une quelconque économie. De plus il s’agit de la longueur du transformateur jusqu’au connecteur d’alimentation du NAS. Mais c’est vrai que ça peut être plus ou moins pratique selon l’environnement dans lequel le NAS est installé.

Dans le sondage, quelle est la différence entre : Oui, 50€ max et Oui, moins de 50€ ? 😜 De la puissance c’est bien, mais pour quoi faire ? Moi je trouve très bien d’avoir un appareil qui consomme et chauffe très peu et de pouvoir le laisser fonctionner 24h/24 en silence. Mais tout cela reste subjectif. Le prix chez Synology est plus lié au logiciel qu’au matériel. C’est un concept plutôt abstrait pour beaucoup, mais c’est la réalité.

Cela peut venir du lien heartbeat qui ne serait pas établi en direct, ou d'un changement d'état du hardware d'un des deux NAS (un des ports LAN qui subirait des coupures par exemple). Comme l'a déjà dit @Mic13710, il vaut mieux que le support officiel constate le souci des fois qu'il serait nécessaire de le corriger avec une mise à jour de DSM.

Je savais bien que j’avais raté un épisode.

Si j’ai bien compris, tous les disques de 4To vont se retrouver dans le nouveau NAS ? Pourquoi ne pas simplement monter tous ces disques dans le nouveau NAS ? https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General_Setup/How_to_migrate_between_Synology_NAS_DSM_5_0_and_later

Comme ton problème n'a rien à voir avec Synology, je ne peux que te conseiller de te tourner vers le support Veeam : https://www.veeam.com/fr/support.html