PC-Services

à toi de voire si les options additionnelles du Plex Pass sont nécessaires dans le cas d'un accès distant, si ta connexion rame, alors le fait de pouvoir synchroniser du contenu sur ton appareil te permettra de quand même visionner, et cela même sans connexion internet. La gestions des utilisateurs (famille par ex.) avec restriction possible de certains contenus. et d'autres options reprises sur leur site. Perso j'ai opté pour un Plex Pass à vie lorsqu'il était encore à un prix réduit au début de leur offre car je trouvait que 74€☻ pour un service à vie c'était pas trop chère payé 😉 Ils leur arrivent de faire des promos temporaires, mais on les voie de moins en moins car Plex est devenu très connu et la demande est forte. Attention aux dernières mises à jours (dont les BETA ne sont accessibles qu'avec un Plex Pass), elles peuvent amener pas mal de soucis comme tu l'as pu constater. Je te conseille de bien toujours garder le fichiers d'installation que tu aurais télécharger sur leur site, car ils ne proposent plus les archives de téléchargement au contraire de Synology mais qui eux n'ont pas toutes les versions existantes. En fait Synology (via le packages manager) ne proposent que celles qui ont étés testées comme "stable" mais pas sure que tu obtiennes la version 64Bits proposée sur le site de plex qui ici n'est de toute façon pas compatible avec ton syno. Tu risques de rencontrer quelques soucis lorsque plusieurs utilisateurs voudront lire en même temps et aussi ton syno n'est pas assez puissant pour pouvoir faire du transcodage à la volée pour certain type de médias dans ce cas aucun réglage du côté de ton plex serveur ne pourra t'aider. Le seul syno qui pour le moment s'en tire pas mal du côté transcodage est le DS918+, mais apparemment les dernières versions de Plex montrent aussi pas mal de soucis avec ce modèle. Tout dépend depuis quel appareil tu te connectes au Plex serveur...si ce dernier est capable de lire sans conversion ton média alors tu ne seras que limité par la vitesse de ton réseau (Lan ou Wan pour du distant)

concernant le backup du backup, j'ai fait quelques tours du côté des avis concernant les différents services fournis en externe (C2, glacier,...) et tous reviennent au même constat pas de soucis pour sauver quoique très long pour le premier dépôt, mais quand il s'agit de récupérer, il faut s'accrocher....des jours voire des semaines selon la quantité avant de récupérés ses données sans parler du coût annuel dans mon cas de minimum 200€ pour un éventuel désastre. Or ici il ne m'a fallut que quelques heures pour trouver une solution et 2 jours de travail de mes Nas pour récupérer mes données (5,5TB). Je conseille évidement du SHR2 ou du RAID6 pour augmenté les chances de récupérations, ou diminuer les risques de pertes de volume et minimum un RAID1 ou SHR1, mais il n'y a jamais de risque 0....(vraiment trop de malchance,vol, incendie,foudre, inondations,tremblement de terre, explosion atomique ,...:-))

