Mic13710

Vous avez un seul volume, le 1 sur un disque installé dans la baie 2. Si vous allez dans le menu "Vue d'ensemble", vous devriez avoir un lien du genre "Réparer la partition système". Essayez de faire cette réparation. Votre disque étant en SHR, vous pouvez tenter dans un premier temps d'installer un nouveau disque dans la baie 1 et de migrer votre SHR monodisque vers un SHR avec protection de donnée ce qui permettra de créer un miroir de votre disque existant. Une fois l'opération terminée (quelques heures), vous pouvez remplacer le disque dans la baie 2 par un nouveau et reconstruire à nouveau votre SHR.

Avez-vous CloudStation ?

Je ne comprends pas bien cette histoire de RAID1 et surtout de pouvoir enlever le groupe pour le recréer. Pour augmenter un RAID1 ou 5, point n'est besoin de retirer le groupe. Il suffit de remplacer un disque par un autre plus gros, de reconstruire le RAID et lorsque c'est fait, de remplacer le deuxième disque pour à nouveau reconstruire. L'extension se faisant à la fin, une fois que les 2 disques sont construits. Je ne comprends pas bien non plus l'intérêt de faire deux RAID1 qui n'apportent rien de plus en terme de continuité de service qu'un RAID5 sur 4 disques et surtout fait perdre la capacité d'un disque. Si vous cherchez de la flexibilité, optez pour un volume en SHR (c'est de toute manière l'installation par défaut sur les NAS Synology)

Je ne saurais le dire. Mais comme de toute manière c'est la seule méthode applicable, va bien falloir faire avec et accepter de devoir reprendre certains paramétrages. C'est tout de même mieux que de repartir de zéro. Une méthode que j'applique c'est de faire des copies d'écran de chaque page de config. Ainsi, je peux retrouver plus facilement les réglages au cas où j'ai à les reconstruire.

J'avais pensé à de l'indexation mais avec un CPU à 5%, j'ai changé d'avis parce que sur un série J, l'indexation a plutôt tendance à charger le CPU vers les 90%. Mais si vous avez copié quelques centaines de Go hier, il est fort possible que ça soit l’indexation. Ce processus est assez long. Il faut attendre quelques heures, voire jours pour que tout se stabilise.

