--- title: "Recuperación bare metal de un servidor Ubuntu 24.04 con tar" description: "Haz una copia completa de un servidor Ubuntu 24.04 con tar y restáuralo en un disco vacío desde un sistema live: particiones, UUID, GRUB e initramfs incluidos." category: "Migración y Recuperación ante Desastres" language: es source: https://cubepath.com/es/docs/migración-y-recuperación-ante-desastres/procedimientos-de-recuperacion-de-metal-desnudo updated: 2026-09-25 --- # 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: ```bash 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`): ```bash sudo sfdisk -d /dev/sda | sudo tee /root/bmr/sda.sfdisk ``` Guarda los sistemas de archivos, sus UUID y los puntos de montaje: ```bash 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: ```bash [ -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`: ```output 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: ```bash 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: ```bash 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: ```bash 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/" ``` ```output ./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: ```bash lsblk -d -o NAME,SIZE,MODEL ``` Recupera los archivos de estructura del paso 1. Si no los tienes aparte, extráelos del backup: ```bash 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: ```bash 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: ```bash 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`): ```bash 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: ```bash 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`: ```bash 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: ```bash ls /mnt cat /mnt/etc/fstab ``` Recrea los directorios que `--one-file-system` no copió, si faltan: ```bash 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: ```bash 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: ```bash grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu ``` Para BIOS: ```bash grub-install --target=i386-pc /dev/sda ``` Regenera la configuración de GRUB y el initramfs: ```bash 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: ```bash 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: ```bash findmnt --real ``` Revisa que no haya servicios con errores: ```bash systemctl --failed ``` ```output 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.