Mic13710

Bonjour Maximesa56, soyez le bienvenu dans la communauté. Si vous avez des questions, ce n'est pas ici qu'il faut les poser mais dans les sections dédiées.

bonjour jeromedev51, soyez le bienvenu parmi nous. Je vous suggère de modifier le titre de votre message qui n'a pas grand chose à voir avec une présentation 😉

Surtout pas à l'abri d'un effacement accidentel, d'un crypto locker, d'une corruption des données, d'un incendie, d'un dégât des eaux, d'un vol, d'un choc mécanique,..... Perso j'attache la plus grande importance aux sauvegardes. J'en ai une locale sur un NAS et une distante sur un autre NAS. Avant de commencer, je vous conseille vivement de faire un maximum de sauvegardes sur tous les supports possibles, PC, disques externes, etc.. Ensuite, il va falloir remettre à zéro le disque actuellement dans le 720+. Vous pouvez simplement détruire le volume existant puis le groupe à partir du gestionnaire de stockage. Vous créez un nouveau groupe sur le disque et vous y montez un nouveau volume en btrfs. Vous réinstallez tous les paquets que vous avez dans le 715 et vous restaurez le fichier de configuration que vous aurez au préalable sauvegardé du 715. Vous installez aussi hyperbackup et hyperbackup Vault sur les deux NAS. Passer par Hyperbackup vous permettra de conserver les fichiers tels qu'ils sont dans le NAS d'origine. Vous pouvez vous inspirer du point 4 de cet article : https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/Backup/How_to_migrate_between_Synology_NAS_DSM_6_0_and_later Mais contrairement à ce qui est décrit, vous n'aurez probablement pas le double de capacité pour pouvoir faire une migration en une seule étape. Je vous propose de la faire petit à petit, en faisant plusieurs tâches de sauvegarde, en commençant d'abord par les données utilisateurs. Une fois que la tâche de restauration sur le 720 est terminée, vous supprimez le fichier de sauvegarde .hbk du 720 pour libérer l'espace. Vous continuez avec les dossiers partagés en faisant là aussi plusieurs sauvegardes si besoin et en supprimant le fichier de sauvegarde une fois restauré. Le principe c'est de maintenir suffisamment d'espace disque disponible pour permettre la restauration. Si l'espace libre est par exemple 1To, vous ne pourrez pas créer une sauvegarde de plus de 500Go pour pouvoir effectuer la restauration dans l'espace restant. Et comme l'espace libre diminue à chaque dossier restauré, il faut bien évidemment commencer par les dossiers les plus lourds pour terminer par les plus légers. Quelle que soit la méthode de migration, il y a un certain nombre de données et de paramètres de paquets qui ne seront pas migrés. Il faudra faire tous ces réglages à la main, mais comme vous avez les deux NAS cote à cote, il sera facile de remettre les choses d'aplomb par comparaisons. Je ne peux rien vous dire à propos de la bibliothèque Plex car je n'utilise pas. Une fois que toute les migrations sont faites et que toutes les données se retrouvent à l'identique sur le 720, vous sortez le disque du 715, vous le formatez sur un PC. Peut importe le type de formatage, le but étant de simplement casser les partitions existantes. Vous montez le disque dans le 720 et vous faite l'augmentation de volume qui va transformer votre SHR sans protection des données en SHR avec protection des données (équivalent RAID1). Bon courage.

C'est de la continuité de service. Vous vivez dangereusement, mais c'est vous qui voyez. Une sauvegarde de tout n'est pas indispensable mais au moins des données essentiels c'est un must. Beaucoup ne l'ont pas fait et s'en morde encore les doigts après avoir tout perdu. Est-ce que le 715 tourne avec le disque en place et est-ce que les données sont accessibles ?

Quel dommage ! En faisant une migration des disques, vous dégradez les possibilités du 720+ (pas de btrfs, de virtualisation, de snapshots....) et vous vous trimbalez les limitations du 715. Il eut été plus avisé de faire une installation à partir de zéro. Tout n'est pas perdu, mais il faudrait avoir des informations supplémentaires. Est-ce que vos données sont sauvegardées et si oui, est-ce avec hyperbackup ?

