Fenrir

il faut effectivement scripter si tu veux automatiser HyperBackup utilise rsync, pas ftp ----- Si tu tiens absolument à le faire en FTP (c'est sale), tu peux utiliser un petit script, un truc dans le genre : #!/bin/bash HOST='ton serveur joomla' USER='login' PASS='password' FTPURL="ftp://$USER:$PASS@$HOST" LCD='/volume1/partage/dossier/source' RCD='/dossier/de/destination' #DELETE='--delete' #DELETE='--delete' DELETE='' lftp -c "set ftp:list-options -a; open '$FTPURL'; lcd $LCD; cd $RCD; mirror --reverse \ $DELETE \ --verbose"

Plein de manière de faire mais qui dépendent de tes connaissances. Le plus simple (mais pas ma recommandation) c'est de "monter" ton site en FTP avec FileStation. Le plus fiable c'est de faire un petit script lancé en tache planifiée qui fait un rsync de ton dossier source vers ton dossier de destination. Entre les 2 tu as la possibilité d'utiliser HyperBackup (dernière destination dans la liste). Ça fait aussi du rsync. Après tu as toutes les méthodes "custo", par exemple : le syno a un interpréteur php, tu devrais donc pouvoir coder un petit script qui se connecte aux api de joomla un petit script coté joomla pour aller chercher les fichiers un point de montage cifs/nfs entre les 2 un petit scp planifié ...

Très bon tuto, juste une petite astuce pour aller plus lors du chargement de l'image => ipxe

Il est possible que l'appli ne sache pas se servir des cartes SD. Je n'ai pas de carte dans mon téléphone, mais je pense qu'un lien symbolique devrait marcher.

Mettre l'interface UP ça ne veut pas dire qu'elle est connectée (tu peux faire ifup sur un carte réseau sans câble). iwconfig ...

Ça ressemble à un bug. Essaye de créer un autre dossier, plus loin dans l'alphabet, que ton dossier qui disparait.

Et en lisant (ou en copiant) un film sur un pc via les partages réseaux, pas de soucis ? Comme indiqué par @Lucien77, il faudrait aussi tester sans le switch. Vérifie également un éventuel conflit d'ip.

Test depuis un PC via vlc et via videostation. Si tu n'as pas de soucis, ce n'est pas le nas le pb, si ça fige encore, vérifie les disques. Regarde aussi la ram et le cpu du nas pendant la lecture d'un film, en particulier au moment des pb d'image

Commence (au moins le temps de tester) par fermer tous les ports autres que celui du VPN => tu n'accèdes plus au nas sans connecter le vpn, c'est que c'est bon Tu peux aussi jeter un coup d’œil à ça : http://www.nas-forum.com/forum/topic/53328-vpn-server/

ça dépend du format du disque. si tu n'as rien dessus, tu peux le formater depuis le nas (dans périph externes)

Avant de connecter le VPN, vérifie ton ip public (il y a plein de site pour ça, par exemple ici) Puis connecte toi et regarde si ton ip public a changé sur le site Normalement tu devrais avoir la même ip que depuis chez toi. De plus, si tu n'as pas forwardé d'autres ports que ceux du vpn vers ton nas, tu ne devrais pas pouvoir accéder aux fichiers dans le vpn

C'est comme quand tu regardes une vidéo (un mkv sur ton pc, une vidéo sur le net, une vhs dans le magneto de mamie), l'écran t'affiche les images une par une (au rythme de 25 par seconde en général), pas toutes d'un coup. En pratique ce qu'il se passe c'est que les "blocs de données" créés par le tar de gauche sont envoyés au fur et à mesure (stream) dans le tunnel ssh et réassemblés à la volée par le tar de droite. Pour faire une analogie, imagine que tu as plein d'objets à passer d'une pièce à l'autre. Tu peux le faire de plusieurs manières : tu ramasses un objet, tu vas le placer dans l'autre pièce, tu reviens et tu recommences => ça c'est ta méthode (scp -r /toto/* login@destination:/titi/.) tu mets tous les objets dans un carton que tu emportes de l'autre coté avant de le vider => c'est déjà plus rapide mais il faut de la place pour le carton tu mets tous les objets sur un tapis roulant qui débouche de l'autre coté => on peut difficilement être plus efficace et pas besoin de carton Pour le détail de la commande et sa syntaxe regarde ici

sync ne renvoi rien, c'est normal, il dit juste au système : "si tu as des écritures en attente, termine les" - un peu comme un commit/rollback sur un base

ça existe déjà (cf mon précédent post), ça ne s’appelle juste pas cp pour ne pas entrer en conflit avec la commande de base et rien ne t'obliges à compresser (ce qui n'a pas d’intérêt pour de la video, de la zik, des png, ...) en pratique c'est "streamé", donc à aucun moment tu n'as un gros fichiers (même en ram) qui se créé nb : ça ne marche qu'avec tar ou équivalent (par exemple dar), il ne faut pas essayer avec zip, rar, 7z, bz, gz, ... sous windows on peut utiliser cygwin, ça marche, mais bof ...

