[reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

rmy · Le 04/10/2010, à 09:00

Bon, OK. Alors je recommence depuis le commencement du début. À commencer par une nouvelle sauvegarde récente.

rmy · Le 04/10/2010, à 16:27

Heu, je viens de penser à un truc :
J'étais sur le point de tout casser mon raid et de recommencer à zéro, et je me suis dit qu'il y avait comme quelque chose qui sentait le roussi :
Puisque le pvdisplay me dit que je suis actuellement sur le raid, j'ai un peu peur de tout casser pour de bon si je fais pas gaffe, là.

sudo pvdisplay
  --- Physical volume ---
  PV Name               /dev/md0p1
  VG Name               debian
  PV Size               1,82 TiB / not usable 2,56 MiB
  Allocatable           yes 
  PE Size               4,00 MiB
  Total PE              476931
  Free PE               324373
  Allocated PE          152558
  PV UUID               NT2mUJ-71Zq-iH2V-wX21-3CkG-lvLN-6gvmQg
   
  "/dev/mapper/cryptroot" is a new physical volume of "595,93 GiB"
  --- NEW Physical volume ---
  PV Name               /dev/mapper/cryptroot
  VG Name               
  PV Size               595,93 GiB
  Allocatable           NO
  PE Size               0   
  Total PE              0
  Free PE               0
  Allocated PE          0
  PV UUID               TJdpFD-iTRr-jQxg-jqqk-5gPU-tHwL-T28IUV

Tu peux me donner ton avis là dessus ? Il faut que je refasse un pvmove pour repasser sur sda ?

rmy · Le 04/10/2010, à 19:55

Allez, hop, même pas peur, j'ai fini mon rsync, je re-pvmove !

sudo vgextend debian /dev/mapper/cryptroot

 Volume group "debian" successfully extended

sudo vgdisplay
  --- Volume group ---
  VG Name               debian
  System ID             
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  25
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                3
  Open LV               3
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               2,40 TiB
  PE Size               4,00 MiB
  Total PE              629489
  Alloc PE / Size       152558 / 595,93 GiB
  Free  PE / Size       476931 / 1,82 TiB
  VG UUID               CryiJf-tvAL-2yZK-rj1I-R5Im-HrTM-OwCgUe
   
rmy@rmyprod:~$ sudo pvdisplay
  --- Physical volume ---
  PV Name               /dev/md0p1
  VG Name               debian
  PV Size               1,82 TiB / not usable 2,56 MiB
  Allocatable           yes 
  PE Size               4,00 MiB
  Total PE              476931
  Free PE               324373
  Allocated PE          152558
  PV UUID               NT2mUJ-71Zq-iH2V-wX21-3CkG-lvLN-6gvmQg
   
  --- Physical volume ---
  PV Name               /dev/mapper/cryptroot
  VG Name               debian
  PV Size               595,93 GiB / not usable 1,67 MiB
  Allocatable           yes 
  PE Size               4,00 MiB
  Total PE              152558
  Free PE               152558
  Allocated PE          0
  PV UUID               TJdpFD-iTRr-jQxg-jqqk-5gPU-tHwL-T28IUV

sudo pvmove /dev/md0p1 
  /dev/md0p1: Moved: 0,2%
  /dev/md0p1: Moved: 0,3%
…

C'est parti.

Dernière modification par rmy (Le 04/10/2010, à 20:19)

rmy · Le 04/10/2010, à 21:07

 /dev/md0p1: Moved: 27,7%

ETA un peu avant 23h.

Dernière modification par rmy (Le 04/10/2010, à 21:08)

rmy · Le 05/10/2010, à 08:09

J'ai tout cassé.

Le pvmove s'est bien passé, mais au reboot du fsck dans tous les sens, apparemment une mise à jour qui n'était pas correctement achevée dans les messages que j'ai vu passer, plus de gdm, plus grand chose à faire.

Je crois que je vais repartir de mon image de fin août, refaire mon rsync récent à l'envers, et recommencer l'expérience de la migration parce que je suis têtu. Mais dès que c'est fini, je refais une install en 64bits en sortant / du lvm et du chiffrage.

Plus de précisions : après reboot ultime sur FUR, le lvm est bien là, mais plus reconnu correctement. Après un ènieme cfgrestore il est à nouveau reconnu, par contre les FS sont dans le sac (impossible à monter même avec un super de secours).

J'abandonne la tentative de réparation, c'est parti pour une restauration de l'image, puis pour le rsync du /home… plus d'infos ce soir, tard.

EDIT :

moi, mon premier message a écrit :

Bonjour,
je n'ai pas à proprement parler de problème. Pas encore. Mais je préfère anticiper pour rester le moins longtemps possible dans une situation délicate.

Dernière modification par rmy (Le 05/10/2010, à 10:09)

rmy · Le 05/10/2010, à 22:54

Hum, hum, bon, on se calme, je fais conneries sur conneries. L'heure est grave.

Nouveau souci, je ne sais pas si il y a une solution.

(tu remarques que je laisse des lignes pour le suspens)

Quand j'ai fait mon rsync, j'ai zappé un dossier "Public", que j'ai confondu avec "public" (pas tappé, t'as même le droit de rire). Sauf que dans ce dossier, j'y avais mis la veille quelques dizaines de gigas de données de ma sœur avant de formater son disque.

