Proxmox: Recuperar un volumen lógico borrado

Hola sobrinos, ¿cómo han estado?.   Hoy veremos cómo recuperar un volumen lógico borrado «por accidente» en un servidor linux. Ayer estuve depurando mis VMs (VM = virtual machine) en Proxmox VE, y en un arranque de furia eliminé una docena que quedaron abandonados de laboratorios previos, y que ya no necesitaba.  Entonces sucede lo inesperado: Había eliminado una VM que tenía un segundo disco con información MUY IMPORTANTE y que tenía que recuperar de vida o muerte.  Al mejor tirador se le escapa la bala, ¿no?. En versiones previas a la 4.2 de Proxmox Virtual Environment, los discos virtuales se almacenaban en /var/lib/vz como archivos individuales. A partir de la versión 4.2 tenemos que los discos virtuales se crean en volúmenes lógicos LVM2-thin. En la interfaz principal de Proxmox se visualiza la versión existente en el servidor (también lo podemos ver en línea de comandos):
Versión de Proxmox VE

root@pve1:/# pveversion
pve-manager/4.4-1/eb2d6f1e (running kernel: 4.4.35-1-pve)

Todo proceso de recuperación de datos tiene mayor probabilidad de recuperación mientras no se grabe más información que pueda sobreescribir las ubicaciones donde residen los archivos eliminados.  Por ello nos ponemos manos a la obra ¡Ya mismo!

Con el PuTTY accedemos al servidor Proxmox.  Se trata de un linux Debian.

Revisamos los grupos de volúmenes existentes:

root@pve1:/# vgdisplay
— Volume group —
VG Name  pve
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 91
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 15
Open LV 4
Max PV 0
Cur PV 1
Act PV 1
VG Size 1.36 TiB
PE Size 4.00 MiB
Total PE 357635
Alloc PE / Size 353580 / 1.35 TiB
Free PE / Size 4055 / 15.84 GiB
VG UUID bdW1Qo-XJxc-t9Xv-Y0af-5sWi-1pGc-O4HdEm

— Volume group —
VG Name SEA3000
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 31
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 10
Open LV 1
Max PV 0
Cur PV 1
Act PV 1
VG Size 2.73 TiB
PE Size 4.00 MiB
Total PE 715396
Alloc PE / Size 660736 / 2.52 TiB
Free PE / Size 54660 / 213.52 GiB
VG UUID TSilsx-jRqE-BbAx-XZDy-afil-rO6W-yhTtJQ

LVM mantiene una copia de seguridad de los metadatos de todos los grupos y volúmenes, con la cual se puede restaurar la configuración original de los volúmenes físicos, de los grupos de volúmenes y de todos los volúmenes lógicos que están dentro de los grupos.

La copia de seguridad más reciente se mantiene en /etc/lvm/backup/, y también se guardan versiones anteriores en /etc/lvm/archive/.  Esto último nos va a servir para recuperar los volúmenes lógicos eliminados accidentalmente.

Visualizamos el contenido de /etc/lvm/archive:

root@pve1:~# ls -l /etc/lvm/archive
total 132
-rw——- 1 root root 9911 Mar 11 13:31 pve_00033-1747798418.vg
-rw——- 1 root root 9536 Mar 11 13:31 pve_00034-257484504.vg
-rw——- 1 root root 9055 Mar 11 13:31 pve_00035-538070396.vg
-rw——- 1 root root 8657 Mar 11 13:32 pve_00036-1452581341.vg
-rw——- 1 root root 8259 Mar 11 13:32 pve_00037-1536873532.vg
-rw——- 1 root root 7863 Mar 11 13:33 pve_00038-1841909368.vg
-rw——- 1 root root 7505 Mar 11 20:02 pve_00039-556635870.vg
-rw——- 1 root root 7865 Mar 11 22:44 pve_00040-954351548.vg
-rw——- 1 root root 7505 Mar 11 22:54 pve_00041-1980330641.vg
-rw——- 1 root root 7904 Mar 11 22:58 pve_00042-676779848.vg
-rw——- 1 root root 6095 Jan 3 2017 SEA3000_00000-906206633.vg
-rw——- 1 root root 6111 Mar 11 13:33 SEA3000_00001-1320802895.vg
-rw——- 1 root root 5675 Mar 11 19:33 SEA3000_00002-1832784757.vg
-rw——- 1 root root 5240 Mar 11 19:33 SEA3000_00003-1317767394.vg