Je ne sais pas côté GSM (je n'utilise pas DSCloud) mais pour ce qui est du PC, c'est tout à fait normal. C'est à vous ensuite de sélectionner dans les paramètres du client quel(s) dossier(s) vous voulez ou pas synchroniser. Un parenthèse cependant : mettre des fichiers multimédia dans un cloud n'est pas une utilisation vraiment appropriée du produit. Un cloud est surtout fait pour stocker des fichiers et dossiers de travail qui sont susceptibles d'être modifiés par un ou plusieurs utilisateurs. A moins que ça ne soit le cas, photos, videos et musiques n'y sont pas vraiment à leur place, bien que ce soit techniquement possible. Il faut savoir que Cloudstation côté NAS maintien un dossier de suivi (non accessible par file station) qui pèse environ autant que la totalité des dossiers Cloudstation ainsi que des dossiers partagés inclus dans Cloudstation. En clair, à chaque Mo dans CloudStation ou dossier partagé inclus dans le Cloud, c'est 2Mo occupés sur le NAS. Vous comprenez pourquoi il n'est pas recommandé d'y mettre des fichiers multimedia qui sont généralement figés mais aussi et surtout particulièrement lourds et donc occupant un espace important sur le NAS sans réel intérêt pour une utilisation cloud.

Ca prend effectivement du temps, mais tout se déroule en tâche de fond, le temps importe donc peu. Avec un 4To entre la phase de test du disque et l'extension il faut compter de 15 à 20 heures suivant la quantité de données à traiter. Le CPU est relativement sollicité pendant cette opération ce qui ralenti un peu l'utilisation du NAS qui reste toujours opérationnel pendant toute la durée de la construction.

Effectivement. Sur les applis, il n'y en a pour l'instant que pour la pomme et le robot.

Bonne recherche pour le modèle de NAS. Autre chose sur CS : il peut gérer jusqu'à 32 versions. Ca laisse de la marge. A savoir : Cloudstation est gourmand en espace disque car il doit maintenir un dossier de suivi en plus du dossier CloudStation lui-même. Ce dossier représente grosso modo le même poids que le Cloud lui-même. En clair, si vous avez 1To sur le Cloud, la place totale occupée sur le NAS sera de 2To. Il faut en tenir compte dans la capacité des disques que vous allez mettre en place. Bien que la limite soit virtuellement infinie, comme pour les autres solutions cloud, il ne faut pas y mettre tout et n'importe quoi. Des fichiers multimédia par exemple n'ont rien à faire sur un Cloud. Ils occupent de la place et remplissent inutilement le NAS. Il existe d'autres solutions pour ces fichiers. Il faut réserver le Cloud pour des fichiers et des documents de travail. Mais ça, je pense que vous le savez puisque vous utilisez des solutions externes.

C'est exactement ce que fait CloudStation. En gros il fonctionne comme un Dropbox. Toute modification ou ajout d'un fichier local est synchronisé avec le serveur qui met ensuite à jour les cloud clients. Malheureusement, comme pour Dropbox, si plusieurs utilisateurs travaillent sur le même fichier, il y a forcément des conflits qui sont indiqués en renommant le fichier avec le poste qui a généré le conflit, la date et l'heure. Comme pour Dropbox, on peut travailler hors connexion sur les fichiers locaux, les mises à jour se faisant dès qu'une liaison réseau est établie. J'utilise cette solution à titre personnel depuis sa version béta. Je la trouve bien aboutie (en tout cas elle répond tout à fait à mes besoins) et Synology y apporte régulièrement des innovations et des améliorations. On peut aussi y raccrocher des cloud externes (Dropbox, Onedrive, Googgle drive etc..)

Tout à fait d'accord lorsqu'il est combiné, mais en solution unique, c'est pas vraiment recommandé.

Tout à fait Gaëtan. C'était réducteur de ma part, d'autant que j'ai un portable avec 2 sessions avec chacune son CS, mais ça ne change rien au problème de Matouf.

RAID0 ou JBOD : configurations à bannir sur un NAS. @Shepard64 : il ne faut pas vouloir le beurre et l'argent du beurre. Si vous voulez un seul volume et limiter les risques de perte de données, pas d'autre solution que de sacrifier une partie de la capacité totale. Et donc : RAID5 ou SHR obligatoire. Sinon, vous pouvez créer des disques en basic avec un volume par disque : la capacité sera supérieure au volume unique mais il va falloir gérer les remplissages. Je n'en vois pas bien l'intérêt dans votre cas.

Pour ce qui concerne la liaison vers votre serveur, ça fonctionne (le lien ci-dessus est toujours opérationnel). Si le 6690 est bien routé, et qu'il est ouvert dans la parefeu avec les bonnes adresses IP, il est possible que les blocages proviennent de la connexion côté client. Si c'est une connexion d'entreprise, il est fort probable que les ports soient bloqués par l'administrateur, dont le 6690. Vous pouvez aussi tenter d'utiliser quickconnect pour voir si ça peut résoudre votre problème.

damned, j'ai oublié de le faire grossir ! Après un grow et un resize, tout est rentré dans l'ordre Sauvegarde> cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md3 : active raid1 sdb3[0] 3902296416 blocks super 1.2 [1/1] md2 : active raid1 sda3[0] 3902296416 blocks super 1.2 [1/1] md1 : active raid1 sda2[0] sdb2[1] 2097088 blocks [2/2] [UU] md0 : active raid1 sda1[1] sdb1[0] 2490176 blocks [2/2] [UU] unused devices: <none> Merci encore une fois Gaëtan. Problème résolu.

Ah ben oui, c'est tout con. Pourquoi n'y ai-je pas pensé ? Merci PiwiLAbruti. Problème résolu.

Test SMART Ok. J'ai essayé le resize et aucun changement. Bizarre tout de même cette différence. Sauvegarde> df -h Filesystem Size Used Available Use% Mounted on /dev/md0 2.3G 559.2M 1.7G 24% / /tmp 496.0M 692.0K 495.3M 0% /tmp /dev/md2 3.6T 2.1T 1.5T 59% /volume1 /dev/md3 3.6T 216.2M 3.6T 0% /volume2 Sauvegarde> umount -l /volume2 Sauvegarde> mdadm -S /dev/md3 mdadm: stopped /dev/md3 Sauvegarde> mdadm -A /dev/md3 /dev/sdb3 --update=devicesize Size was 7804592833 Size is 7804592833 mdadm: /dev/md3 has been started with 1 drive. Sauvegarde> cat /sys/block/md3/md/dev-sdb3/size 3902296416 Sauvegarde> cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md3 : active raid1 sdb3[0] 3902296256 blocks super 1.2 [1/1] md2 : active raid1 sda3[0] 3902296416 blocks super 1.2 [1/1] md1 : active raid1 sdb2[1] sda2[0] 2097088 blocks [2/2] [UU] md0 : active raid1 sdb1[0] sda1[1] 2490176 blocks [2/2] [UU] unused devices: <none> Sauvegarde> resize2fs /dev/md3 resize2fs 1.42.6 (21-Sep-2012) The filesystem is already 975574064 blocks long. Nothing to do! (Device size is 975574064 blocks long) mdadm: /dev/md3 donne la bonne taille (3902296416) comme pour les 3 autres disques, mais cat /proc/mdstat ne me donne que 3902296256 pour le même md3. La différence est minime et ce qui me rassure tout de même c'est que la taille physique sur le disque est correcte, ce qui voudrait dire que je peux changer la destination de ce disque pour l'associer à un RAID existant.

Un onduleur line interactive ne fait pas plus de bruit qu'un offline puisqu'il n'en fait ...... aucun. Tous les onduleurs de ces types sont en veille. Ils surveillent la tension d'entrée et si elle ne rentre plus dans les limites de tension et/ou les critères de qualité pour les line interactive, ils activent la partie onduleur qui prend le relais du secteur. C'est seulement à ce moment là que l'onduleur fait du bruit.Ils font aussi du bruit pendant les tests réguliers de batterie lancés par l'onduleur.

Tant qu'on ne saura pas de quel modèle de nas il s'agit, il est impossible de donner une réponse qui tienne la route. Donc Seb51, si vous voulez de l'aide, il faut nous en dire plus.

Salut à tous, Mon écran est tombé en panne. C'était un bon vieux 4/3 et comme ce format ne se fait plus, j'ai dû le remplacer par un 16/9. Je n'aime pas beaucoup ce format pour de la bureautique mais là n'est pas le propos. J'avais réglé la taille de certaines fenêtres du DSM de manière à pouvoir les voir sur la plus grande hauteur possible de mon 4/3. Mais voilà, la hauteur d'un 16/9 étant moins importante qu'un 4/3, je n'ai plus accès à la partie basse de ces fenêtres, et je suis réglé sur la résolution maximum. C'est assez déconcertant et plutôt ennuyeux. Question : quelqu'un sait-il comment on peut régler la taille des fenêtres ou les réinitialiser sans passer par une réinstallation du DSM ? Il y a sans doute un truc simple et j'ai peine à croire que les développeurs de Synology aient oublié quelque chose d'aussi évident.

Possible, sauf que les 4 disques ont été initialisés sur le même NAS. C'est peut-être une histoire de version de DSM mais je n'y crois pas trop puisque le même DSM a permis au disque 1 de s'étendre sur le même nombre de blocs que les autres 4To. J'ai lancé un test smart étendu sur le disque 2, on verra bien. Edit : Si le test se déroule bien, je peux faire un umount du volume 2 et tenter un resize comme sur le volume 1, ça ne mange pas de pain.

Désolé pour le réveil brutal En fait la différence n'est pas sur le disque sur lequel on a travaillé mais sur le deuxième. Les deux disques sont rigoureusement les mêmes (même référence, achetés ensemble) et exception faite du firmware plus récent, ils sont identiques à ceux de mon autre nas qui ont 1 an. Sauvegarde> sfdisk -l /dev/sda /dev/sda1 256 4980735 4980480 fd /dev/sda2 4980736 9175039 4194304 fd /dev/sda3 9437184 7814032064 7804594881 fd Sauvegarde> sfdisk -l /dev/sdb /dev/sdb1 256 4980735 4980480 fd /dev/sdb2 4980736 9175039 4194304 fd /dev/sdb3 9437184 7814032064 7804594881 fd Aucune différence entre les deux. la même chose sur mon autre nas : xxxxxx> sfdisk -l /dev/sda /dev/sda1 256 4980735 4980480 fd /dev/sda2 4980736 9175039 4194304 fd /dev/sda3 9437184 7814032064 7804594881 fd xxxxxx> sfdisk -l /dev/sdb /dev/sdb1 256 4980735 4980480 fd /dev/sdb2 4980736 9175039 4194304 fd /dev/sdb3 9437184 7814032064 7804594881 fd et pour ses md: xxxxxx> cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md2 : active raid1 sda3[3] sdb3[2] 3902296416 blocks super 1.2 [2/2] [UU] md1 : active raid1 sda2[0] sdb2[1] 2097088 blocks [2/2] [UU] md0 : active raid1 sda1[0] sdb1[1] 2490176 blocks [2/2] [UU] unused devices: <none> Ce qui me gène un peu c'est que 3 disques sur 4 ont les mêmes nombres de blocs, et que le petit dernier en a moins. Si tu regardes plus haut, j'ai utilisé ce disque pour pouvoir étendre le premier. Le nombre de bloc était différent (voir ma remarque à la suite des cat). Depuis, j'ai supprimé les partitions DSM, fait un test d'écriture de zéros qui n'a décelé aucune erreur, réinitialisé le disque et créé le volume 2. Le nombre de blocs est inchangé. Après, c'est vrai que l'écart est minime. C'est juste que j'aimerais comprendre pourquoi et si surtout ce n'est pas un signe de faiblesse du disque. Pour info, les 4 disques ont tous été créés sur le NAS Sauvegarde. Les deux de mon NAS principal ont été migrés du sauvegarde vers le principal. Le soucis avec le nombre de blocs, c'est que si j'utilise le dernier disque sur un raid existant (en remplacement d'un disque sur le nas principal par exemple) il risque de se faire jeter.