Voilà. Y a-t-il besoin de poser la question ?

(Hoper, ne soit pas vexé, mais je vais essayer de rameuter du monde sur ce cas)

Dernière modification par rmy (Le 05/10/2010, à 22:55)

rmy · Le 05/10/2010, à 23:07

Un point sur la situation actuelle :
après mon dernier pvmove et mon reboot problématique, j'ai restauré une image disque datant du 23/09 sur /dev/sda. Ensuite, j'ai réassemblé mon raid, et je me retrouve donc avec une situation bancale, mais curieuse :

sudo pvscan && sudo vgscan && sudo lvscan && sudo pvdisplay && sudo vgdisplay && sudo lvdisplay
  PV /dev/md0p1              VG debian   lvm2 [1,82 TiB / 1,82 TiB free]
  PV /dev/mapper/cryptroot   VG debian   lvm2 [595,93 GiB / 0    free]
  Total: 2 [2,40 TiB] / in use: 2 [2,40 TiB] / in no VG: 0 [0   ]
  Reading all physical volumes.  This may take a while...
  Found volume group "debian" using metadata type lvm2
  ACTIVE            '/dev/debian/swap_1' [2,53 GiB] inherit
  ACTIVE            '/dev/debian/rootbuntu' [15,00 GiB] inherit
  ACTIVE            '/dev/debian/homebuntu' [578,40 GiB] inherit
  --- Physical volume ---
  PV Name               /dev/md0p1
  VG Name               debian
  PV Size               1,82 TiB / not usable 2,56 MiB
  Allocatable           yes 
  PE Size               4,00 MiB
  Total PE              476931
  Free PE               476931
  Allocated PE          0
  PV UUID               NT2mUJ-71Zq-iH2V-wX21-3CkG-lvLN-6gvmQg
   
  --- Physical volume ---
  PV Name               /dev/mapper/cryptroot
  VG Name               debian
  PV Size               595,93 GiB / not usable 1,67 MiB
  Allocatable           yes (but full)
  PE Size               4,00 MiB
  Total PE              152558
  Free PE               0
  Allocated PE          152558
  PV UUID               TJdpFD-iTRr-jQxg-jqqk-5gPU-tHwL-T28IUV
   
  --- Volume group ---
  VG Name               debian
  System ID             
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  31
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                3
  Open LV               3
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               2,40 TiB
  PE Size               4,00 MiB
  Total PE              629489
  Alloc PE / Size       152558 / 595,93 GiB
  Free  PE / Size       476931 / 1,82 TiB
  VG UUID               CryiJf-tvAL-2yZK-rj1I-R5Im-HrTM-OwCgUe
   
  --- Logical volume ---
  LV Name                /dev/debian/swap_1
  VG Name                debian
  LV UUID                LxEGT1-fmgR-XGGX-byOt-j2p6-bXrs-SasLSs
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                2,53 GiB
  Current LE             648
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:1
   
  --- Logical volume ---
  LV Name                /dev/debian/rootbuntu
  VG Name                debian
  LV UUID                qjJsVW-8iWp-CT0H-YqoS-hsl1-yFTL-MlzMub
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                15,00 GiB
  Current LE             3840
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:2
   
  --- Logical volume ---
  LV Name                /dev/debian/homebuntu
  VG Name                debian
  LV UUID                fo3HBW-BL0n-ctuO-Rgg7-U03h-Vorb-bjq8cP
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                578,40 GiB
  Current LE             148070
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:3

- Puisque le pvmove ne détruit pas les PE sur le dev de initial
- Bien que le résultat précédent n'était pas concluant mais que lvm me signifiait que c'était bien le PV /dev/md0p1 qui était "in USE"
=> Je me dis que les données de ma frangine ont dû être copiées quelque part sur ce [auto-censuré] de raid et que je devrais pouvoir y accéder encore d'une manière ou d'une autre… voir d'une autre.

