Mic13710

Ni l'une, ni l'autre. La première ne peut pas fonctionner car il n'y a pas de gestion des adresses réseau (un serveur DHCP) et même si c'était possible, ça n'irait pas plus vite. La deuxième parce que le syno va installer un nouveau dsm et formater votre disque. Il faut continuer à faire les transferts du PC vers le NAS et être patient. Sortez, prenez l'air, jardinez, bricolez, faites la sieste ou autre. Bref, laissez du temps au temps, lancez vos copies et prenez du bon temps. P.S. : le contrôle de parité freine beaucoup les transferts ....

Oooops! a encore une fois été à la hauteur et plus rapide que moi. Personnellement, je n'aime pas trop la deuxième alternative. Trop de manipulations des données et des disques. A n'utiliser que si vraiment rien ne fonctionne. Je ne connais pas du tout Ubuntu, mais il doit être possible de connecter un lecteur réseau comme on le ferait avec windows, sans oublier un point important : il faut activer le service NFS dans le panneau de configuration - Win/Mac/NFS ou son équivalent dans DSM5.0 pour permettre la communication sous linux. Peut-être faudra t'il aussi passer par Synology assistant version linux pour mapper le disque du nas. Mais pour moi, Linux est suffisamment flexible et devrait permettre de faire le lien entre PC et NAS sans grande difficulté. Une fois ce lien établi, les transferts peuvent se faire indifféremment par FileStation ou par le gestionnaire de fichier d'Ubuntu.

Bonjour niflon, Après les interventions d'Oooops! et domlas, je n'ai vraiment plus grand chose à dire . Je pense que vous avez tous les éléments pour faire votre choix entre basic et raid. Comme l'a fort justement dit domlas, si vous optez pour une solution raid ou shr, l'onduleur est un must. Petite réflexion en passant : Bien qu'on puisse y mettre 4 disques en basic, un nas 4 baies est plutôt conçu pour héberger des solutions raid ou shr. Même si les disques sont un peu plus sollicités, les gros avantages du raid par rapport au basic sont que la perte d'un disque n'entraine pas la perte des données, que le service peut continuer sur le disque restant, et que la reconstruction du raid se fait en tâche de fond une fois le disque défectueux remplacé par un nouveau qui aura été préparé préalablement. Le basic demandera une réinstallation complète. Enfin, même si une solution de migration existe pour votre ancien disque, je rejoins totalement la proposition d'Oooops! pour au moins 2 bonnes raisons : - votre nas étant en défaut, la migration de 4.3 vers la 5.0 ne s'est peut-être pas déroulée correctement, - les problèmes rapportés sur la 5.0 sont essentiellement liés à des migrations. Repartir d'une installation neuve avec DSM 5.0 et la toute dernière évolution qui vient de sortir me semble être le meilleur choix. C'est très certainement plus long, mais vous serez sûr au final de ce que contient votre nas.

Salut niflon, Où en êtes-vous avec vos disques ? Si ce n'est pas concluant, il vous restera au final la préparation dans le nas en passant par telnet/ssh. J'ai eu les instructions si vous en avez besoin, mais il ne faut pas avoir peur de se lancer dans des lignes de commandes en linux.

Dommage que je n'ai pas noté les instructions dans un coin de mon pc. Comme je n'y connais rien en Linux, je ne pourrai guère vous aider sur le coup. Je vais poser la question à quelqu'un qui a peut-être gardé des infos.

j'ai l'explication pour le tuto de fred : c'est encore un dommage collatéral de dsm5. Cette version est une vraie tuerie ! Ca va être dur pour retrouver les instructions en ssh, à moins qu'une âme charitable passe par là. Avez vous essayé de lancer windlg en mode administrateur ? Ne vous obstinez pas avec roadkil : il ne peut pas traiter des disques de plus de 2To. Je suis tout de même surpris qu'il s'arrête à 1.67To. N'avez-vous pas créé une partition ? Pour que roadkil fonctionne, il est recommandé de supprimer d'abord les partitions. De même, Roadkil doit être lancé en mode administrateur.

