Fenrir

En complément de ce qui a été expliqué par mes camarades, il faut aussi faire très attention au blindage. Un CAT5e de 80m en UTP aura beaucoup de mal à faire passer du 1Gbits s'il y a des parasites alors que le même CAT5e en STP le supportera sans soucis. Le blindage permet de limiter les interférences externes mais aussi la diaphonie. Ça permet aussi aux câbles de mieux résister dans le temps (très important lorsque les câbles passent dans des endroits peu accessibles, comme les combles ou entre des étages). Un autre point important, mono filament (ou monobrin) VS multi filaments (multibrin). L'atténuation est nettement moins élevée en mono filament, mais un mono filament ne doit pas (ou peu) être courbé, un multi filament lui ne doit pas excéder quelques mètres (environ 5m max, après il y a de la perte). =>mono filament dans les murs (prises femelles) / multi filament pour les cordons (prises mâles) Ensuite tu as le brin de masse, rarement pris en compte, pourtant très important (surtout maintenant que même les box commencent à faire du poe), bien sûr les équipements doivent être à la terre ... Enfin, un câble qui doit passer par l'extérieur (exposé au soleil ou à l'humidité) doit être choisi en conséquences. Si tu prends un câble d'intérieur pour une connexion exposée au soleil ou à l'humidité, en quelques mois ton câble va se déliter (ou au moins durcir) et donc finir par casser. http://www.nas-forum.com/forum/topic/53291-probleme-de-logistique-suite-a-déménagement/?do=findComment&comment=1319305070 Pour ce qui est des électriciens qui font du réseau ... il y a de tout, des bons, des moins bons et des mauvais.

Ça y est, tu as craqué J'en ai un au taf, il fonctionne très bien mais je passe mon tour pour chez moi. ps : il va falloir mettre ta signature à jour

Il s'agit de 2 systèmes différents. Le raid 10 (ou 1+0) est basiquement un raid 0 composé de 2 raid 1 avec une tolérance aux panne de 1 à 2 disques (si pas sur le même raid 1) Le SHR-2 est un raid 6 (avec un truc en plus permettant de mixer des tailles des disques différentes) avec une tolérance aux panne 2 disques Je ne recommande pas le raid 10 ni le raid 01 (et encore moins le raid 0) car ils n'ont plus vraiment d’intérêts depuis des années. DS1512+ : non DS115 : non

normalement mon script log ses actions dans un fichier (à spécifier en haut), regarde ce que ça raconte