Qui a des supers pouvoirs dans l'assistance ?

tshirtman · Le 05/10/2010, à 23:35

Sur le disque de ta seur, qui n'est pas cripté lvmé et tout… t'as remis des trucs… ou il a "juste" été formaté (bon, ça parait peu probable, mais on sait jamais).

sinon pour les luks et tout c'est vraiment au dessus de ma tête

rmy · Le 06/10/2010, à 00:00

@tshirtman : sur le disque de ma sœur, comme chaque fois qu'un disque change de proprio en passant par chez moi, /dev/zero… et ensuite partitionnement, install fraîche 10.04, et dans un ordi déjà reparti pour l'autre bout de la France (et merci du soutien psychologique )

chopinhauer · Le 06/10/2010, à 03:03

J'ai essayé de lire cette discussion depuis le début, mais vu la longueur j'ai plutôt survolé. Est-ce que tu peux résumer l'état de ta migration? Pourquoi le deuxième PV du groupe (le RAID /dev/md0p1) n'est pas crypté?

Pour donner une idée plus claire de l'arborescence de ton installation, est-ce que tu pourrais donner le résultat de:

sudo dmsetup ls --tree
sudo lvs -a -o +devices
sudo pvs -o +lv_name

Je n'en ai pas vu en lisant.

PPdM · Le 06/10/2010, à 08:46

@rmy
je ne veux pas enfoncer le clou, mais pour quoi chosir un solution chiffrée, je ne vois vraiment as a quoi cela peut te servir.
Le LVM m'a causé des souci sous toutes les distro ou je l'ai essayé y compris Seven, si tu as un disque qui lâche tu es dans la merde un raid5 est largement suffisant quand au chiffrage??? Tu crains l'espionnage industriel ?

chopinhauer · Le 06/10/2010, à 14:12

Après une relecture de ce sujet de discussion, je crois comprendre ce que tu veux faire: t'as une configuration /dev/sda2 -> /dev/mapper/cryptroot -> LVM -> /dev/mapper/debian-uburoot -> système de fichiers et tu veux faire passer le LVM au dessous du chiffrement.

On a donc un /dev/sda2 chiffré, un /dev/mapper/cryptroot en clair et le reste de la structure LVM.

Si tu veux avoir une structure /dev/md0p1 (la partition est vraiment nécessaire?) -> LVM -> debian-uburoot -> cryptroot -> système de fichiers tu dois chiffrer le volume debian-uburoot. La commande pvmove ne peux pas t'aider dans l'opération, tout ce qu'elle peut faire est bouger le LVM sur le RAID (les données ne sont pas en clair sur /dev/sda2, mais le seront sur le RAID).

Pour faire cette opération il faut:

* Créer un volume logique ubuntu-cryptroot qui contiendra les données chiffrés. La taille doit être au moins légèrement plus grande (1 Mio pour sécurité) que le volume contenant '/' actuel: on doit y mettre les métadonnées LUKS et les données.
* Utiliser cryptsetup sur ubuntu-cryptroot pour chiffrer les données à l'intérieur. En gros “Initialiser la partition” de la page cryptsetup.
* Créer le périphérique déchiffré avec 'cryptsetup luksOpen' et une entrée dans crypttab pour la création automatique au démarrage. Disons que le périphérique créé s'appelle ubuntu-plainroot.

* Maintenant deux possibilités s'ouvrent:
1. Créer une système de fichiers sur ubuntu-plainroot et copier les données de l'ancien système de fichiers.
2. Utiliser notre fidèle dd pour copier tout depuis debian-uburoot vers ubuntu-plainroot. En suite un coup de resize2fs va conclure l'œuvre.

PS: Tu veux que Grub démarre de ton LVM? Donne-lui un peu d'espace au début du disque. La première partition commence normalement au secteur 63 (comme le dit 'fdisk -ul'), ce qui laisse juste 31 kio à Grub pour faire ce qu'il veut. Cela pourrait être suffisant, mais vaut mieux laisser un espace plus grand (un multiple de 8 * 63 par exemple, pour faire contents les disques avec bloques multiples de 4 kio).

Dernière modification par chopinhauer (Le 06/10/2010, à 14:20)

chopinhauer · Le 06/10/2010, à 14:40

pierguiard a écrit :

Le LVM m'a causé des souci sous toutes les distro ou je l'ai essayé y compris Seven, si tu as un disque qui lâche tu es dans la merde un raid5 est largement suffisant quand au chiffrage??? Tu crains l'espionnage industriel ?