root@pve1:~#

Se observan los registros antiguos para los grupos «pve» y «SEA3000».    El máquina virtual que fue eliminada es VM-106 y el disco virtual que se requiere recuperar es «SEA3000/vm-106-disk-1», entonces buscaremos alguna referencia a él en el contenido de las copias de seguridad.  

Usaremos el comando «vgcfgrestore» para listar el detalle de los archivos relacionados al grupo de volúmenes SEA3000:

root@pve1:~# vgcfgrestore –list SEA3000

File: /etc/lvm/archive/SEA3000_00000-906206633.vg
VG name: SEA3000
Description: Created *before* executing ‘vgchange -aay –sysinit’
Backup Time: Tue Jan 3 20:09:34 2017

File: /etc/lvm/archive/SEA3000_00001-1320802895.vg
VG name: SEA3000
Description: Created *before* executing ‘/sbin/lvremove -f SEA3000/vm-101-disk-1’
Backup Time: Sun Mar 11 13:33:23 2018

File: /etc/lvm/archive/SEA3000_00002-1832784757.vg
VG name: SEA3000
Description: Created *before* executing ‘/sbin/lvremove -f SEA3000/vm-106-disk-2’
Backup Time: Sun Mar 11 19:33:12 2018

File: /etc/lvm/archive/SEA3000_00003-1317767394.vg
VG name: SEA3000
Description: Created *before* executing ‘/sbin/lvremove -f SEA3000/vm-106-disk-1’
Backup Time: Sun Mar 11 19:33:13 2018

Como pueden ver, se visualizan dos discos para la VM 106 (disk-2 y disk-1), por tanto el archivo de respaldo que nos interesa se encuentra al final del listado y es «/etc/lvm/archive/SEA3000_00003-1317767394.vg» que fue creado justo antes de eliminar el volumen lógico con el comando «lvremove» (ejecutado internamente por el Proxmox).  De manera conveniente nos indica: «Creado *antes* de ejecutar /sbn/lvremove -f SEA3000/vm-106-disk-1«.  He ahí nuestro disco virtual perdido. También se pueden visualizar las cabeceras de los archivos con el comando «head»:

root@pve1:~# head /etc/lvm/archive/SEA3000_00003-1317767394.vg
# Generated by LVM2 version 2.02.116(2) (2015-01-30): Sun Mar 11 19:33:13 2018

contents = «Text Format Volume Group»
version = 1

description = «Created *before* executing ‘/sbin/lvremove -f SEA3000/vm-106-disk-1′»

creation_host = «pve1» # Linux pve1 4.4.35-1-pve #1 SMP Fri Dec 9 11:09:55 CET 2016 x86_64
creation_time = 1520814793 # Sun Mar 11 19:33:13 2018

Verificamos que la hora de creación de la copia de seguridad de los metadatos es similar al momento en que eliminamos la máquina virtual (y con la VM se fueron al limbo nuestros discos virtuales).

Ya estamos listos para recuperar el volumen perdido; vamos a restaurar la configuración previa del grupo SEA3000 que lo contenía.  Ejecutamos «vgcfgrestore» con el parámetro «–test» para comprobar el estado de la recuperación.  Este procedimiento deshabilita la escritura de metadatos y nos sirve como ensayo previo necesario.  Si existen situaciones inesperadas nos emitirá un mensaje de error.

root@pve1:~# vgcfgrestore SEA3000 –test -f /etc/lvm/archive/SEA3000_00003-1317767394.vg
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Restored volume group SEA3000

Como no obtuvimos mensajes de error, tenemos la confianza que la recuperación será satisfactoria.  Volvemos a ejecutar «vgcfgrestore» pero ahora sin el parámetro «–test» para que se realice la recuperación, esta vez con la escritura de metadatos:

root@pve1:~# vgcfgrestore SEA3000 -f /etc/lvm/archive/SEA3000_00003-1317767394.vg
Restored volume group SEA3000

Ahora comprobamos que el volumen fue recuperado:

root@pve1:~# lvscan
ACTIVE ‘/dev/pve/swap’ [7.00 GiB] inherit
ACTIVE ‘/dev/pve/root’ [96.00 GiB] inherit
ACTIVE ‘/dev/pve/data’ [1.25 TiB] inherit
ACTIVE ‘/dev/pve/vm-150-disk-1’ [80.00 GiB] inherit
ACTIVE ‘/dev/pve/vm-120-disk-1’ [120.00 GiB] inherit
ACTIVE ‘/dev/pve/vm-136-disk-1’ [500.00 GiB] inherit
ACTIVE ‘/dev/pve/vm-137-disk-1’ [80.00 GiB] inherit
ACTIVE ‘/dev/pve/vm-138-disk-1’ [40.00 GiB] inherit
ACTIVE ‘/dev/pve/vm-208-disk-1’ [80.00 GiB] inherit
ACTIVE ‘/dev/pve/vm-216-disk-1’ [80.00 GiB] inherit
inactive ‘/dev/pve/snap_vm-216-disk-1_antes_de_promover’ [80.00 GiB] inherit
inactive ‘/dev/pve/snap_vm-208-disk-1_antes_de_promover’ [80.00 GiB] inherit
ACTIVE ‘/dev/pve/vm-160-disk-1’ [120.00 GiB] inherit
ACTIVE ‘/dev/pve/vm-101-disk-1’ [80.00 GiB] inherit
ACTIVE ‘/dev/pve/vm-125-disk-1’ [120.00 GiB] inherit
ACTIVE ‘/dev/SEA3000/vm-107-disk-1’ [80.00 GiB] inherit
ACTIVE ‘/dev/SEA3000/vm-109-disk-1’ [80.00 GiB] inherit
ACTIVE ‘/dev/SEA3000/vm-108-disk-1’ [80.00 GiB] inherit
ACTIVE ‘/dev/SEA3000/vm-110-disk-1’ [80.00 GiB] inherit
inactive ‘/dev/SEA3000/vm-106-disk-1’ [1.95 TiB] inherit
ACTIVE ‘/dev/SEA3000/vm-111-disk-1’ [20.00 GiB] inherit
inactive ‘/dev/SEA3000/vm-103-disk-1’ [80.00 GiB] inherit
ACTIVE ‘/dev/SEA3000/vm-100-disk-1’ [1.00 GiB] inherit
ACTIVE ‘/dev/SEA3000/vm-113-disk-1’ [80.00 GiB] inherit
ACTIVE ‘/dev/SEA3000/vm-112-disk-1’ [80.00 GiB] inherit

Ya aparece el volumen lógico correspondiente al disco virtual recuperado, aunque figura como INACTIVO.  Procedemos a activarlo:

root@pve1:~# lvchange -a y /dev/SEA3000/vm-106-disk-1
root@pve1:~#

¡Y listo!.  Así fue cómo 2 terabytes de información volvieron a la vida luego de aplicar el procedimiento para recuperar un volumen lógico borrado.   En mi caso agregué el disco recuperado como secundario en otra máquina virtual ya existente (modificando manualmente el archivo de configuración en /etc/pve/nodes/pve1/qemu-server/).  Y para evitar una nueva confusión lo he renombrado con la referencia de la misma VM que ahora lo tiene conectado (usando el comando «lvrename»).   Eso fue todo, amigos!.

PD:  Las operaciones indicadas se realizaron directamente con el usuario root por tratarse de un entorno privado para laboratorio de práctica.  Por cuestiones de seguridad, en entornos de producción es importante utilizar un usuario restringido que realice las tareas administrativas con privilegios de superusuario a través del comando «sudo».

Redactado por Tezé, 11/marzo/2018

Deja un comentario