Mic13710

Tuto en ligne https://www.nas-forum.com/forum/topic/77094-tutodocker-linuxserverwireguard-wireguard-ui/

Vous avez la possibilité de sauvegarder les paramètres de deux manières : Dans DSM, Mise à jour et Restauration/Sauvegarde de configuration Dans les sauvegardes Hyperbackup où ils sont automatiquement sauvegardés

Impossible de conserver les données, ni le volume ni le groupe actuels. Il faut : Tout sauvegarder (Hyperbackup est le meilleur choix), Supprimer le ou les volume(s) Supprimer le groupe, Reconstruire le groupe en choisissant le RAID0, Créer un nouveau volume (ou plusieurs selon ce que vous aviez précédemment) Restaurer les sauvegardes.

Vu ce qui précède, il ne pouvait en être autrement. Et il fallait bien cela pour pouvoir bénéficier du btrfs (votre autre discussion)

Lorsque vous créez un lien partagé dans file station, vous accédez directement aux dossiers et/ou fichiers contenu dans le NAS. Pour ce qui est des photos (et en général tout ce qui est du multimedia) il faut passer par l'application dédiée qui pourra exploiter les miniatures qui ont été crées par le service d'indexation. En l’occurrence, il faut que vous créiez un lien de partage dans Synology Photos qui enverra vos parents dans l'application où ils pourront visionner les miniatures.

Pas vraiment puisque tu as remplacé ton 8To par un plus gros. Ma question concernait seulement le remplacement par un disque de même capacité. Mais je pense avoir compris le principe (voir mon message ci-dessus) A l'évidence, oui puisque si ton groupe avait été créé sous DSM7, tu aurais eu d'entrée une partition système en 8.5Go, tout comme sur ton 218+ ou sur mon 220+, et comme l'a confirmé @Einsteinium. C'est la configuration standard à partir de DSM7.

Bon, après analyse, il est clair que la partition système ne peut pas évoluer si le disque est de même capacité. En regardant simplement mon message ci-dessus : Mes deux NAS sont montés avec des 4To quasi identiques, et en tout cas de mêmes capacités. Les deux partitions de données font respectivement 3996Go sur le 718+ avec une partition système à 2550Mo, et 3990Go sur le 220+ avec une partition système à 8590Mo. On voit bien que la partition des données du 220+ à été amputée de 6Go au profit de la partition système. Il est bien évident qu'on ne peut pas associer une partition de données à un groupe existant s'il manque de l'espace. Et donc, la seule possibilité c'est de reconstruire une partition système de 2550Mo sur un disque de même taille que le ou les disques d'un groupe existant pour avoir une partition des données qui puisse être associée à celle du groupe. Ma conclusion c'est que si on associe un disque de même capacité sous DSM7, la partition système reste inchangée. Si par contre, on change ou on ajoute un disque plus gros à un groupe existant, alors la partition système de ce disque passe à 7.9Go. C'est très exactement ce qu'on voit sur le disque de 12To de @Jeff777 : La partition 5 est bien de la même taille que la partition 5 de son 8To ainsi que la partition 3 de mon 718+, les start/end sont simplement décalés des 6Go qui ont été rajoutés à la partition 1. Ainsi, cette partition 5 a pu être associées avec celle existante sur le 8To. La partition 6 est identique en taille à la partition 6 de son disque de 8To, elle aussi décalée des mêmes 6Go. Et quand le disque 8 sera remplacé par un 12To, la partition système devrait passer à 7.9Go et la nouvelle partition 7 qui sera créée à l'occasion occupera le restant de capacité non utilisée, je présume 4001-6 = 3995Go. Voili voulou.

Là, j'en suis moins sûr. Si le RAID est existant, je pense que la reconstruction d'un disque sorti du groupe, formaté et réinitialisé se fera sur les mêmes partitions que l'existant pour la raison que j'évoquais plus haut. Mais encore une fois, il faudrait le retour d'un membre du forum qui a fait l'opération pour le savoir. Le swap ne bouge pas. Il fait toujours 2147Mo. C'est la partition système qui est passée de 2550Mo à 8590Mo, soit une augmentation de 6040Mo.

@Einsteinium Tu confirmes que c'est bien une nouveauté DSM7. La taille de cette partition n'a en effet aucun lien avec la taille du disque. Il s'agit de la partition système allouée par Syno pour DSM. La partition donnée est construite avec ce qui reste après md0 et md1. Ma question était de savoir comment se comportait DSM lorsqu'on remplace ou ajoute un disque de même taille dans un groupe existant avec une md0 à 2.3Go. Je suppose qu'elle n'augmente pas, sinon ça risque de poser un problème pour construire la partition de donnée qui manquerait de Go pour être associée au RAID existant. Si quelqu'un a fait cette opération récemment, ce serait bien de vérifier par curiosité.

@Jeff777 s'il est plein, ça fait cher le 12To 😄