Il avait dit quelque part qu'il utilisait le chiffrage pour les données disque des ses clients. Pour cette utilisation je comprends bien, pourvu qu'on oublie pas la clé de chiffrement.

T'as réussi à utiliser le LVM de Linux sur Seven? Normalement quand un disque lâche LVM ne pose pas de problèmes en plus: les métadonnées sont sur chaque volume physique et peut-être dans plusieurs copies. Et en tout cas on peut sauvegarder la configuration dans un endroit sur avec 'vgcfgbackup' ou récupérer le backup dans /etc/lvm/backup.

Dernière modification par chopinhauer (Le 06/10/2010, à 14:56)

Hoper · Le 06/10/2010, à 15:45

je ne veux pas enfoncer le clou, mais pour quoi choisir un solution chiffrée, je ne vois vraiment as a quoi cela peut te servir.

TOUT LE MONDE devrait chiffrer ses données. Enfin, non, pardon, je corrige... Tous les êtres humains capables de retenir ou de conserver leur clef dans un endroit sur devrait le faire. Ce qu'il y a dans ton pc ne concerne que toi. C'est ta vie privé. Maintenant je constate que cette notion de vie privée n'est pas partagé par tous. Qu'ils y a même des gens qui, au contraire, préfèrent étaler leur problèmes de coeur et toutes les autres anecdotes de leur vie banales sur des pages facebook et autre bêtises. C'est leur choix... Mais c'est un choix que beaucoup regretteront un jour ou l'autre.

Le LVM m'a causé des souci sous toutes les distro ou je l'ai essayé

LVM permet de sécuriser et de simplifier la gestion des volumétries importante. Évidement, si pour toi seul la simplicité compte, je suppose qu'un simple raid avec un seul système de fichier de plusieurs To est "ce qu'il y a de plus simple". C'est aussi, et de très loin, ce qui est le plus dangereux et le plus inexploitable en terme de sauvegarde etc. Et combien de temps prendra le fsck sur un fs de 4To ? LVM offre des fonctionnalités (pvmove, snapshot...) avancés permettant de réaliser des opérations à chaud ou quasiment (backups, déplacement de données...) plein de chose que tu ne pourra jamais faire avec un simple fs.

(Hoper, ne soit pas vexé, mais je vais essayer de rameuter du monde sur ce cas)

Au contraire, je laisse ma place bien volontiers
Pour les données de ta sœur... J'avoue que je comprend pas trop comme t'a fait ton coup la... Je veux dire, confondre deux répertoires, ca peut arriver à tout le monde, rien de drôle la dedans. Mais avoir copié des données importantes à un endroit que tu n'arrête pas de casser et de reconstruire !? La j'avoue j'ai plus de mal

