changement de disque dur - Récupération de données

[jbonlinea]

Bonjour à tous, 

J'ai un Syno 712+, dans lequel se trouve un disque dur que nous nommerons hddA, et qui tourne sur dsm 6 (en fait DSM 4 puis 5 et enfin 6) mais au fil de l'eau divers problèmes sont apparut... (interface web qui ne réponds pas toujours, lenteur de copie...). J'ai fait les test smart et etc... mais l'idée de mon post n'est pas la maintenance de l'actuel dsm.

 

J'ai un nouveau hdd, appelons le hddN,  et je souhaite installer un DSM "frais" dessus (fresh install, comme on dit).

Une fois configuré, je veux pouvoir rapatrier sur hddN mes données qui se trouve sur hddA. 

 

Comment dois-je procéder ? 

Est-ce possible d'insérer hddA dans la seconde baie et lancer les copie de fichier ? Qu'en est-il si j'éteins mon syno et le rallume ? sachant qu'il contiendrait deux disques dur avec deux DSM fonctionnels ? 

Est-ce possible de brancher hddA comme disque dur externe et lancer les copie de fichier ?

C'est tout bête, mais je trouve rien là-dessus !

 

Merci de vos conseils

Modifié le 1 septembre 2017 par catimimi
Orthographe

[Mic13710]

Il n'y a pas de recette miracle.

Vous ne pouvez pas insérer un disque et y installer une version différente de DSM. La partition système fonctionne en RAID1. Lorsque vous introduisez un nouveau disque, sa partition système recopiera intégralement celle des disques en opération.

Si vous voulez partir sur une installation fraîche, pas d'autre choix que tout reprendre à zéro.

De même, vous ne pouvez pas lire votre disque à partir d'un lecteur externe connecté au NAS car son système de fichier est en RAID. Le seul moyen pour le lire c'est de l'installer sur un PC sous linux, d'y installer mdadm et lvm2 avant de pouvoir accéder aux données. Vous pouvez utiliser une distribution linux genre ubuntu sur un PC classique. Il y a un tuto Synology pour ça.

La meilleure méthode consiste à mettre à jour vos sauvegardes Hyperbackup, d'installer le dernier DSM avec un nouveau disque sur le NAS et de restaurer les sauvegardes sur le nouveau volume.

[jbonlinea]

Bonjour et merci pour ces premiers éléments.

Plusieurs questions/questionnements

 

Mettons que je n'ai qu'un hdd dans mon syno, et que le système de fichier soit le système "propriétaire" de synology dont j'ai oublié le nom (sans duplication des hdd, le truc hybride quelque chose).

Je peux sortir mon hddA, en mettre le nouveau hddN, et faire une installation fraiche sur ce dernier. ok

Ce fait, je ne peux ni insérer mon ancien hddA dans la seconde baie, ni le mettre dans un boitier externe et y accéder via usb depuis le syno. (c'est tout de même pas pratique, qu'avaient-il en tête)

 

Par ailleurs, faire une sauvegarde hyperbackup, oui pourquoi pas, mais sur quel disque et comment ?

Il faudrait que j'insère mon hddN dans ma seconde baie et que je fasse un backup de hddA dessus ? puis que je formate hddA pour repartir d'une installation fraiche ? vu la quantité de donnée, il ne faut pas être pressé et ce type de sauvegarde rends impossible l'accès au donné depuis une machine tierce (j'aime pas trop ça)

 

In fine, j'ai l'impression que le mieux serait encore que je branche mon hddN en usb sur le syno, fasse des copie de fichier manuellement... (avec les problème connus en cas d'erreur de copie), que je fasse une instalation fraiche sur le hddA et que je ramène de nouveau mes données dessus ! 

 

j'ai l'impression que quelque chose m'échappe !

 

merci

[Mic13710]

il y a une heure, jbonlinea a dit :

j'ai l'impression que quelque chose m'échappe !

Et moi il y a un gros truc qui m'échappe, c'est que vous n'ayez pas de sauvegarde de vos données ! Que se passera t'il le jour ou vous perdrez votre unique disque ?

Quand on met en place une solution de stockage de données, on met obligatoirement en place en parallèle une sauvegarde périodique.

il y a une heure, jbonlinea a dit :

Mettons que je n'ai qu'un hdd dans mon syno, et que le système de fichier soit le système "propriétaire" de synology dont j'ai oublié le nom (sans duplication des hdd, le truc hybride quelque chose).

Il n'y a pas vraiment de système propriétaire Synology. Le SHR puisque c'est de ça dont vous voulez parler n'est rien d'autre qu'un RAID classique sur laquelle a été ajoutée une couche lvm (qui n'a rien de propriétaire) pour faire de la gestion multiraid.

il y a une heure, jbonlinea a dit :

(c'est tout de même pas pratique, qu'avaient-il en tête)

