gaetan.cambier

Faudrait un test pour voir la différence de perd entre les nouveau bonding et le 802.3ad

715 oui forcément vu qu'il l'ont compiler, c'est pas pour rien Le 715+, faudra voir, rien de sûr

bizarre, tes 2 précédent clonage avait très bien fonctionné :s le disk est bien ok ? tu as fais un test smart etendu ?

le + sur sera d'attendre le support syno ses extention sont qd meme une vrai faiblesse, c'est toujours dessus que ca plante :s

Je l'ai déjà fait remonté ce problème, mais ça n'a jamais été changé. Comme souvent, ma première recherche est pas bonne, après faut attendre sans raison (faut surtout pas me dire que 2ou 3pauvre recherche vont faire tomber un serveur)

pour ma part j'en ait beaucoup moin que cela et pourtant plein de chose tourne sur mon nas : SSH tcp 22 (avec restriction ip) HTTP tcp HTTPS tcp 443 CloudStation tcp 6690 (avec restriction ip) Torrent tcp 6881 IPSEC udp 500, udp 1701, udp 4500 Ce que fait deja pas mal, faudrai m'expliquer comment arrivé à 36

ca fait combien de temps que tu as lancé cette mise à jour ?

36 port, c'est journée porte ouverte chez toi ?

le ds715 est en architecture alpine, juste pour la precision, tous les package ne seront pas forcement compatible (docker, plex, ...)

Pour générer le .SQL, tu supprime la compression du script mais le fichier ça prendre au moins 20 fois + de place

Pour les personne qui test, on pourrait savoir les paquet de la communauté utilisé et si c'est bien ok ? pour savoir si il y a pas des problèmes de ce coté

pas de soucis

J'avais dis que ca serai plus rapide oui, tu peux refaire la meme chose pour tes autres disques, la procédure est toujours la meme attention à ses commande : DiskStation> sfdisk -l /dev/sdb /dev/sdb1 256 4980735 4980480 fd /dev/sdb2 4980736 9175039 4194304 fd /dev/sdb3 9437184 5860528064 5851090881 fd DiskStation> sfdisk -N3 -o9437184 -z-1 -tfd /dev/sdb le nombre "9437184" de la 2° commande provient de la 1° commande et peux varier !!! faut surtout pas se tromper et la paramètre -N3 car sdb3 ca pourrai etre 5, ca arrive sur certaine partition tu peux effectiverment changer d'un dx213 --> dx513, tant que tu remet tes disque dans le meme ordre, il y aura aucun problème

ok, tu peux essayer le bouton gérer à mon avis tu peux toujours refaire si ca va pas un : cat /proc/mdstat

donc, tu as mis un disque de 4TO bon, au lieu de faire un reboot, tu va : enlever le disque attendre 30 sec remettre le disque (pense à couper les alarme, ca risque de sonner ) le syno la relire la partition et prendre en compte les nouvelles données ensuite : tu démonte le volume2 umount -f /volume2 tu stoppe le raid correspondant : mdadm -S /dev/md3 on met à jour la taille : mdadm -A /dev/md3 /dev/sdb3 --update=devicesize on reverifie l'état du raid : cat /proc/mdstat et puis, tu reboot

ou via ton vendeur, ton vendeur va te faire un echange standard le sav syno, va lui te renvoyer un ventillo a changé surement, l'avantage, c'est que le nas restera chez toi

l'informatique, ca tombe en panne souvent qd c'est neuf, ou alors après, c'est presque increvable

bon, on agrandis la taille de la partition : sfdisk -N3 -o9437184 -z-1 -tfd /dev/sdb on verifie le résultat : sfdisk -l /dev/sdb au passage, j'aurai besoin de l'etat du raid : cat /proc/mdstat PS: on va faire essayer de faire + court que la dernière fois

bon, je m'y colle si j'ai bien compris, on doit travailler sur ton disque 2 --> "sdb" on va commencer doucement par ceci en ssh : sfdisk -l /dev/sdb pour voir ou on en est

le + sur, c'est d'ouvrir un ticket auprès de synology, ils vont te reconstruire le raid p-e un bug sur ton ancien nas, en théorie, c'est click click bouton et çà fonctionne tu peux aussi le tenter toi meme en ligne de commande, mais bon, au vu de l'erreur, je laisserai faire syno, ils connaissent mieux les problème de raid de leur matériel

tu peux brancher les disque et les enlever en usb, c'est pas un problème. en général, la sauvegarde se fait par dossier partager --> pense a avoir les disque assez grand par rapport à chaque dossier partagé

A noté aussi que des volume trop rempli augmente la fragmentation, il y a pas de miracle, si les disques sont full, ça fragmentera

Ajouter plusieurs disques est supporté, mais dangereux en cas de problème disque durant la reconstruction, vaut mieux les mettre 1 à 1

ip forward n'est probablement pas activé sur le syno pour le verifier, c'est simple en ssh : cat /proc/sys/net/ipv4/ip_forward 0 ou 1 comme reponse pour l'activer : echo 1 > /proc/sys/net/ipv4/ip_forward c'est ma première iddée, si ca ne change rien, faut faire un tracert pour voir ou le paquet se perd ...

Tu as bien installe java ?