Mic13710

Bizarre. A moins qu'il y ait un paramètre que je ne connais pas et qui est sauvegardé dans le fichier de config. Est-ce que vous avez vérifié si les droits d'utilisation de filestation sont attribués pour le compte de connexion ? Avez-vous essayé avec un autre compte ?

OK. Juste pour confirmation : Vous voulez détruire tout ce que contient votre JBOD ? D'après vos relevés, votre JBOD est sur les disques 1, 2 et 3. Est-ce exact ? Votre disque en basic est bien le 4 et c'est celui que vous voulez conserver ? Je présume que par la suite, vous voulez réutiliser vos disques dans le NAS. Que souhaitez-vous obtenir au final ?

Vous pouvez passer en lignes de commande par le compte root. Pour cela, il faut d'abord activer le terminal ssh et installer putty sur votre PC. Sur putty, vous vous connectez au NAS (IP du NAS), port 22. Compte 'root', mdp : celui du compte admin. On commence par repérer les disques. Vous lancez les commandes suivantes et vous postez ici les résultats : grep "[sh]d." /proc/partitions cat /proc/mdstat

Si aucun formatage à partir du nas n'était nécessaire, il était inutile de casser le RAID. Un simple échange de disque faisait l'affaire. Mais bon, rien de grave, c'est juste une opération qui pouvait être évitée.

Il y a peut-être un soucis au niveau du DSM. Vous pouvez tenter une réinstallation. Pour cela, faites d'abord une sauvegarde de votre configuration, puis faite un double reset pour réinitialiser le DSM en suivant ce tuto. Lisez bien les liens vers les FAQ et la sauvegarde de la config. Cette manip n'affecte pas les données, mais comme toujours, il est recommandé de mettre les sauvegardes à jour avant de procéder.

Si j'ai bien tout compris, jmiche34 ne peut pas faire autrement qu'un formatage sur le NAS. Si j'avais au départ proposé la séparation propre du RAID, ce n'était qu'une question de confort pour ne pas avoir de message RAID dégradé durant la phase d'attente du nouveau disque. C'est très simple à faire en moins de 5mn chrono, aussi ce serait dommage de s'en priver. Mais Amazon a envoyé le disque avant le retour de l'ancien et en toute logique, cette phase n'a plus lieu d'être. Un simple échange de disque et une reconstruction plus tard, tout est fini. Cependant, pour lancer un formatage par le NAS, il est à mon avis préférable de bien séparer les disques pour ne pas avoir de problème. L' installation du nouveau disque peut ensuite se faire très simplement en passant par une augmentation de volume.

Oui si vous voulez seulement changer le disque, et j'aurais tendance à dire non si vous voulez effacer l'ancien sur le NAS avant de le renvoyer. Comme de toute façon vous devez casser le RAID, autant le faire de manière propre, d'où la méthode Gaëtan. Le disque 2 étant ainsi détaché, vous pouvez travailler dessus sans crainte pour les données sur le disque 1.

Non, pas vu de pb de ce côté là. Mais je sais que les Rasp sont assez capricieuses avec les SD. J'ai suivi les conseils des "experts" sur les forums et wiki spécialisés et j'ai installé des Transcend 16GB Class 10, modèle TS16GUSDU1E que j'avais trouvé en promo et qui sont parait-il compatibles Rasp.

C'est pourtant pas compliqué à comprendre. Le port esata est directement géré par le NAS. Le format du disque doit donc être compatible avec celui du NAS : ext3 ou ext4. Si votre disque est en NTFS, il est probablement détecté, mais vous ne pouvez pas le lire. Sur un boitier externe, c'est différent puisque c'est le boitier qui gère le format du disque.

C"était pour éviter le message du RAID dégradé, le temps de renvoyer le disque et de recevoir le nouveau. La procédure étant très simple, on peut aussi l'appliquer dans ce cas. Mais comme jmiche64 a reçu son disque avant d'avoir renvoyé l'ancien, cette étape n'est bien évidemment plus d'actualité.

Je suis désolé mais je ne suis pas un expert dans le monde des pommes. Aussi je ne comprends pas bien votre problème d'écriture sur votre MAC avec le format natif. Mais si ça fonctionne avec ExtFs, c'est très bien. Infos importantes pour la suite : Le RAID est un principe de stockage des données qui permet d'assurer la continuité de service en cas de perte d'un ou plusieurs disques. Ce n'est en aucun cas une sauvegarde ! Il faut toujours mettre en place un système de sauvegarde périodique de vos données, au moins les plus importantes. Contrairement aux idées reçues, un RAID est plus fragile qu'un simple disque en basic s'il n'est pas contrôlé en permanence par le NAS. D'où la nécessité absolue d'alimenter le NAS avec un onduleur compatible. En effet, une panne d'alimentation peut provoquer des dégâts irréversibles dans le système de fichier, qui peuvent aller jusqu'à la perte totale des données.

