Acceder a particiones de discos con LVM que están en archivos de imágenes en formato qcow de qemu

Ya el título del artículo se las trae, pero es así, es lo que tuve que hacer la semana pasada en el trabajo debido a un descuido y una configuración errónea en el backup.

En el trabajo, para hacer los backups de las máquinas virtuales que tenemos, no respaldamos todos los directorios de las máquinas al completo, sino que tenemos una serie de savesets (/etc/, /root/, /usr/local/, /opt, /var, /home) que son los que copiamos todos los días utilizando rsync. Durante una intervención en una de esas máquinas virtuales, eliminamos el contenido de un directorio del que no teníamos copia de seguridad y no nos dimos cuenta de ello hasta que fue demasiado tarde.

Aunque empezamos a mirar diferentes formas de recuperar el contenido, advertimos de que estas máquinas, al ser MV de un hipervisor con KVM, vimos que el directorio /var/ del hipervisor estaba respaldado por el rsync. Y dentro de /var esta /var/lib/libvirt que tiene la configuración de las máquinas virtuales y de los discos que utilizan las maquinas virtuales (Yuju!!). Así que era posible recuperar el contenido, al disponer de una copia de seguridad de la máquina al completo de la noche anterior. Sólo teníamos que montar los discos de la copia de seguridad.

Como primer intento, pensamos en copiar los discos al hipervisor y levantar una nueva máquina virtual, pero el hipervisor se encontraba en otra sede, por lo que llevar un disco de 12 GB iba a tardar cerca de cuatro horas. Otra solución, era montar los discos, localizar los dispositivos y acceder a las particiones, sin necesidad de levantar una máquina virtual, trabajando desde un equipo que tuviera acceso a las ficheros de imágenes de los discos que estaban en la copia de seguridad. Mucho más rápido.

El primer problema era acceder al formato qcow que tienen los discos de qemu. Con ellos directamente no podíamos trabajar, por lo que había que convertirlos a formato raw. Esto se puede lograr con el comando qemu-img y la opción convert. Si le añadimos la opción -p obtenemos el progreso de la conversión entre qcow y raw.

$ qemu-img convert -p servidor015.qcow servidor015.raw

El comando anterior, nos genera un nuevo archivo llamado servidor015.raw con el que podremos trabajar a partir de ahora. El siguiente paso ha sido ver que es lo que hay en la imagen raw (discos, particiones, formatos, etc). Realmente, no hace nada, solo nos va a mostrar lo que tenemos dentro del fichero raw.

$ disktype servidor015.raw
--- servidor015.raw
Regular file, size 12 GiB (12884901888 bytes)
GRUB boot loader, compat version 3.2, boot drive 0x80
DOS/MBR partition map
Partition 1: 500 MiB (524288000 bytes, 1024000 sectors from 2048, bootable)
  Type 0x83 (Linux)
  Ext3 file system
    UUID 205F140C-E079-4970-9D62-7EFA29DB423B (DCE, v4)
    Last mounted at "/boot"
    Volume size 500 MiB (524288000 bytes, 512000 blocks of 1 KiB)
Partition 2: 11.51 GiB (12359565312 bytes, 24139776 sectors from 1026048)
  Type 0x8E (Linux LVM)
  Linux LVM2 volume, version 001
    LABELONE label at sector 1
    PV UUID k9Aj9f-v3Uh-iNlg-K6s4-HAAS-1JO9-3Dnr77
    Volume size 11.51 GiB (12359565312 bytes)
    Meta-data version 1

El siguiente paso es utilizar losetup. Con este comando podemos montar la imagen como un device en el sistema.

$ losetup /dev/loop0 servidor015.raw

El device es /dev/loop0, y los siguientes pasos se van encargar de utilizar el dispositivo /dev/loop0 y seguir con el trabajo. No olvidemos que queremos acceder a la partición que tiene los datos de un servidor virtual del que tenemos una imagen en formato qcow de sus discos.

Antes de seguir, hay que echar un vistazo al dispositivo, dependiendo de lo que encontremos haremos una cosa u otra. En este paso, podemos utilizar fdisk, que nos tiene que aportar una información similar a la que obtuvimos con disktype. La diferencia es que fdisk se utiliza sobre un dispositivo (/dev/loop0) en lugar de emplearla sobre un archivo como hicimos con disktype. Si utilizamos fdisk sobre el fichero, hubiera dado un mensaje de error.

$ fdisk /dev/loop0
Welcome to fdisk (util-linux 2.23.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Orden (m para obtener ayuda): p
Disk /dev/loop0: 12.9 GB, 12884901888 bytes, 25165824 sectors
Units =3D sectors of 1 * 512 =3D 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Identificador del disco: 0x0000320b
   Disposit. Inicio    Comienzo      Fin      Bloques  Id  Sistema
/dev/loop0p1   *        2048     1026047      512000   83  Linux
/dev/loop0p2         1026048    25165823    12069888   8e  Linux LVM
Orden (m para obtener ayuda): quit

Llegados a este paso del trabajo, vemos que no tenemos directamente dispositivos /dev/sdaX o /dev/sdbX, sino que nos han aparecido dispositivos de LVM, lo que nos complica un poco la vida, al tener que montar antes el LVM.

Lo primero aquí es leer los dispositivos que aparecen en /dev/loop0 y agregarlos al sistema.

$ kpartx -a /dev/loop0

Luego creamos unos directorios de trabajo que necesitaremos posteriormente y hacemos un scan de los grupos de volúmenes de lvm.

$ mkdir /mnt/p1
$ mkdir /mnt/p2
$ vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "VolGroup" using metadata type lvm2

Con esto, ya tenemos un grupo de volúmenes llamado VolGroup, que no esta activo. Para poder utilizarlo, hay que activarlo primero.

$ vgchange -ay VolGroup
  2 logical volume(s) in volume group "VolGroup" now active
$ vgdisplay
  --- Volume group ---
  VG Name               VolGroup
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  3
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               11,51 GiB
  PE Size               4,00 MiB
  Total PE              2946
  Alloc PE / Size       2946 / 11,51 GiB
  Free  PE / Size       0 / 0
  VG UUID               XR6jkV-pokl-kI2y-d1MY-jjTm-5O1T-BUeD4k

Podemos comprobar los dispositivos que se han creado mirando en /dev/VolGroup/ y /dev/mapper

$ ls /dev/VolGroup/
lv_root  lv_swap
$ ls /dev/mapper/
control           loop0p1           loop0p2           VolGroup-lv_root VolGroup-lv_swap

El último paso a dar será montar las particiones. Como los datos están en el lv_root, nos centramos en él y lo montamos para ver si hemos tenido suerte.

$ mount /dev/mapper/VolGroup-lv_root /mnt/p2
$ ls /mnt/p2/
usr var root home etc lib datos imagenes lost+found

Todo esto, no se me ocurrió de golpe -no soy tan listo-, pero sabía que era posible hacerlo y gracias a las recetas de Antonio Mario (montar imagen qcow) y David Robinson (montar lvm) pude combinarlo y lograrlo.

http://antonio-mario.com/montar-imagen-qcow-para-explorar-su-contenido/

http://www.redhat.com/archives/linux-lvm/2008-June/msg00045.html

Prevía a toda esta película, agregamos los directorios 'extras' que faltaban en la configuración del backup de la máquina.