Tout est expliqué dans ce tuto Synology

Il y a effectivement un problème d'accès au tuto de fred. J'espère que c'est temporaire. Roadkil diskwipe ne sait pas traiter les DD au delà de 2To. C'est pour cela qu'il n'affiche pas la capacité totale. Pour windlg, je ne peux pas dire grand chose, je ne le connais pas. Surprenant tout de même que l'écriture des zéros ne soit pas possible. Avez-vous regardé ce ? J'ai préparé mes disques à partir du Syno en passant par ssh et PuTTY avec la méthode du tuto de fred. Elle n'est pas bien compliquée à mettre en oeuvre si on suit correctement la procédure et les commandes associées. Il reste à souhaiter que fred remette son tuto en ligne car je ne me rappelle plus des commandes.

Il se trouve que j'ai 4 axis 207, 2 x 207 normales connectées en filaire, 1 x 207W connectée en wifi et 1 x 207MW connectée aussi en wifi. Exceptée cette dernière qui souffre de quelques déconnexions qui sont liés à un problème de distance (wifi dégradé), je n'ai pas de problèmes de déconnexions liés au fonctionnement de Surveillance Station. Il semblerait à priori que tous ces soucis proviennent de la version 5.0 car je suis encore (et pour un bon moment je pense) en DSM 4.3. Il y a encore pas mal de défauts de jeunesse à corriger avant d'avoir une version enfin opérationnelle. Il faudra se montrer patient. C'est en tout cas ce que je vais faire.

En fait, les cas de figures en opération sont assez simples : uniquement lorsque le nas démarre automatiquement pour lancer des sauvegardes, la surveillance est inutile est doit être arrêtée. Pour tous les autres cas (démarrage manuel ou au travers du wol), surveillance station doit rester actif. Si je souhaite travailler sur le DSM, je peux très bien démarrer le nas par le wol et désactiver SS si besoin. Le seul petit bémol que je vois avec le démarrage auto c'est lors des changements d'horaires hiver/été qui risquent de perturber les sauvegardes du fait des décalages d'une heure entre les deux nas. Mais ce n'est que deux fois par an et je peux éventuellement lancer les sauvegardes manuellement si besoin. A ce propos, je crois avoir vu dans les fichiers que le nas procèdait à la mise à jour de l'horloge au démarrage. Est-ce exact ? Le deuxième volet de ce que je souhaite faire concerne l'arrêt du nas secondaire une fois les opérations de sauvegardes terminées. Pour le moment, les cron de mes 7 sauvegardes sont dans le nas principal. Le secondaire est complètement aveugle et ne fait que faire des enregistrements en fonction des requêtes du nas principal. Il faudrait qu'il puisse savoir si toutes les sauvegardes sont terminées pour pouvoir initier un signal d'arrêt. L'arrêt du nas serait alors conditionné par le status de surveillance station : si actif, l'arrêt est retardé jusqu'à ce que la surveillance soit désactivée. Si désactivé, arrêt immédiat. La encore, je ne suis pas capable de dire si c'est réalisable et encore moins comment le faire. Mais ce sujet, bien qu'il corresponde à mon "plus si affinité", sort un petit peu du cadre de ce fil et fera je pense l'objet d'une autre discussion. Voila, je pense n'avoir rien oublié. Reste à mettre tout ça en musique et c'est là tout mon problème. Merci à toi si tu peux m'aider à mettre le ou les scripts en place.