Plutôt que de le faire à la main et de rater un truc (chemin/droits/copie/...) : ssh-copy-id -i /chemin/vers/ta/clef login@serveur

uninterruptable => qui ne peut pas être interrompu Sauf très rares exceptions, c'est un appel en ring0, parfois en ring1 (aucun rapport avec H. Nakata ... quoique ...). C'est presque toujours lié à une actions qui attend un retour d'IO => la piste du disque se confirme. Tu peux tenter de faire un sync (c'est une commande) au cas où le soucis serait lié à ton gros mouvement. Regarde aussi du coté de /proc/mdstat Mais surtout => vérifie tes sauvegardes

ba si tu as compris Les "vrais" homes des utilisateurs sont déclarés dans /etc/passwd. Par défaut sur un syno, ils sont dans /var/services/homes (sauf pour root qui est à sa place, dans /root).

=> /var/services/homes/admin

Le LOAD n'est pas nécessairement lié à de la charge CPU, le load indique (à peu de choses près) le nombre de processus en attente dans la file de traitement. Il peut y avoir plusieurs causes, les plus fréquentes sont : utilisation cpu : ça n'a pas l'air d'être ton cas latence disque => un disque fatigué ou entrain de lâcher peut vite faire monter la charge utilisation mémoire : ce n'est pas lisible sur ta vue, mais comme tu ne swap pas ça doit être ok réseau : c'est rare qu'un process se bloque à cause de ça ... tout autre composant matériel/logiciel mal utilisé : presque aucune chance ps : htop c'est sympa, mais ce n'est pas très pratique pour déboguer, il vaut mieux utiliser ps (par exemple avec ps -eo state,pid,cmd | grep "^D")

ce n'est pas un système de Google => OTP Pas de soucis chez moi avec la double authentification et firefox (je n'utilise pas d'autre navigateur) : login + password => je valide code à 6 chiffres => je valide Commence par tester avec une autre machine (pc, tablette, ...)

non, je veux bien dire 5h50, soit bien après l'heure fatidique de 4h50

en faisant ça, tu donnes accès à ton nas (et par extension à tout ton lan) à, au minimum, tous les admin de ton VPN et, potentiellement, à tout ou partie de ses autres clients. Un VPN c'est un tunnel, comme pour un vraie tunnel, quand on est à l’extérieur, on ne voit pas ce qui passe dedans, mais on peut facilement aller d'un bout à l'autre si on a accès à l'une des entrées

