Recuperación bare metal de un servidor Ubuntu 24.04 con tar

La recuperación bare metal consiste en reconstruir un servidor completo, con su tabla de particiones, sistemas de archivos, cargador de arranque y datos, sobre un disco vacío. Es lo que necesitas cuando falla un disco, cuando un error borra el sistema o cuando quieres clonar un servidor en otra máquina. En este tutorial documentarás la estructura de un servidor Ubuntu 24.04, harás una copia completa a nivel de archivos con tar y la restaurarás desde un sistema live, reinstalando GRUB para que el servidor vuelva a arrancar.

Requisitos previos

Para seguir esta guía necesitas:

El servidor que quieres proteger, con Ubuntu 24.04 LTS y un usuario no root con privilegios sudo.
Un servidor de backups accesible por SSH con espacio para una copia completa (en los ejemplos, backup_user@your_backup_server con el directorio /srv/backups). Configura el acceso por clave SSH desde el servidor de origen.
Para ensayar la restauración: una máquina o VPS de destino con un disco de tamaño igual o mayor que el original, que puedas arrancar desde una ISO de Ubuntu 24.04 o un sistema de rescate. Un VPS de CubePath de prueba sirve para esto.

Importante

los datos de bases de datos en ejecución no se copian de forma consistente con tar. Haz antes un volcado (mysqldump, pg_dump) y deja que tar copie el archivo resultante, o detén el servicio durante la copia.

¿Por qué una copia a nivel de archivos?

Hay dos formas habituales de copiar un servidor entero:

Método	Ventajas	Inconvenientes
Imagen de disco (`dd`)	Copia exacta, sector a sector	Copia también el espacio vacío, exige un disco de destino igual o mayor y el sistema debe estar parado para que sea consistente
Archivos (`tar`) + estructura del disco	Solo copia datos reales, se puede hacer en caliente y restaurar en discos de otro tamaño	Hay que recrear particiones y reinstalar el cargador de arranque

La copia con tar es más flexible y es la que usan herramientas como Relax-and-Recover (ReaR) por debajo. El precio es un procedimiento de restauración de varios pasos, que es precisamente lo que vas a practicar.

Paso 1: Documentar la estructura del disco

Al restaurar tendrás un disco vacío y necesitarás saber cómo estaba particionado. Crea un directorio para esta información dentro del sistema, de modo que viaje con la copia:

sudo install -d -m 0700 /root/bmr

Guarda la tabla de particiones en un formato que sfdisk puede volver a aplicar. Sustituye /dev/sda por tu disco (en muchos VPS es /dev/vda; compruébalo con lsblk):

sudo sfdisk -d /dev/sda | sudo tee /root/bmr/sda.sfdisk

Guarda los sistemas de archivos, sus UUID y los puntos de montaje:

lsblk -f | sudo tee /root/bmr/lsblk.txt
findmnt --real | sudo tee /root/bmr/findmnt.txt

Por último, anota si el servidor arranca en modo UEFI o BIOS, porque la reinstalación de GRUB es distinta:

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS

Un servidor típico de Ubuntu 24.04 en la nube muestra algo así en lsblk.txt:

NAME    FSTYPE FSVER LABEL           UUID                                 MOUNTPOINTS
sda
├─sda1  ext4   1.0   cloudimg-rootfs 5b8e3f7a-2c1d-4e8b-9f0a-1d2c3b4a5e6f /
├─sda14
├─sda15 vfat   FAT32 UEFI            7A1B-3C2D                            /boot/efi
└─sda16 ext4   1.0   BOOT            0e4f9c2a-8b7d-4a61-b3e2-6f5d4c3b2a19 /boot

Anota cada sistema de archivos montado (en este ejemplo /, /boot y /boot/efi): los necesitarás en el siguiente paso y al restaurar. Si el servidor usa LVM, guarda también la configuración de los grupos de volúmenes junto al resto:

sudo vgcfgbackup
sudo cp /etc/lvm/backup/* /root/bmr/

Paso 2: Hacer la copia completa con tar

tar con --one-file-system no entra en otros sistemas de archivos, así que excluye automáticamente /proc, /sys, /dev, /run y cualquier montaje de red. Por eso hay que indicar de forma explícita cada sistema de archivos local que quieras incluir, como /boot y /boot/efi en el ejemplo.

Ejecuta la copia y envíala por SSH al servidor de backups:

sudo tar --create --gzip --numeric-owner --acls --xattrs --one-file-system \
  --exclude=swap.img \
  -C / --file=- . ./boot ./boot/efi \
  | ssh backup_user@your_backup_server "cat > /srv/backups/$(hostname)-$(date +%F).tar.gz"

Qué hace cada opción:

--numeric-owner guarda los UID y GID numéricos, que es lo que importa al restaurar desde un sistema live con otros usuarios.
--acls --xattrs conservan listas de control de acceso y atributos extendidos, como las capacidades de archivos (ping depende de ellas).
-C / ... . archiva la raíz con rutas relativas (./etc, ./home...), lo que simplifica la restauración.

Si tu servidor tiene otros sistemas de archivos, como /home o /var en particiones propias, añade ./home o ./var a la lista. Si /boot no es una partición separada, quítalo.

Comprueba en el servidor de backups que el archivo está completo y es legible:

ssh backup_user@your_backup_server "gzip -t /srv/backups/$(hostname)-$(date +%F).tar.gz && tar -tzf /srv/backups/$(hostname)-$(date +%F).tar.gz ./root/bmr/"

./root/bmr/
./root/bmr/sda.sfdisk
./root/bmr/lsblk.txt
./root/bmr/findmnt.txt

Guarda también una copia de /root/bmr/ fuera del archivo tar (por ejemplo, en tu gestor de documentación): al restaurar la necesitas antes de extraer nada. Para repetir la copia cada noche, pon el comando en un script y prográmalo con un temporizador de systemd o con cron.

Paso 3: Arrancar el servidor de destino en un sistema live

Arranca la máquina de destino desde la ISO de Ubuntu 24.04 (en la versión Desktop, elige "Probar Ubuntu"; en la versión Server, abre una shell desde el menú del instalador) o desde el modo de rescate de tu proveedor. Todo lo que sigue se ejecuta en ese sistema live.

Identifica el disco de destino:

lsblk -d -o NAME,SIZE,MODEL

Recupera los archivos de estructura del paso 1. Si no los tienes aparte, extráelos del backup:

mkdir -p ~/bmr
ssh backup_user@your_backup_server "cat /srv/backups/your_host-2026-09-25.tar.gz" | tar -xzf - -C ~/bmr --strip-components=3 ./root/bmr
ls ~/bmr

Paso 4: Recrear particiones y sistemas de archivos

Advertencia

los comandos de este paso borran todo el contenido del disco indicado. Comprueba dos veces que /dev/sda es el disco de destino y no el del sistema live.

Aplica la tabla de particiones guardada:

sudo sfdisk /dev/sda < ~/bmr/sda.sfdisk

Si el disco de destino es mayor, sfdisk avisará de que la tabla no ocupa todo el disco; el espacio sobrante podrás usarlo después con growpart y resize2fs. Si es más pequeño, sfdisk fallará y tendrás que editar los tamaños en sda.sfdisk.

Crea los sistemas de archivos reutilizando los UUID originales de lsblk.txt. Así /etc/fstab y la configuración de arranque seguirán siendo válidos sin tocarlos:

sudo mkfs.ext4 -U 5b8e3f7a-2c1d-4e8b-9f0a-1d2c3b4a5e6f -L cloudimg-rootfs /dev/sda1
sudo mkfs.ext4 -U 0e4f9c2a-8b7d-4a61-b3e2-6f5d4c3b2a19 -L BOOT /dev/sda16
sudo mkfs.vfat -F 32 -i 7A1B3C2D -n UEFI /dev/sda15

En FAT32, el identificador 7A1B-3C2D se escribe sin guion en la opción -i. La partición sda14 es la de arranque BIOS de GRUB y no lleva sistema de archivos. Ajusta dispositivos, UUID y etiquetas a los tuyos.

Si el servidor usaba LVM

Recrea el volumen físico con su UUID original y restaura la configuración del grupo de volúmenes desde el archivo que guardaste en ~/bmr (en Ubuntu, el grupo por defecto se llama ubuntu-vg):

sudo pvcreate --uuid "your_pv_uuid" --restorefile ~/bmr/ubuntu-vg /dev/sda3
sudo vgcfgrestore -f ~/bmr/ubuntu-vg ubuntu-vg
sudo vgchange -ay ubuntu-vg

El UUID del volumen físico aparece en ese archivo, en la sección physical_volumes. Después crea los sistemas de archivos sobre /dev/ubuntu-vg/ubuntu-lv igual que antes.

Paso 5: Montar y restaurar los archivos

Monta los sistemas de archivos en el mismo orden jerárquico que tenían:

sudo mount /dev/sda1 /mnt
sudo mkdir -p /mnt/boot
sudo mount /dev/sda16 /mnt/boot
sudo mkdir -p /mnt/boot/efi
sudo mount /dev/sda15 /mnt/boot/efi

Extrae la copia directamente desde el servidor de backups. --xattrs-include='*' es necesario para que tar restaure todos los atributos extendidos, no solo los del espacio user:

ssh backup_user@your_backup_server "cat /srv/backups/your_host-2026-09-25.tar.gz" \
  | sudo tar --extract --gzip --numeric-owner --acls --xattrs --xattrs-include='*' --preserve-permissions -C /mnt --file=-

Comprueba que el sistema restaurado tiene buena pinta:

ls /mnt
cat /mnt/etc/fstab

Recrea los directorios que --one-file-system no copió, si faltan:

sudo mkdir -p /mnt/proc /mnt/sys /mnt/dev /mnt/run /mnt/tmp
sudo chmod 1777 /mnt/tmp

Paso 6: Reinstalar GRUB desde un chroot

La tabla de particiones y los archivos ya están, pero el disco no arrancará hasta que GRUB se instale en él. Hazlo desde dentro del sistema restaurado, que ya tiene los paquetes de GRUB, con un chroot. Primero monta los sistemas de archivos virtuales:

for d in dev proc sys run; do sudo mount --rbind "/$d" "/mnt/$d"; done
sudo chroot /mnt /bin/bash

Dentro del chroot, instala GRUB según el modo de arranque que anotaste en el paso 1. Para UEFI:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu

Para BIOS:

grub-install --target=i386-pc /dev/sda

Regenera la configuración de GRUB y el initramfs:

update-grub
update-initramfs -u -k all

grub-install debe terminar con Installation finished. No error reported. Sal del chroot, desmonta todo y reinicia sin el medio live:

exit
sudo umount -R /mnt
sudo reboot

Paso 7: Verificar el servidor restaurado

Cuando arranque, inicia sesión y comprueba que los sistemas de archivos están montados como antes:

findmnt --real

Revisa que no haya servicios con errores:

systemctl --failed

  UNIT LOAD ACTIVE SUB DESCRIPTION

0 loaded units listed.

Si restauraste en otra máquina, verifica la red con ip -br addr y la conectividad con ping -c 3 1.1.1.1. Por último, restaura los volcados de bases de datos que hiciste antes de la copia y comprueba tus aplicaciones.

Solución de problemas

El servidor arranca en la shell de GRUB (grub>) o en grub rescue>. GRUB no encuentra su configuración, normalmente porque se instaló en modo distinto (BIOS o UEFI) al del firmware. Repite el paso 6 con el destino correcto.

Arranca en la consola de emergencia de initramfs con ALERT! UUID=... does not exist. Algún sistema de archivos se creó con un UUID distinto del de /etc/fstab o de la línea de comandos del kernel. Compara blkid con /etc/fstab y corrige uno de los dos desde el sistema live, y vuelve a ejecutar update-grub en el chroot.

Sin red tras restaurar en otra máquina. Netplan puede tener una regla match: macaddress con la MAC antigua. Revisa los archivos de /etc/netplan/, ajusta la MAC o la IP y aplica con sudo netplan apply.

ping: socket: Operation not permitted para usuarios normales. Se perdieron los atributos extendidos o las capacidades. Asegúrate de extraer con --xattrs --xattrs-include='*'.

Conclusión

Has hecho una copia completa de un servidor Ubuntu 24.04 y lo has reconstruido desde un disco vacío, recreando particiones, sistemas de archivos con sus UUID originales y el cargador de arranque. Ensaya este procedimiento en un servidor de pruebas al menos una vez al trimestre y mide cuánto tarda, porque ese es tu tiempo real de recuperación. Como siguientes pasos, automatiza la copia nocturna con un temporizador de systemd, cifra los archivos antes de enviarlos fuera del servidor o valora herramientas como ReaR, que generan una ISO de rescate con este mismo proceso automatizado.

On this page