A l'usage, il n'y a pratiquement aucune différence entre RAID1 et SHR avec 2 disques. Le SHR est très fiable. Disons que si vous passez plus tard dans un avenir proche sur un NAS 4 baies, la migration de vos disques en SHR vous offrira la flexibilité inhérente à ce type de construction alors que le RAID sera plus limité. Après je dis ça mais tous mes NAS en 2 baies sont en RAID1. Pas tout à fait vrai mais c'est à peu près ça. Il y a des montages qui laissent des espaces inoccupés car non utilisables pour créer un RAID. Amusez vous avec le comparateur de RAID à marier des disques de différentes capacités et vous verrez.

L'installation par défaut est en SHR. Si vous voulez du RAID1, il faudra passer par l'installation avancée pour installer le premier disque en Basic qui lui peut évoluer vers du RAID1. Mais le SHR est très bien aussi 😉

Oui. Il suffira de rajouter le nouveau disque au groupe existant. Ce n'est pas la bonne formulation. C'est la mise en miroir.

Malheureusement pour vous et heureusement pour les données, je ne connais pas de moyen pour récupérer sur le NAS une clé qui est sensée protéger. Sinon ça n'aurait pas de sens du point de vue sécurité. Je crois que le meilleur moyen serait de restaurer votre sauvegarde.

Bonjour Thonysan, soyez le bienvenu dans la communauté. Avec un NAS, l'appétit vient en s'en servant et on arrive petit à petit à coder

il ne s'agit pas de rentrer dans DSM mais de réinitialiser DSM pour le reinstaller (deuxième niveau de reset) Rappel du point 2 : En réinitialisant DSM, vous pourrez repartir sur une version vierge, mais il vous faudra refaire les paramétrages et réinstaller les paquets. Vous pourrez récupérer une partie des paramètres de configuration et des paquets à partir de vos sauvegardes.

Extrait de la base de connaissance Synology : https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General_Setup/How_do_I_log_in_if_I_forgot_the_admin_password Si la méthode ci-dessus n'a pas réinitialisé votre mot de passe administrateur, il existe deux raisons possibles: Votre navigateur a enregistré votre ancien mot de passe. Essayez d'utiliser un autre navigateur ou d'ouvrir une fenêtre InPrivate (pour Edge), une fenêtre Incognito (pour Chrome) ou une fenêtre Privé (pour Firefox et Safari) pour vous connecter avec le nouveau mot de passe. Vous avez choisi de laisser le mot de passe administrateur inchangé aux chemins suivants. Si c'est le cas, vous devrez appliquer le Mode 2 réinitialiser 4 pour réinstaller DSM sur votre Synology NAS.5 Pour DSM 6.2 et versions antérieures: l' option Conserver le mot de passe admin actuel inchangé est cochée dans Panneau de configuration > Mise à jour et restauration > Réinitialiser. Pour DSM 7.0 et les versions ultérieures: l' option Conserver le mot de passe admin inchangé est cochée dans Panneau de configuration > Mise à jour et restauration > Réinitialisation du système. Si vous ne parvenez toujours pas à réinitialiser votre mot de passe administrateur, contactez l'assistance technique de Synology pour obtenir de l'aide.

Bonjour sv59510, soyez le bienvenu dans la communauté.

Et puis on perd la possibilité de passer en btrfs, ce qui du même coup limite les possibilités du 220+

oui, mais il faudra confirmer tous les mois.

Alors il faudra expliquer à ceux qui ne l'utilisent pas, et j'en suis, pourquoi ça fonctionne très bien sans. Pour moi, sans vouloir dénigrer le travail qui a été fait et que je respecte, ce script n'a (plus) aucun intérêt. Edit : Mais si tu es réellement convaincu qu'il y a un problème, plutôt que de pallier des dysfonctionnements à coup de script, il me semble plus productif d'alerter les contributeurs de github pour qu'ils apportent une solution qui profite à tous. C'est ici que ça se passe pour synology_dsm.sh : https://github.com/acmesh-official/acme.sh/issues/2727

IP fixe chez Bouygues ? Pourquoi pas. Si c'est le cas, vous n'avez pas besoin de DDNS.