Si (c'est un gros si) les fichiers du pc distants sont accessible via le réseau et que tu arrives à les montrer à rsync sur le nas, le plus dur est fait, rien à configurer coté client.

Tu as testé à 5h50 ? Si ça marche c'est top comme bug.

Faux. L’agrégation de lien ne s'amuse pas à couper 1 paquet sur 2 pour les faire passer par l'une ou l'autre des cartes réseau, sinon imagine la charge CPU (ou des ASICS) sur les différents équipements (ton pc, le switch, le nas) pour couper/réassembler les morceaux de paquets. Déjà qu'on perd pas mal de temps à réassembler les fragments de 1500o (d'où l’intérêt du jumbo frame), alors qu'ils sont numérotés et qu'ils arrivent dans l'ordre, si on devait le faire sur 2, 3 -> 8 fois plus de morceaux, dans le désordre et sans avoir les n° de séquence, il faudrait des monstres de puissances. Donc je répète, il faut au moins 2 clients (comprendre 2 machines clientes) pour en profiter. 1 client avec 8 cartes 1gbits utilisera toujours la même carte dans un dialogue avec un serveur lui aussi en 802.3ad. Après, avec un peu de tuning, on peut faire passer certains protocoles (comprendre n° de port) par telle ou telle carte, mais jamais par plus d'une à la fois. Donc avec un super tunning, tu peux faire du FTP à 1gbits + du SMB à 1gbits, mais pas du FTP ou du SMB à 2Gbits. Perso je fais aussi souvent ça en ssh, c'est tellement plus simple que les autres manières de faire (sauf quand j'ai des gros volumes à balader). Elles pourraient, mais dans ce cas ça ne serait plus les mêmes binaires (pour info, cp n'est pas un programme au sens où tu l'entends, il faut plus voir ça comme une fonction de coreutils (sous GNU Linux), qui doit répondre à certains impératifs très bas niveau et des contraintes POSIX fortes). Changer cp (ou quelques autre outils du même genre), ne serait ce que pour ajouter une option, peut avoir d'énormes répercutions sur le reste du système. Enfin, KISS (Keep it simple, stupid) reste un des principes fondamentaux pour avoir un système stable. Le calcul de l'avancement dépend fortement du système de fichiers, du type de stockage et du cache des disques. Pour chaque "morceau" (bits/bytes/inode/bloc/... ?) il faudrait enregistrer en ram (donc prendre des ressources) sa taille, faire la somme de ce qui est déjà passé (encore un bout de ram qui s'envole), faire le ratio de la taille totale (ram), créer l'affichage (ram), le transmettre au terminal (ram), que le terminal le dessine (tu as combien de caractère de large dans ta console ? il se passe quoi en cas de redimensionnement ? ...), puis tout recommencer pour mettre à jour la barre ... C'est con ce qu'une bête commande copie de fichier doit faire pour afficher des choses et encore, je n'en ai pas listé le quart. Par contre rien ne t’empêches d'utiliser l'un des X programmes de copies qui peuvent prendre le temps d'afficher une estimation de la progression (mc, bar, advanced-copy, gcp, curl (oui il peut copier des fichiers) ...) perso j’utilise rsync quand j'ai besoin de suivre l'avancement d'une copie locale. A titre d'illustration sur le cout de l'affichage : tar cf /tmp/etc.tar /etc cd /tmp ########### je n'affiche rien time tar xf etc.tar real 0m0.088s user 0m0.015s sys 0m0.070s ########### j'affiche la progression time tar xfv etc.tar real 0m0.292s user 0m0.054s sys 0m0.198s ########### j'enregistre la progression dans un fichier , sans l'afficher time tar xfv etc.tar > 1 real 0m0.129s user 0m0.034s sys 0m0.092s Dans le même genre, dès qu'on a beaucoup de fichiers à déplacer via le réseau, il est très vite plus rapide de faire une archive, de la copier (ou de la streamer) puis de l'extraire que de copier les fichiers directement, surtout en ssh => tar zcf - toto | ssh login@destination "cd /titi && tar zxf -" Rsync sert principalement pour de la copie de gros volumes de fichiers, en particulier car il est capable de reprendre là où il s'est arrêté (crash, coupure réseau, interruption utilisateur, ...). ps : au cas où ... j'ai pris le temps de répondre avec pas mal de détails à ta question car elle cache plein de choses super intéressantes (avis très subjectif) si on s’intéresse au fonctionnement d'un système d'exploitation et aux perfs.