Aucun disque RAID qu'il soit matériel ou logiciel ne peut être lu directement. Il lui faut un environnement hard ou soft spécifique ce qui interdit toute possibilité d'accès aux données à partir d'un simple boitier usb.

il y a une heure, jbonlinea a dit :

In fine, j'ai l'impression que le mieux serait encore que je branche mon hddN en usb sur le syno, fasse des copie de fichier manuellement... (avec les problème connus en cas d'erreur de copie), que je fasse une instalation fraiche sur le hddA et que je ramène de nouveau mes données dessus ! 

Puisque vous travaillez sans sauvegarde, c'est effectivement la solution la plus évidente.

[jbonlinea]

Re,

Il y a 1 heure, Mic13710 a dit :

Et moi il y a un gros truc qui m'échappe, c'est que vous n'ayez pas de sauvegarde de vos données ! Que se passera t'il le jour ou vous perdrez votre unique disque ?

Quand on met en place une solution de stockage de données, on met obligatoirement en place en parallèle une sauvegarde périodique.

J'ai mes données importante en double, bien sûr, et même en triple,  une copie sur le ssd de mon portable, une copie sur le syno et une copie sur un hdd usb que je branche plus ou moins régulièrement sur le syno et que je synchronise (synchronisais) avec time-backup... 

Ceci étant dit, j'ai pas mal de donnée que je n'ai pas en double... notamment, film, musique, tutoriel d'informatique ou de musique en vidéo, ainsi que des sauvegardes des données de ma mère que je fais de temps en temps... bref des choses que je peux me permettre de perdre, mais qu'il m'est plus simple de garder que de récupérer de nouveau.

Mis bout à bout ça fait pas mal de chose...

Il y a 1 heure, Mic13710 a dit :

Il n'y a pas vraiment de système propriétaire Synology. Le SHR puisque c'est de ça dont vous voulez parler n'est rien d'autre qu'un RAID classique sur laquelle a été ajoutée une couche lvm (qui n'a rien de propriétaire) pour faire de la gestion multiraid.

Ok, j'avais retenu que c'était un système dont syno était propriétaire, mais ça fait 5ans que j'ai le NAS et ne me suis pas reposé la question depuis la première instalation

 

Il y a 1 heure, Mic13710 a dit :

Aucun disque RAID qu'il soit matériel ou logiciel ne peut être lu directement. Il lui faut un environnement hard ou soft spécifique ce qui interdit toute possibilité d'accès aux données à partir d'un simple boitier usb.

Ok, je comprends sur le principe, j'ai des boitier externes avec lesquels je ne peux pas faire de test smart, d'autres oui... mais quatres choses me viennent : 

- j'ai envie de dire, évidement, je ne lis pas un hdd, qu'il soit en fat16, en NTFS ou en HFS+ directement, du bout des yeux, il y a forcément un environnement hard et soft...

- dans l'absolu, si je peux lire le hdd de mon syno dans une machine linux avec mdadm et lvm2, alors c'est bien qu'on peut accéder au contenu d'un disque raid, sans qu'il ne soit utilisé en tant que tel... 

- il n'est pas dit, en soit, qu'un boitier externe, n'est pas doté, niveau hard, des moyens permettant au système sur lequel il est branché d'acceder au contenu d'un hdd raid...

- le DSM pourrait par exemple être doté de  mdadm et lvm2, ou il est probablement possible de les installer depuis le terminal du syno...

 

Alors :

- il y a peut être des spécificité au raid qui font que, par exemple, ce serait trop couteux de faire des boitier externe qui le gère, mais en soit...

- quid d'une solution logiciel, incluse dans le dsm, qui une fois lancé, permettrait d'insérer dans une des baies libre du syno, un hdd provenant d'un (autre) syno...
 

Il y a 1 heure, Mic13710 a dit :

 

Puisque vous travaillez sans sauvegarde, c'est effectivement la solution la plus évidente.

pour finir je ne peux m'empêcher de penser à ça, car j'ai bien faillit être dans cette situation

imaginons, j'ai un vieux syno DS112, il tombe en panne matériel,  mais le hdd est bon, j'achète un nouveau syno, un 417+ , je l'installe avec un nouveau hdd, notamment car les deux syno n'ont pas du tout a même architecture matériel et je profite de l'occasion pour augmenter ma capacité de stockage ; eh ben je ne peux pas récupérer les donnée du hdd de mon ancien syno sans le monter dans une tour linux sur laquelle il me faut installer des package... 

il me semble que cela demande des connaissance technique et du matériel que tout le monde n'a pas sous le coude... c'est une galère et limite l'intérêt d'avoir un nas puisque l'on paye notamment pour une solution logiciel performante, et c'est un peu de la provocation, mais à ce compte là, un rapsberry pi n'a plus grand chose à envier au DSM... 

 

donc oui je m'étonne qu'il ne soit pas possible d'extraire les données stockées sur un syno plus facilement.