Comme dirait fort justement Fenrir, un sous-domaine n'existe pas. mondomaine.tld est un domaine, tout comme toto.mondomaine.tld est un autre domaine, certes rattaché au premier, mais c'est un domaine. Et donc oui, vous pouvez très bien utiliser toto.mondomaine.tld pour atteindre votre NAS et obtenir le certificat correspondant à partir du moment ou vous en êtes le propriétaire. Avant cela, il faudrait savoir si votre ip publique est fixe ou dynamique. Si elle est dynamique, il faudra effectivement activer un service DDNS et dans ce cas, il faut vérifier si O2switch offre ce service. Sinon, comme l'a dit @PiwiLAbruti, il faudra passer par un service externe.

cloudfare est pris en exemple par l'auteur. Ce n'est pas à suivre aveuglément. Puisque vous avez suivi ce tuto, vous avez déjà toutes les clés OVH pour passer directement à l'installation. Pour lancer la configuration DNS, il faut simplement utiliser les mêmes clés et les exporter : export OVH_AK='Application Key' export OVH_AS='Application Secret' export OVH_CK='Consumer Key' @oracle7 Tu as tout à fait raison. Ce n'est pas DSM mais bien acme.sh qui lance le déploiement en appelant un autre script : /usr/local/share/acme.sh/deploy/synology_dsm.sh. Ce dernier a été mis à jour plusieurs fois en 2020, la dernière date du 10 décembre, ce qui explique probablement que le déploiement s'effectue maintenant normalement et sans l'aide d'un script supplémentaire.

Avec plus de 51000 heures, ça fait presque 6 ans de fonctionnement 24/7.

Généralement, un test smart bloqué à 90% = disque HS.

Bonjour Arno22, soyez le bienvenu dans la communauté

Justement, le tuto sur github dont j'ai parlé plus haut que j'utilise sur tous les NAS non compatibles Docker. Et si vous le comparez au tuto d' @Einsteinium, vous verrez qu'il est très similaire. Il y fait d'ailleurs référence à la fin de son tuto. Que ce soit avec Docker ou pas, la méthode est la même : on passe par le deploy_hook. La seule différence c'est qu'avec Docker, le certificat est créé dans une instance Docker alors que sans, il est créé dans DSM. Les deux utilisent le même script acme.sh. Docker n'est absolument pas une nécessité puisqu'on fait au final la même chose que ce soit avec ou sans. C'est juste une autre manière d'obtenir le certificat qui est fondamentalement la même dans les deux cas avec des commandes quasi identiques. Le déploiement est ensuite strictement le même puisqu'il s'agit de déployer le certificat dans les dossiers appropriés en utilisant le deploy_hook de DSM. Je ne l'avez pas relevé. acme.sh ne fait pas de déploiement. Il se contente d'obtenir le certificat. C'est le deploy_hook de DSM qui fait ensuite le déploiement.

Toujours ce problème de certificat sur le VPN. Pour ne pas y être confronté, il faut utiliser pour le seul serveur VPN un certificat spécifique d'une durée de validité éloignée. Soit on lui affecte le certificat par défaut de DSM synology.com, soit un certificat auto-signé. Ainsi le certificat n'est pas affecté par les renouvellements Let's Encrypt, et surtout on ne perd pas la connexion à distance qui peut devenir un vrai cauchemar à rétablir.

Absolument pas. Je n'ai rien eu à faire pour rétablir les affectations. Et je n'ai pas qu'un seul domaine, ce qui pourrait simplifier les choses. Comme je l'ai écrit, je n'ai fait que le déploiement et basta. tous les ".pem" sont en place, les infos renvoyées par Firefox sur les certificats sont conformes aux dernières mises à jour, les affectations n'ont pas bougé. Alors, je veux bien creuser un peu plus mais en l'état je ne vois rien qui cloche. Je ne dis pas que ton script ne sert à rien, je dis qu'il ne sert plus à grand chose, ou pour être plus précis, qu'il ne m'est d'aucune utilité. As-tu au moins essayé de ne faire que le déploiement ? Parce que faire tourner un script qui est sensé corriger des erreurs qui n'existent plus ne prouve pas qu'il sert à quelque chose. Juste qu'il s'évertue à recopier des fichiers qui n'ont pas besoin de l'être. Je ne vois pas l'intérêt d'un déclenchement avant les 60 jours, mais s'il faut le faire, un simple --force dans le script permet de renouveler le certificat. Aisément contournable en créant un user admin spécifique uniquement pour ça que tu appelles par exemple ACME avec des droits très limités et sans double authentification.