Bonjour,
Sur ma Debian, j'ai actuellement deux disques en RAID1 logiciel avec du LVM par dessus.
Cependant, comme je travaille un peu à améliorer mes backups, je pense que je pourrais bientôt me débarrasser du RAID. Je l'avais mis en place après un crash disque où j'avais perdu pas mal de choses.
D'autre part, même si la machine n'est plus toute jeune, j'ai l'impression que le RAID1 fait un peu souffrir la machine de temps en temps.
J'ai trouvé pas mal de doc (comme celle-ci http://www.webstrat.fr/blog/web-technology/supprimer-un-raid-logiciel-sur-linux-ubuntu) pour arrêter le RAID.
Mais, je n'ai rien trouvé de vraiment simple pour dire à LVM qu'il faut taper sur /dev/sdb2 et non plus sur /dev/md2.
Est-ce que j'ai loupé un truc ?
Je me demande aussi si LVM sollicite beaucoup la machine.
Merci de votre aide.
# j'ai pas compris
Posté par NeoX . Évalué à 2.
meme si le RAID n'est pas une solution de backup,
supprimer le raid n'améliore pas la pérennité des données
sauf à avoir un disque externe sur lequel tu archives/backups tes données.
Mais j'imagine que tu envisages de le faire en connaissance de cause.
[^] # Re: j'ai pas compris
Posté par sifu . Évalué à 1.
En fait, je suis en train de mettre en place des sauvegardes régulières de mes disques sur mon NAS (en RAID1) via rdiff-backup. Après, j'essaierais de faire un backup de mon NAS régulièrement sur un disque externe.
Du coup, je me dis que le RAID1, sur ma machine de bureau est un peu superflu.
[^] # Re: j'ai pas compris
Posté par NeoX . Évalué à 2.
ah oui, là je comprend mieux ;)
# pvmove et vgreduce
Posté par cel . Évalué à 4.
Les commandes que tu cherches sont pvmove et vgreduce.
Un rapide pas à pas:
1. TU FAIS UNE SAUVEGARDE DE TES DONNEES
2. tu "casses" ton RAID1 afin de récupérer un disque (c'est ce que décrit le lien que tu donnes)
3. tu ajoutes ce même disk à LVM (pvcreate et vgextend)
4. tu migres tes données du RAID1 vers le disque que tu a ajouté (pvmove)
5. tu supprimes ton RAID1 de LVM (vgreduce)
Source: LVM HOWTO
[^] # Re: pvmove et vgreduce
Posté par sifu . Évalué à 0.
Ok. Merci.
J'avais trouvé quelques trucs dans le genre. Mais je me disais qu'il y avait peut-être moyen de faire juste un changement dans un fichier de configuration.
En effet, les partitions /dev/sda2 et /dev/md2 sont censés être identiques. Non ?
[^] # Re: pvmove et vgreduce
Posté par cel . Évalué à 2.
Il ne faut pas oublier que le RAID logiciel et LVM stockent des meta-data sur les disques utilisés.
/dev/sda2 et /dev/md2 contiennent les mêmes données, mais /dev/sda2 fait partie d'un RAID et LVM ne sait pas l'utiliser directement. C'est pour cela que tu dois d'abord l'initialiser avec la commande pvcreate et l'intégrer à ton volume group avec la commande vgextend.
[^] # Re: pvmove et vgreduce
Posté par sifu . Évalué à 1.
On est d'accord, il y a les méta-données.
Mais pour moi, si LVM, ajoute des métadonnées sur /dev/md2, elles devrait être ajouté sur mon /dev/sda2 et /dev/sdb2. LVM ne doit pas savoir qu'il est sur un RAID.
Une fois que j'ai dégagé les métas-données RAID de /dev/sda2, LVM ne devrait-il pas le voir comme /dev/md2 ? Les partitions sont les mêmes etc.
Pour moi mes deux disques (une fois les métas-données retirées) sont identiques et devrait contenir les métas-données LVM.
J'ai du loupé un truc ...
[^] # Re: pvmove et vgreduce
Posté par NeoX . Évalué à 3.
facile, en resumé tu as un paquet ficelé comme ca
{ [(tes données)+ metadata LVM] + metadata RAID } => ton disque dur
donc ton LVM ne lit pas directement ton disque sda2/sdb2, il ne sait meme pas si y a un ou 5 disques dessous le raid
donc non, il ne peut pas aller taper directement sda2 à la place de md2
puisque les données sur sda2 sont ecrites dans une langue que seule RAID peut lire pour ensuite les proposer à LVM.
[^] # Re: pvmove et vgreduce
Posté par sifu . Évalué à 1.
Ben pour moi c'est pas si facile ;-)
Je pensais que le disque /dev/sda2 et /dev/md2 étaient identiques au méta-données RAID près. En clair, que si je prenais un disque /dev/sda2 et que je le montais sur une autre machine il serait vu comme l'était /dev/md2.
Pour moi, c'était un peu l'objet de la manipulation suivante http://www.superkikim.com/technologies-de-linformation/suppression-dun-volume-raid-soft/
Du coup, que LVM lise sur /dev/md2 ou /dev/sda2, cela devrait revenir au même il faudrait juste lui dire que c'est n'est plus dans la langue "RAID" qu'il faut lire mais que c'est la langue "Linux partition".
On peux le faire au niveau du montage pourquoi LVM n'y arrive pas ?
[^] # Re: pvmove et vgreduce
Posté par nono14 (site web personnel) . Évalué à 2.
Essayes, mais ça va faire mal...
Système - Réseau - Sécurité Open Source
[^] # Re: pvmove et vgreduce
Posté par sifu . Évalué à 0.
En fait, c'est juste que je trouve cela un peu dommage.
Je n'aurais pas LVM, je pourrais faire me débarrasser du RAID avec un seul disque. Là, je suis obligé de faire un pvmode qui me force à avoir les deux disques et qui va certainement prendre un peu de temps.
[^] # Re: pvmove et vgreduce
Posté par NeoX . Évalué à 3.
tu ne m'as pas compris ou je me suis peut-être mal exprimé.
OUI, tu peux passer en mode RAID dégradé pour retirer /dev/sdb2 et ne tourner que sur /dev/sda2
mais ton LVM travaillera toujours avec /dev/md2
tu auras donc toujours l'intermédiaire raid entre ton LVM et ton disque puisqu'il va travailler avec les metadata du raid
et donc la réponse à ta question est bien
NON, tu ne peux pas simplement dire à LVM de travailler directement avec /dev/sda2
il faut donc bien :
- sortir sda2 du raid (pour ne tourner que sur sdb2)
- integrer sda2 au LVM, deplacer les données dessus (pvmove, vgcreate et les outils précédemment cités)
- sortir /dev/md2 du LVM
- sortir /dev/sdb2 du raid (et donc détruire le raid)
- reutiliser /dev/sdb2 pour ce que tu veux (LVM ou disque de données...)
[^] # Re: pvmove et vgreduce
Posté par totof2000 . Évalué à 1.
C'est ce genre de détail qui me fait dire que la non intégration du RAID dans LVM est une belle erreur.
[^] # Re: pvmove et vgreduce
Posté par NeoX . Évalué à 4.
peut-être parce que ce n'est pas le but le LVM
le but de LVM étant de s'affranchir des disques au sens ou tu peux avoir un disque de 10Go, un de 100Go, et faire une espace de 30Go et un de 80Go
alors que tu ne pourrais pas faire de RAID avec ça, ou alors juste avec les 2 premières parties de 10Go
[^] # Re: pvmove et vgreduce
Posté par totof2000 . Évalué à 2.
Ca se fait très bien sous d'autres OS utilisant LVM. Et lea tu t'affranchis du ou des disques sous-jacants.
Tu peux avoir d'un coté un disque de 160 Go et de l'autre 2 disques de 80 Go et tu fais un RAID de cette façon.
[^] # Re: pvmove et vgreduce
Posté par Anonyme . Évalué à 1.
Le seul soucis que j’ai avec LVM c’est qu’il faut nécessairement créer un groupe même quand le groupe ne contient qu’une partition.
[^] # Re: pvmove et vgreduce
Posté par Sébastien Koechlin . Évalué à 1.
Ce n'est pas un soucis; ça permet
[^] # Re: pvmove et vgreduce
Posté par nono14 (site web personnel) . Évalué à 3.
et d'ajouter/supprimer des volumes physiques de manière transparente...
Système - Réseau - Sécurité Open Source
[^] # Re: pvmove et vgreduce
Posté par Sébastien Koechlin . Évalué à 1.
Cette manipulation est un bricolage risqué. Elle profite du fait que sur certaines versions des méta-données RAID, les données de la partition sous-jacente se retrouvent à la même place que si la partition n'était pas RAID. Elle n'a aucune chance de fonctionner avec les version de RAID qui placent les méta-données au début de la partition.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.