Pour les mise à jour, pour éviter de charger le mauvais fichier, le mieux et d'utiliser la fonction de mise à jour du DSM du panneau de configuration. Tout d'abord, cette mise à jour sera faite de manière chronologique parce qu'il n'est pas du tout certain que vous puissiez passer directement de la 4.1 à la 4.3. Le NAS ne vous proposera que la version que vous pouvez télécharger en fonction de celle installée dans le NAS. Par contre, je vous déconseille fortement de mettre la 5.0 pour le moment, surtout si c'est un NAS qui tourne dans un environnement professionnel. Pour ne charger que les versions critiques, vous avec un choix à faire dans le menu de mise à jour. Pour cela vous cliquez sur "Options de mise à jour" et vous choisissez "Mises à jour importantes". La 5.0 n'étant pas une mise à jour importante, elle ne vous sera pas proposée, donc pas de risque de la télécharger par mégarde. Avec cette option, vous devriez vous arrêter à la 4.3-3827 Update 1 qui comporte la correction de la faille de sécurité. Mais à la vue de vos remarques, je ne crois pas que vous soyez affecté. Et comme le dit domlas, vous avez sûrement une solution de sauvegarde mise en place, surtout si ce sont des données professionnelles dont la perte serait dommageable pour l'entreprise. Même s'il y a toujours un risque que la maj ne se passe pas bien, il est malgré tout très limité dans la mesure où vous évoluez de la 4.1 vers la 4.3, donc dans une même version du DSM. Ce sont des évolutions et non des révolutions. Dans le cours ou à la suite à vos mises à jour, il est possible que vous ayez à remettre à jour des paquets. Là encore, les risques sont limités.

En fait, je ne suis pas du tout certain que le démarrage ou l'arrêt du paquet dans le DSM soit la solution car il y a du même coup la perte des paramètres. En fait, quand on arrête le paquet, tous les paramètres de connexion qui ont été mis dans le portail des applications sont perdus, ce qui du même coup interdit toute connexion directe par le DSM ou DSCam. C'est absurde mais c'est comme ça que ça fonctionne, ou plutôt que ça ne fonctionne pas. Je crois que le seul moyen accessible sans trop se prendre la tête c'est d'utiliser le start-stop-status qui assure l'activation/désactivation de SS tout en laissant le paquet en opération. Seulement voilà, si je vois bien maintenant ce qu'il faut faire, je ne sais malheureusement ni lire ni écrire des partitions Linux. Tout d'abord, je ne sais pas s'il est possible de capturer le mode de démarrage (manuel, par WOL ou bien automatique) Ensuite, je ne sais pas comment se comporte le démarrage automatique si le nas est déjà allumé. Est-ce que le démarrage auto est inhibé ? Si le démarrage auto peut-être capturé et si et seulement s'il a effectivement démarré le NAS, alors il s'agit dans mon cas d'un démarrage pour faire la sauvegarde et SS est inutile. On peut donc envoyer un stop pour arrêter SS juste après son démarrage. Pour ce script, on peut peut-être utiliser le start-stop-status status, mais je n'ai aucune idée de ce qu'il renvoit, ou bien encore vérifier la présence du fichier temporaire /var/tmp/ssrunning qui lui n'existe que si SS est actif. Si c'est un démarrage manuel ou par le WOL, c'est que je souhaite faire de la surveillance et on laisse donc SS en opération. Si entre temps le démarrage auto est arrivé à échéance pour effectuer les sauvegardes programmées, il ne faut pas bien entendu que SS soit arrêté. Voilà comment je vois les choses. Est-ce que c'est faisable et comment, c'est toute la question.

Oui bien sûr. Surveillance Station ne redémarre pas. Enabled c'est apparemment la mémorisation du choix utilisateur pour le paquet SS. S'il est présent, SS démarre avec le NAS, sinon SS reste à l'arrêt. Comme Surveillance Switch semble agir autrement et se contrefiche de la présence ou non du enabled, de même qu'il n'utilise pas le start-stop-status pour démarrer ou arrêter la surveillance, je ne vois qu'une seule issue, c'est de laisser SS démarrer avec le NAS et de faire un arrêt de SS suivant critères comme j'en ai parlé dans mon message #15. Qu'en penses-tu ?