Il me faut réfléchir à où je vais mettre ma sauvegarde hyper backup, sur un hdd sur la seconde baie ou en usb ;  que se passera-il une fois le dsm fraichement installé, dans quelle condition la sauvegarde d'hyper backup sera accessible ? sans ses réponse, on se jette dans le vide...

 

et c'est bien pour éviter cela que je fais appel à votre expérience...

 

alors comment procéderiez vous pour repartir avec une installation fraiche de votre syno, sachant que vous avez du hdd et du boitier externe à disposition (ce qui est déjà un luxe)  ?

merci 

 

Modifié le 1 septembre 2017 par jbonlinea

[Mic13710]

Désolé de vous le dire mais votre raisonnement est trop binaire.

Oui, et fort heureusement, mdadm et lvm2 sont installés sur les nas multibaie sinon il serait impossible de faire du raid logiciel. Mais non encore une fois, on ne peut pas lire les disques issus d'un raid directement à partir d'un simple boitier usb parce que mdadm a besoin d'au moins N-1 disques d'une grappe pour pouvoir fonctionner. Vous voyez votre cas personnel, celui où vous n'avez qu'un RAID simple disque ou à deux disques. Mais comment pensez-vous pouvoir lire un disque issu d'un RAID5 (3 disques et plus) ? De plus, il y a probablement des contraintes matérielles qui font que mdadm a probablement besoin que les disques soient connectés en sata ou ide pour pouvoir fonctionner.

il y a 35 minutes, jbonlinea a dit :

quid d'une solution logiciel, incluse dans le dsm, qui une fois lancé, permettrait d'insérer dans une des baies libre du syno, un hdd provenant d'un (autre) syno...

Parce qu'en l'état actuel c'est totalement impossible sur un NAS et ça le sera encore très longtemps je pense à cause du principe de gestion des disques de linux.

il y a 17 minutes, jbonlinea a dit :

imaginons, j'ai un vieux syno DS112, il tombe en panne matériel,  mais le hdd est bon, j'achète un nouveau syno, un 417+ , je l'installe avec un nouveau hdd, notamment car les deux syno n'ont pas du tout a même architecture matériel et je profite de l'occasion pour augmenter ma capacité de stockage ; eh ben je ne peux pas récupérer les donnée du hdd de mon ancien syno sans le monter dans une tour linux sur laquelle il me faut installer des package... 

Et bien non, là encore vous avez tord. Un disque issu d'un nas monobaie n'a ni mdadm ni lvm2 puisqu'il n'en n'a pas besoin. Dans ce cas le disque est un vrai basic en ext4 qui peut être utiliser directement dans un boitier USB !

Ce n'est pas du tout le cas des disques de NAS multibaie où tous les disques sans exception fonctionnent avec mdadm.

Si vous ne vouliez qu'un seul disque, et que vous vouliez que ce disque soit lisible directement, il fallait choisir un NAS monobaie (ou un Rasp PI avec un disque dur, lui aussi en ext4).

Quand on prend un nas multibaie, il faut être conscient que l'accès aux données hors nas demande un peu plus de matériel qu'un simple boitier usb.

il y a 28 minutes, jbonlinea a dit :

donc oui je m'étonne qu'il ne soit pas possible d'extraire les données stocker sur un syno plus facilement.

Je vous ai donné une méthode à partir d'un PC. On peut aussi le faire en migrant les disques d'un nas vers un autre.

il y a 31 minutes, jbonlinea a dit :

alors comment procéderiez vous pour repartir avec une installation fraiche de votre syno, sachant que vous avez du hdd et du boitier externe à disposition (ce qui est déjà un luxe)  ?

 

Il y a 2 heures, jbonlinea a dit :