J'en ai effectivement retrouvés pas mal concernant le SHR en EXT4, pas en BTRFS. mais mon raid lui n'était pas dégradé... , mais bien seulement le volume qui refusait de se monter et restait en panne dans le DSM. (bad superblock, parent system failed, system file cache corrupted) Une rubrique spéciale "dépannage" serait la bienvenue dans ce forum....j'ai ajouté mon expérience dans la rubrique "tutoriels" ou il y a un post complet similaire au miens mais avec EXT4. concernant la"bidouille": je place donc dans la zone "DANGER" le fait de faire une recherche de dossier en SSH depuis son root sur l'entièreté du DSM....mais je n'ai à ce jour pas d'explication technique de l'impacte que cela peut avoir de faire une telle recherche et encore moins pourquoi cela a complètement planter le DSM mais pas certains services de packages comme Docker, Plex, Surveillance station. Je pensait qu'une recherche ne faisait que lire la table d'index et ici n'ouvrait rien ou n'éditait rien, soit une simple lecture, voire que si il tombe sur un fichier verrouillé/en cours d'utilisation, il soit simplement bloqué dans sa recherche. Par sécurité, et cela malgré le fait d'avoir un UPS, j'ai désactivé le cache en écriture de DSM, car je suppose que c'est aussi lui qui à planté mon volume lors du redémarrage forcé. je n'ai fait que 2 redémarrages forcés avec un DSM dans ma vie (Dire ici que DSM c'est vraiment très stable) et c'est ce dernier qui a réellement causé de gros problème. Le premier il y a longtemps et c'était en Raid SHR1 mais avec un volume en EXT4 et DSM a pu réparer le volume de lui même. Donc le BTRFS c'est super pour tous les possibilités supplémentaire qu'il propose, mais il est apparemment vachement plus récalcitrant face à une panne. J'ai pu lire des recommandations de ne pas utiliser de RAID5,0,1 avec du BTRFS mais bien du RAID10, or il me semble que le SHR est un hybride qui mix du 5 et 1, est-ce bien cela ?

voici une autre procédure dans le cas ou votre volume n'est pas de en EXT4 mais BTFRS dans le cas EXT4 nous avions l’outil: e2fsck Pour le BTRFS c'est simple c'est : btrfs check Le SHR de Synology correspond à une couche raid (mdadm avec # cat /proc/mdstat) et une couche de LVM2. (vous trouverez sur le web plus d'infos à leurs sujet et ce n'est pas le sujet du post ici) Voici déjà quelques commandes pour afficher les status du système Pour voir l'état de ses volumes nous avons: #lvdisplay -v #pvdisplay # vgdisplay -v # lvs # lvm vgscan # lvm pvscan # lvm lvmdiskscan Pour connaitre le status de ses raid: # cat /proc/mdstat pour voire le type de ses disques physiques ou virtuels (raid) : # cat /etc/fstab pour voire ses points de montages de fichiers systèmes: # df après toutes ces commandes, vous devriez avoir une vue d'ensemble de votre problème. vient ensuite la tentative de réparation et remontage dans DSM de mon volume qui n'a pas aboutie car apparemment DSM utilise un kernel avec sa propre version de btrfs et donc certain outils ne fonctionnent pas de manière attendue. # btrfs check --init-extent-tree /dev/vg1000/lv pour un volume en EXT4 ce sera: # e2fsck -pvf -C 0 /dev/vg1000/lv # btrfs rescue super-recover /dev/vg1000/lv et il y en a plein d'autres dépendant du cas de rupture voire https://www.suse.com/support/kb/doc/?id=000018769: ou le WIKI sur le BTRFS. je ne m'attarderai donc pas à ces dernières qui n'ont pu résoudre mon cas. Il semblerait (pas testé ici) que j’aurai pu aussi, si j'avais un autre Synology, démarrer ce second Syno., installer DSM, ne pas créer de volume, éteindre, brancher mes 4 disques du syno1 en problème et normalement ces derniers devraient êtres remontés correctement. Mais vu que je n'ai pas de second syno libre pour cette manip, voici ce qui a marché pour moi : # vgchange -ay il permet de réactiver le groupe de volume puis j'ai pu remonter mon volume planté en lecture seule et sans son fichier cache système, donc juste pour pouvoir rattraper mes données : # mount -o recovery,ro /dev/vg1000/lv /volume2 ou ici vg1000 est le device mappé pour mon volume lv que je monte dans un dossier volume2 ensuite il ne reste plus qu'à (c'est un euphémisme ici avec 6To) copier mes données sur un autre volume du nas. dans mon cas mon volume 1 n'étant pas suffisant j'ai créé un dossier \volume1\MOUNTNFS\volume2 que j'ai monté en NFS sur un dossier d'un autre NAS ici <<ip du nas 2>>/shareFolders/volume2. Pour pouvoir suivre et éviter un problème d'interruption de copie entre les deux (je sais que certain vont me dire qu'il n'était pas nécéssaire de faire un montage nfs du coup) au lieux d'utiliser la commande CP j'ai utiliser rsync en mode de suivi (-v) et progression (--progress) en gardant les paramètres de permission et une copie recursive (-a) et compression de transfert de données (-z) ce qui donne pour moi # rsync -avz --progress --exclude='/@*/' /volume2/ /volume1/NOUNTNFS/volume2/ ou ici --exclude='/@*/' permet d'éviter un copie des snapshots de réplications qui grossieraient inutilement la quantitées de données copiées. Toutes ces commandes doivent être faites en privilège root et donc soit vous rajouter sudo devant chacune ce qui vous demanderas à chaque fois votre mot de passe administrateur du nas ou alors dès votre entrée en ssh tapez la commande sudo -i pour rester en root durant toute la cession. J'ai choisi RSYNC au lieu de CP ou BTFRS RECOVER pour faciliter le transfer (compression, copie incrémentale au cas ou la connection serait perdue, et BTRFS RECOVER ne fonctionnait pas pour je ne sais quelle raison voire a cause du kernel synology) Voilà, mes données sont en train d'être copiées et il va faloir plusieurs jours pour qu'il termine le job. Restera ensuite à supprimer le volume en panne depuis DSM et de le refaire pour rebasculer tout mes dossiers à nouveau avec rsync depuis le NAS de secours ver mon syno. Malheureusement cette procédure ne permet pas de retrouver son volume initiale en état ainsi que tout ses dossiers partagés dans DSM et elle demande beaucoup plus de temps et du matériel supplémentaire par rapport à la procédure du post initial pour un Raid en EXT4. Apparemment il n'y en aurait pas du moins avec les outils et version du btrfs installé par Synology de possibilité de restaurer complètement un volume btrfs planté.

Bonjour @Einsteinium Et bien justement, je n'ai rien trouvé sur ce forum concernant une récupération de données d'un volume planté et j'ai effectivement cité la provenance la source de mon information qui vient bel et bien du forum de la version illégale de DSM malheureusement pour ce forum 🙂 j'ai pourtant, avant de placer mon poste, tenté une recherche dans ce forum avec les mots clefs "btrfs", "volume planté", "volume crashé", "réparation de volume", "récupération de données, "dossiers partagés disparus", "disparition de dossiers partagés" mais rien ne sort de ce forum à part évidement maintenant mon propre poste. Avant de pousser mon petit coup de gueule, cela évidement dans un état de frustration face à une perte probable de mes données, mes messages étaient tout à fait cordiales et bien descriptifs de la situation technique. Je comprend bien que les experts sur le forum on du taf et ne peuvent sans doute pas répondre à toutes les demandes. Mais je ne comprend pas alors pourquoi un sujet nouveau comme le mien n'aie pas directement attiré ces experts qui auraient eux l'occasion d'ajouter une nouvelle connaissance et procédure sur ce forum, en plus du fait que c'est une situation critique voire urgente et une expérience douloureuse pour l'utilisateur qui la rencontre. Le pire, c'est que même maintenant que j'ai fournis un dossier complet sur la procédure qui permet de récupérer les données dans ce cas de figure, vous continuez à me blâmer et là cela devient déprimant. à croire que vous faites tout pour avoir une bonne raison de modéré et peut-être de pouvoir supprimer ce poste gênant. Je viens de corriger ma citation concernant l'autre DSM et son forum en appuyant bien sur le fait qu'il est donc "illégal", comme cela pour vous je suis bien en conformité avec votre demande ? par contre ce n'est pas moi mais bien @maxou56 qui a cité le vrai nom de cette version illégale et là je ne peux rien modifier. Passez une excellente journée.

tu as créer un utilisateur spécifique pour cet iPad ? As-tu au moins ton serveur visible dans l'appli plex de l'ipad ? (voire accueil >>Plus) est-ce que ta bibliothèque est bien visible et remplie lorsque tu te connectes depuis un pc à http://plex.tv et que tu lance ta cession ?

L'ip affichée sera bel et bien celle de ton VPS Je ne te conseil pas d'utiliser un service français (pays ou Hadopi règne) et qui de plus est ne t’inscrit pas noire sur blanc qu'aucun logs n'est pris de leur côtés. Ils seront de toutes manières obligés de présenté quelque chose si un juge venait saisir ton IP louée par ton VPS. Ton tunnel protègera bien le contenu des données transférées, mais tu restes néanmoins traçable ici sur la destination IP source et destination.... de plus tu reste quand même limité par la bande passante de ton FAI pour ta connexion entre ton VPN et ton Syno qui lui aussi est limité par le choix de chiffrage vpn que tu choisiras. Par curiosité, Quelle vitesse avais-tu avec Nordvpn, purevpn ? et quelle vitesse as-tu réellement avec ton VPS ?

dis moi, si c'est pour utiliser transmission, je suppose qu'en plus de vouloir obtenir une meilleur bande passante c'est aussi pour éviter des soucis avec hadopi ? Si c'est le cas, il me semble que l'IP de ton VPS est bel et bien à ton nom, du moins lié à ton compte client OVH. Donc fait quand même gaffe là.

cela doit être faisable depuis le panneaux de config de ton OpenVPN, peut-être dans la rubrique advanced VPN ? je n'ai malheureusement jamais utilisé ce service chez OVH as-tu un accès ssh sur ce serveur ? cela pourrait te donner la possibilité de modifier l'IPTables et de créer une règle NAT pour ton vpn Ton transmission qui est dans le syno reste toujours joignable sur ta porte 9091 si tu fait bien aussi une redirection de port de ton propres routeur pour un accès distant. si c'est pour simplement lancer une tâche de téléchargement depuis local ou distant à ton transmition, il n'est pas nécessaire de passer par ton tunnel. Je suppose que ton syno est donc un client de ton Openvpn et que tu as bien mis dans l'ordre de tes passerelles multiples, ton VPN comme première passerelle ce qui forcera tes applis à utiliser cette dernière pour accéder au web et du coup ton transmission aussi. donc ta demande de tâche peux passé en direct, mais le téléchargement lui passera par ton tunnel. c'est cela que tu désires ?

Bonjour. Je ne comprend pas bien ce que tu essaies de faire. Tu veux accéder à ton syno via openvpn ? si c'est le cas il aurait mieux vallu installer le paquet VPNserveur dans ton syno au lieux de souscrire à un openvpn chez OVH....

de mêm pour le 1900, pas nécéssaire ici

pas besoin d'autre port que le 32400 pour Plex. Plex se charge du reste pour le relaying. tu as un site internet sur ton syno ? pourquoi as-tu ouvert les ports 80 et 443 ?

ok, apparament ils n'avait pas accepté la connexion sécurisée https Veille bien à lire les recommandation de Plex pour correctement ranger tes dossiers multimédias. Il te faudra aussi ouvrir la porte 32400 dans ton routeur si tu veux accéder à distance à ton Plex. Bon amusement

pourrais-tu faire une copie d'écran de la version du package Plex que tu as installé.

bonjour, as-tu réclamé ton serveur plex via https//ip.de.ton.nas:32400/web ?

Que me recommandez-vous pour une sauvegarde de 8TB ? car cette quantité c'est lourd à garder à jour en dehors du syno qui est lui déjà un point de sauvegarde de mes postes windows et biblihothèques multimédias. (donc en fait une sauvegarde de la sauvegarde ici) J'utilise spideroak pour tout ce qui concerne les documents et boulots mais il ne peut pas garder les image windows comme mon syno le fait avec active backup for business qui est TOP ! et en multimédias ces plusieurs teras de photos, musiques et films....du coup il faudrait des semaines pour récupérer une sauvegarde externes et peut-être des mois pour le premier upload. J'ai essayer un disque dur externe branché en usb sur le syno, mais là aussi les taux de transferts sont horribles. En plus pour 8TB c'est pas gratos en externe et il faut mettre en balance le prix coutant de la valeur réelle de ces données. J'ai déjà eux pas mal d'expériences avec des RAID et j'e reste toujours sur une solution à parité sur 1 voire 2 disques selon le cas d'importance. Et j'ai jamais eux de très mauvaise chance d'avoir 2 disques qui tombent en rade en même temps (encore moins 3 avec SHR2) du coup les probabilités de vraiment perdre les données brutes sur un Raid sont vraiment minime, dailleurs ici à nouveau volume planté, illisible depuis dsm mais tout à fait récupérable en linux.

il n'y a rien d'inutile à partager, tant que cela reste poli chacun à son jugement comme tu le montres vis à vis de mes compétences.... je m’attèle à les élever comme tu peux lire. par contre je serai intéressé de savoir l'erreur que j'ai commise, du moins son explication technique pour éviter de repasser par là, peut-être par un autre chemin. comme cela ton message sera aussi moins inutile 🙂

je tient juste à marquer le point qu'avant de déclaré une situation comme dixit niklos0 "A voir si quelqu'un à une idée lumineuse mais à mon avis, c'est mort... " il vaut mieux être prudent. concernant la sauvegarde, il n'est pas évident de garder à jour et en dehors de son réseau plusieurs Teras de données, et les récupération des sauvegardes en ligne sont extrêmement lentes pour de telles quantités. Ici de toutes manières , quoi qu'elles soient comme données informatique, c'est JAMAIS vital ! on continue très bien à vivre après une perte de données.tout est une affaire de matérialisme et son esprit. Mais il est vrai que l'on peut perdre pas mal de temps à les garder ou à les récupérer et que le temps est souvent considérer comme de l'argent ce qui n'est pas ma préférence comme considération. Concernant mes incompétences, c'est grâce à mes erreurs qu'elles se se réduisent et je comptait un peut sur le soutient de vos bénévoles dont certains prennent la peine de partager leur savoir qui aurait aussi servis à d'autres, mais en réponse j'ai plutôt reçu des questions du genre pourquoi as-tu fait cela ?, il aurrait mieux vallu..., va voire ailleurs chez syno si ils peuvent t'aider. ce n'est juste que quelques constats ici . Maintenant concernant mon propre partage d’expériences et nouveaux savoirs voici ce que j'ai pu recevoir dans d'autres forums (debian.org, XXXXXXXXXX.com): en premier lieu il faut bien faire la distinction entre un volume format EXT4 et BTRFS car en fonction de la version les commande de vérification de fichiers systèmes ne sont pas les même. dans le cas EXT4 nous aurons l’outil: e2fsck Pour le BTRFS c'est simple c'est : btrfs check Le SHR de Synology correspond à une couche raid (mdadm avec # cat /proc/mdstat) et une couche de LVM. (vous trouverez sur le web plus d'infos à leurs sujet et ce n'est pas le sujet du post ici) Voici déjà quelques commandes pour afficher les status du système Pour voir l'état de ses volumes nous avons: #lvdisplay -v #pvdisplay # vgdisplay -v # lvs # lvm vgscan # lvm pvscan # lvm lvmdiskscan Pour connaitre le status de ses raid: # cat /proc/mdstat pour voire le type de ses disques physiques ou virtuels (raid) : # cat /etc/fstab pour voire ses points de montages de fichiers systèmes: # df après toutes ces commandes, vous devriez avoir une vue d'ensemble de votre problème. vient ensuite la tentative de réparation et remontage dans DSM de mon volume qui n'a pas aboutie car apparemment syno utilise un kernel avec sa propre version de btrfs et donc certain outils ne fonctionnent pas de manière attendue, et ils uploadent surement d'autres composants propre à leur systèmes lorsqu'ils prennent à distance le contrôle d'un dsm qui présente un volume en panne (de là la petite mention sur leur site, notifiant de prendre contact avec eux): # btrfs check --init-extent-tree /dev/vg1000/lv pour un volume en EXT4 ce sera: # e2fsck -pvf -C 0 /dev/vg1000/lv # btrfs rescue super-recover /dev/vg1000/lv et il y en a plein d'autres dépendant du cas de rupture voire https://www.suse.com/support/kb/doc/?id=000018769: ou le WIKI sur le BTRFS. je ne m'attarderai donc pas à ces dernières qui n'ont pu résoudre mon cas. J’aurai pu aussi, si j'avais un autre syno, demarrer ce second syno, installer DSM, ne pas créer de volume, éteindre, brancher mes 4 disques du syno1 en problème et normalement ces derniers devraient êtres remontés correctement. Mais vu que je n'ai pas de second syno libre pour cette manip, voici ce qui a marché pour moi : # vgchange -ay il permet de réactiver le groupe de volume puis j'ai pu remonter mon volume planté en lecture seule et sans son fichier cache système, donc juste pour pouvoir rattraper mes données : # mount -o recovery,ro /dev/vg1000/lv /volume2 ou ici vg1000 est le device mappé pour mon volume lv que je monte dans un dossier volume2 ensuite il ne reste plus qu'à (c'est un euphémisme ici avec 6To) copier mes données sur un autre volume du nas. dans mon cas mon volume 1 n'étant pas suffisant j'ai créé un dossier \volume1\MOUNTNFS\volume2 que j'ai monté en NFS sur un dossier d'un autre NAS ici <<ip du nas 2>>/shareFolders/volume2. Pour pouvoir suivre et éviter un problème d'interruption de copie entre les deux (je sais que certain vont me dire qu'il n'était pas nécéssaire de faire un montage nfs du coup) au lieux d'utiliser la commande CP j'ai utiliser rsync en mode de suivi (-v) et progression (--progress) en gardant les paramètres de permission et une copie recursive (-a) et compression de transfert de données (-z) ce qui donne pour moi # rsync -avz --progress --exclude='/@*/' /volume2/ /volume1/NOUNTNFS/volume2/ ou ici --exclude='/@*/' permet d'éviter un copie des snapshots de réplications qui grossieraient inutilement la quantitées de données copiées. Toutes ces commandes doivent être faites en privilège root et donc soit vous rajouter sudo devant chacune ce qui vous demanderas à chaque fois votre mot de passe administrateur du nas ou alors dès votre entrée en ssh tapez la commande sudo -i pour rester en root durant toute la cession. J'ai choisi RSYNC au lieu de CP ou BTFRS RECOVER pour faciliter le transfer (compression, copie incrémentale au cas ou la connection serait perdue, et BTRFS RECOVER ne fonctionnait pas pour je ne sais quelle raison voire a cause du kernel synology) Voilà, mes données sont en train d'être copiées et il va faloir plusieurs jours pour qu'il termine le job. Restera ensuite à supprimer le volume en panne depuis DSM et de le refaire pour rebasculer tout mes dossiers à nouveau avec rsync depuis le NAS de secours ver mon syno. Je suis loins de tout savoir sur la gestion BTRFS, je ne comprend pas encore certains aspect de son fonctionnement, mais mon expérience montre que le mix DSM + BTFRS +RAID Hybrid SHR1 peuvent se désaccordés sans prévenir et je n'explique toujours pas comment mon volume est passé par un stade de synchro sans avoir eu le mode "dégradé" et que malgré la fin de la synchro il restait en panne. bref le btrfs de syno et leur RAID SHR est sympa sur papier mais peu causer de sérieuses frayeurs. t'inquiètes maxou, pas de soucis, tu as fais ce que tu pouvais. merci pour tes conseils. j'espère que d'avoir amené mon problème ici pourra en aider d'autres et relever la base de connaissance du forum concernant le BTRFS de syno qui est apparemment légèrement bridé en plus d'un RAID SHR à leur sauce. J'étais sure d'être mieux à l’abri avec leur solution btrfs RAID SHR qu'un simple RAID1 mais là il reste des points nébuleux au niveau des outils qu'ils emploient et implantés dans leur systèmes. Pas normal que l'on doivent contacter un support qui peut prendre des jours avant de revenir vers toi alors qu'il y aurait moyen de fournir des outils plus élaborés de gestions de sinistre dans le cas d'un BTRFS. mais évidement pour eux, le système est stable tant qu'on n'en demande pas de trop et il y a sans doute quelques rares cas comme le mien, sinon le forum puluerait de ce genre de post. sans rancune j'espère pour ceux qui se sont sentis piqués 😉

pour info @niklos0 je viens sur ce forum justement pour éviter de me faire plumer par ces chères sociétés spécialisées qui non seulement ont des tarifs surfait mais qui en plus n'aboutissent pas toujours aux résultats escomptés, j'en ai déjà fait l'expérience. Dommage qu'un forum comme ici ne puisse pas aider réellement dans ce cas de figure qui me semble plus important qu'un simple petit paramétrage pour novice perdu. Soit, je me suis résigné à voire ailleurs et j'ai pu trouver des solutions pour retrouver mes données qui n'étaient donc pas perdues mais juste inaccessible depuis DSM, le comble est que c'est sur un autre forum non officiel pour un DSM illégal; donc en fait on est mieux épaulé par de vrais connaisseurs qui bidouillent non officiellement les systèmes que sur les forums référencés par le constructeur. Heureusement que j'ai gardé l'espoir et pas considérer comme mort ma situation, sinon j’aurais effectivement tout perdu en effaçant mon volume pour repartir de 0. Paroles d'initié Pour un chevalier du syno et un grand Maître des syno @maxou56 p.s. par sécurité, je suis en train de tout recopier vers un autre nas, avant de procéder plus loins au rétablissement de mon volume dans DSM. pour ceux qui tomberaient comme moi dans ce problème, n'hésitez par à me faire un UP 😉

oui désolé, je suis un peu dans un état de frustration qui découle d'un état de choque face à ma bêtise et ma perte brutale. milles excuses pour cette mention qui n'apporte pas grand chose à ce poste.

je sais j'ai été con là, en fait je travailler sur l'une de mes containers docker et je voulais rapidement retrouver l'un de ses dossiers "data", j'ai donc lancer une recherche de nom de dossier sur l’entièreté du NAS et après 3 ou 4min ma cession SSH/Winscp à figé....et le reste du DSM aussi. J'aurrai du en fait utiliser le terminal de mon container pour ce genre de boulo.... on apprend toujours de ses erreurs, mais là je le paye très très cher 😞 apparemment j'ai vraiment la scoumoune là. ou alors je suis mal tombé. toujours est-il que je dois du coup me débrouiller autrement et c'est là qu'on se rend compte qu'il y a très peu de vrais connaisseurs en linux, btfrs et gestions de raid hybride qui utilisent un Syno.... ceux là préfèrent restés en freenas et travailler en ext4.

@maxou56 , merci du conseil, mais mon syno étant hors garantie, ils ne veulent pas m'aider. C'est dure, car je voie d'autres expérience similaire à la mienne ou ils ont pris la main à distance et pu monter le volume en lecture seule, le temps de pouvoir récupérer et copier les données à un autre emplacement. Malheureusement, personne n'indique les commande BTFRS qu'ils ont ustilisé pour ce faire, cela reste apparemment un secret bien gardé puisque même le support Syno reste vague à ce sujet lorsque le client demande comment ils ont fait.. Il est vrai que cela demande un niveau de connaissances professionnels et je comprend que ici dans ce genre de forum je ne retrouverai pas quelqu'un d'assez qualifié qui donnerai un peu de son temps pour aider . Mon espoir m'avait ouvert un rêve qui m'a ramené à une dure réalité... merci quand même à ceux qui ont lu mon appel et pris le temps de me répondre.

@maxou56 @niklos0 en cherchant un peu , il y aurait peut-être moyen de monter le Raid en lecture seule avec Ubuntu : https://www.synology.com/en-global/knowledgebase/DSM/tutorial/Storage/How_can_I_recover_data_from_my_DiskStation_using_a_PC l'un de vous est-il au courant de ce genre de procédure ? mount /dev/vg1000/lv /mnt -o ro mount /dev/vg1/volume_1 /mnt -o ro n'étant vraiment pas familier avec les commandes Linux, je suis un peu perdu. Pour préparer le terrain j'ai vérifier en ssh l'état actuel de mes disques avec "fdisk -l" et apparament tout s'y trouve ...sauf que je retrouve une chose bizzare sur l'un des "sdh" ici "f W95 Ext'd (LBA)" au lieu de "fd Linux raid autodetect" comme les autres...? donc le RAID serait bel et bien en problème ? J'ai aussi trouver ce post, mais là à part le fait qu'il est apparament arriver à recoupler sont RAID et de l'avoir monté en lecture seule, je pige quedal sur la manière à interpréter cela pour mon RAID. https://unix.stackexchange.com/questions/78804/how-to-mount-a-disk-from-destroyed-raid-system Esct-ce que quelqu'un est calé en Linux et gestion des disques dans ce forum pour pouvoir m'épauler ? merci résultat de la commande "fdisk -l" sur mon nas : root@Synology:~# fdisk -l Disk /dev/sda: 167.7 GiB, 180045766656 bytes, 351651888 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x1abb81da Device Boot Start End Sectors Size Id Type /dev/sda1 2048 4982527 4980480 2.4G fd Linux raid autodetect /dev/sda2 4982528 9176831 4194304 2G fd Linux raid autodetect /dev/sda3 9437184 351447071 342009888 163.1G fd Linux raid autodetect Disk /dev/sde: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 500E666E-579D-421D-8549-30B236F6226C Device Start End Sectors Size Type /dev/sde1 2048 4982527 4980480 2.4G Linux RAID /dev/sde2 4982528 9176831 4194304 2G Linux RAID /dev/sde5 9453280 3906822239 3897368960 1.8T Linux RAID /dev/sde6 3906838336 7813830239 3906991904 1.8T Linux RAID Disk /dev/sdf: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 761196C2-0C48-40E4-86DA-36268A4B5C2E Device Start End Sectors Size Type /dev/sdf1 2048 4982527 4980480 2.4G Linux RAID /dev/sdf2 4982528 9176831 4194304 2G Linux RAID /dev/sdf5 9453280 3906822239 3897368960 1.8T Linux RAID /dev/sdf6 3906838336 7813830239 3906991904 1.8T Linux RAID Disk /dev/sdg: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: dos Disk identifier: 0xb46ff839 Device Boot Start End Sectors Size Id Type /dev/sdg1 2048 4982527 4980480 2.4G fd Linux raid autodetect /dev/sdg2 4982528 9176831 4194304 2G fd Linux raid autodetect /dev/sdg3 9437184 3907015007 3897577824 1.8T f W95 Ext'd (LBA) /dev/sdg5 9453280 3906822239 3897368960 1.8T fd Linux raid autodetect Disk /dev/sdh: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: dos Disk identifier: 0xe9e4646f Device Boot Start End Sectors Size Id Type /dev/sdh1 2048 4982527 4980480 2.4G fd Linux raid autodetect /dev/sdh2 4982528 9176831 4194304 2G fd Linux raid autodetect /dev/sdh3 9437184 3907015007 3897577824 1.8T f W95 Ext'd (LBA) /dev/sdh5 9453280 3906822239 3897368960 1.8T fd Linux raid autodetect Disk /dev/md0: 2.4 GiB, 2549940224 bytes, 4980352 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/md1: 2 GiB, 2147418112 bytes, 4194176 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/zram0: 1.1 GiB, 1228931072 bytes, 300032 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/zram1: 1.1 GiB, 1228931072 bytes, 300032 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/zram2: 1.1 GiB, 1228931072 bytes, 300032 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/zram3: 1.1 GiB, 1228931072 bytes, 300032 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/md3: 5.5 TiB, 5986355576832 bytes, 11692100736 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 65536 bytes / 196608 bytes Disk /dev/md4: 1.8 TiB, 2000378789888 bytes, 3906989824 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/md2: 163.1 GiB, 175107997696 bytes, 342007808 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/mapper/vg1000-lv: 7.3 TiB, 7986730762240 bytes, 15599083520 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 65536 bytes / 196608 bytes

apparament ce serait le BTFRS qui a merdé ici....car tout mes disques sont en bonne santé et je suspecte le scan en WINSCP d'avoir interférer avec certains fichiers de suivis btfrs. du coup je pense que @niklos0 voie juste car le btfrs en RAID SHR ici est propre au DSM je penses et donc la couche linux du syno ne pourra sans doute pas m'aider à accéder aux données qui sont à mon avis toujours présentes mais inaccessibles. J'ai pu lire sur le support syno, que je pouvait retirer tout mes disques et tenter de redémarrer mon syno avec un disque de secours et de réinstaller DSM sans créer de volume et d'ensuite replacer mes disques Raid mais j'ai un doute là.

@firlin oui le plantage à eu lieux durant une session ssh root, et simplement durant un scan recherche d'un nom de dossier, je fait toujours super gaffe de ne rien modifier en root sans être sur de ce que je fait, mais là je ne m'attendait pas à une perte seche du genre en faisant simplement une recherche dans tout le contenu \.... lorsque ma cession SSH à planté, plus moyen d'accéder au DSM, mais les instances de packages comme Plex et surveillance station continuaient à fonctionner, mais évidement avant le plantage mes dossiers qui me manquent étaient visibles au niveau du panneau de configuration\dossier partager. On dirait que mon volume2 n'est plus monté correctement dans le système, car je suis retourné en ssh pour voir et faire un ls volume2 et là il me dit que volume2 est simplement un répertoire. comment puis-je vérifier si ce volume RAID est encore avec ses données ou vérifier son point de montage ?