Mic13710

Le SHR1 est un RAID hybride qui combine le RAID1 et le RAID5. Il peut avoir qu'un seul disque et dans ce cas il s'agit d'une SHR sans protection des données, ou 2 à x disques et dans ce cas il s'agit d'un SHR avec protection des données puisqu'on peut perdre 1 disque sans perte de données. Le SHR2 est un RAID hybride qui offre la protection des données sur 2 disques. C'est l'équivalent du RAID6.

Non. Ce n'est qu'une sauvegarde, pas un déplacement. Ce n'est pas destructif. Suivez les tutos en bas de page du lien que je vous ai donné et tout devrait bien se passer.

Là non plus, ce n'est pas une choix judicieux. La gestion de Drive implique un dossier caché qui occupe grosso modo le même espace que l'ensemble des fichiers du drive. Mettre des fichiers de plusieurs mégas dans Drive qui ne sont pas vraiment appelés à être modifier charge les disques inutilement. Vous ne perdrez pas les données sur les clients qui serviront pour reconstruire les dossiers sur le NAS, mais en créant une base neuve, vous perdrez tout les historiques. Si vous faite les transferts des données via hyperbackup, les dossiers et fichiers seront restaurés à l'identique ce qui devrait accélérer le processus de synchronisation puisqu'il n'y aura qu'une synchro très limitée à faire entre les clients et le serveur.

Oui bien sûr. Il y a Migration assistant. Je ne l'ai jamais utilisé car très récent. Il y a aussi la solution hyperbackup qui permet de retrouver les dossiers et fichiers avec leur time code à l'identique. un peu de lecture : https://www.synology.com/fr-fr/dsm/feature/migration

Je ne vois pas où est le problème. Comme tout lecteur réseau, vous avez à indiquer des identifiants de connexion une première fois pour pouvoir accéder au dossier. Si vous validez la reconnexion automatique au démarrage de windows, vous n'avez plus besoin des identifiants pour accéder à vos dossiers, quel que soit le dossier partagé sur lequel vous avez les droits (multimedia ou autre).

Même si c'est possible techniquement, ce n'est vraiment pas une bonne idée si vous voulez exploiter pleinement votre 420. En migrant vos disques, vous migrez aussi les limitations du 218J. Entre autre, vous perdez les bénéfices du BTRFS. Je vous conseille de mettre à jour vos sauvegardes et de partir sur une installation neuve.

@PiwiLAbruti C'est comme les paquets de biscuits : recette modifiée et toujours le même goût !

Etrange qu'ils aient repris le même indice que la version retirée. Je me demande comment va se faire la maj pour ceux qui ont chargé l'ancienne version. Je l'ai installée sur quelques NAS et je n'ai pas de message de maj pour le moment. Aucun n'est concerné par les correctifs, c'est plus par simple curiosité.