Premiers retours. Tout d'abord quelques relevés dans le fichier /var/log/surveillance.log Arrêt du paquet SS à partir du centre des paquets de DSM Apr 19 13:46:42 services.cpp:573:StopAllSsd(): Try to stop cam[1]. Apr 19 13:46:42 services.cpp:573:StopAllSsd(): Try to stop cam[2]. Apr 19 13:46:42 services.cpp:573:StopAllSsd(): Try to stop cam[3]. Apr 19 13:46:42 ssd.cpp:170:main(): Cam[1]: Signal! Stop retry init(). Apr 19 13:46:42 services.cpp:573:StopAllSsd(): Try to stop cam[4]. Apr 19 13:46:42 ssd.cpp:187:main(): Cam[3]: Signal! Stop ssd. Apr 19 13:46:42 ssd.cpp:187:main(): Cam[2]: Signal! Stop ssd. Apr 19 13:46:42 ssd.cpp:187:main(): Cam[4]: Signal! Stop ssd. Apr 19 13:46:47 vsctrld.cpp:109:main(): Stop vsctrld. Apr 19 13:46:47 ssrotated.cpp:695:main(): Stop ssrotated. Apr 19 13:46:48 ssfindhostd.cpp:49:SSFHOSTDExit(): Stop ssfindhostd. Apr 19 13:46:49 services.cpp:655:Kill(): [sscmshostd] is not running. Apr 19 13:46:49 sscored.cpp:167:main(): Stop sscored. Le fichier /var/packages/SurveillanceStation/enabled est supprimé Démarrage du paquet SS à partir du centre des paquets de DSM Apr 19 13:48:12 sscored.cpp:109:main(): Start sscored. Apr 19 13:48:13 ssrotated.cpp:658:main(): Start ssrotated. Apr 19 13:48:13 ssfindhostd.cpp:266:main(): Start ssfindhostd. Apr 19 13:48:13 vsctrld.cpp:48:main(): Start vsctrld. Apr 19 13:48:13 services.cpp:530:StartAllSsd(): Try to start cam[1]. Apr 19 13:48:13 services.cpp:530:StartAllSsd(): Try to start cam[2]. Apr 19 13:48:13 services.cpp:530:StartAllSsd(): Try to start cam[3]. Apr 19 13:48:13 services.cpp:530:StartAllSsd(): Try to start cam[4]. Le fichier /var/packages/SurveillanceStation/enabled est créé Arrêt de la surveillance à partir de l'appli android Surveillance Switch Apr 19 13:40:00 services.cpp:573:StopAllSsd(): Try to stop cam[1]. Apr 19 13:40:00 services.cpp:573:StopAllSsd(): Try to stop cam[2]. Apr 19 13:40:00 services.cpp:573:StopAllSsd(): Try to stop cam[3]. Apr 19 13:40:00 services.cpp:573:StopAllSsd(): Try to stop cam[4]. Apr 19 13:40:00 ssd.cpp:187:main(): Cam[1]: Signal! Stop ssd. Apr 19 13:40:00 ssd.cpp:187:main(): Cam[4]: Signal! Stop ssd. Apr 19 13:40:00 ssd.cpp:187:main(): Cam[3]: Signal! Stop ssd. Apr 19 13:40:00 ssd.cpp:187:main(): Cam[2]: Signal! Stop ssd. Apr 19 13:40:05 vsctrld.cpp:109:main(): Stop vsctrld. Apr 19 13:40:06 ssrotated.cpp:695:main(): Stop ssrotated. Apr 19 13:40:07 ssfindhostd.cpp:49:SSFHOSTDExit(): Stop ssfindhostd. Apr 19 13:40:08 services.cpp:655:Kill(): [sscmshostd] is not running. Apr 19 13:40:08 sscored.cpp:167:main(): Stop sscored. Le fichier /var/packages/SurveillanceStation/enabled n'est pas supprimé Démarrage de la surveillance à partir de l'appli android Surveillance Switch Apr 19 13:44:49 sscored.cpp:109:main(): Start sscored. Apr 19 13:44:51 ssrotated.cpp:658:main(): Start ssrotated. Apr 19 13:44:51 ssfindhostd.cpp:266:main(): Start ssfindhostd. Apr 19 13:44:51 vsctrld.cpp:48:main(): Start vsctrld. Apr 19 13:44:51 services.cpp:530:StartAllSsd(): Try to start cam[1]. Apr 19 13:44:51 services.cpp:530:StartAllSsd(): Try to start cam[2]. Apr 19 13:44:51 services.cpp:530:StartAllSsd(): Try to start cam[3]. Apr 19 13:44:51 services.cpp:530:StartAllSsd(): Try to start cam[4]. Arrêt dans PuTTY par /var/packages/SurveillanceStation/scripts/start-stop-status stop Apr 19 13:50:41 services.cpp:573:StopAllSsd(): Try to stop cam[1]. Apr 19 13:50:41 services.cpp:573:StopAllSsd(): Try to stop cam[2]. Apr 19 13:50:41 services.cpp:573:StopAllSsd(): Try to stop cam[3]. Apr 19 13:50:41 services.cpp:573:StopAllSsd(): Try to stop cam[4]. Apr 19 13:50:41 ssd.cpp:187:main(): Cam[2]: Signal! Stop ssd. Apr 19 13:50:41 ssd.cpp:187:main(): Cam[4]: Signal! Stop ssd. Apr 19 13:50:41 ssd.cpp:170:main(): Cam[1]: Signal! Stop retry init(). Apr 19 13:50:41 ssd.cpp:187:main(): Cam[3]: Signal! Stop ssd. Apr 19 13:50:44 vsctrld.cpp:109:main(): Stop vsctrld. Apr 19 13:50:45 ssrotated.cpp:695:main(): Stop ssrotated. Apr 19 13:50:46 ssfindhostd.cpp:49:SSFHOSTDExit(): Stop ssfindhostd. Apr 19 13:50:47 services.cpp:655:Kill(): [sscmshostd] is not running. Apr 19 13:50:47 sscored.cpp:167:main(): Stop sscored. Le fichier /var/packages/SurveillanceStation/enabled n'est pas supprimé Démarrage dans PuTTY par /var/packages/SurveillanceStation/scripts/start-stop-status start Apr 19 13:52:44 sscored.cpp:109:main(): Start sscored. Apr 19 13:52:45 ssrotated.cpp:658:main(): Start ssrotated. Apr 19 13:52:45 ssfindhostd.cpp:266:main(): Start ssfindhostd. Apr 19 13:52:45 vsctrld.cpp:48:main(): Start vsctrld. Apr 19 13:52:45 services.cpp:530:StartAllSsd(): Try to start cam[1]. Apr 19 13:52:45 services.cpp:530:StartAllSsd(): Try to start cam[2]. Apr 19 13:52:45 services.cpp:530:StartAllSsd(): Try to start cam[3]. Apr 19 13:52:45 services.cpp:530:StartAllSsd(): Try to start cam[4]. Conclusion : exception faite du /var/packages/SurveillanceStation/enabled qui n'est modifié qu'à partir du paquet, les logs sont identiques quel que soit le mode d'activation ou de désactivation de la surveillance. A noter toutefois une légère difficulté à arrêter la cam 1. C'est simplement dû à un problème de connexion sur cette caméra que je dois encore régler. Les logs étant identiques, je me suis dit qu'il suffisait alors de modifier le script start-stop-status pour y intégrer la suppression ou la création du /var/packages/SurveillanceStation/enabled En me servant des instructions proposées par Fravadona, j'ai rajouté les lignes suivantes : start() { if [ ! -f $PACKAGE_ENABLED ]; then exit 0; fi # Lignes rajoutées pour restitution du Enabled /bin/touch /var/packages/SurveillanceStation/enabled /bin/chmod 3377 /var/packages/SurveillanceStation/enabled stop() { RemoveWebapiLink # stop services ${SCRIPTS_DIR}/S82surveillance.sh stop # remove index and help entry ${DSM_INDEX_DEL} ${PKG_APP_PATH}/index.conf ${PKG_INDEXDB_PATH}/appindexdb # Lignes rajoutées pour suppression du Enabled /bin/rm /var/packages/SurveillanceStation/enabled En passant par PuTTY, /var/packages/SurveillanceStation/scripts/start-stop-status stop supprime bien /var/packages/SurveillanceStation/enabled mais malheureusement /var/packages/SurveillanceStation/scripts/start-stop-status start ne fonctionne pas et ne recréé pas le fichier enabled. Et en passant par Surveillance Switch, l'activation et la désactivation fonctionnent, mais contrairement à ce que je pensais au départ, cette appli n'utilise pas /var/packages/SurveillanceStation/scripts/start-stop-status pour activer ou désactiver la surveillance. Je n'arrive pas à comprendre comment cette appli fonctionne. Autre constatation très surprenante avec Surveillance Switch : quel que soit le status de Surveillance Station dans le DSM (activé ou arrêté), l'activation et la désactivation se fait sans problème, les caméras détectent les mouvements et enregistrent les séquences, et le NAS envoi les notifications comme si Surveillance Station était en opération alors qu'il est arrêté pour DSM et donc inaccessible ! Donc pour le moment, si je ne veux pas que Surveillance Station soit activé au démarrage du NAS, je doit arrêter le paquet dans le DSM. Dans ce cas, les sauvegardes automatiques peuvent se faire sans que Surveillance Station se lance. Si je veux lancer la surveillance, je peux utiliser le module de contrôle de l'alim du NAS dans Surveillance Switch pour démarrer le NAS, puis activer la surveillance. Les enregistrements se font, je reçois les notifications, mais je n'ai aucun accès possible à Surveillance Station soit par DSM et encore moins par DSCam pour pouvoir lire les enregistrements. Ce n'est pas vraiment satisfaisant comme mode de fonctionnement et certainement pas très orthodoxe, mais mes connaissances en Linux étant quasi inexistantes, je suis bloqué.

