 |
LVM: Monter un Logical Volume issu d’une restauration |
Alors aujourd’hui, nous allons voir comment monter un Logical Volume issu d’une restauration de données.
En somme, nous avons une VM que nous avons restauré, et nous avons besoin de monter sur la VM d’origine, le VMDK restauré.
Sauf que, notre VMDK contient un volume LVM, avec le même UUID. Et pour couronner le tout, la partition est en XFS avec elle aussi un problème d’UUID dupliqué…
Les préparatifs
Alors nous allons partir du principe que le VMDK (ou le VHDX, bien sûr) a été restauré et qu’il est monté sur le système. Nous avons donc :
/dev/sda1 : Boot /dev/sda2, /dev/sda3, /dev/sda4 : partitions LVM /dev/sdb1 : Boot (restauré) /dev/sdb2, /dev/sdb3, /dev/sdb4 : partitions LVM (restaurées)
Tentative de montage
Alors, on lance un petit pvscan pour se faire peur :
[root@guylux ~]# pvscan WARNING: PV lz0vGQ-2G8O-qJF2-0y4v-oTN1-3zZu-n3iGKb on /dev/sdb2 was already found on /dev/sda2. WARNING: Disabling lvmetad cache which does not support duplicate PVs. WARNING: PV iKZKNN-AQ50-4vqk-kZVo-Zyu7-CArv-lJu67t on /dev/sdb3 was already found on /dev/sda3. WARNING: PV cOQN0n-A12t-6NrC-8l3p-gIvt-rSLC-LspbSl on /dev/sdb4 was already found on /dev/sda4. WARNING: Not using lvmetad because duplicate PVs were found. WARNING: PV lz0vGQ-2G8O-qJF2-0y4v-oTN1-3zZu-n3iGKb on /dev/sdb2 was already found on /dev/sda2. WARNING: PV iKZKNN-AQ50-4vqk-kZVo-Zyu7-CArv-lJu67t on /dev/sdb3 was already found on /dev/sda3. WARNING: PV cOQN0n-A12t-6NrC-8l3p-gIvt-rSLC-LspbSl on /dev/sdb4 was already found on /dev/sda4. WARNING: PV lz0vGQ-2G8O-qJF2-0y4v-oTN1-3zZu-n3iGKb prefers device /dev/sda2 because device is used by LV. WARNING: PV iKZKNN-AQ50-4vqk-kZVo-Zyu7-CArv-lJu67t prefers device /dev/sda3 because device is used by LV. WARNING: PV cOQN0n-A12t-6NrC-8l3p-gIvt-rSLC-LspbSl prefers device /dev/sda4 because device is used by LV. PV /dev/sda2 VG centos lvm2 [<49,00 GiB / 0 free] PV /dev/sda3 VG centos lvm2 [<10,00 GiB / 0 free] PV /dev/sda4 VG centos lvm2 [<40,00 GiB / 0 free] Total: 3 [<98,99 GiB] / in use: 3 [<98,99 GiB] / in no VG: 0 [0 ]
Jusqu’ici, rien d’illogique, puisque nos UUID sont dupliqués !
Changement des UUID
Nous allons donc modifier les UUID pour pouvoir aller plus loin. Mais avant de commencer, nous allons importer les VolumeGroups clonés :
[root@guylux ~]# vgimportclone -n centos /dev/sdb2 /dev/sdb3 /dev/sdb4 WARNING: PV lz0vGQ-2G8O-qJF2-0y4v-oTN1-3zZu-n3iGKb on /dev/sdb2 was already found on /dev/sda2. WARNING: PV iKZKNN-AQ50-4vqk-kZVo-Zyu7-CArv-lJu67t on /dev/sdb3 was already found on /dev/sda3. WARNING: PV cOQN0n-A12t-6NrC-8l3p-gIvt-rSLC-LspbSl on /dev/sdb4 was already found on /dev/sda4. WARNING: PV lz0vGQ-2G8O-qJF2-0y4v-oTN1-3zZu-n3iGKb prefers device /dev/sda2 because device is used by LV. WARNING: PV iKZKNN-AQ50-4vqk-kZVo-Zyu7-CArv-lJu67t prefers device /dev/sda3 because device is used by LV. WARNING: PV cOQN0n-A12t-6NrC-8l3p-gIvt-rSLC-LspbSl prefers device /dev/sda4 because device is used by LV.
Et on obtient ceci si on relance un vgdisplay :
[root@guylux ~]# vgdisplay --- Volume group --- VG Name centos System ID Format lvm2 Metadata Areas 3 Metadata Sequence No 7 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 3 Act PV 3 VG Size <98,99 GiB PE Size 4,00 MiB Total PE 25341 Alloc PE / Size 25341 / <98,99 GiB Free PE / Size 0 / 0 VG UUID 8BTTPw-iuCi-uBEg-zNUt-cCaf-hd1A-MHxoBw --- Volume group --- VG Name centos1 System ID Format lvm2 Metadata Areas 3 Metadata Sequence No 8 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 0 Max PV 0 Cur PV 3 Act PV 3 VG Size <98,99 GiB PE Size 4,00 MiB Total PE 25341 Alloc PE / Size 25341 / <98,99 GiB Free PE / Size 0 / 0 VG UUID R7l6aU-EK42-md7F-Jpgp-VMTo-1S8F-CmcHOK
vgimportclone a accepté l’import et a renommé notre VolumeGroup “centos1”.
Et maintenant, on modifie l’UUID des Physical Volumes :
[root@guylux /]# pvchange -u /dev/sdb2 /dev/sdb3 /dev/sdb4
Par contre, si on fait un lvdisplay, on voit que les UUID sont toujours dupliqués :
[root@guylux /]# lvdisplay --- Logical volume --- LV Path /dev/centos/root LV Name root VG Name centos LV UUID kt0z7y-2PeP-Nfu0-XgFt-tKPp-g3eL-ylqvbi LV Write Access read/write LV Creation host, time localhost, 2018-06-04 13:54:10 +0200 LV Status available # open 1 LV Size 95,11 GiB Current LE 24349 Segments 3 Allocation inherit Read ahead sectors auto - currently set to 8192 Block device 253:0 --- Logical volume --- LV Path /dev/centos1/root LV Name root VG Name centos1 LV UUID kt0z7y-2PeP-Nfu0-XgFt-tKPp-g3eL-ylqvbi LV Write Access read/write LV Creation host, time localhost, 2018-06-04 13:54:10 +0200 LV Status NOT available LV Size 95,11 GiB Current LE 24349 Segments 3 Allocation inherit Read ahead sectors auto
Logique, du coup on s’occupe des UUID des Volume Groups et des Logical Volumes et on renomme au passage le Volume Group (l’opération vgrename change l’UUID à la volée) :
[root@guylux /]# vgchange -u centos1 [root@guylux /]# vgrename centos1 centosrestored
Maintenant, on monte le volume
Maintenant que les UUID sont changés, on va pouvoir activer le volume et le monter :
[root@guylux /]# lvchange -a y centosrestored
[root@guylux /]# mount /dev/centosrestored/root /restore/
mount: mauvais type de système de fichiers, option erronée, superbloc erroné
sur /dev/mapper/centosrestored-root, page de code ou programme auxiliaire manquant, ou autre erreur
Dans certains cas des renseignements utiles sont dans le journal
système — essayez « dmesg | tail » ou quelque chose du genre.
Ce n’est pas drôle sinon ! Du coup, on lance un tail pour voir ce que ça raconte :
[root@guylux /]# dmesg|tail [1956470.059675] scsi 0:0:1:0: Direct-Access VMware Virtual disk 2.0 PQ: 0 ANSI: 6 [1956470.059936] sd 0:0:1:0: Attached scsi generic sg2 type 0 [1956470.060034] sd 0:0:1:0: [sdb] 209715200 512-byte logical blocks: (107 GB/100 GiB) [1956470.060096] sd 0:0:1:0: [sdb] Write Protect is off [1956470.060099] sd 0:0:1:0: [sdb] Mode Sense: 61 00 00 00 [1956470.060115] sd 0:0:1:0: [sdb] Cache data unavailable [1956470.060118] sd 0:0:1:0: [sdb] Assuming drive cache: write through [1956470.061414] sdb: sdb1 sdb2 sdb3 sdb4 [1956470.062094] sd 0:0:1:0: [sdb] Attached SCSI disk [1957062.834599] XFS (dm-3): Filesystem has duplicate UUID e1cc7eeb-f5ec-4919-b7c7-b0dce08b6a47 - can't mount
Et oui! Notre système de fichiers XFS a lui aussi un UUID qu’il faut mettre à jour ! Alors, allons-y !
[root@guylux /]# xfs_admin -U generate /dev/centosrestored/root Clearing log and setting UUID writing all SBs new UUID = 999979b1-1f19-4387-b404-cf4d237e7cf3
Et maintenant, on monte le volume :
[root@guylux /]# mount /dev/centosrestored/root /restore/
En résumé
On reprend le modus operandi :
- vgimportclone -n centos /dev/sdb2 /dev/sdb3 /dev/sdb4
- pvchange -u /dev/sdb2 /dev/sdb3 /dev/sdb4
- vgchange -u centos1
- vgrename centos1 centosrestored
- lvchange -a y centosrestored
- xfs_admin -U generate /dev/centosrestored/root
- mount /dev/centosrestored/root /restore/
Et voilà !
En bonus
Si le volume XFS est un peu fatigué (à cause d’une sauvegarde pour trop clean) :
[root@guylux /]# xfs_repair -L /dev/centosrestored/root
Le ‘-L’ va indiquer à xfs_repair de supprimer les logs de transaction (perte de données à prévoir, mais aux grands maux, les grands remèdes!).