CoolRaoul

ben non: suffit simplement d'installer le package ipkg perl de la meme façon que tu as installé gcc c'est ce que j'ai fait.

pas tout a fait le meme probleme en fait, mon syno a un CPU arm, j'avais du creer ce symlink: /opt/bin/arm-none-linux-gnueabi-ld -> ../arm-none-linux-gnueabi/bin/ld [/size][/CODE] pour régler des erreurs similaires Mais comment se fait-il que ce soit dans "/usr/local" que ca se passe chez toi? Est-ce le perl natif du syno que tu veux étendre ou celui de optware (installé par ipkg). Pour ma part j'ai préféré laisser intact le perl "natif" (/usr/bin/perl) et installer le perl optware (/opt/bin/perl) afin d'étendre ce dernier Voici un extrait de sa config: [font=courier new,courier,monospace]Characteristics of this binary (from libperl): Compile-time options: PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP USE_LARGE_FILES USE_PERLIO Built under linux Compiled at Mar 16 2012 04:49:07 @INC: /opt/lib/perl5/5.10.0/arm-linux /opt/lib/perl5/5.10.0 /opt/lib/perl5/site_perl/5.10.0/arm-linux /opt/lib/perl5/site_perl/5.10.0 [/font]

**HS** A ta place le relogerai le ".cpan" (par un symlink) ailleurs que dans "/root" (la place est comptée sur le file system "/" et .cpan peut beaucoup grossir au fil des mise a jours.)

Absolument: l'environnement des scripts lancés au boot (et en cron) n'exécute ni /etc/profile ni /root/.profile (ces derniers étant comme dans tout unix destiné aux shells interactifs) . Je conseille toujours de mettre le PATH en dur (et donc ici /opt/bin pour optware) dans les scripts: il n'est jamais bon de faire dépendre un script de son environnement hérité. Ce dernier qui peut être tres variable suivant le contexte (cron, startup, ssh <commande>, shell interactif, CGI,...) ou il est invoqué

Le backup standard fait bien une copie incrémentale, mais tu ne disposera pas d'un clone de ton disque HD1 sur le disque HD2 si c'est ce que tu souhaitais au départ. Tous les dossiers sources sont sauvegardés dans un sous dossier du dossier de backup cible L'important est d'avoir des sauvegardes, non ? La on dirait que tu veux avoir simultanément les avantages du raid miroir (limiter les temps d'arret de service en cas de panne disque) et ceux de la sauvegarde différentielle sur un volume séparé (sécurité des données en cas de corruption de volume) Ce n'est pas possible à ma connaissance.

En usb2 ca me semble un peu optimiste Débits théoriques: MBits/sec 480 MBytes/sec 48 Mbytes/min 2880 Mbytes/hr 172800 Gbytes/hr 169 En pratique: Gbytes/hr ~ 110

C'est surtout que tu aurais du le dire des le départ Cela dit Je n'en vois pas vraiment l'utilité mais c'est toi qui vois .. L'important est que la raison en soit bien claire pour toi. Avec tes 2 partitions par disque tu va donc te retrouver au final avec 4 volumes (sache que rien ne t'oblige a ce que les partitions 1 et 3 - et respectivement 2 et 4- fassent la meme taille, tu peut tout aussi avoir deux partitions sur le HDD 1 et une seule sur le 2) En tout cas faire une configuration basée sur les groupes de disques plutot que sur des disques isolés n'est pas forcément utile non plus ici. Mais bon, ca ne pose pas de problème de fond non plus. L'intéret d'un groupe de disque est qu'il peut être étendu en lui ajoutant des ultérieurement des disques supplémentaire. Mais dans le cas d'un NAS à deux baies sur lequel on a déja deux disques ... bref ... tu imagines. Je répete que file station ne voit ni les disques ni les volumes (et faut aussi savoir que le terme "partition" s'applique au sous découpage d'un disque en zones physiques et ne s'applique pas ici ) mais bien les dossiers partagés Tu vas crééer ces derniers via l'icone du panneau de configuration. DSM en préconfigure certains par défaut (exemple music, video,music) Lors de la création, pour chacun d'entre eux, tu vas choisir dans quel volume il sera situé (les dossiers pré-configurés peuvent être déplacés dans un autre volume si necessaire) Par la suite, quand tu vas configurer les sauvegardes (soi de type timebackup soit de type sauvegarde standard), Il faudra tenir compte de la contrainte que la source et la cible de la sauvegarde ne doivent pas être sur le même volume. Et pour que la sauvegarde ait un sens il faut en plus que la configuration du volume source et du volume partagent un même disque (donc groupe de disques dans ton cas). Je ne me souviens plus si DSM vérifie cette deuxième contrainte, si ce n'est pas le cas c'est à toi de vérifier que tout est correct (et une fois encore tu constatera que ca serait plus simple avec juste deux volumes, un par disque donc) Voila...

C'est toujours pas bon pourquoi insistes-tu a utiliser les groupes de disques? DSM ne te permet pas de faire une seule partition par disque de 2To ?

