Mic13710

Salut @.Shad., pas pu te répondre plus tôt. Pour moi, il n'y a pas de donnée alarmante. Je ne vois rien de grave dans la 200. C'est sûr qu'elle serait mieux à 0, pour autant elle n'est pas considérée comme étant un signe de dégradation du disque. D'ailleurs, cette valeur est absente des tests SMART pour les Seagate. Ceci étant dit, les valeurs que tu présentes sont celles du derniers test qui s'est terminé correctement et non pas les données actuelles. Celui en cours n'étant pas arrivé à terme, il y a probablement un souci sur le disque qui empêche le test de se terminer. Si tu peux lui faire passer d'abord les tests constructeur sur un PC, ce serait un bon début. Si c'est concluant, un badblocks sur le NAS serait un plus pour définitivement s'assurer que le disque est bon.

En enlevant le disque, le volume va passer en mode dégradé. Il suffit de lancer la reconstruction avec le nouveau disque à partir du gestionnaire de stockage, ce qui va recréer le miroir (c'est le terme consacré). C'est seulement à la fin de la reconstruction (quelques nombreuses heures) que vous pourrez faire de même avec le deuxième disque.

@Kiki91800Il serait préférable de supprimer le début de la commande qui je pense est la copie de votre domaine pour ne conserver que la deuxième partie à partir du deuxième docker.

Désolé pour le retard. C'est très succinct. Ca a le mérite de défricher. Il faudrait effectivement agrémenter de vues. J'ai voulu essayer mais il faut que le groupe et le ou les volume(s) du NAS source soient OK, et il faut que le groupe de destination soit au moins strictement égal ou supérieur au groupe cible car le transfert se fait par blocs. J'avais d'abord tenté en dégradant le volume de destination pour récupérer un disque pour la cible. Ca n'a pas marché à cause du groupe dégradé. J'ai reconstruit le groupe et utilisé un disque de même capacité dans la cible, mais là non plus ça n'a pas marché car soit disant le disque cible était plus petit que la destination (il devait manquer quelques octets...). J'ai abandonné. Il semblerait que cette méthode soit une bonne alternative mais je n'ai pas pu tester pour en parler. Les paquets tiers notamment ne sont pas sauvegardés. C'est d'ailleurs ce qui est dit plus loin. Pour le reste, je n'ai guère de temps pour approfondir, désolé.

C'est pas trop tôt ! Ces trapanelles de routeurs vont enfin être capables de gérer les VLAN et de partitionner le réseau, ce qu'ils auraient dû pouvoir faire dès le début. De ce que j'ai compris, le multigig sera dispo sur un seul port du nouveau routeur. Mais quid pour les NAS ?

Merci pour le retour.😉

On voit souvent sur le forum des tests qui bloquent à 90% et ce n'est généralement pas bon signe (disque défaillant).

Etrange en effet. Voila une mission toute indiquée pour le support....

Si ça peut aider :

Votre NAS est doté d'une extension PCIe. Ce serait plutôt de ce côté là qu'il faudrait regarder afin de mettre en place une solution pérenne et supportée par Synology.

Je ne suis pas aller voir les liens. Je viens de regarder le dernier et tout est dit dès le départ. Cette "bidouille" n'a rien d'officiel, elle utilise un paquet tiers dont la maintenance sera faite au bon vouloir de son auteur, et je ne donne pas longtemps à Synology pour trouver la parade et brider un peu plus DSM pour interdire ce genre d'utilisation. Donc oui, passer en 2.5Gb vous apportera un gain substantiel, maintenant le faire par cette méthode me semble amha pour le moins hasardeux et à vos risques et périls.

A mon avis, la première solution ne vous permettra pas plus de 1Gb puisque c'est la vitesse du lien qui est à prendre en compte. Et pour la deuxième, elle ne fonctionnera pas car les ports USB du NAS ne sont pas prévus pour se connecter au NAS (et donc à DSM) mais seulement pour des transferts de fichiers et/ou de la communication avec des unités externes (UPS par exemple). Pour cela, il vous faudrait une carte PCIe (si votre NAS possède un port de ce type). Ce qui est sûr c'est que vous aurez forcément de l'amélioration en passant en 2.5Gb si votre réseau suit.

@Jeff777 @maxou56 @byothe Pour information : Je viens de créer un certificat LE sur 3 niveaux et je viens ici signaler une erreur dans ce que j'ai écrit précédemment. A partir du moment où il y a un ndd en wildcard, on ne peut pas ajouter dans la même demande un ndd en dur qui est déjà couvert par le wildcard sinon il y a une erreur de ce type : Create new order error. Le_OrderFinalize not found. { "type": "urn:ietf:params:acme:error:malformed", "detail": "Error creating new order :: Domain name \"tartanpion.ndd.fr\" is redundant with a wildcard domain in the same request. Remove one or the other from the certificate request.", "status": 400 En supprimant tartanpion.ndd.fr du SAN, le certificat se crée sans problème.

Tu as raison. En relisant tout le fil, je ne suis finalement pas sûr que @byothe ait émis un certificat via acme.sh, et encore moins s'il a un wildcard. Donc pour clarifier pour @Jeff777, on peut très bien faire un certificat sur plusieurs niveaux via DSM. Il faut dans ce cas renseigner tous les noms dans le SAN. Donc, un certificat couvrant ndd.fr, nas.ndd.fr, tartenpion.nas.ndd.fr est tout à fait possible. Il faut simplement que tous les ndd du SAN soient existants dans la zone publique et puissent être résolus, peu importe que la zone comporte des noms en dur et/ou des wildcards. Ceci étant dit, même si elle exige un certain niveau de maitrise, la méthode acme.sh est tout de même préférable, ne serait-ce que par le fait qu'il n'y a aucune ouverture de port à faire dans le parefeu et le routeur pour les renouvellements.

Comme l'a dit @Kramlech, le wildcard est uniquement réservé aux adresses Synology si on passe par DSM (mode HTTP-02). Aucun problème lorsqu'on passe par la méthode acme.sh (mode DNS-02), que ce soit par docker ou par ssh. Ainsi, dès lors qu'on parle de wildcard sur un ndd autre que Synology, le certificat est obligatoirement généré par une méthode externe à DSM en mode DNS-02

un seul suffit. ndd.fr, *.ndd.fr, tartanpion.ndd.fr, *.tartanpion.ndd.fr

A mon avis, le problème vient du fait que votre groupe est plein à 100%. Il n'a aucune marge pour lancer la restructuration des bandes. Il faudrait à mon sens déplacer quelques dossiers sur un disque externe pour donner un peu d'air au groupe le temps de l'augmentation.

Là, mis à part que votre système est sain et que votre volume est plein à 100%, on ne voit rien. Postez des vues du groupe de stockage, du volume et des hdd pour qu'on puisse comprendre.

Comme sur tout forum, un petit passage par la section des présentation est très apprécié. Certains y sont sensibles. Vous ne pourrez pas réutiliser le volume existant sur le disque car il y aurait conflit avec le nouveau volume portant le même numéro. Si vous n'avez pas besoin de vos données, vous pouvez directement faire la manip à partir du NAS. Dans le gestionnaire de stockage, menu HDD/SSD, votre disque devrait être indiqué comme étant en panne. Vous le sélectionnez et en cliquant sur le bouton Action, vous choisissez Désactiver le disque. Attention de ne pas vous tromper de disque ! Vous redémarrez le NAS (ou vous sortez et remettez le disque à chaud si votre NAS est compatible). Le disque devrait être noté comme étant non initialisé. Il vous suffit ensuite d'aller dans le menu Groupe pour soit rajouter le disque au groupe existant, soit créer un nouveau groupe sur ce disque et d'y monter un nouveau volume.

L'info y était mais vous l'avez supprimée... Ce n'est tout de même pas très compliqué de localiser un dossier partagé qui contient les mêmes fichiers que ceux qui sont inclus dans le périmètre de la sauvegarde. Il suffit de chercher un peu et ça devrait pouvoir se trouver sans difficulté.

Ce n'est pas une sauvegarde mais une synchro entre votre sauvegarde Blackblaze et Cloud Sync. C'est dans la liste des tâches de Cloud Sync. Mais comme vous avez supprimé le paquet, c'est maintenant difficile de le retrouver. Il vous faut chercher dans File Station et dans le menu des dossiers partagés le dossier qui recevait cette synchro et le supprimer. Je ne peux guère vous aider. Vous ne touchez surtout pas à la sauvegarde entre votre NAS et Blackblaze, on est bien d'accord.

Il faut bien entendu avoir une sauvegarde de ses données sur un autre support et dans un autre lieu. Que ce soit Blackblaze ou autre, c'est votre choix. Par contre, je ne vois aucun intérêt à synchroniser la sauvegarde externe du NAS sur le NAS lui-même. Ca ne sert à rien. Supprimez la synchro de Cloud Sync et ça devrait être suffisant. En supprimant cette synchro, les dossiers devraient être supprimés automatiquement. Au pire, vous supprimez manuellement le dossier partagé associé à votre synchro. Il est indiqué dans la liste des tâches.

Tout dépend de ce qu'il y a dans blackblaze. S'il y a la sauvegarde de votre NAS et qu'en plus vous la synchronisez dans Cloud Sync, vous faite un doublon de vos données sur le NAS. Si vous supprimez 50Go dans Cloud Sync qui ne fait qu'une synchro de Blackblaze vers le NAS, forcément ils vont se re-remplir à la prochaine synchro. Je pense que vous devriez regarder de plus près la pertinence de votre couple blackblaze/CloudSync

@.Shad. Cloud Sync n'est en principe qu'une synchronisation avec un cloud externe. Il ne fait pas de versionning. Il se comporte exactement comme la version PC. Le nombre d'enregistrements maximum par défaut est à 20000. C'est le nombre d'enregistrements du journal. Ca n'a pas d'incidence sur le stockage. A moins que cloudsync soit couplé avec des clouds démesurés, je ne vois pas d'appli qui pourrait remplir les disques. Ou alors il y a des services qui ne sont pas listés...

Pourquoi je ne suis pas surpris..... Content pour vous si vous êtes arrivé au bout des 15 jours d'errance et d'incertitude.