Mic13710

Entièrement d'accord avec Gaëtan. Faut arrêter la parano. Pour arriver à lire un disque sur lequel on a écrit des zéros, il faut des logiciels puissants que le simple quidam n'a pas. Si vraiment parano, une deuxième passe en écriture aléatoire devrait alors effacer encore un peu plus les données et demander un logiciel surpuissant. Ensuite, je vois mal un particulier détenir des données tellement confidentielles qui nécessitent tant de précautions. Comme je le dis plus haut, à ce stade, on ne vend pas ses disques, on les détruit purement et simplement.

Alors, puisque vous semblez avoir des données si confidentielles qui pourraient intéresser la NSA, la seule solution utilisée par toutes les entreprises qui comme vous veulent protéger leur données, c'est la destruction physique des disques. Un bon coup de marteau suivi d'un passage sous presse et là pas de risque de vous faire voler vos données.

Impossible à réparer car tout se trouve sur la carte mère. Il faudrait faire un reset de premier niveau pour réinitialiser les paramètres de connexion puis refaire tous les réglages de votre routeur à la main pour que seul le LAN 2 soit utilisé. Mais je ne comprends pas très bien votre problème avec EZ et je ne pourrais pas vous aider de toute façon car je n'utilise pas ce truc. Mon routeur est entièrement paramétré par mes soins et je n'ai pas besoin du NAS pour cela. Complément d'information : les protections foudre que vous trouvez sur les blocs prises ou les onduleurs sont en fait de vulgaires passoires totalement inefficaces en cas de vrai coup de foudre. Leur temps de réaction est bien trop long face à un front de foudre et leur capacité d'écoulement est tellement faible qu'ils ne protège absolument rien en cas de sévère coup de foudre. Une vraie protection foudre ne s'improvise pas et fait appel à des équipements autrement plus sophistiqués que ce que vous trouvez dans les gsb. Le prix de ces équipements est aussi en rapport (quelques centaines d'Euros), et leur pose fait appel à des règles strictes. On est très loin des "gadgets" cité plus haut.

Une écriture de zéros ne vous conviendrait pas ? Ca revient à préparer des disques. Vous trouverez la procédure sur

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.