lordtaki

Comme d'habitude... attention le mirroir (ou RAID1) n'est pas une vraie sauvegarde. C'est une tolérance de panne d'1 seul disque sur les 2 qui composent le RAID1. C'est rare, mais déjà vu une fois en milieu professionnel, que le 2e disque tombe aussi en panne avant que le premier disque soit changé et le mirroir reconstruit.

Bonjour Anna, c'était un transfert local au NAS ou entre votre poste de travail et le NAS?

Allez dans le gestionnaire de disques, quelle est la taille de votre volume? Un screenshot pourrait nous aider.

Quid de l'historique des logs des disques?

Avec cette lecture vous comprendrez mieux je pense: https://www.randco.fr/blog/2012/gestion-de-la-ram-sous-linux/ Vous avez quasiment 4.4Go de buffer/cache, à part pour le plaisir je ne vois pas l'intérêt d'augmenter la RAM.

Le fameux buffer/cache (voir commande top ou free) :)

Bonjour, cette fonctionnalité n'est pas disponible avec DownloadStation.

J'imagine que vous essayez de le faire sur vos postes via un montage NFS ou équivalent. Le lien physique ne pourra être fait à priori que depuis le NAS, donc connection SSH et le lien hard sera possible.

A part éduquer les utilisateurs :)

Oui donc du coup il n'y a pas de soucis j'ai l'impression :D

Vous pouvez aussi restreindre l'accès au port 22 à une IP particulière. Il y a aussi fail2ban pour bloquer les scans sauvages.

http://www.iholken.com/index.php/2016/07/22/guide-for-installing-fail2ban-for-synology-nas-devices-and-configuring-it-for-web-services-like-owncloud-or-wordpress/ Vous pouvez commencer par renseigner ingoreip avec les adresses IP de confiance. Ensuite, si vous vous connectez d'une adresse ip inconnue, il reste toujours la fenêtre de recherches (findtime), le nombre d'essais (maxretry) pour faire le tri entre vous et une attaque.

Fail2ban si jamais il y a un package pour syno. Sinon les possibilités du firewall ne suffisent pas?

Il n'y a pas d'ordre à suivre tant qu'on ne touche pas au répertoire @download via un terminal. Comme dit le sujet a déjà été couvert sur les hard links mais je vais essayer d'expliquer encore via ce thread. Pour commencer le contexte: le dossier de destination des fichiers complétés de Download Station (pour faciliter la lecture on va l'appeler COMPLETE) est sur le même volume que le répertoire caché (@download) de Download Station. Typiquement cela se traduit par: COMPLETE est sur le volume1. Les liens hard ne fonctionnent que sur le même filesystem, donc impossible entre 2 volumes. Tant qu'un fichier n'est pas completé on ne le voit pas via File Station dans COMPLETE, on peut voir le fichier temporaire dans @download. Une fois le téléchargement terminé, le fichier est complet dans @download (il utilise XXX Mo), Download Station fait un lien en dur (hard) de ce fichier dans le répertoire COMPLETE. Conséquence? Le fichier est visible dans COMPLETE via File Station, on ne peut pas différencier les 2 fichiers et cela n'utilise toujours que XXX Mo (et non 2 * XXX Mo si cela avait été une copie par exemple). Ceci permet en fait à l'utilisateur lambda de bidouiller comme il veut le fichier visible dans COMPLETE sans impacter par exemple le seeding (protégé dans @download). Pour supprimer le fichier dans @download, il faut supprimer le téléchargement dans Download Station. Il restera alors le lien en dur dans COMPLETE, qui utilisera toujours XXX Mo. Inversement, supprimer le fichier dans COMPLETE se fait avec File Station et il restera le lien en dur dans @download et la tâche dans Download Station, qui utilisera aussi XXX Mo. Faire les 2 actions ci-dessous, dans n'importe quel ordre, et on récupère les dits XXX Mo. Une explication sur les liens hard: http://davidmasclet.gisgraphy.com/post/2009/12/22/Différence-entre-un-hard-link-et-un-lien-symbolique

Netflix optimise à mort, c'est peut-être du 1080p mais il n'y a pas que la définition qui compte, le bitrate a son importance (plus ou moins compressée). Ensuite, revoir peut-être la configuration de Plex pour s'assurer que le serveur ne transcode pas. Enfin le client final que vous utilisez peut avoir du mal selon le codec et le bitrate aussi.

Comme expliqué l'ordre de vos actions peut avoir son importance. Normalement: - suppression du torrent en seed via l'application Download Station (ceci supprime la référence du fichier dans @download) - suppression du fichier téléchargé dans l'application File Station dans le répertoire de destination des téléchargements complets (ceci supprime l'autre référence du dit fichier et libère normalement l'espace disque) Je soupçonne que vous ayez d'abord supprimé directement les fichiers dans @download. Dans ce cas, l'espace disque n'est pas libéré tant que Download Station ne sera pas redémarré (dans un terminal : lsof | grep deleted confirmera cette théorie). Le sujet a été abordé plusieurs fois déjà sur le fonctionnement interne de Download Station et des hard links linux.

Bonjour, parce que c'est le fonctionnement normal de Download Station si vous aviez des torrents en seeding. Le répertoire @download est caché pour éviter de mauvaises manipulations des utilisateurs moins expérimentés que des experts. Si vous aviez un Download Station vierge ce n'est par contre pas normal.

J'ai justement mis un lien à ce sujet.

Il ne manquerait pas ':" entre IP et le / de la racine pour target?

Si c'est pour maximiser le support Synology alors prendre dans ce cas le tout dernier. Mais vu que le besoin est de faire du backup rsync... sécurisation maximale pour ce nas de backup qui autorise uniquement l'adresse IP du nas source à se connecter en ssh et la question des maj de sécurité se posera moins.

Ce sont les dépendances du service. Comment est-ce que cela pourrait être plus simple? Vu le critère d'arrêt cela ne peut pas être planifié.

Il faut planifier une tâche qui lancera un script. http://www.kitpages.fr/fr/cms/148/scripter-des-acces-ftp-avec-bash

Vous voulez parler de RAID1?

Donc le script est dans Volume1/web/dossier/ ... Il faudrait vérifier la configuration de Webstation et surtout celle de php.

Je ne connais pas les box Orange, mais j'utilise google :) Avant de poursuivre, puisqu'il s'agit d'accéder depuis l'extérieur à votre NAS, je vous conseille la lecture de ce tutoriel: Ensuite vous pouvez suivre ce tutoriel Synology: https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General/How_to_make_Synology_NAS_accessible_over_the_Internet Je déconseille QuickConnect et je connais pas EZ-Internet, j'ai fait manuellement (point 4). Côté Livebox, il faudra configurer la redirection de port (ie NAT): https://assistance.orange.fr/livebox-modem/toutes-les-livebox-et-modems/installer-et-utiliser/piloter-et-parametrer-votre-materiel/le-parametrage-avance-reseau-nat-pat-ip/configurer-des-regles-nat-pat/livebox-2-configurer-les-regles-nat-pour-l-utilisation-d-un-jeu-ou-d-une-application-serveur_18998-19118 Pour que le port X du NAS (local) soit accessible depuis l'extérieur (internet) il faut indiquer à la livebox que le dit port X doit être redirigé vers l'adresse IP locale port X du NAS (d'où la nécessite d'avoir une attribution d'IP statique via la MAC adresse).