Ah oui, je n'avais pas regardé tes relevés en détail car je ne pensais pas que cette partition pouvait être modifiée lors de l'augmentation de groupe ! Au temps pour moi. Ca veut dire qu'il est très probable qu'elle augmentera lorsque tu changeras ton 8 par un 12. C'est une bonne chose. Reste à savoir si c'est DSM7 qui fait ça à chaque changement de disque quelle que soit sa taille ou seulement lors du remplacement ou ajout d'un disque par un plus gros. J'aurais tendance à penser que c'est uniquement lors d'un passage à une taille supérieure puisqu'il y a de la place pour décaler les partitions, ce qui n'est pas possible si le disque est remplacé par un autre de taille identique. Il serait intéressant d'avoir un retour de quelqu'un qui a remplacé (ou ajouté à un groupe existant) un disque de même taille sous DSM7.x pour en avoir le coeur net.

Attention aux crampes car il va falloir patienter un peu, le temps que les modos donnent leur feu vert ! J'ai donné mon avis. Si c'est OK pour d'autres, je publie.

Non. Elle restera telle qu'elle est sur le disque existant. En augmentant la taille du disque, tu n'augmente que la taille de la partition de données. Ou je dirais plutôt, tu crées une nouvelle partition de données qui vient s'ajouter aux existantes. Dans ton cas, je vois que tu as commencé par des 4To que tu as remplacé par des 8To. Au remplacement de ton 8To par un 12To, tu auras une nouvelle partition numéro 7 qui fera 4To. Si c'est les erreurs sur les md2 et md3, rien d'anormal. Tu fais bien. C'est DSM qui gère cette partition, mieux vaut ne pas y toucher.

A ma connaissance, la seule possibilité c'est de supprimer CloudStation, d'attendre que le fichier caché soit vidé (ça peut prendre un certain temps) et de le réinstaller pour qu'il reparte sur un dossier neuf. Cette opération ne détruit pas les données, seulement le dossier caché. Mais Cloudstation n'est plus dispo pour DSM6.x et le client Synology Drive n'est plus compatible avec Cloudstation depuis la version 3. Il vous faut basculer sur Synology Drive.

Ils sont en général peu bavards sur ce genre d'information technique qui est propre au fonctionnement de DSM. On peut ensuite se poser la question pour les évolutions futures de DSM sur des NAS avec seulement 2.3G. Parce que augmenter la partition alors qu'elle est contiguë avec le swap, va falloir repousser des blocs et ça, c'est pas une opération qui se fait en 10 minutes, ni 20. parted -list sur mon 718 : Number Start End Size File system Name Flags 1 1049kB 2551MB 2550MB ext4 raid 2 2551MB 4699MB 2147MB linux-swap(v1) raid 3 4832MB 4001GB 3996GB raid Pas de place entre la 1 et la 2. Par contre, y'a un peu d'espace entre la 2 et la 3, mais c'est dérisoire. parted --list sur mon 220 : Number Start End Size File system Name Flags 1 4194kB 8594MB 8590MB ext4 raid 2 8594MB 10.7GB 2147MB linux-swap(v1) raid 5 10.9GB 4001GB 3990GB raid On voit nettement l'augmentation de la partition 1. Il y a 4 Mo entre 1 et 2 et 200Mo entre 2 et 3.

C'est que le 5001 est dirigé vers le NAS dans le routeur. Remettez le 5001 dans le reverse proxy et faites la manip indiqué plus haut.

@Jeff777 ça semble être apparu avec la version 7. Mon 220+ a été installé avec 7.1 42661. Et franchement, ce n'est pas du luxe cette augmentation.

@baobab379 D'accord, mais où vous en êtes dans vos opérations ?

La meilleure méthode : https://kb.synology.com/fr-fr/DSM/tutorial/How_to_migrate_between_Synology_NAS_DSM_6_0_Hyper_Backup

Oui. Dans Accès externe/Avancé mettre partage.monnas.synology.net et mettre 443 dans https. Bizarre le .net, c'est pas plutôt .me ?

Ben si. Autrement comment ils feraient pour intervenir avec un compte utilisateur lambda ?

A ma connaissance, DSM ne permet pas de le savoir. Je ne sais pas te dire où tu peux trouver cette info, ni même s'il existe un fichier en particulier à consulter. En recherchant un peu plus, j'ai trouvé le fichier /var/log/synoupdate.log Pas sûr cependant que la première date du fichier corresponde à la date d'installation. En tout cas, les dates données sur mes deux syno sembleraient coller à leur installation primitive.

@Jeff777 j'ai aussi une partition à 7.9G sur mon 220+ et seulement 2.3G sur le 718+. Le 220+ a été installé "from scratch", le 718+ est une migration des disques de mon ancien 713+. Je dois à l'occasion lui refaire une beauté avec une réinstallation complète. Et vu vos retours, j'aurais bien du mal à le passer en 7.2 vu que sa md0 est remplie à 85% ! Tu as probablement refais une install de zéro sur ton 218+ et c'est apparemment la nouvelle taille de partition système adoptée sur les dernières versions de DSM. Ce n'est d'ailleurs pas un luxe car cette partition est très souvent bien remplie.

Plus grand monde utilise utilise Cloudstation qui a été remplacé par Synology Drive depuis DSM6.x Je ne me souviens plus des possibilités de suppression de cette application. Quelle est votre version de DSM ?

C'est une habitude chez Syno de nous pondre des versions que les clients doivent débuguer. Ce qui est moins courant en revanche c'est la sortie d'une version majeure à 15 jours d'intervalle. Ca fait désordre. Comme tu le dis, soyons fou, attendons que les retours négatifs se calment avant de nous lancer.