Pourtant, il te suffisait de copier mon script et de le lancer en mode test via ssh. Je ne vois pas ce qui te bloque (outre le fait de ne peut être pas tout comprendre, mais pour ça on peut t'aider).

Tu peux mettre la même clef partout si besoin, les clefs ne sont pas liées à un login particulier.

Je n'ai pas de freebox récente, donc je ne sais pas comment est l'interface, mais de manière générale : désactivation de l'upnp suppression de toutes les règles de "forward" de port création des règles nécessaires et uniquement celles-ci

oui

En fait non, il veut un double de certains dossiers uniquement et ces dossiers sont chiffrés. Comme il est encore en 5.2, il doit se "contenter" de Sauvegarde et Réplication, mais si j'ai bien compris, il rencontre des soucis avec les dossiers chiffrés, d'où l'utilisation de rsync en direct. Ce n'est pas mon script ça

Tu peux créer une paire de clef pour un utilisateur et l'utiliser pour 50, c'est juste un choix d'organisation/sécurité.

c'est tout ? (mon vieux DS107+ allait plus vite) tes dossiers sont chiffrés ? si oui ça expliquerait le débit ps : si tu fais 25mo/s en filaire, n'espère pas faire mieux en wifi (donc ton 22mo/s est bon)

Ces tuto ont au moins le mérite de permettre de faire des réponses rapides

C'est pour ça qu'il faut aller regarder en ssh, ou alors tu dois faire un script propre qui log ses erreurs. Rien que ça est suffisant pour que ça ne fonctionne pas, les variables globales sont à proscrire (et je crois qu'elles ne font plus du tout géré par php).

Si tu lance ton script php en ligne de commandes (via ssh), ça donne quoi ? Sans message d'erreur ni même voir le script, personne ne pourra t'aider.

Entre 40 et 45mo/s avec mon petit portable mais c'est son cpu qui sature (core M), le nas était à 30%. Donc oui, tu dois avoir un soucis.

Depuis qu'ils ont sorti la version 8 en beta, ils proposent une application en lieu et place des version navigateur : Surveillance Station Client Elle fonctionne correctement, mais c'est effectivement dommage qu'ils n'aient pas sortie une version pure HTML5. J'espère qu'ils ne vont pas se dire que puisqu'ils ont un client lourd, pas la peine de chercher plus loin ...

NFSv3 : le mapping se fait sur les ID numériques NFSv4 : le mapping se fait sur les ID textuels et il utilise idmapd (il faut qu'il tourne sur le client et le serveur) Donc vérifie que tu es bien en v4 (il faut le forcer coté client) et que /etc/idmapd.conf est correctement configuré, pas contre il y a un risque de devoir se battre avec RPC (AUTH_SYS vs AUTH_NAME) Sinon il te reste 6 alternatives : utiliser kerberos : ça nécessite tout de même idmapd mais aucune idée de si c'est correctement géré sur le syno modifier les uid sur le syno et rester en v3 : je l’avais fait a une époque, ça fonctionne mais il ne faut pas oublier un seul chown (et osef pour es gid) modifier les uid/gid sur tes clients : tu les fais correspondre à ceux du syno (galère pour les groupes mais c'est faisable) utiliser l'annuaire ldap du syno : c'est lourd pour si peu de clients passer par smb : en smb3 c'est aussi rapide qu'en nfs, mais ça reste moins souple créer une passerelle : plein de manière de faire, mais ça veut dire avoir une machine allumée h24 rien que pour ça

Je vais te résumer la chose en quelques phrases : Une sauvegarde c'est un processus de copie à sens unique, de la source vers la cible uniquement, mais personne n'a le droit de supprimer de l'autre coté : La cible ne doit pas être en mesure de supprimer quoi que ce soit dans la source La source ne doit pas être en mesure de supprimer quoi que ce soit dans la cible Pour limiter l'espace consommé, la cible peut mettre en place des mécanismes de rotation. Dropbox, CloudStation Drive, onedrive, ... sont des systèmes bidirectionnel qui n'ont qu'un objectif, donner l'impression que les fichiers sont dans un seul est unique endroit, mais accessible de partout. Il faut donc les considérer comme tel, un espace "virtuel" unique où tout le monde peut créer/modifier/supprimer n'importe quoi, n'importe quand, de n'importe où. --------------- Dans ton cas, de ce que j'ai compris (mais je n'ai pas tout lu), tu souhaites sauvegarder automatiquement un certain nombre de fichiers depuis ton pc vers ton nas. C'est donc un système unidirectionnel qu'il te faut, pas un système de synchronisation. Tu souhaites aussi pouvoir revenir en arrière en cas d'erreur, il faut donc un système de sauvegarde incrémental. Tu as plein de logiciels qui font ça très bien (y compris des gratuits). Si tu tiens à avoir à la fois une version synchronisée ET un version de sauvegarde, le cout en espace disque sera obligatoirement de 200% minimum, par exemple avec un CloudStation + une sauvegarde.

C'est qu'il est têtu celui là Le Mr te dit que c'est le débit WIFI de ton installation qui limite ta vitesse. Qui plus est en branchant le nas sur un livebox, ça ne peut pas améliorer les choses. 72mbits ça fait à peu près 6mo/s ... Si tu veux plus rapide en WIFI, il va falloir passer à la caisse : borne wifi AC (100€) + vrai switch gbits (20€) + carte wifi ac pour ton pc (20€) Ou alors un câble rj45 : 5€

Un bon petit tuto qui devrait servir, juste une petite remarque dsa est déprécié, il faut choisir rsa ou ed25519

Si tu supprimes le compte DANS rsync (tu vires les lignes "auth users" et "secrets file"), alors rsync ne ferait plus d'authentification (il laissera passer tout le monde), c'est ce qu'a fait @Langer dans son Tuto. On le fait par exemple pour les serveurs rsync publiques (comme les miroirs des distribution linux, sauf qu'ils sont en lecture seule évidemment). Si tu supprimes le compte du serveur (/etc/passwd), alors tu ne pourras plus utiliser ssh. Les 2 sont dissociés. Il s'agit bien de 2 comptes qui n'ont aucun lien technique entre eux. Encore une fois, il y a plein de manière de se servir de rsync : en local : d'un dossier vers un autre serveur rsync : pas utilisé serveur ssh : pas utilisé chiffrement du transfert : non mais pas très utile en local (au sein de la même machine) authentification : aucune via un serveur rsync serveur rsync : utilisé serveur ssh : pas utilisé chiffrement du transfert : non, tout passe en clair authentification : éventuellement celle de rsync via un transfert ssh serveur rsync : utilisé mais lancé par le client au travers du tunnel ssh (pas besoin de le lancer en service) serveur ssh : utilisé chiffrement du transfert : oui par ssh authentification : ssh et éventuellement celle de rsync via un tunnel ssh serveur rsync : pas utilisé serveur ssh : utilisé chiffrement du transfert : oui par ssh authentification : celle de ssh uniquement et plein d'autres manière que je ne détaillerais pas ici (trop compliqué à vous expliquer) HyperBackup propose les 3 premières méthodes. Perso j'utilise plutôt la méthode 4, plus simple ou la 2 mais dans un VPN. Si tu regardes bien : 3=2+ssh 4=1+ssh Extrait de man rsync (c'est la méthode 3 dans mes exemples) : Je trouve ça très clair

Tout simplement parce que une authentification par clef est plus sûr qu'une authentification par mot de passe. Après on peut répondre qu'en mettant un super mot de passe (64 caractères aléatoires par exemple) c'est aussi fiable, j'ai 3 réponses à ça, sans même chercher : si tu autorises les connexions par mot de passe, tous les autres comptes de ton serveur sont potentiellement accessible par mot de passe, donc même si ton compte de backup est super blindé, rien ne dit que les autres le seront tout autant se connecter avec une clef c'est techniquement comme utiliser un mot de passe de la taille de la clef, soit 4096 bits en général, nettement plus de caractères que tu ne peux en mettre dans un mot de passe en lassant l'authentification par mot de passe, tu invites les scanner à lancer des attaques par dictionnaire ou brute force (elles ne passeront pas avec un super pass, mais ça va consommer bcp plus de ressources que si seules les connexions avec clef étaient autorisées) Après tu as tous les aspects confort et ré-utilisabilité, un même compte peut accepter plusieurs clefs, mais un seul mot de passe, ce qui ouvre plein de possibilités. petite précision sur ce point précis, tu as 2 utilisateurs : un compte rsync un compte linux (utilisé par ssh) Si tu as mis le même login+pass sur les 2 (c'est mal mais Syno ne laisse pas le choix ... visuellement), tu ne peux pas t'en rendre compte.

Le login/pass que demande le syno sert surtout à rsync, mais le compte rsync de le compte ssh ne sont en fait pas liés. En utilisant une clef, vous protégez l'accès à votre serveur ssh, le serveur rsync lui n'a pas besoin d'être autorisé depuis internet => bcp plus sécurisé Donc login+clef pour le ssh et login+pass pour rsync. Le seul soucis c'est que syno ne permet pas de mettre un login ssh différent de celui du rsync, c'est ce qui a du vous perturber.

Pour la peine, tu nous fais un tuto ici http://www.nas-forum.com/forum/forum/28-tutorials/ ?

Autre façon de faire : #!/bin/php en entête de ton fichier, sinon le shell ne peut pas savoir quoi utiliser