Vos disques 3 et 4 sont en erreur sur leurs partitions système. Le système (DSM) ne fonctionne que sur les disques 1 et 2. Vérifiez les données smart des disques. Je ne saurais dire pourquoi. Problème de disques ? Installation défaillante ? Cette erreur est totalement indépendante de CloudStation ou Drive. Je suspecte un souci d'installation (migration ?) Lors du passage de CloudStation vers Drive, le dossier @cloudstation est converti et renommé @synologydrive. La présence d'un ancien dossier cloudstation n'est donc pas normale. C'est du pipo. Il faut bien comprendre que tous les fichiers n'ont pas 32 versions. Certains comme les pdf et autres jpeg n'ont qu'une seule version et la grand majorité des fichiers n'ont que quelques versions. Ensuite, le fichier caché @synologydrive est compressé. Il fonctionne un peu comme ceux créés par Hyperbackup qui eux aussi peuvent avoir plusieurs versions (256 de mémoire par défaut). Et pourtant le volume des fichier hbk est très loin de représenter 256 fois l'ensemble des fichiers sauvegardés. La seule vrai différence, c'est de mettre le nombre de versions à 0, mais on se prive alors du versionning et surtout de la récupération de fichiers supprimés qui est tout de même un des avantages d'un cloud. Il est vrai toutefois que l'EXT4 n'est pas très performant pour la gestion des versions et que le BTRFS est de loin plus efficace. Le changement du nombre de versions n'agit pas sur les anciennes versions mais seulement sur les nouveaux fichiers. Il faut procéder à un nettoyage. Le dossier @.... contient aussi tous les fichiers actuels ou anciens de cloudstation ou drive. Si vous y avez mis des fichiers lourds tels que des vidéos, photos, ils sont toujours présents dans le dossier, même si vous les avez supprimés des client ou du serveur. C'est très certainement pourquoi votre base pèse 4.1To. Je n'utilise pas l'intelliversionning car je ne veux pas donner le choix à Drive de gérer les versions à sa guise. Je ne peux donc pas parler de cet outil. DS415+, tout dépend de sa date de fabrication et de la présence ou non de la fameuse résistance (voir le sujet traitant des Atom 2000 et des NAS affectés). Faire du EXT4 sur un NAS compatible BTRFS, c'est se priver d'un système de fichier performant qui justement gère bien le versionning. Et faire deux groupes distincts en SHR sur un NAS 4 baies c'est beaucoup de perte d'espace de stockage (dans votre cas, vous avez 5To de perdus pour de la protection). Bref, tout cela pour dire que vu le nombre de problèmes rencontrés, et surtout les erreurs sur les partitions système, je vous conseillerais de mettre à jour vos sauvegardes pour repartir sur une nouvelle installation en intégrant les 4 disques dans un unique groupe SHR et en créant un seul volume en BTRFS plus simple à gérer, ou 2 volumes distincts (sur le même groupe bien entendu) en BTRFS si vous souhaitez séparer vos données de vos vidéos, mais je n'y vois guère d'intérêt. Si vous souhaitez seulement reprendre votre Drive et garder l'EXT4 avec vos erreurs de partitions système (c'est votre droit), vous pouvez désinstaller simplement Synology Drive, supprimer les dossiers @synologydrive et les restes de @cloudstationxxxx, puis réinstaller l'application et reprogrammer toutes vos synchros à partir de vos différents clients.

Aucun problème. Renouvellement par le protocole DNS-01 par acme.sh, soit via Docker, soit via SSH. Aucun port à ouvrir.

Je ne crois pas non. C'est du simple bon sens. Tout comme @Jeff777, je n'autorise pas les accès de l'extérieur aux équipements sensibles. Pour ceux-là, je passe par le serveur VPN : DSM, le routeur, la box, mes bornes Wifi, mes caméras, etc.. Pourquoi prendre des risques inutiles alors qu'il existe des modes de connexion plus sécurisés (L2TP, Open VPN, Wireguard ....)

@Einsteinium bien le "recommander" ! Je n'avais pas encore capté quel en était le résultat sur le fil. Au moins comme ça on ne peut pas le rater.

Je rejoins @.Shad.. On pourrait mettre une annonce sur le forum, mais je pense qu'un sujet qui cible cette réparation aura plus d'impact car les membres peuvent poster et apporter leur contributions, à la différence d'une annonce qui est statique. Une augmentation de la résistance ne peut que diminuer le courant dans le transistor, ce qui au pire peu se traduire par la réapparition du dysfonctionnement si la R est trop élevée mais ne met en danger ni le NAS, ni ses composants, ni les données. Le risque est surtout que la soudure ne soit pas correctement réalisée. Cette opération, même si elle n'est pas compliquée, demande un certain doigté. Je suis moi-même électronicien de formation et j'ai des milliers de soudures à mon actif. Il est très courant d'aboutir à une soudure sèche quand on ne connait pas la technique.

Tout à fait .Shad., c'est bien ce que je souhaitais faire, mais le message initial ne parle pas de réparation, seulement du pb rencontré sur les atom. Je n'ai pas trop le temps de chercher dans les 18 pages de ce fil le message qui parle de réparation pour rajouter un lien vers le message de @jacaj que je remercie au passage pour son implication dans cette affaire. Je pense que pour faciliter la recherche, il serait effectivement souhaitable de rajouter un encart sur le message initial pour faire un renvoi vers les messages importants. Si quelqu'un a du temps à consacrer pour "creuser" dans ce fil et isoler les messages traitant de la réparation, je pourrai rajouter les liens.

https://github.com/runfalk/synology-wireguard En cherchant un peu, vous en trouverez aussi sous Docker