C'est comme cela que ca fonctionne, pour audiostation c'est tout ou rien (on ne peux gérer par utilisateur et par groupe que le droit d'utiliser audiostation ou pas, via la rubrique "privilèges d'application") (j'imagine que "DS audio" et AudioStation utilisent le même protocole de connection et donc partagent cette gestion de doit monolithique)

Suffit d'installer le soft ad hoc:

Tu devais supprimer ces "groupes de disques" et repartir à zero

tu veux dire que la colonne "volume" est identique à la colonne "numéro" ?

Ben oui, faut créer un volume (volume1) sur le disque 1 et autre (volume2) sur le disque 2 Pb, comme je n'ai pas de syno sous la main et avec une config vierge je ne peux pas te faire de demo pas à pas avec copie d'ecran Voici ma config si ca peux t'aider (celle a laquelle tu devrais aboutir): Volume1 (pour le volume 2 est identique en remplacabt "disque 1" par "disque 2"):

Pourquoi ne pas avoir suivi le conseil que je t'avais donné dans le fil ci dessous? D'apres ton expression de besoin je t'avais écris "Pas de raid, chaque disque = 1 Volume" Et la tu nous reviens avec une config ou les deux volumes sont répartis sur les deux disques???

Je crois que je comprend un peu ... tu as créé deux volumes (1 et 2), chacun étant réparti sur les deux disques physiques Sinon pour timebackup il faut que la cible soit sur un autre volume que la source Mais a partir du moment ou tu réparti tes deux volumes sur tes deux disques, quel que soit le disque qui lache, tu pers tout! Sur quels critères t'es-tu appuyé pour choisir cette configuration? Me semble que l'on ne peut pas faire moins fiable.

Quel est le type des volumes 1 et 2 ? Ils sont visibles ou pas alors? dans le filestation on visualise les dossiers partagés pas les disques

Juste une info: il faut savoir que, statistiquement, les pannes sur les composants hardware sont plus fréquentes dans leurs premières semaines de vie. Dans le cas d'un disque neuf (mais ca vaut pour un PC complet aussi), je conseille de le soumettre a un "stress test" dans les premiers jours (il y des logiciels pour ça) pour détecter rapidement si il est "sain".

tout est expliqué ici

Dans le cas d'un raid a deux disques, on est en présence d'un systeme de fichier *unique* réparti sur les deux disques. Si il arrive une corruption, dire que que ça va "toucher" les disques ne signifie pas grand chose (puisque c'est la structure logique qui est touchée), mais par contre les données peuvent tout a fait être définitivement perdues Comme on l'a dit et répété à de nombreuses reprises ici et ailleurs: "un RAID n'est pas une sauvegarde"

Pas forcément: j'ai deux disques en mode "basic" et je fais des backups auto du Volume1 vers le Volume2. Si le volume 2 lache, suffit de le remplacer. Si c'est le 1, faudra en plus faire une restauration. En plus je peux utiliser l'espace libre de chacun d'entre eux comme zones temporaires quand je doit stocker provisoirement de gros fichiers ou pour des choses sans importance pour lesquelles je n'ai pas vraiment besoin de sauvegardes (téléchargements depuis internet par exemple) L'autre avantage est que si le systeme de fichier se retrouve corrompu (ce qui peut toujours arriver) je ne me retrouve pas "à poil" (a moins d'ajouter une sauvegarde externe, mais comme je n'ai qu'un ds212, en usb2 c'est pas tres performant niveau débit)

Ca permet de ne pas à faire l'ouverture et la redirection vers le NAS du port cloudstation (6690) dans sa box. Dans ce type de configuration, le Syno se connecte sur les serveurs EZ, et les clients *aussi*. Les serveurs EZ font donc office de passerelle. Schématiquement ça donne (les fléches représentent la direction du flux lors de l'ouverture de connection TCP) Client Cloudstation windows -> serveurs EZ <- <box adsl> <- NAS au lieu de : <Client Cloudstation Windows> -> <box Adsl> -> NAS

*une* image d'un des disques? "shr ext4"? Aucune idée de ce que cela signifie je ne comprend rien de ce qui tu essaie de nous expliquer: tu a choisis quelle configuration finalement? vraiment désolé **edit** peut être que je devine ce que tu veux nous dire tu avais fait une configuration basée sur "Synology Hybrid RAID" (c'est bien ce que tu veux dire par "shr ext4." ?) et tu va maintenant choisir ce que je t'ai proposé? c'est bien ça?

Ta question ("Quel est l'intérêt?") n'a pas beaucoup de sens: au final tu aura toujours un ou plusieurs volumes qui sont des espaces de stockage *logiques*. Suivant la façon dont tu organise ton stockage avec l'outil "gestionnaire de stockage", tu va pouvoir te retrouver au final avec un volume unique , constitué des deux disques physiques (en mode raid mirroir ou stripe ou jbod par exemple) , ou deux volumes, un par disque (mode "basic") Ensuite c'est a toi d'étudier les différentes organisations, de peser les avantages et les inconvénients de chacune et de choisir celle qui te conviens. Mais on ne peux pas décider à ta place.