J'ai testé mon deuxième disque et monté mon volume 2. J'ai lancé un cat /proc/mdstat pour vérifier les md et j'ai toujours une différence de 160 blocs entre md2 et md3 Sauvegarde> cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md3 : active raid1 sdb3[0] 3902296256 blocks super 1.2 [1/1] md2 : active raid1 sda3[0] 3902296416 blocks super 1.2 [1/1] md1 : active raid1 sdb2[1] sda2[0] 2097088 blocks [2/2] [UU] md0 : active raid1 sdb1[0] sda1[1] 2490176 blocks [2/2] [UU] unused devices: <none> Comme j'ai les mêmes disques montés en raid1 sur mon nas principal, j'ai lancé la même commande et je retrouve le même nombre de blocs que pour le md2. As-tu une idée pourquoi mon md3 a des blocs en moins ?

quand je dis couple switch / caméra, c'est un peu large pour dire que le Syno n'a rien à voir dans ce processus. C'est principalement la compatibilité de l'injecteur avec la cam qu'il faut regarder. Il faut qu'il injecte la bonne tension et qu'il ait la puissance suffisante pour alimenter la cam. Et il ne faut pas que l'injecteur ait des incompatibilités avec le switch (il y est raccordé).

Comme quoi on passe à côté des choses simples . Bon. Redémarrage du NAS et là, Oh miracle ! mon volume 1 est passé à 3.58To ! Mais (il faut bien qu'il y ait un mais) le gestionnaire m'indique pour le volume "échec de partition système" et il a lancé une optimisation du système de fichier. J'ai lancé une réparation comme suggéré par DSM et tout est maintenant au vert. Merci INFINIMENT Gaêtan pour ton aide et ta patience. Sans toi je n'y serais pas arrivé et j'ai aussi appris beaucoup. Très bonne soirée à toi et bon WE.