Fenrir

Il te suffit d'écrire un petit script, du genre : #!/bin/bash PATHtmp=/volume1/video/temp/*.avi for file in $PATHtmp do echo "Convert $file..." ffmpeg [les options qui vont bien] -i $file ... $file.mkv mv $file.mkv /volume1/video/ok/. mv $file $file.done done

Attention à ne pas faire de confusion entre un codec (h264, xvid, ...) et un conteneur (avi, mp4, mkv, ...). Si tu veux juste changer le conteneur (avi -> mkv), tu peux le faire avec le nas sans soucis. Si tu veux transcoder des vidéos (passer de xvid à x264 par exemple), le nas va prendre cher en CPU : pour une vidéo de base (un film en SD), la nas va probablement travailler plusieurs heures là où un PC mettrait une dizaine de minutes. Perso je converti mes vidéos en x264 (conteneur m4v ou mkv) sur mon PC (avec handbrake en général) avant de les copier sur le nas. Si tu tiens vraiment à la faire sur le nas, tu as des exemples ici : https://trac.ffmpeg.org/wiki/Encode/H.264

Si la méthode de magicIdea (qui est la plus simple/fiable) n'est pas possible, il faut simplement t'assurer que tu copie les fichiers en USB au bon endroit sur la destination Je te recommande d'utiliser un disque avec le même système de fichier (ext4 pour un syno) Quand j'ai besoin de faire ça, je lance d'abord une première synchro à vide ou presque (je laisse la structure des dossiers et quelques petits fichier témoins), si c'est bon, je refais le rsync complet sur le disque externe avec les mêmes paramètres (sauf l'adresse du serveur !!)

welcome

Il s'agit de TAG (auteur, titre, commentaires, ...) qui sont embarqués dans la plupart des fichiers multimédia. C'est utiliser pour bien identifier un média, dans le cas des médias tombés du camionloud, on y retrouve les tag des personnes qui ont créé le fichier Perso je les retire

pour faire court : ça permet d'avoir un produit clefs en main pour le grand public (les gens copient les photos dans /photo et pouf, elles apparaissent dans PhotoStation, idem pour la music, ...) Si tu n'utilise le Syno que comme un nas, ils ne servent pas à grand chose. Mais le Syno embarque plein d'autres fonctions (VideoStation, PhotoStation, DLNA, ...), qui, par défaut, utilisent ces partages pour fonctionner Je m'étais fais la même réflexion avec mon 1er Syno : l'utiliser uniquement comme un nas ou me servir des autres fonctions Au final j'ai choisi d’exploiter le Syno en entier, pas seulement sa fonction nas, et je ne le regrette pas (par exemple pour avoir les photos sur un grand écran et mon téléphone sans avoir à passer par un cd ou une clef usb ou ...) A noter que PhotoStation peut utiliser Flickr De plus tu ne peux pas supprimer ces partages, donc autant les utiliser, ou les laisser vide. Mais dans tous les cas ils ne sont pas gênants. A titre perso, je n'utilise pas le /photo, mais le /home/photo (comme ça chaque utilisateur gère son PhotoStation) par contre toute la musique est dans /music. Chacun son usage Oui Mais je ne te recommande pas de le faire comme ça De manière général (ce n'est pas lié au Syno), ce qui est dans home (ou /homes/user) ne doit être accessible qu'à 1 utilisateur (hors admin) Ce qui est commun à plusieurs utilisateurs doit être stocké ailleurs et accessible aux utilisateurs d'un groupe =>il ne faut pas mettre de droits sur des sous dossiers, ça devient très vite ingérable (on ne sait plus qui qui accède à quoi) ex : /homes/fenrir : n'est accessible qu'à l'utilisateur fenrir (qui peut très bien, de son propre chef, décider de rendre accessible ses photos à tout le monde via photostation) /music : est accessible à tous les membres du groupe "grp-photo" (en général on créé 2 groupes, 1 en lecture seul et 1 en lecture+écriture) Pour reprendre ton exemple, stock tes photos dans /photo et gère les droits à ce niveau Maintenant c'est ton NAS , tu peux le gérer à ta manière (puis comme c'est du Linux, tu peux faire presque tout ce que tu veux) edit : pour la manip que je propose avec Hubic, ça à peut de chose près ce qui est fait sur un Mac avec certains dossiers

J'ai fait le test, on ne peut effectivement utiliser qu'une seule fois Hubic par compte, dommage... mais il y a d'autres manières d'arriver à ce que tu veux, à condition d'accepter de mettre un peu les mains dans le cambouis et de bien comprendre ce que l'on fait En informatique, les barrières ne sont, en général, qu'un manque de connaissances (ce n'est absolument pas une critique ni péjoratif). J'aime à penser que ceux qui s'offrent un Syno (ou équivalent) ont de la curiosité et l'envi d'apprendre Voici un exemple qui marche (je l'ai testé en écrivant ce message) si tu veux jouer On monte les partages à synchroniser (music, photo, video, ...) dans un même dossier et on synchronise ce dernier avec Hubic 0-Créé un compte Hubic de test afin de ne pas toucher à tes données déjà synchronisées En Web sur le Syno 1-créé 3 partages pour tester : test, testdocuments et testimages test est un vrai faux partage que l'on va utiliser uniquement pour la synchro testdocuments représente l'un de tes partages testimages en représente un autre 2-place les bons droits dessus 3-n'active pas l'indexation sur le partage test 4-dans le partage test, créé 2 dossiers : testdocuments : on va se servir de ce dossier pour "afficher" le contenu du partage testdocuments testimages : on va se servir de ce dossier pour "afficher" le contenu du partage testimages 5-masque le partage test (Hide this shared folder in "My Network Places"), ce n'est pas obligatoire mais je te le recommande 6-copie quelques fichiers dans les partages testdocuments et testimages histoire d'avoir un peu de contenu 7-en SSH sur le Syno, entre les commandes suivantes : mount --bind /volume1/testdocuments /volume1/test/testdocuments mount --bind /volume1/testimages /volume1/test/testimages =>tu devrais voir le contenu des partages testdocuments et testimages dans les dossiers testdocuments et testimages du partage test 8-configure CloudSync pour synchroniser le partage test en entier vers Hubic Si tu as bien compris la manipulation et que ça te satisfait, tu n'as plus qu'à adapter les partages/dossiers La commande mount n'est pas persistante au reboot, si tu veux que ce montage soit permanent, il faut créé un petit script qui fasse cette action au démarrage du Syno (tu peux aussi modifier le fstab, mais ce n'est pas recommandé sur un Syno) ps : la commande pour démonter, c'est umount suivi du point de montage (par exemple : umount /volume1/test/testdocuments) pps : monter A dans B ça veut dire rendre disponible le contenu de A dans B

Je pense, mais je n'ai pas testé, que tu peux créer plusieurs profils CloudSync avec le même compte Hubic sur le Syno Ce que je ferai (sous réserve que ce soit possible) : 1-sur Hubic : création de dossiers correspondants aux partages du nas 2-sur le nas : 1 profil par partage, synchronisé avec le dossier correspondant chez Hubic Ce qui est certain par contre, c'est que Syno ne te permet pas de synchroniser tout un volume car les applis et certains paramètres du Syno sont stockés dans ce volume (tu ne peux les voir qu'en ssh), mais surtout, permettre de synchroniser tout un volume nécessiterait une gestion des droits trop complexe (n'importe quel utilisateur pourrait synchroniser tous les partages, même ceux auxquels il n'a pas accès, et donc y accéderait in fine)

Si Synology a correctement fait son travail, tu ne peux rien faire sans le mot de passe ou la clef privée. Pour rappel, cette a été téléchargée automatiquement quand tu as créé ton partage chiffré Avec un peu de chance elle est dans donc dossier "Téléchargement" de ton navigateur, ou dans un backup ...

merci pour l'nfo, comme j'utilise mes propres certificats je n'avais jamais fait attention à l'emprunte de celui par défaut.

il suffit de regarder comment est signé le certificat par défaut perso j'ai ma propre pki et je créé des sha256 (donc sha-2) sans soucis

Pour le mail, il faut vérifier qu'il y a bien un client mail sur le syno, sinon tu peux le faire avec un telnet. Pour le log, c'est le RM à la fin qui doit faire le ménage. Pour les stats, regarde les options de rsync, il y a tout ce qu'il faut.

à la fin de ta commande, tu peux déclencher d'autres opérations. ; & et && permettent d'enchainer des commandes commande1 ; commande2 #commande2 sera lancée quand commande1 sera terminée commande1 & commande2 #commande2 sera lancée juste après le lancement de commande1 commande1 && commande2 #commande2 sera lancée si commande1 se termine sans erreur commande1 && commande2 ; commande3 #tu peux les enchainer à volonté Mais il est plus propre et plus souple de faire un petit script #!/bin/bash fichierlog='/tmp/rsync.log' email='ton@adresse.mail' #la commande rsync avec toutes les options qui vont bien rsync ... > $fichierlog cat $fichierlog | mail -s "fini" $email rm $fichierlog Sinon, en fonction de ce que tu souhaite sauvegarder, rsync n'est pas forcement la meilleur des options. Perso je fais des archives que je sauvegarde via download station en https. J'ai fait 2 petites docs ici : http://blog.fenrir.fr/tag/sauvegarde-2/

c'est un peu brutal comme réponse, même si c'est vrai dans le cas présent iSCSI n'est pas fait pour être utilisé sur des liens non fiables, comme la plupart des protocoles en mode bloc Les liaisons WAN (Internet) état rarement très fiable, il vaut mieux éviter à moins d'avoir de quoi faire du multipath (peu probable dans ton cas) C'est par contre parfaitement adapté pour un usage entre datacenter avec des liens fiables et redondés iSCSI est un protocole permettant de faire transiter du SCSI sur IP, il s'agit donc de faire transiter des informations de lecture/écriture de bloc disque. S'il y a la moindre perte de paquet qui n'est pas compensée par la couche IP, il y a une très forte probabilité de corrompre les données. comme il s'agit d'écrire des blocs, il faut un système de fichiers adapté pour l'utiliser à plus de 1 machine en même temps. Par exemple ocfs, gfs, ... NTFS ne le permet pas, d’ailleurs à ma connaissance il n'y a aucun système de fichier compatible Windows qui le permette C'est pour ça qu'il existe de systèmes de fichiers réseau (CIFS, NFS, AFP, ...). Je te recommande d'utiliser un système de fichier réseau (CIFS si c'est du Windows, NFS sinon) pour ton besoin, idéalement au travers d'un VPN site à site Tu as tout ce qu'il faut dans le syno pour ça.

J'ai souvent lu la même chose sur différents sites/forums, mais ils n'indiquent que trop rarement les conditions EXACTES des tests. Si le PC qui fait les tests a un lien 1Gbtis, même avec un NAS à 10Gbits tu ne dépasseras pas les 1Gbits. C'est toujours le maillon le plus faible lent qui donne le ton. Je n'ai pas testé l'aggregation avec un syno, mais j'en utilise quotidiennement au boulot et j'obtiens facilement des débits bien supérieurs à ce qu'un simple lien permet. Il y a différents type d'aggregation, le débit dépend des réglages, du matériel, de l'OS et du logiciel de copie utilisé. Par contre, dans la pratique et en conditions "home user", il est rare de pouvoir dépasser les 1Gbits/s car il faut : 1-un nas qui dispose d'au moins 2 cartes 1Gbits en 802.3ad et de disques suffisamment rapide (plus de 100Mo/s) 2-un pc qui dispose d'au moins 2 cartes 1Gbits en 802.3ad et de disques suffisamment rapide (plus de 100Mo/s) 3-le tout connecté à un switch qui gère l'agreggation et qui a un fond de panier supérieur au débit escompté 4-et d'un logiciel de copie qui gère le multiplexage Autant dire qu'on ne rencontre pas ça chez les Michu =>donc comme l'indique PiwiLAbruti, il y a peu de chances que tu en ai le besoin et que tu puisse en profiter.

Vérifie qu'il n'y ait pas d'erreurs sur le dd du syno (info smart), voir sur le syno lui même (dans les logs)

fais le même test avec un autre pc

ça ressemble à des pertes de paquets les causes les plus fréquentes sont : -câble défectueux -interférences : proximité d'un câble courant fort, d'un haut parleur ou d'un équipement électroménager avec l'un des maillons de la chaîne -carte réseau défectueuse -problème de mtu Il faut tester chacun des morceaux de ton installation (pc/câbles/switch/syno) Le plus simple pour tester : -configure une ip fixe sur le syno, par exemple 10.0.0.1/255.255.255.0 -configure une ip fixe sur le pc, par exemple 10.0.0.2/255.255.255.0 -branche les 2 en direct avec un câble de bonne qualité et pas trop long (selon le pc, il faudra peut être un câble croisé) -test Si tu n'as pas de soucis dans cette configuration, tu peux mettre hors de cause le pc et le syno. Il faudra alors tester le reste (en particulier les interférences et les switch)

En pondérant par la compatibilité des disques, tu devrais pouvoir utiliser tes anciens disques dans un synology. En écriture c'est le raid 5 qui consomme le plus de ressources car il faut faire des calculs de parité. Par contre le radi5 permet d'avoir des volumes plus grand. Pour faire un volume de 4To raid 1 : 2 disques de 4To - un disque entier sert à la redondance raid 5 : 3 disques de 2To - 1/3 de chaque disque sert à la redondance (le shr ou shr2 permet d'utiliser des disques de tailles différentes sans perdre trop de surface) Dans ton cas tu peux faire : raid 1 : 2* 2 disques de 4To => 8To dispo, deux volumes de 4To, chacun avec un disque pour la redondance raid 5 : 4 disques de 4To => 12To dispo, un volume unique de 12To et 1disque pour la redondance raid 6 : 4 disques de 4To => 8To dispo, un volume unique de 8To et 2 disques pour la redondance Si 8To te suffisent et que les perfs ne sont pas le principal critère, le raid6 est un excellent choix car hautement secouru. Ensuite il y a l'éternel débat raid mirroir VS raid parité : mirroir (raid1, raid 10) : en cas de crash il est possible de récupérer les données depuis un ordi parité (raid5, raid6, ...) : en cas de crash, c'est presque impossible Utilise le comparateur de raid (sur le site support synology) pour te faire une idée. Pour le boitier, il semble intéressant pour un usage domestique. Pour ta dernière phrase, il n'y a qu'une seule solution : faire des backups et les stocker ailleurs (chez des amis, la famille, à la banque si tu as un coffre, ...)

les cartes réseaux du Rasp n'ont pas de PXE, donc pour faire du PXE il faut d'abord booter le rasp sur un pre-os (un syslinux par exemple) qui se chargera de récupérer l'OS ailleurs (par exemple en tftp sur un syno). mais c'est inefficace (pas assez de ram sur un rasp pour faire ça efficacement) et lent (la carte réseau ne dépote pas assez) concernant ton problème de carte, je ne sais pas comment tu t'y prends pour les flinguer :s j'ai un rasp allumé H24 depuis plus d'un an, il me sert entre autre de miroir Debian (donc lecture/écriture importante) et aucun soucis. Pour l’anecdote il est alimenté par le port usb d'un syno j'en ai un autre qui me sert à faire joujou, donc il est installé/formatté/réinstallé assez souvent, là aussi aucun problème tu as peut être un pb d'alimentation, ou alors tu retire la carte sans éteindre le rasp si tu veux limiter les écriture sur la carte, il y a plusieurs méthode non exclusives -monter les dossiers dans lesquels il y a des écriture ailleurs que sur la carte : --par exemple dans un tmpfs en ram --en faire des liens vers /dev/null (attention, toutes les applis ne le supportent pas) --sur un media externe (clef usb, nas, ...) -désactiver/supprimer les composants qui écrivent comme les logs (syslog/rsyslog/...), les mta (postfix/...), ... -désactiver la swap ou la déplacer loin de la carte (c'est con et inutile mais on peut monter la swap en ramfs) -... Tu peux aussi limiter les lectures : -noyau statique et allégé -busybox -pas de cron -pas de services non indispensable -... En bref, tout ce qui est fait dans les linux embarqué (par exemple les box internet ou les routeurs grand public on juste un peu de rom pour stocker l'os et la conf, le reste est volatile)

Comme le dit Oooops!, c'est principalement pour faire de l’agrégation de liens (meilleur débit, tolérance aux pannes) mais il faut un switch compatible Oui, d'où l’intérêt des onduleurs et des backups Entre autre, mais pas seulement, ça permet aussi d'avoir une copie des données en cas de mauvaise manip ou pire (incendie, vol, ... si on ne laisse pas les 2 au même endroit) Les 7xx+ sont de bons modèles (j'en ai 3) à la condition de bien gérer son espace disque. Un 713+ sans disque c'est moins de 450€ 1 disque de 3To c'est environ 100€ 450+2*100 = 650 Donc il y a mieux ailleurs

Bonjour, C'est le "travailler sur le même fichier en même temps" qui risque de poser problèmes car la limitation vient des applications, pas des nas. Selon les applications et selon le type d'action, les comportements peuvent être très différents, certains applications posent des verrous, d'autres copie intégralement le fichier en mémoire, voir sur le disque, par exemple : -selon les réglages et les versions, les outils de la suite Office MS modifient les fichiers dès qu'ils sont ouverts, même sans faire "save", si on veut éditer un même fichier à plusieurs, on doit le mettre en mode "partagé", de plus à l'ouverture une copie du fichier est créée sur le nas, donc si le fichier est gros, l'ouverture peut prendre le double de temps -à l'inverse, les applications qui font du streaming de données (lecture d'une ISO, d'un fichier multimédia, d'une image disque, ...) ne posent aucun problème Pour la gamme, la plupart des modèles en "+" devraient convenir, après c'est fonction du budget et de l'environnement réseau. Si tu as un switch capable de faire de l’agrégation, prends un syno avec au moins 2 cartes réseaux. Bien sur si tes utilisateurs sont en wifi, ce n'est pas la peine, c'est le wifi qui sera la limitation (même avec un nas bas de gamme) L'un ou l'autre de ces modèles devrait convenir (le 1514+ et peut être le 1814+ devraient sortir bientôt) : DS1813+ : 8disques, 4*rj45 DS1513+ : 5disques, 4*rj45 DS713+ : 2disques, 2*rj45 Sans agrégation de liens, tu seras limité par le réseau à 1gbits, tous ces modèles peuvent faire plus (pour des gros fichiers) Tu peux regarder les perfs ici : http://www.synology.com/fr-fr/products/performance/#4_bay Ma recommandation personnelle va à 1 DS1513+ accompagné d'un autre modèle (peu importe le quel tant que c'est du raid avec un espace disque suffisant) servant uniquement à faire les backups du premier, l'idéal et d'avoir 2 modèles équivalents pour s'en servir en remplacement en cas de gros problèmes.

Les homes sont tous sous /homes (donc /volumeX/homes/login). Il faut donc monter /volumeX/homes sur /home. En complément il faut que tes utilisateurs locaux aient le même uid/gid que tes comptes syno (il faut adapter l'un ou l'autre) ou faire du remapping d'UID sur ton linux. perso j'ai laissé tombé le nfs syno au profit du cifs depuis DSM5, même si c'est nettement moins performant, c'est beaucoup moins pénible à maintenir. Mais maintenant que les syno gèrent le kerberos et le nfsv4, je vais peut être y revenir...

Le premier article date de 2009, il aurait été intéressant s'il n'avait pas fait abstraction d'un point crucial : tous les disques font des erreurs et le savent, il y a donc une partie du disque en réserve pour ré-allouer les secteurs défectueux automatiquement (pour info, c'est aussi valable sur un SSD). Le taux de panne est donc considérablement réduit (de même que les performances). Je suis aussi tombé sur l'article de clubic, même s'il n'est pas faux en soit, il est rempli de "si ceci, et si cela, dans le cas où, ...". Avec tant de suppositions, rien n'est fiable. Au jugé on doit avoir quelques milliers de DD en salle machine (certains ont plus de 10ans) et on doit en jeter/remplacer une grosse dizaine par an (parfois dès le premier démarrage). Ce n'est pas négligeable. Donc un disque unitaire n'est pas une chose super fiable. Par contre j'utilise différents raid au quotidien en usage professionnel (sur de l'emc, du netapp et du quantum), avec une volumétrie à plat (comprendre en surface brute) de plusieurs centaines de To. Je n'ai "presque" jamais vu un raid tomber en panne en 7ans. Des disques individuels oui, mais du moment qu'ils sont vite remplacés (hotspare + supervision), aucune casse. Donc un raid supervisé c'est fiable. Dans le monde professionnel, pour limiter les risques de pannes, on utilise plusieurs méthodes (disques haut de gamme, panachage de disques, hotspare, supervision proactive, contrôleurs redondés, ...). Tout ça à un cout, ce n'est donc pas pour M. ToutleMonde. Pour le grand public, il y a moins de possibilités et le matériel est souvent moins fiable (question de budget). Mais certaines bonne pratiques permettent d'éviter la plupart des problèmes : -il faut par exemple éviter d'utiliser des "contrôleurs" raid qui nécessitent d'installer un truc (s'il y a un truc à installer, c'est que le raid est géré par le soft, donc si le disque en panne contient le soft, il n'y a plus de soft pour recalculer la parité ...), comme ceux qu'on trouve dans beaucoup de carte mère de PC -à l'opposé, les raid 100% softs (même celui de windows) sont assez fiable car ils ne dépendent plus d'un contrôleur et peuvent donc être remontés sur un autre hardware, de plus ils gèrent bien mieux les secteurs défectueux que la plupart des contrôleurs matériel (y compris de gamme pro) -un disque dur doit être régulièrement testé (au moins smart, si possible test de surface). Un contrôleur raid de bonne qualité le fait de lui même, indépendamment de l'OS installé (même sans OS en pratique) -il ne faut JAMAIS mettre des données critiques sur un même raid que le système -mieux vaut plusieurs disques mono plateau de faible capacité qu'un gros disque multi-plateaux avec plein de To -l'achat d'un onduleur est souvent plus rentable que l'achat d'un gros disque A titre perso, le PC devant moi a 3 disques (1ssd système et 2 disques en raid 1 pour les données), de temps en temps (1 à 2 fois par an), j'enlève un des disques du raid et je le tests (après l'avoir remplacé par un 3ème de même taille). Si le disque passe par le test, il fera la rotation suivante, sinon j'en rachète un. Bien sur en faisant cette manip, je cours un risque (panne du disque restant le temps de la manip). C'est pour ça que mes données sont sauvegardées sur un syno et que ce dernier est sauvegardé sur un autre syno (pas au même endroit). Pour les données critiques, j'en ai une copie...ailleurs. Pour en revenir au raid, le raid1 offre à peu prêt le même niveau de protection que les raid5 et 6, l'avantage de ces derniers n'est donc pas leur fiabilité, mais le fait que l'on perde moins d'espace (n-1 ou n-2 contre 50% avec un raid1) et que les performance sont bien plus élevées. Entre le raid1 et les raid5 et 6 on trouve le raid 1+0 qui offre un bon compromis perf/redondance mais qui coute cher (4 disques mini, 50% de perte en surface). Ce qu'il faut retenir des 2 articles et du raid en général : -un disque dur c'est fragile : quand c'est allumé, on ne doit pas y toucher (utilisateurs de portables sur les genoux méfiez vous) -un disque dur c'est fiable : quand c'est utilisé avec soins, ça peut durer des années sans problèmes. Amusez vous à comparer le nombre d'heure avant une panne de disque dur avec le nombre d'heure avant de devoir changer de voiture, c'est édifiant (un indice, une voiture c'est beaucoup moins fiable) -le raid n'est pas une solution de sauvegarde -une sauvegarde au même emplacement physique que l'original n'est pas une sauvegarde -une sauvegarde non testée régulièrement n'est pas une sauvegarde -avant de créer une grappe raid, il faut s'assurer des capacités/limitations des disques mais aussi et surtout du contrôleur

Si tu veux supprimer toute trace de CloudStation : Via l'interface WEB, désinstalle l'appli CloudStation. Normalement ça supprime aussi les fichiers de synchro (ça peut prendre du temps). tu peux ensuite vérifier, en ssh, c'est dans /volumeX/@cloustation (ou un nom du genre) que CS stoke ses fichiers, si ce dossier existe encore après avec désinstaller l'appli, il suffit de le supprimer. Si tu veux limiter la place occupée par CS, je te renvoi à mon post juste au dessus CloudStation Il fonctionne très bien pour des petits volumes de données (on va dire moins de 10Go), c'est une autre histoire pour des gros volumes. Sinon il y a OwnCloud (prend le sur le site officiel, le paquet de la communauté syno semble avoir des pb) qui marche aussi très bien L'appli est légalement gratuite sur android, mais seulement via F-Droid, pas sur le store Google.