In fine, j'ai l'impression que le mieux serait encore que je branche mon hddN en usb sur le syno, fasse des copie de fichier manuellement... (avec les problème connus en cas d'erreur de copie), que je fasse une instalation fraiche sur le hddA et que je ramène de nouveau mes données dessus ! 

Vous avez vous même donné la réponse.

Mais plutôt que de faire toutes ces circonvolutions, pourquoi ne pas simplement commencer par un double reset du NAS pour faire une réinstallation propre du DSM ?

[jbonlinea]

 

ok merci pour ces éléments complémentaires, et pas de problème, je raisonne avec ce que je sais et j'apprends de mes questions, et surtout de vos réponses :-)

il y a 26 minutes, Mic13710 a dit :

Désolé de vous le dire mais votre raisonnement est trop binaire.

Oui, et fort heureusement, mdadm et lvm2 sont installés sur les nas multibaie sinon il serait impossible de faire du raid logiciel. Mais non encore une fois, on ne peut pas lire les disques issus d'un raid directement à partir d'un simple boitier usb parce que mdadm a besoin d'au moins N-1 disques d'une grappe pour pouvoir fonctionner. Vous voyez votre cas personnel, celui où vous n'avez qu'un RAID simple disque ou à deux disques. Mais comment pensez-vous pouvoir lire un disque issu d'un RAID5 (3 disques et plus) ?

Dans mon monde de d'utilisateur final, qui pense à l'usage avant tout, un disque issue RAID5 se lit comme un disque RAID1 ou d'Ext4, il suffit (mais tout est là) que mdadm ait été conçu pour également pouvoir lire des disque raid non monté en raid, justement pour faciliter la récupération de donnée... mais c'est peut être un souhait de simplicité qui aurait un cout (développement, ressource matériel, etc.) trop important pour les structures auxquels il se destine plus largement, non pas mon petit nas, mais de gros gros gros serveurs de donnée

 

il y a 26 minutes, Mic13710 a dit :

Parce qu'en l'état actuel c'est totalement impossible sur un NAS et ça le sera encore très longtemps je pense à cause du principe de gestion des disques de linux.

ok, c'est bien dommage 

 

il y a 26 minutes, Mic13710 a dit :

Et bien non, là encore vous avez tord. Un disque issu d'un nas monobaie n'a ni mdadm ni lvm2 puisqu'il n'en n'a pas besoin. Dans ce cas le disque est un vrai basic en ext4 qui peut être utiliser directement dans un boitier USB !

Ce n'est pas du tout le cas des disques de NAS multibaie où tous les disques sans exception fonctionnent avec mdadm.

alors reprenons le même scénario que précédement sauf que je n'ai plus un DS112, mais un DS212, dans lequel il n'y aurait qu'un disque dur, je suis sûr que c'est très fréquent dans les petites structures et chez les particulliers...

il y a 26 minutes, Mic13710 a dit :

Si vous ne vouliez qu'un seul disque, et que vous vouliez que ce disque soit lisible directement, il fallait choisir un NAS monobaie (ou un Rasp PI avec un disque dur, lui aussi en ext4).

Quand on prend un nas multibaie, il faut être conscient que l'accès aux données hors nas demande un peu plus de matériel qu'un simple boitier usb.

Je vous ai donné une méthode à partir d'un PC. On peut aussi le faire en migrant les disques d'un nas vers un autre.

Vous avez vous même donné la réponse.

J'ai le matériel nécessaire, je trouve l'opération un peu lourde, c'est surement le cout de la puissance du raid.

Néanmoins, je pense que le développement d'un utilitaire/package, permettant de monter ou de simuler le montage d'un disque raid 1 ou 5 en disque classique, uniquement dans le cadre d'une maintenance ou récupération du système, serait un vrai plus

 

il y a 26 minutes, Mic13710 a dit :

Mais plutôt que de faire toutes ces circonvolutions, pourquoi ne pas simplement commencer par un double reset du NAS pour faire une réinstallation propre du DSM ?

oui, mais je ne voulais pas courir le risque de perdre les donnée "secondaire" que j'ai, même si elles ont une importance relative.

Du coup, je vais mettre des hdd usb, y faire des sauvegarde via hyperbackup, refaire une installation complète du nas et restaurer mes sauvegarde.

[Mic13710]

Je comprends que vous ne comprenez pas ce qu'est un RAID et encore moins un RAID5. Si c'était le cas, nous n'aurions pas cette discussion sans fin car vous sauriez qu'il est absolument impossible de lire des données sur un seul disque d'une grappe puisque les données sont réparties entre tous les disques selon le principe de l'agrégation par bandes.

il y a une heure, jbonlinea a dit :

je ne voulais pas courir le risque de perdre les donnée "secondaire" que j'ai, même si elles ont une importance relative.

Rien ne vous empêche de le faire une fois que vous aurez terminé votre sauvegarde. Si ça fonctionne, vous n'aurez pas a transférer les données sauvegardées.

[jbonlinea]

Bonsoir, 

Effectivement, je ne connais pas les fondements du RAID.

Ces méconnaissances m'ont mis sur une mauvaise piste, quoi que cet échange m'a apprit quelque petites chose, que j'aurais certes pu trouver ailleurs si je m'étais intéressé au RAID, mais ce n'est qu'en partie le problème. L'autre étant que synology pourrait prévoir qu'un utilisateur insère dans une baie libre d'un syno fonctionnel et sur lequel se trouve un dsm et des données, un  autre disque précédemment utilisé  dans un autre syno et sur lequel il se trouvait également une installation du dsm et des données; dans l'absolu, ca dois bien être possible à réaliser, et vous me direz que oui dans l'absolu tout est possible, mais  que ça ne fait pas des masse avancer les choses, et vous auriez raison, excepter qu'il est parfois intéressant de penser à la souplesse d'utilisation... 

 

Mise à part ça, je suis en train de faire mes backup et je constate à mon grand étonnement que le disque se trouvant dans mon syno 712+ est formaté en ext4 ! 

Cordialement

[Mic13710]

Non, là encore il est impossible d'insérer un disque issu d'un NAS dans un autre NAS en opération. La raison en est simple : la gestion des disques sous Linux n'a strictement rien à voir avec ce qui se fait sous windows. Contrairement à windows, linux considère le stockage comme un tout. Il n'y a pas de disque A, B, C .... mais un seul stockage qui est la combinaison de ce qu'il y a sur les disques A, B, C...

Si vous prenez un disque d'un autre NAS, il aura forcément un volume 1 qui rentrera en conflit avec le volume 1 existant, et si par hasard il n'y a pas conflit de volume il y aura ceux des dossiers partagés (photo, music, etc ) qui eux aussi rentreront en conflit avec ceux existants. Je ne parle même pas des conflits dans les paramétrages système et paquets. Dans ce cas, Linux n'a pas d'autre choix que de rejeter l'intrus du système et de le considérer que comme un disque à formater.

Il y a 20 heures, jbonlinea a dit :

je constate à mon grand étonnement que le disque se trouvant dans mon syno 712+ est formaté en ext4

Et vous vous attendiez à quoi ?

[jbonlinea]

Il y a 1 heure, Mic13710 a dit :

Non, là encore il est impossible d'insérer un disque issu d'un NAS dans un autre NAS en opération. La raison en est simple : la gestion des disques sous Linux n'a strictement rien à voir avec ce qui se fait sous windows. Contrairement à windows, linux considère le stockage comme un tout. Il n'y a pas de disque A, B, C .... mais un seul stockage qui est la combinaison de ce qu'il y a sur les disques A, B, C...

a ma connaissance linux monte les disque et partitions comme sda1, sda2, sdb1, etc., mais ce système ne tient vraisemblablement pas pour le raid.

 

Non, là encore il est impossible d'insérer un disque issu d'un NAS dans un autre NAS en opération. La raison en est simple : la gestion des disques sous Linux n'a strictement rien à voir avec ce qui se fait sous windows. Contrairement à windows, linux considère le stockage comme un tout. Il n'y a pas de disque A, B, C .... mais un seul stockage qui est la combinaison de ce qu'il y a sur les disques A, B, C...

Si vous prenez un disque d'un autre NAS, il aura forcément un volume 1 qui rentrera en conflit avec le volume 1 existant, et si par hasard il n'y a pas conflit de volume il y aura ceux des dossiers partagés (photo, music, etc ) qui eux aussi rentreront en conflit avec ceux existants. Je ne parle même pas des conflits dans les paramétrages système et paquets. Dans ce cas, Linux n'a pas d'autre choix que de rejeter l'intrus du système et de le considérer que comme un disque à formater.

Et vous vous attendiez à quoi ?

quelque chose qui distingue l'ext4 simple du ext4 raid / lvm / mdam

 

[Mic13710]

il y a une heure, jbonlinea a dit :

a ma connaissance linux monte les disque et partitions comme sda1, sda2, sdb1, etc., mais ce système ne tient vraisemblablement pas pour le raid.

Oui, en ce qui concerne un disque en basic (notation sd). Pour les RAID ou SHR se rajoute au sd le moteur md. De plus, nos disques (comme c'est souvent le cas sous linux) ont 3 partitions : système, swap, données.

Pour un disque en basic pur (celui d'un NAS monobaie) nous aurons seulement sda1(système), sda2(swap), sda3(données). Les monobaie sont les seuls NAS a avoir de vrais disques basic. Il n'y aura donc pas de sdb, ni de sdc etc...

Tous les autres NAS ont des disques en RAID.

Par exemple, pour un NAS 2 baies nous aurons toujours :

• un groupe md0 (système) formant un RAID1 avec sda1 et sdb1
• un groupe md1 (swap) formant un RAID1 avec sda2 et sdb2

Puis selon l'organisation des disques nous aurons :

• avec 2 disques en 1 volume (RAID1 ou SHR avec protection des données), un groupe md2 formant un RAID1 avec sda3 et sdb3
• avec 2 disques en 2 volumes ("pseudo" Basic ou SHR sans protection des données), un groupe md2 formant un RAID monodisque avec sda3 et un groupe md3 formant un RAID monodisque avec sdb3, d'où la dénomination que je leur donne de "pseudo" basic puisqu'ils ont besoin du moteur md pour pouvoir être lus.

A noter que le SHR peut créer des md supplémentaires, mais ce n'est pas le propos ici.

il y a une heure, jbonlinea a dit :

quelque chose qui distingue l'ext4 simple du ext4 raid / lvm / mdam

Ca n'a rien à voir. L'EXT4 c'est le système de fichier des disques, le RAID c'est ce qui les fait travailler ensemble.

Edit :

Pour illustrer mon propos, voici les relevés de mes deux NAS :

le 214+ en vrai RAID1 :

Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid1 sda3[3] sdb3[2]
      3902296416 blocks super 1.2 [2/2] [UU]

md1 : active raid1 sda2[0] sdb2[1]
      2097088 blocks [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[1]
      2490176 blocks [2/2] [UU]

le 710+ avec 2 disques en "pseudo" basic :
 

Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md3 : active raid1 sdb3[0]
      3902296416 blocks super 1.2 [1/1] [U]

md2 : active raid1 sda3[0]
      3902296416 blocks super 1.2 [1/1] [U]

md1 : active raid1 sda2[0] sdb2[1]
      2097088 blocks [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[1]
      2490176 blocks [2/2] [UU]

Vous voyez bien que md2 et md3 sont indiqués comme étant des RAID1 dont les seuls supports sont respectivement sda3 et sdb3, donc rien de basic.

[jbonlinea]

Bonjour, 

Merci pour ces infos, je comprends effectivement mieux les différences.

En fait, si je comprends bien, c'est très simple ; j'ai bon ? j'ai faux ? :

- toute distribution linux, même les plus épurées (tel que raspbian_lite pour cite un exemple que je connais) est doté du moteur sd (ou du/des package.s), celui-ci étant nécessaire à l'accès au.x disque.s ;  par contre le moteur md  (ou le.s package.s et dépendances) n'est pas installé de base (Out of the box)

- De part les modalité de gestion des disque sous linux, un disque dur issue d'une grappe Raid ne peut être lu que sur une machine doté des moteurs sd et md (ou packages et dépendances) 

- toutefois une machine doté de sd et md n'a pas nécessairement besoin d'un contrôleur raid pour lire un disque issue d'une grappe

--> pas nécessairement, car le raid et peut être logiciel ou matériel (controleur raid).  

--> Le matériel, n'est donc pas nécessaire en soit, mais soulage l'ordinateur (le processeur et +) d'une partie du travail lié à l'accès/écriture des disques.

--> Pour ce faire le controleur raid utilise lui aussi du logiciel

--> si la couche  logiciel utilisée par le controleur raid est la même que le raid logiciel dont est doté votre ordinateur, alors vous pouvez lire un disque raid en le branchant directement sur un port sata de votre carte mère ; c'est semble-il le cas pour synology ; nos nas sont des controleurs raid (notamment), mais ces derniers utilisent (grosso modo) les même logiciels qu'un système linux conventionnel (debian/ubuntu/fedora/raspbian... peu importe)

--> si le controleur raid utilise une couche logiciel différente, vous êtes coincé, car vous ne pouvez de facto accéder à vos disque raid que via cette couche logiciel... 

 

Reste un point a éclaircir : pourquoi peut on accéder à un disque raid en le branchant directement sur un port sata de la carte mère et pas par usb ? très certainement car le moteur md, ne sais pas travailler en usb, contrairement au moteur sd. Reste à voir si et dans quelle mesure l'usb est en soit limitant, et si un boitier e-sata est fonctionnel ? 

 

j'ai bon ? j'ai faux ?

 

 

ps :je continu de creuser car j'aime bien comprendre/apprendre et que ça à une implication pour l'utilisation / la gestion des disque et sauvegarde avec un syno; mais pour mon problème initial, c'est totalement superficiel, j'ai fais mes backup hyper hyper backup et finito :-)

[Mic13710]

Je suppose que ce que vous appelez "les packages et dépendances" sont mdadm (RAID logiciel classique) + lvm2 (si SHR).

Il y a 3 heures, jbonlinea a dit :

- toute distribution linux, même les plus épurées (tel que raspbian_lite pour cite un exemple que je connais) est doté du moteur sd (ou du/des package.s), celui-ci étant nécessaire à l'accès au.x disque.s ;  par contre le moteur md  (ou le.s package.s et dépendances) n'est pas installé de base (Out of the box)

Vrai pour le sd. Par contre md est dispo en principe sur toutes les distris dont le kernel le supporte. C'est le cas par exemple d'Ubuntu. C'est mdadm et lvm2 qui sont absents des distris classiques. Ils le sont bien évidemment sur nos NAS .

Il y a 3 heures, jbonlinea a dit :

- De part les modalité de gestion des disque sous linux, un disque dur issue d'une grappe Raid ne peut être lu que sur une machine doté des moteurs sd et md (ou packages et dépendances) 

Vrai, mais pour le md seul si le disque est issu d'un RAID1, sinon il va falloir y ajouter mdadm et éventuellement lvm2 et travailler avec au moins N-1 disques.

Il y a 3 heures, jbonlinea a dit :

- toutefois une machine doté de sd et md n'a pas nécessairement besoin d'un contrôleur raid pour lire un disque issue d'une grappe

--> pas nécessairement, car le raid et peut être logiciel ou matériel (controleur raid).  

--> Le matériel, n'est donc pas nécessaire en soit, mais soulage l'ordinateur (le processeur et +) d'une partie du travail lié à l'accès/écriture des disques.

--> Pour ce faire le controleur raid utilise lui aussi du logiciel

--> Pour ce faire le controleur raid utilise lui aussi du logiciel

--> si la couche  logiciel utilisée par le controleur raid est la même que le raid logiciel dont est doté votre ordinateur, alors vous pouvez lire un disque raid en le branchant directement sur un port sata de votre carte mère ; c'est semble-il le cas pour synology ; nos nas sont des controleurs raid (notamment), mais ces derniers utilisent (grosso modo) les même logiciels qu'un système linux conventionnel (debian/ubuntu/fedora/raspbian... peu importe)

--> si le controleur raid utilise une couche logiciel différente, vous êtes coincé, car vous ne pouvez de facto accéder à vos disque raid que via cette couche logiciel... 

J'ai un peu de mal à comprendre ce que vous voulez dire.

Des disques issus de RAID logiciels ont besoin de mdadm et éventuellement lvm2 pour pouvoir être lu sur un PC sous linux ayant suffisamment de ports sata pour y connecter au moins N-1 disques de la grappe.

Pour le RAID matériel, c'est le contrôleur intégré dans le rack qui gère. Il n'a donc en principe pas besoin des packages supplémentaires (mdadm etc..) mais peut nécessiter un logiciel spécifique qui est le plus souvent propriétaire. Il ne peut pas être lu sur une machine autre.

Il y a 4 heures, jbonlinea a dit :

Reste un point a éclaircir : pourquoi peut on accéder à un disque raid en le branchant directement sur un port sata de la carte mère et pas par usb ? très certainement car le moteur md, ne sais pas travailler en usb, contrairement au moteur sd. Reste à voir si et dans quelle mesure l'usb est en soit limitant, et si un boitier e-sata est fonctionnel ? 

Je pense effectivement que le moteur md est difficilement concevable sur un port usb, mais je n'ai pas de réponse précise à cette question. Désolé.

[jbonlinea]

Le 16/09/2017 à 20:02, Mic13710 a dit :

C'est mdadm et lvm2 qui sont absents des distris classiques. Ils le sont bien évidemment sur nos NAS .

Vrai, mais pour le md seul si le disque est issu d'un RAID1, sinon il va falloir y ajouter mdadm et éventuellement lvm2 et travailler avec au moins N-1 disques.

ok, c'est ce à quoi je pensais, mais je ne savais pas quel était précisément le role de mdadm et lvm2 sans l'affaire, donc md --> raid 1, mdadm  raid 5 et 6,  lvm2 -->SHR

Des disques issus de RAID logiciels ont besoin de mdadm et éventuellement lvm2 pour pouvoir être lu sur un PC sous linux ayant suffisamment de ports sata pour y connecter au moins N-1 disques de la grappe.

 

oui, et rien d'autre, c'est pourquoi un disque isolé d'une grappe peut être lu !

Pour le RAID matériel, c'est le contrôleur intégré dans le rack qui gère. Il n'a donc en principe pas besoin des packages supplémentaires (mdadm etc..) mais peut nécessiter un logiciel spécifique qui est le plus souvent propriétaire. Il ne peut pas être lu sur une machine autre.

c'est bien ça ! 

et quand ce controleur utilise lui-même sd, md, mdadm et lvm2 pour gérer les disque, alors ont peut, si je ne m'abuse, sortir le disque de la grappe et le brancher directement en sata dans une tour ; et c'est le cas de nos syno (pas si mal foutu que ça finalement, mais quand même un peu ;-))

par contre quand le controleur utilise des logiciels (propriétaire) non fonctionnel sans le matériel lui-même, ou non distribué indépendamment du matériel, alors il n'est plus possible de lire un disque RAID hors de son environnement logiciel/matériel de provenance 

Je pense effectivement que le moteur md est difficilement concevable sur un port usb, mais je n'ai pas de réponse précise à cette question. Désolé.

Le noeud est donc là, et c'est la qu'intervient le JBOD, j'imagine...

Et c'est aussi la qu'il serait top qu'il existe des package md-usb mdadm-usb qui ferait le boulot magique (tel une machine virtuelle par ex) permettre à un système de monter en sd, un disque md connecté en usb ! mais il y a surement des contrainte qui me dépassent ; la même chose avec md-esata,  mdamd-esata est peut être plus réaliste (et la avoir un nas type 712+ serait un réel atout) 

 

bon, ça fait pas des masse avancer les choses, mais en tout cas j'ai apprit pas mal de truc ! 

et puis ca fait partie des chose qu'il est bon de savoir avant d'acheter un nas, notamment car je pense que la plupart des acheteurs de petits nas type 1xx (qui n'ont pas ce problème) ou 2xx (qui l'ont) ne se sont pas penché sur la question et que ce qui détermine l'achat d'un 1xx vs 2xx est tout autre, imaginaire du qui peu le plus peut le moins, imaginaire de j'ai pas un tout petit nas, je me suis fait plaisir / je suis pas un clown / j'ai des vrai besoins /etc, imaginaire de sécurité offert par le raid alors que deux nas 1xx à deux endroits différents offrent bien mieux (feu, cambriolage, etc.)

en fait c'est une subtilité c'est fondamentale, et me connaissant ça m'étonne que ça m'est échappé au moment de l'achat, du coup je pense que ce n'est pas quelque chose mis en avant dans le choix d'un Nas alors que ce pourrait/devrait

 

En tout cas merci pour tes explications

[Mic13710]

il y a une heure, jbonlinea a dit :

c'est pourquoi un disque isolé d'une grappe peut être lu !

Encore une fois, c'est non pour un RAID 5, 6 ...!

Si vous prenez un disque RAID1 oui car il est en miroir, mais pas un disque isolé issu d'un RAID5, 6 etc.. car il est en agrégation. Ce que vous pourrez éventuellement lire (je dis bien éventuellement) sera très parcellaire et largement inexploitable.

[jbonlinea]

il y a 50 minutes, Mic13710 a dit :

Encore une fois, c'est non pour un RAID 5, 6 ...!

Si vous prenez un disque RAID1 oui car il est en miroir, mais pas un disque isolé issu d'un RAID5, 6 etc.. car il est en agrégation. Ce que vous pourrez éventuellement lire (je dis bien éventuellement) sera très parcellaire et largement inexploitable.

ok, 

à y réfléchir, sachant qu'un  RAID 5 (ou 6 avec une double parité) fonctionne de la sorte : 

hdd1     hdd2    hdd3  hdd4

A1         A2        A3      Ap

B1         B2       Bp      B3

C1       C        C2     C3

Dp        D1       D2      D3

je comprend pourquoi je ne peux pas lire A1 A2 et A3 si mes hdd 1, 2 ou 3 sont isolée, mais je comprends pas comment le raid peut restaure ce qui est perdu sur A1, 2 ou 3 à partir de Ap, si Ap n'est pas lisible seul ?!

enfin... 

en tout cas merci !

[Mic13710]

Extrait de Wikipedia sur le RAID5 :

Considérons quatre disques durs A, B, C et D, de taille identique. Le système va répartir les premiers blocs sur les disques A, B et C comme en mode RAID 0 (striping) et, sur le disque D, le résultat de l'opération OU exclusif entre les autres disques (ici A xor B xor C). Il va répartir les blocs suivants sur les disques D, A et B, puis la parité (soit D xor A xor B) sur le disque C, et ainsi de suite en permutant circulairement les disques, à chaque bloc. La parité se trouve alors répartie sur l'ensemble des disques.

En cas de défaillance d'un disque, les données qui s'y trouvaient pourront être reconstituées par l'opération xor. En effet, l'opération XOR ( ⊕{\displaystyle \oplus }) a la propriété suivante : si on considère N{\displaystyle N} blocs de taille identique A1,A2⋯AN{\displaystyle \scriptstyle A_{1},A_{2}\cdots A_{N}} et si A1⊕A2⊕⋯AN=X{\displaystyle \scriptstyle A_{1}\oplus A_{2}\oplus \cdots A_{N}=X} alors X⊕A2⊕⋯AN=A1{\displaystyle \scriptstyle X\oplus A_{2}\oplus \cdots A_{N}=A_{1}}, et de façon générale, A1⊕⋯Ak−1⊕X⊕Ak+1⊕⋯AN=Ak{\displaystyle \scriptstyle A_{1}\oplus \cdots A_{k-1}\oplus X\oplus A_{k+1}\oplus \cdots A_{N}=A_{k}}.

C'est-à-dire que n'importe quel bloc de données Ak{\displaystyle A_{k}} perdu à cause d'un disque défaillant sur un RAID 5 de N+1{\displaystyle N+1} disques peut être récupéré grâce au bloc X{\displaystyle X} de données de contrôle.

On voit donc que si on veut écrire dans un bloc, il faut lire le bloc à modifier. Lire le bloc de parité de la bande. Écrire le bloc de données et le bloc de parité. L'opération xor permet heureusement de calculer la nouvelle parité sans avoir besoin de lire les N{\displaystyle N} blocs de données de la bande. Augmenter le nombre de disques d'une grappe RAID 5 n'allonge donc pas le temps de lecture ou d'écriture. Cependant si plusieurs processus veulent écrire simultanément dans un ou plusieurs blocs de données d'une même bande la mise à jour du bloc de parité devient un point de blocage. Les processus concurrents sont suspendus à la libération du bloc de parité et de fait cela limite le débit d'écriture. Plus le nombre de disques d'une grappe RAID 5 augmente plus le temps de reconstruction d'un disque défaillant augmente. Puisque pour reconstituer le bloc manquant d'une bande il faut lire tous les autres blocs de la bande et donc tous les autres disques.