Pour le faire à partir du NAS, une fois le raid cassé, vous lancez la commande suivante pour détruire les partitions du disque 2 : Vous éteignez le nas (important) et vous le rallumez. Vous lancez cette commande en mode root : Cette commande va écrire des zéros sur le disque. Procédure très longue (une dizaine d'heures). A la fin du processus, vous devriez avoir le message suivant : suivi du nombre de secteurs testés et validés. Note importante : si vous voulez voir les résultats, il faut maintenir le terminal en opération. Attention aux mises en veille des PC qui coupent la connexion et ferment le terminal ! Si vous voulez voir la progression, il faut se logger sur un autre terminal et vous entrez la commande ps aux | grep dd qui va vous donner la liste et les PID des processus en cours dans laquelle vous trouverez le processus dd. Il ne vous reste plus qu'à rentrer la commande suivante : kill -USR1 '+ PID du processus dd' qui vous donnera le nombre de record in et record out. Par exemple si le numéro indiqué est le 1154, vous mettrez : kill -USR1 1154

Tout d'abord vous mettez à jour vos sauvegardes. Ensuite, vous cassez le RAID en suivant la méthode proposée par Gaëtan Cambier. Ça vous permettra d'avoir un SHR sans protection de données, mais surtout pas de message de RAID dégradé. Vous pourrez continuer à utiliser votre NAS, mais si votre disque crash, il faudra tout réinstaller. Vous pourrez sortir votre disque 2 et le passer dans un PC pour lui faire un nettoyage complet (avec le logiciel de WD par exemple) avant de le renvoyer.

Désolé de plomber l'ambiance mais il y a toujours un pb. Avec 3 disques de 3To en SHR, vous devriez avoir 6To et pas 3 ! Pouvez-vous faire des scan des onglets de votre gestionnaire de stockage ?

Le problème ne vient pas forcément du wifi mais de la gestion des photos public/privé dans photostation. Si vos photos sont visibles par n'importe qui sur votre réseau privé c'est qu'elles sont publiques, et elles le sont aussi sur la toile (avec les ouvertures de ports adéquates). Il faut revoir vos paramétrages de photostation.

Non, ce n'est pas le même principe. Sur un RAID1, les fichiers sont répartis à l'identique sur chaque disque. Donc les temps d'E/S sont ceux d'un seul disque (le plus rapide en général). Sur un RAID5 les données sont réparties sur plusieurs disques, et avec 4 disques et plus on peut obtenir un accès quasi simultané vers des données stockées sur les disques 1&2 et d'autres stockées sur les disques 3&4. Mais pour que ce soit utile, il faut obligatoirement faire de l'agrégation de lien.

Chaque disque à sa place.

C'est pourtant pas compliqué à comprendre. Si les 2 disques ne peuvent plus fonctionner ensemble directement, chaque disque peut-être utilisé pour reconstruire un RAID. Donc, si vous faite vos manips avec le disque 1 et que ça se passe mal, vous pouvez toujours utiliser le disque 2 qui contient les mêmes données que le 1 pour refaire la reconstruction.

Il y a le JBOD qui lui écrit d'une manière moins formelle que le RAID0 puisqu'il utilise toute la place dispo et met les fichiers où il trouve de la place. C'est très bien au départ car les fichiers sont pas ou peu fractionnés. C'est de moins en moins évident au fur et à mesure des écritures, et au bout du compte, les fichiers sont disséminés sur tous les disques de la grappe. Et donc, la perte d'un disque ..... Alors, si vous voulez vivre dangereusement, RAID0 ou JBOD, le résultat est quasiment le même. Grosse erreur ! le RAID (1 et +) ou le SHR n'est absolument pas un système de sauvegarde, c'est seulement un système de stockage qui permet d'assurer la continuité de service. C'est tout, et c'est déjà pas mal !

Sans doute est-il possible de faire une petite surveillance sur une base rasp 3 (après tout, il y a bcp d'applis dispos), mais il sera bien difficile de lui faire supporter jusqu'à 36 caméras IP Haute Définition comme peut le faire le VS360HD. Il y a aussi le prix des licences à regarder. A 170€ pour 4 cams, pour un Visual Station rempli au ras de la gueule (36 cams), on est à plus de 1500€, soit 2000€ avec la VS. OK, c'est un peu cher, mais si on rajoute aussi le prix de 36 caméras IP de qualité, ce montant devient très marginal. Si votre surveillance ne comporte que quelques caméras, il est plus simple je pense d'utiliser directement le NAS. Le tout est de choisir un modèle suffisamment performant pour pouvoir supporter toutes vos caméras avec une définition suffisante.

C'est même totalement impossible ! Faite un parallèle avec les PC : si vous voulez passer de W7 à W10, est-ce que vous retirez le disque ? Là c'est pareil. Le DSM est installé sur tous les disques du NAS. Si vous les enlevez, vous avez une belle coquille vide.

Les données se répartissent à peu près comme un RAID5. Toutes les explications sont ici.

J'y suis allé juste pour le fun, mais j'ai très vite compris qu'il était extrêmement difficile d'y retrouver ce qu'on cherche, surtout qu'on ne sait pas où chercher dans tous les dossiers du répertoire. Alors peut-être qu'avec un CS peu rempli ça peut s'envisager mais je pense comme tu dis que ça ne doit pas être une partie de plaisir.

DSM n'affiche que ce à quoi le compte de connexion a accès. Normal non ? Si par exemple, vous ne donnez pas accès à Music Station à un utilisateur, il n'apparaitra pas sur son bureau DSM.

Par défaut oui, mais si le nombre de versions est à 0 ..... On ne peut rien récupérer dans le dossier @cloudstation. C'est juste impossible car totalement illisible. La seule récupération possible c'est en se connectant avec le compte de l'utilisateur afin de retrouver les fichiers effacés par l'utilisateur en question dans l'historique de son CloudStation. Mais il arrive que ça ne marche pas...