Sinon, concernant ton problème... j'avoue que je suis un peu paumé la...
En gros, si tu pense que les données sont sur le raid, alors tu devrai isoler ce raid totalement. Autrement dit, vgexport, puis ré-import, en changeant le nom du vg pour être sur... bref, avoir un nouveau vg, avec uniquement ton raid dedans, et tenter de retrouver les lvs et donc les données dedans...
au pire du pire, si tu n'arrive pas à reconstituer des données lvm cohérentes, et puisque si je me souviens bien rien n'était crypté sur le raid (j'était malade hein... je dis peut etre des bêtises), alors tu connais bien mieux que moi tous les outils de récupérations qui fonctionnent sur du raw (photorec...) et qui feront de la lecture sur les blocs séquentielles à la recherche d'un fs voir d'un répertoire précis...

Cela dit, chopinhauer à l'air d'avoir bien tout compris (mieux que moi durant les deniers jours donc tu devrai aussi peut être suivre ces recommandations...

Dernière modification par Hoper (Le 06/10/2010, à 15:46)

rmy · Le 06/10/2010, à 16:47

Bonsoir à tous, merci pour ton attention chopinhauer. Je viens de rentrer du boulot, je fais un résumé le plus concis possible (ce soir) pour expliquer où j'en suis.

Toutefois, pour préciser un détail important, le sujet actuel n'est plus celui de départ. J'ai bien compris, avec les expérimentations précédentes et l'œil aiguisé d'Hoper sur ce point, que mon chiffrage initial avait été fait en amont du LVM et que donc, dans ma tentative de migration de LVM, j'avais oublié de créer un conteneur similaire au niveau du raid. Tout cela n'a plus d'importance maintenant, et j'ai tout mon temps pour trouver la solution adéquate au problème que je me posais au début de ce post.

L'objectif actuel est de tenter de récupérer les données de ma frangine, et uniquement celle-ci puisque tout le reste est de multiples fois sauvegardé, rsync-é, etc…

Pour répondre sur ce point à Hoper, oui, c'est une connerie de ma part. Et sans étaler mes problèmes de cœur et ma vie de famille ^^ c'est juste que mes parents sont passés en coup de vent me déposer plein de vieux matos info, dont le disque de ma frangine, et que mon père m'a demandé de lui faire une config sur le pouce. Du coup la solution la plus rapide pour moi a été de copier ces données là où j'avais de la place, sur la machine en cours de migration, puis immédiatement après de m'occuper de refaire un rsync quand j'avais fini ma mission d'install pour le paternel. Sauf que c'est lors du rsync que j'ai merdé, et j'ai eu un flash sous la douche, alors même que le disque sda était en train d'être écrasé par une restauratiuon d'image… tu imagines ma tête sous la douche…

Voilà, à tout à l'heure pour des détails plus techniques, après le classique 17h-20h30 familial où je n'ai guère le temps de tripoter l'ordi.

rmy · Le 06/10/2010, à 17:18

Pub en passant, pour un autre problème de raid5, d'un gars sympa qui m'a appelé au secours. Je crois plutôt que c'est un problème de FS ext4, mais si vous voulez bien donner votre avis sur la partie raid pour être sûr…

Dernière modification par rmy (Le 06/10/2010, à 17:19)

chopinhauer · Le 06/10/2010, à 18:22

Hoper a écrit :

TOUT LE MONDE devrait chiffrer ses données.

C'est une opinion comme les autres. Se faire cambrioler son appartement/bureau et se faire voler les disques durs n'est pas l'unique possibilité de fuite de données, mais c'est l'unique cas où le chiffrement est vraiment effectif.

Je n'ai jamais étudié à fond l'état légal du chiffrement en France, mais, si je me souviens bien, dans le cas d'une saisie judiciaire il faut donner accès aux contenus ou faire face à des poursuites.

Vu que rmy envoie des disques par Poste dans la France entière, son utilisation du chiffrement peut être justifié. Cependant ce n'est pas le cas pour tout le monde.

Hoper a écrit :

plein de chose que tu ne pourra jamais faire avec un simple fs.

À quelque exception près. :-)

rmy a écrit :

L'objectif actuel est de tenter de récupérer les données de ma frangine, et uniquement celle-ci puisque tout le reste est de multiples fois sauvegardé, rsync-é, etc…

Si dans ton mise à jour du soir tu peux nous pointer vers le message à partir du quel les données de ta frangine étaient sur ton disque…

Dernière modification par chopinhauer (Le 06/10/2010, à 18:23)

chopinhauer · Le 06/10/2010, à 19:35

rmy, j'essaie de comprendre où les données de ta sœur sont apparus.

rmy a écrit :

8/ Chaque fois que je reboote, je perds la config lvm sur sda et je suis obligé de faire un cfgrestore.

C'était la config sur sda2 ou cryptroot que tu remettais? Car vu qu'il s'agit du même périphérique sous deux formats, un casse l'autre.

Le message #77 montre que cryptroot est une périphérique vide que t'ajoute au LVM. Dans le message suivant tu parles d'un rsync. Il est depuis où vers où?

rmy · Le 07/10/2010, à 01:44

(désolé, je réapparais seulement, crève de cheval, mal de crâne toussa. Je pointe demain)

Hoper · Le 07/10/2010, à 09:38

C'est une opinion comme les autres. Se faire cambrioler son appartement/bureau et se faire voler les disques durs n'est pas l'unique possibilité de fuite de données, mais c'est l'unique cas où le chiffrement est vraiment effectif.

C'est faux. Dans une famille, chaque membre de celle ci n'a pas forcément envi qu'un autre puisse connaitre sa vie privée. C'est le principe même du journal intime. (sauf que désormais il est facile d'ajouter de la musique ou de la vidéo, et pas seulement du texte brut). Bref, la soeur n'a pas forcément envi que son frere (ou ses parents) puisse connaitre tout de sa vie. Un couple qui s'aime pourrait aussi avoir des secrets. Si ma femme me trompait un jour, je ne suis pas vraiment certain de vouloir le savoir. A elle de juger si elle ve me le dire ou pas. Bref, tes données, tu les chiffre, point.

À quelque exception près. :-)

Tu as oublié le légendaire advfs. Zfs n'en est qu'une très, très pale copie. Mais avoue que me citer des fs qui intègre justement une gestion de volume, et donc un LVM, c'est assez moyen pour me démontrer l'inutilité d'un gestionnaire de volume non ?

rmy · Le 07/10/2010, à 09:46

Bonjour, bonjour… je vais essayer de clarifier la situation, mais j'ai pas le cerveau très opérationnel…

Au début, l'idée était de migrer d'un lvm chiffré (conteneur luks /dev/mapper/cryptroot, vg "debian") vers une solution raid5 partitionné, dans l'idée de peut-être avoir à faire une partition /boot séparée plus tard (Erreur au niveau de la partition, mais on est plus à ça près). Lors de cette étape, comme tu l'as vu, j'ai zappé la construction d'un conteneur chiffré sur /dev/md0p1 avant le pvmove. Je m'étais douté que ça ne collait pas, mais j'ai poursuivi.

Ensuite, j'ai sorti /dev/cryptsetup du vg (vgreduce), mais laissé provisoirement le disque branché pour continuer d'utiliser le /boot (dev/sda1) afin de tester. Là, plantage, puisqu'effectivement, pas de luks sur le raid. Comme mes sauvegardes "récentes" étaient tout de même de plus de 20 jours, Hoper m'a indiqué la solution du vgcfgrestore, que j'ai pu appliquer avec succès en allant chercher mon fichier de conf lvm dans une image disque précédente.

Le vgcfgrestore était donc appliqué, depuis un live-usb, au niveau de /dev/mapper/cryptroot puisque précédé d'un luksOpen. Vu qu'au reboot les modifs des quelques heures précédentes étaient perdues, cela signifiait pour moi que le raid avait bien été utilisé comme PV suite au move des extends, et que j'étais à nouveau "sur" /dev/mapper/cryptroot. Pourtant pvscan semblait me dire le contraire.

J'ai cherché un petit moment comment récupérer les quelques données perdues pendant l'usage du raid comme pv unique, mais puisque finalement j'ai pu récupérer les données utiles (quelques mails) par un autre intermédiaire, je me suis décidé à reprendre tout à zéro "proprement" en tenant compte de toutes les expérimentations et erreurs rencontrées lors de cette première étape.

C'est là que se place l'épisode "frangine" : copie des données dans un dossier "Public", mais rsync du dossier "public".
À ce moment là, j'ai l'impression que je "tournais" tout de même encore sur le raid (cf pvdisplay), je pense donc que les données de la frangine ont été copiées "physiquement" sur celui-ci.

Ensuite pour "déconstruire", je rappatrie mes PE (vgextend, pvmove) et pendant cette étape, j'ai eu plusieurs signaux alarmants : firefox ne démarrait plus, thunderbird m'affichait un profil vierge alors que le profil du .thunderbird de mon home était toujours là (et la taille ne présentait pas d'équivoque sur son contenu) etc… et pour finir, une fois le pvmove achevé, impossible de redémarrer autrement qu'en passant par les magic keys : Alt+Syst+ [ S, U, I, B].

Au reboot, système grognon, restauration sur /dev/sda d'une image du 23/09, et perte au passage des données de la frangine.

Actuellement :
les deux PV sont dans le VG debian, puisque sur l'image du 23/09 cryptroot était encore dans le VG, et qu'avant le reboot je n'ai pas pu sortir le raid.

PV /dev/md0p1              VG debian   lvm2 [1,82 TiB / 1,82 TiB free]
  PV /dev/mapper/cryptroot   VG debian   lvm2 [595,93 GiB / 0    free]
  Total: 2 [2,40 TiB] / in use: 2 [2,40 TiB] / in no VG: 0 [0   ]

Par contre, comme sur le raid :

Total PE              476931
Free PE               476931

Je pense qu'actuellement j'utilise bien /dev/sda2 (/dev/mapper/cryptroot) et que je ne touche plus au raid. Juste ?

Enfin, pour répondre à tes questions :

Le rsync a été fait vers un dd externe, et depuis le /home alors en usage. Donc probablement "physiquement" depuis le raid, vers support externe. Sauf que pour une question de place, le dossier "Public" contenant de nombreuses images disques que je n'avais pas besoin de rsync-er, j'ai mis un --filter "- Public" sur le rsync.

sudo dmsetup ls --tree
debian-swap_1 (252:1)
 └─cryptroot (252:0)
    └─ (8:2)
debian-rootbuntu (252:2)
 └─cryptroot (252:0)
    └─ (8:2)
debian-homebuntu (252:3)
 └─cryptroot (252:0)
    └─ (8:2)

sudo lvs -a -o +devices
  LV        VG     Attr   LSize   Origin Snap%  Move Log Copy%  Convert Devices                    
  homebuntu debian -wi-ao 578,40g                                       /dev/mapper/cryptroot(4488)
  rootbuntu debian -wi-ao  15,00g                                       /dev/mapper/cryptroot(648) 
  swap_1    debian -wi-ao   2,53g                                       /dev/mapper/cryptroot(0)

sudo pvs -o +lv_name
  PV                    VG     Fmt  Attr PSize   PFree LV       
  /dev/mapper/cryptroot debian lvm2 a-   595,93g    0  swap_1   
  /dev/mapper/cryptroot debian lvm2 a-   595,93g    0  rootbuntu
  /dev/mapper/cryptroot debian lvm2 a-   595,93g    0  homebuntu
  /dev/md0p1            debian lvm2 a-     1,82t 1,82t

Voilà.

L'idée maintenant est de voir si il n'est pas possible de reconstruire le lvm qui était sur le raid avant mon dernier pvmove, et de trouver le moyen d'accéder au données qui s'y trouvent (ce que je n'avais pas su faire précédemment).

Dernière modification par rmy (Le 07/10/2010, à 09:52)

chopinhauer · Le 07/10/2010, à 17:15

La commande pvmove est censée être sécurisée. Ainsi elle crée un LVM miroir, elle copie les données et puis elle efface le LVM de départ (les métadonnées, pas les données).

Ainsi cryptroot et le RAID devaient contenir tous les deux un système ext4 identique.

Tu dis que t'as restauré un backup sur cryptroot, si c'était l'image de la partition et pas juste les fichiers, les inode des données de ta frangine risques d'être encore là. Marqués comme libres, bien sur, mais pas totalement détruits.

Sinon du côté RAID tout devrait être là. Si tu vas créer des volumes logiques sur le RAID (en spécifiant le PV via des paramètres additionnels à lvcreate) de la même taille que ceux qui y étaient, tu pourras monter les ext4 y contenus. pvmove (de ce que je vois sur mes disques) ne doit pas faire des gros efforts pour décider où allouer des PE. Le premier LVM migré aura les premiers PE, et ainsi de suite. L'allocation est linéaire. Vu que tu connais la quantité exacte de PE (ou LE) de tes volumes logiques cela ne doit pas être difficile de tomber sur les bons chiffres pour retrouver tes systèmes de fichiers.

La création et destruction de volumes logiques se fait juste à niveau des métadonnées, donc cela ne devrait avoir aucun danger.

PS: Je crois que tu n'as pas créé à nouveau ton ensemble RAID, juste assemblé. Dans le cas contraire tu pourrais avoir un problème d'ordre des disques dans le RAID. Si l'implémentation du RAID 5 est comme les dessins sur Wikipedia, alors certains bloquent du RAID serait juste XOR-é avec celui qui précède ou suit, mais on sait jamais.

Ce serait amusant d'écrire un pilote de disque virtuel sous Linux qui sait permuter l'ordre des disques d'un RAID. :-) Finalement un RAID mal assemblé c'est comme du One-Time-Pad (sauf que la clé est disponible).

PS: dmsetup, lvs et pvs sont bien plus pratiques pour voir quel LV est sur quel PV, n'est-ce pas? C'est juste dommage que dmsetup ne sache pas que 8:2 (major:minor) on l'appelle sda2. :-)

Dernière modification par chopinhauer (Le 07/10/2010, à 17:18)

rmy · Le 07/10/2010, à 18:56

En fait, je n'ai pas restauré un backup sur cryptroot, mais sur tout sda. DOnc exit les données de la frangine ici car vu la date du backup (23/09) il y a des chances que les inodes ait été de multiples fois modifiés entre temps.

Par contre, côté raid, je n'ai rien fait du tout depuis la copie des données de la frangine, hormis le pvmove. Est-ce qu'il n'est pas possible d'utiliser directement vgcfgrestore pour recréer la config lvm sur celui-ci ?

chopinhauer · Le 07/10/2010, à 19:07

rmy a écrit :

Par contre, côté raid, je n'ai rien fait du tout depuis la copie des données de la frangine, hormis le pvmove. Est-ce qu'il n'est pas possible d'utiliser directement vgcfgrestore pour recréer la config lvm sur celui-ci ?

Probablement oui. Personnellement je donnerais un coup d'œil à ce backup avant de l'écrire sur disque. Il est dans /etc/lvm/backup et facilement lisible. Au pire il faut faire un:

sudo pvs -o +pv_uuid

pour voir si les UUID n'ont pas changé dans les manipulations que t'as fait.

rmy · Le 07/10/2010, à 19:48

sudo cat /etc/lvm/backup/debian
# Generated by LVM2 version 2.02.54(1) (2009-10-26): Tue Oct  5 21:55:35 2010

contents = "Text Format Volume Group"
version = 1

description = "Created *after* executing 'vgscan'"

creation_host = "rmyprod"    # Linux rmyprod 2.6.32-25-generic #44-Ubuntu SMP Fri Sep 17 20:26:08 UTC 2010 i686
creation_time = 1286308535    # Tue Oct  5 21:55:35 2010

debian {
    id = "CryiJf-tvAL-2yZK-rj1I-R5Im-HrTM-OwCgUe"
    seqno = 31
    status = ["RESIZEABLE", "READ", "WRITE"]
    flags = []
    extent_size = 8192        # 4 Megabytes
    max_lv = 0
    max_pv = 0

    physical_volumes {

        pv0 {
            id = "NT2mUJ-71Zq-iH2V-wX21-3CkG-lvLN-6gvmQg"
            device = "/dev/md0p1"    # Hint only

            status = ["ALLOCATABLE"]
            flags = []
            dev_size = 3907024002    # 1.81935 Terabytes
            pe_start = 577
            pe_count = 476931    # 1.81935 Terabytes
        }

        pv1 {
            id = "TJdpFD-iTRr-jQxg-jqqk-5gPU-tHwL-T28IUV"
            device = "/dev/mapper/cryptroot"    # Hint only

            status = ["ALLOCATABLE"]
            flags = []
            dev_size = 1249758554    # 595.931 Gigabytes
            pe_start = 384
            pe_count = 152558    # 595.93 Gigabytes
        }
    }

    logical_volumes {

        swap_1 {
            id = "LxEGT1-fmgR-XGGX-byOt-j2p6-bXrs-SasLSs"
            status = ["READ", "WRITE", "VISIBLE"]
            flags = []
            segment_count = 1

            segment1 {
                start_extent = 0
                extent_count = 648    # 2.53125 Gigabytes

                type = "striped"
                stripe_count = 1    # linear

                stripes = [
                    "pv1", 0
                ]
            }
        }

        rootbuntu {
            id = "qjJsVW-8iWp-CT0H-YqoS-hsl1-yFTL-MlzMub"
            status = ["READ", "WRITE", "VISIBLE"]
            flags = []
            segment_count = 1

            segment1 {
                start_extent = 0
                extent_count = 3840    # 15 Gigabytes

                type = "striped"
                stripe_count = 1    # linear

                stripes = [
                    "pv1", 648
                ]
            }
        }

        homebuntu {
            id = "fo3HBW-BL0n-ctuO-Rgg7-U03h-Vorb-bjq8cP"
            status = ["READ", "WRITE", "VISIBLE"]
            flags = []
            segment_count = 1

            segment1 {
                start_extent = 0
                extent_count = 148070    # 578.398 Gigabytes

                type = "striped"
                stripe_count = 1    # linear

                stripes = [
                    "pv1", 4488
                ]
            }
        }
    }
}

sudo pvs -o +pv_uuid
  PV                    VG     Fmt  Attr PSize   PFree PV UUID                               
  /dev/mapper/cryptroot debian lvm2 a-   595,93g    0  TJdpFD-iTRr-jQxg-jqqk-5gPU-tHwL-T28IUV
  /dev/md0p1            debian lvm2 a-     1,82t 1,82t NT2mUJ-71Zq-iH2V-wX21-3CkG-lvLN-6gvmQg

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#76 Le 04/10/2010, à 09:00

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#77 Le 04/10/2010, à 16:27

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#78 Le 04/10/2010, à 19:55

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#79 Le 04/10/2010, à 21:07

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#80 Le 05/10/2010, à 08:09

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#81 Le 05/10/2010, à 22:54

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#82 Le 05/10/2010, à 23:07

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#83 Le 05/10/2010, à 23:35

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#84 Le 06/10/2010, à 00:00

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#85 Le 06/10/2010, à 03:03

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#86 Le 06/10/2010, à 08:46

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#87 Le 06/10/2010, à 14:12

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#88 Le 06/10/2010, à 14:40

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#89 Le 06/10/2010, à 15:45

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#90 Le 06/10/2010, à 16:47

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#91 Le 06/10/2010, à 17:18

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#92 Le 06/10/2010, à 18:22

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#93 Le 06/10/2010, à 19:35

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#94 Le 07/10/2010, à 01:44

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#95 Le 07/10/2010, à 09:38

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#96 Le 07/10/2010, à 09:46

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#97 Le 07/10/2010, à 17:15

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#98 Le 07/10/2010, à 18:56

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#99 Le 07/10/2010, à 19:07

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#100 Le 07/10/2010, à 19:48

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

Pied de page des forums