Merci Fravadonna pour ces éléments de réponses. Je vais regarder tout ça. J'ai bien vu le enabled dans le suveillance station et en le supprimant, SS ne peut pas démarrer. Mais le problème, c'est que Surveillance Switch est alors incapable de démarrer SS et reçoit même des infos contradictoires du nas qui lui dit que les caméras sont activées alors que le paquet SS n'est pas démarré ! Pour que Suveillance Switch puisse fonctionner, il faut que SS soit démarré. Il doit ensuite probablement utiliser /var/packages/SurveillanceStation/scripts/start-stop-status pour arrêter ou démarrer SS. Mon idée, c'était de laisser démarrer SS et de lui envoyer un cron dépendant du jour et de l'heure et de la condition du démarrage (soit auto, soit manuel ou wol) et du temps d'activité (si le nas était en opération avant le cron de démarrage auto pour la sauvegarde, c'est que Surveillance Station est en opération) pour arrêter ou non SS. Je vais étudier tes propositions (pas tout de suite car je suis occupé) et je reviens vers toi dès que possible.

Personne n'a une petite idée ?

A quoi bon avoir un réseau Gb pour le freiner avec du wifi. Les liaisons wifi sont très loin d'offrir des débits suffisants pour permettre des transferts convaincants. Mais vous jugerez par vous-même.

Si vous montez vos disque en basic, l'onduleur n'est pas indispensable. Pour le switch Gb, tout dépend de votre installation mais il vous faut un réseau Gb pour ne pas brider les échanges NAS - PC. Si votre box est en Gb, nul besoin d'un switch supplémentaire, sauf pour étendre votre réseau. Avec un box en 100Mb, je vous conseille vivement de mettre un switch Gb. Vous pouvez créer des raccourcis et/ou des favoris dans DSM à partir de file station. Une fois que vous aurez mappé vos disques, vous pourrez aussi créer tous les raccourcis que vous voudrez sur votre PC ou MAC.

Syno confirme bien que le NAS a un défaut. Leur réponse ne me surprend pas. Il est normal de se tourner vers le revendeur plutôt que le constructeur. Normal aussi que le constructeur prenne le pas et assure le remplacement en cas de défaillance du revendeur.

Pour le Raid 0 ou JBOD vous avez raison : si un disque lâche, vous perdez tout. En raid1 si un disque lâche, les données sont toujours dispos sur le disque sain. Il suffit de remplacer le disque défectueux par un neuf de capacité au moins équivalente, puis de reconstruire le raid pour retrouver un raid opérationnel. Pour le basic, je ne comprends pas bien votre question. Si vous créez deux disques en basic, vous perdez toutes les données contenues dans le disque qui tombe en panne. Si vous ne montez qu'un disque, vous pouvez choisir de le monter en basic mais ce n'est pas une obligation. Vous pouvez choisir de le monter en raid à un disque et vous construirez votre raid plus tard. Dans tous les cas de figure, il faut impérativement avoir une sauvegarde périodique des données les plus importantes soit sur un disque externe, soit sur vos pc, soit avec un autre nas, soit avec une solution externalisée. Edit : si votre choix est de faire un RAID0, alors oui vous ne pourrez pas le créer ultérieurement si vous ne mettez qu'un disque au départ.

Non, ce n'est pas applicable à toutes les box. Sur la Freebox V5 le switch est en 100Mb alors que nos nas et les PC actuels sont en Gb. Mais s'il y a d'anciens équipements en 100Mb, ils peuvent être connectés sur la Freebox puisqu'ils ne gagneront rien à être sur un switch Gb. La V6 (Freebox Revolution) est en Gb.

Décidément, cette 5.0 donne du fil à retordre à ceux qui ont eut la mauvaise idée de s'y aventurer. Avez-vous vérifié les droits ? Peut-être faudrait-il les redéfinir.

Si vous avez personnalisé votre NAS, la sauvegarde de configuration n'en tiendra pas compte. Quand à cloner le disque, je n'ai pas encore vu quelqu'un réussir à le faire. Mais comme vous le dites, attendez d'autres avis.

Je viens de comprendre pourquoi le paquet redémarre tout seul au démarrage du NAS. En fait, si SS est arrêté à partir de Surveillance Switch, il n'est pas vraiment arrêté en tant que paquet comme il le serait à partir de DSM. Il est toujours en opération dans le centre des paquets. Si bien que le redémarrage du NAS redémarre le paquet SS. Si par contre le paquet est stoppé dans le DSM, SS ne redémarre pas, ce qui est tout de même plus logique. Le hic c'est que Surveillance Switch est aveugle et peut donner une info "détection active" alors que le paquet est arrêté dans DSM. Il n'est pas capable de redémarrer SS. Il faut donc que SS soit en opération pour pouvoir avoir le contrôle depuis l'extérieur. D'où le besoin de pouvoir recréer la séquence d'arrêt une fois le NAS démarré et la positionner au bon endroit. Pas simple.

Dans ce cas, c'est plus compliqué. Vos disques sont donc 2 volumes en raid à 1 disque (pseudo basic à la mode Synology). Vous pourriez éventuellement construire votre raid en remplaçant le disque 2 par votre nouveau disque, mais je ne suis pas sûr ensuite que vous puissiez déplacer le disque 2 dans la baie 1 et ensuite étendre votre volume à 4To et recréer un raid à 1 disque. La seule solution qui me paraisse envisageable est la suivante : sauvegarde de la configuration mise en place du nouveau disque dans la baie 1, installation du DSM et création du volume restauration de la configuration et enfin transfert de vos données en 2 étapes : premier lot issu de votre volume 2 réinstallation de l'ancien disque dans la baie 1, nettoyage du volume 2 et copie des données non sauvegardée réinstallation du nouveau disque dans la baie 1 et copie des données restantes réinstallation de l'ancien disque dans la baie 1 et suppression du volume 1 réinstallation du nouveau disque dans la baie 1 et de l'ancien disque dans la baie 2 création du volume 2 et création de vos sauvegardes entre le volume 1 et le volume 2 Maintenant, vous aurez sûrement d'autres avis. Par exemple, il est peut-être possible de mettre votre volume 1 actuel dans la baie 2, de modifier son numéro et de recréer un volume 1 sur le nouveau disque installé dans la baie 1. Mais je n'en sais rien car je n'ai jamais fait ce genre de manip. Bonne chance et surtout beaucoup de patience.