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
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