Guía completa de recuperación del sistema Linux

Cuando un sistema Linux deja de arrancar o se queda colgado tras una actualización, lo normal es que cunda un poco el pánico. Sin embargo, con las herramientas de recuperación adecuadas y una buena estrategia de copias de seguridad, es totalmente posible devolver la máquina a la vida sin tener que reinstalar desde cero.

En el mundo Windows existen rutas muy trilladas: modo seguro, restaurar sistema, herramientas de reparación y, como última opción, reinstalar. En Linux también contamos con un conjunto muy potente de métodos para restaurar el sistema, reparar el arranque, usar modos de emergencia y recuperar datos. La clave está en conocerlos de antemano para no tener que improvisar cuando llegue el desastre.

Conceptos básicos de recuperación en Linux

Antes de meternos en comandos, conviene tener claro qué entendemos por recuperación del sistema Linux. No siempre hablamos de lo mismo: a veces es solo reparar GRUB, otras veces restaurar un backup completo, y en otros casos rescatar datos de un disco dañado.

En general, podemos agrupar los escenarios en tres grandes bloques: restaurar el sistema tal como estaba usando una copia de seguridad completa, reparar problemas de arranque o del kernel desde GRUB o UEFI, y por último la recuperación de datos cuando el sistema de archivos está dañado.

También es importante diferenciar entre herramientas que actúan dentro del propio sistema (cuando aún arranca en algún modo) y otras que usamos desde un entorno externo, como un Live CD/USB o un shell UEFI. Cuanto peor esté la máquina, más dependeremos de esos entornos externos.

Por eso es tan recomendable tener siempre a mano un medio de arranque de alguna distribución similar a la que usamos (por ejemplo un Live de Debian, Ubuntu, Linux Mint, etc.), ya que facilita muchísimo formatear, montar particiones, restaurar archivos y reinstalar el cargador de arranque.

Restaurar un sistema Linux completo desde un backup

Uno de los métodos más fiables para salir de una “catástrofe” es haber creado previamente una copia completa del sistema. Con ese backup podemos devolver el sistema a su estado anterior, con sus programas, configuraciones y personalizaciones, sin tener que reinstalarlo desde cero.

El proceso para restaurar un sistema desde una copia de seguridad basada en archivos (por ejemplo un tar.bz2 del sistema) se puede resumir en unos pocos pasos claros: preparar la partición, montarla, extraer la copia, recrear algunos directorios que se excluyeron y rehacer el arranque con GRUB.

Lo ideal es arrancar con un Live CD/USB de una distribución similar a la original (si tu sistema era Debian, usar Debian Live, Linux Mint, Xubuntu, etc.). Estas distros ligeras son perfectas para trastear sin que el sistema vaya a tirones y nos permiten trabajar con las herramientas de discos cómodamente.

Formatear y preparar la partición de destino

Con el sistema arrancado desde el Live, lo primero es dejar limpia la partición donde vamos a restaurar el sistema. Para ello es muy práctico GParted, una herramienta gráfica que suele estar disponible o se puede instalar con un simple sudo apt install gparted en Debian, Ubuntu o Linux Mint si tenemos conexión a Internet.

Desde GParted podemos borrar la partición antigua, crear una nueva y formatearla con el sistema de archivos adecuado, habitualmente ext4 para la partición raíz. La idea es que el destino de la restauración esté completamente limpio y sin restos de instalaciones anteriores.

Una vez formateada, conviene anotar bien el identificador de la partición (por ejemplo /dev/sda1, /dev/sdb2, etc.), ya que lo necesitaremos para el montaje y más tarde para instalar GRUB en el disco correcto.

Si no queremos usar GParted, siempre podemos recurrir a herramientas de consola como fdisk, parted o mkfs.ext4, pero para muchos usuarios la interfaz gráfica hace más cómodo este trabajo delicado de particionado y formateo.

Montar la partición donde restauraremos el sistema

Con la partición ya formateada, el siguiente paso es montarla en un directorio del Live para poder acceder a ella. La forma más sencilla es montar directamente sobre /mnt, aunque podríamos crear un subdirectorio específico si queremos tenerlo más ordenado.

Por ejemplo, podríamos hacer algo así:

sudo mkdir /mnt/sistema

Después comprobamos el nombre de la partición de destino con:

sudo fdisk -l

Y finalmente montamos (suponiendo que sea /dev/sda1):

sudo mount /dev/sda1 /mnt

A partir de este momento, todo lo que copiemos, creemos o borremos dentro de /mnt se aplicará en realidad a esa partición del disco, que será la futura raíz del sistema cuando terminemos la restauración.

Extraer el backup en la nueva partición

El backup completo suele estar guardado en un medio externo: un pendrive, un disco USB, un NAS, etc. Pongamos el caso de que tenemos una copia comprimida en un pendrive llamado USB32GB, dentro del directorio System_backup_06oct14, con un archivo System_backup_06oct14.tar.bz2.

En ese escenario, bastaría con ejecutar un comando similar a:

sudo tar -xvpjf /media/USB32GB/System_backup_06oct14/System_backup_06oct14.tar.bz2 -C /mnt

Con esa orden estamos diciendo a tar que extraiga el archivo, manteniendo permisos, propietarios y estructura de directorios, dejando el contenido exactamente igual que estaba cuando hicimos la copia, pero ahora situado en la partición que hemos montado en /mnt.

Dependiendo del tamaño del backup y de la velocidad del hardware, este proceso puede tardar bastante. Es normal que toque armarse de paciencia y esperar a que termine la restauración de todos los archivos antes de seguir con el resto de pasos.

Crear los directorios del sistema que se excluyeron

A la hora de crear copias de seguridad completas del sistema, es habitual excluir ciertos directorios volátiles o que no tiene sentido respaldar, como /proc, /tmp, /mnt, /media o algunos logs. Eso implica que, una vez descomprimido el backup, conviene recrear manualmente esos directorios vacíos.

Un ejemplo típico de comando para generarlos podría ser:

sudo mkdir /mnt/proc /mnt/mnt /mnt/media /mnt/tmp /mnt/var/log

Cada usuario debería adaptar esta lista a lo que realmente dejó fuera en la copia original. Lo importante es que, cuando el sistema arranque, estén presentes todas las rutas críticas que necesita el sistema operativo para funcionar correctamente.

Entrar en chroot para operar como si estuviéramos dentro del sistema

Una de las grandes ventajas de Linux es poder usar chroot para “enjaular” el entorno y hacer que el sistema considere un directorio como su nueva raíz. En este caso, queremos que /mnt pase a ser / desde el punto de vista de los comandos que ejecutemos.

Antes de entrar en chroot hay que montar algunos pseudo-sistemas de archivos del Live dentro de /mnt para que el sistema enjaulado tenga acceso a /proc, /sys, /dev y demás dispositivos necesarios:

sudo mount -t proc proc /mnt/proc/
sudo mount -t sysfs sys /mnt/sys/
sudo mount -o bind /dev /mnt/dev/
sudo mount -t devpts pts /mnt/dev/pts

Una vez montado todo esto, ya podemos entrar en el entorno enjaulado:

sudo chroot /mnt /bin/bash

Desde ese momento, en ese terminal todo funcionará como si estuviésemos dentro del sistema restaurado. Las rutas se interpretan tomando /mnt como raíz real, lo que nos permite trabajar cómodamente: actualizar GRUB, ajustar configuraciones, instalar paquetes, etc.

Por comodidad, podemos hasta cambiar el prompt para que quede claro que estamos en chroot, por ejemplo:

export PS1=»(chroot) $PS1″

Instalar y configurar GRUB en el disco

En este punto, el sistema ya está restaurado en disco, pero todavía no arrancará porque falta un cargador de arranque funcional. Desde el chroot, lo normal es actualizar el menú de GRUB y luego instalarlo en el MBR o en la unidad correspondiente.

Primero, actualizamos el menú de GRUB para que detecte los sistemas presentes en el disco y genere su archivo de configuración, generalmente con:

sudo update-grub

Después, instalamos GRUB en el disco adecuado (no en la partición, sino en el dispositivo de disco, por ejemplo /dev/sda para el primer disco):

sudo grub-install /dev/sda

Con esto, cuando reiniciemos y el sistema utilice ese disco como dispositivo de arranque, GRUB debería cargar su menú correctamente y permitir iniciar el sistema restaurado. Es recomendable revisar que la BIOS/UEFI está configurada para arrancar desde el disco donde hemos instalado GRUB.

Si al arrancar tenemos problemas con permisos en carpetas como /tmp que impiden levantar el entorno gráfico, se puede solucionar desde una consola de texto (Ctrl+Alt+F1) entrando con nuestro usuario y aplicando algo como:

sudo chmod 777 /tmp

Este tipo de detalles dependen mucho de cómo se creó el backup, pero en general son fáciles de corregir una vez que el sistema vuelve a iniciar. A partir de ahí, ya podemos volver a usarlo con normalidad y, si queremos, automatizar nuevos backups periódicos.

Herramientas específicas de recuperación en distribuciones Linux

Además del enfoque “manual” restaurando tar, existen herramientas y paquetes diseñados específicamente para simplificar copias y recuperación de sistemas Linux. Una de las más conocidas en entornos empresariales es Relax-and-Recover (ReaR), que permite crear imágenes de sistema y medios de recuperación personalizados.

En sistemas basados en Red Hat, por ejemplo, podríamos instalar ReaR junto con las utilidades necesarias para generar imágenes ISO y cargadores de arranque mediante un comando del estilo:

yum install rear genisoimage syslinux

ReaR se encarga de preparar un entorno de rescate capaz de restaurar el servidor en caso de desastre, combinando scripts, configuración del sistema y herramientas de premasterización como genisoimage, además del paquete syslinux que aporta distintos bootloaders.

Fuera del mundo empresarial, en escritorios y equipos personales también son muy populares las herramientas tipo “máquina del tiempo”, que permiten crear instantáneas del sistema de forma programada y restaurarlas con un par de clics o comandos.

Directorios y componentes críticos para el arranque

Para moverse con soltura en la recuperación del sistema es esencial saber dónde vive cada pieza clave del proceso de arranque. En particular, el directorio /boot concentra los elementos más importantes: imágenes del kernel, initramfs, ficheros de GRUB, etc.

Dentro de /boot encontramos a menudo subdirectorios como /boot/grub/, donde se guardan los módulos del gestor de arranque y sus archivos de configuración, así como las entradas que determinan qué kernel cargará el sistema.

También están presentes las imágenes initrd o initramfs (/boot/initrd.img o initramfs con diferentes sufijos de versión). Estas imágenes contienen un pequeño sistema de archivos en RAM que se usa en las primeras fases del arranque para cargar módulos, detectar discos y montar la raíz real.

En sistemas que usan UEFI, la partición EFI se monta normalmente en /boot/efi y puede compartirse entre varios sistemas operativos. Ahí se almacenan los binarios .efi que actúan como cargadores de arranque para Linux, Windows u otros sistemas.

Por último, en sistemas clásicos con sysvinit existía el fichero /etc/inittab, donde se definían runlevels y comportamientos de arranque. Aunque muchas distros han dado el salto a systemd y usan otros mecanismos, conocer estos conceptos (single-user mode, multi-user, etc.) sigue siendo muy útil para entender los modos de rescate y emergencia.

Modos de rescue y emergencia con systemd y GRUB

En sistemas modernos basados en systemd, además del arranque normal, tenemos targets especiales pensados para la recuperación, como rescue.target y emergency.target. Estos modos arrancan el sistema con servicios mínimos, permitiendo reparaciones sin interferencias.

Cuando el sistema todavía muestra el menú de GRUB, podemos usarlo para elegir opciones avanzadas. Muchas distribuciones, como Ubuntu, ofrecen directamente entradas de Advanced options con variantes “(recovery mode)” para cada kernel instalado.

Desde ese submenú se pueden cargar utilidades muy útiles para diagnóstico y reparación: comprobar particiones con fsck, intentar reparar paquetes rotos con dpkg, actualizar GRUB, activar red o arrancar una shell con privilegios de root.

Otra opción es usar el editor de GRUB (tecla E sobre una entrada) para añadir al final de la línea de linux parámetros especiales, como systemd.unit=emergency.target o systemd.unit=rescue.target. De este modo, aunque no tengamos una entrada explícita en el menú, podemos forzar el arranque directo a esos modos de emergencia.

En emergency.target se inicia un entorno muy básico con solo una shell raíz y los sistemas de archivos en modo lectura, ideal para revisar logs, volver a montar el sistema, corregir fstab o deshacer cambios de configuración que hayan roto el arranque normal.

Uso práctico del Recovery Mode en distros como Ubuntu

Si elegimos desde GRUB las opciones avanzadas y luego una entrada etiquetada como (Recovery Mode), en muchas distros aparecerá un menú adicional con varias utilidades para recuperación. En Ubuntu, por ejemplo, se suelen ver opciones como:

• resume: vuelve a intentar el arranque normal desde ese kernel.
• clean: abre un shell con instrucciones para liberar espacio si el disco se ha quedado sin sitio.
• dpkg: repara o elimina paquetes dañados que puedan estar impidiendo el arranque, tirando de los repositorios si activamos la red.
• fsck: ejecuta comprobaciones de sistemas de archivos y particiones para detectar y corregir errores.
• grub: analiza y actualiza el propio gestor de arranque.
• network: habilita la red, útil para instalar o descargar paquetes de reparación.
• root: abre una shell como superusuario desde la que podemos hacer cambios de configuración profundos.
• system-summary: muestra un resumen del sistema, versión del kernel, discos, etc.

Estas herramientas, combinadas con un conocimiento básico de comandos como mount, fsck, systemctl, journalctl o nano/vi, permiten resolver una gran cantidad de incidencias sin necesidad de volver a instalar todo el sistema desde cero.

Trabajar con el shell de GRUB y nomenclatura de discos

En fallos más serios, puede ocurrir que el sistema no arranque de forma normal y que solo podamos interactuar con un prompt de GRUB, ya sea grub> (shell normal) o grub rescue> (modo recuperación más limitado). Incluso en esta situación, todavía tenemos margen de maniobra.

Desde el menú de GRUB podemos acceder a su línea de comandos pulsando la tecla C. Esto abre un entorno donde ejecutar órdenes específicas del bootloader, listar discos, buscar kernels, cargar módulos y preparar un arranque manual del sistema.

Es importante tener en cuenta que GRUB no nombra los discos y particiones igual que Linux. Mientras que en Linux usamos /dev/sda, /dev/sdb, etc. para discos y /dev/sda1, /dev/sda2… para particiones, GRUB utiliza sintaxis del estilo (hd0,0), (hd0,1), (hd1,0), etc.

De forma aproximada, podemos asociar /dev/sda con hd0, /dev/sdb con hd1, y así sucesivamente. Luego, para las particiones, GRUB usa índices entre paréntesis, con disco y partición separados por coma, lo que hay que tener muy presente cuando intentamos localizar el /boot o la raíz desde el shell de GRUB.

Con las órdenes adecuadas (ls, set, linux, initrd, boot, etc.), y una vez identificada la partición donde están el kernel y el initramfs, es posible lanzar a mano un arranque, y después ya desde el sistema restaurar la configuración normal de GRUB con las herramientas habituales.

Recuperación avanzada desde UEFI Shell

En máquinas modernas con UEFI, a veces el problema no es Linux en sí, sino la pérdida o corrupción de la entrada de arranque que apunta al archivo .efi del cargador. En esos casos puede que solo veamos un prompt tipo Shell> propio de UEFI al encender el equipo.

Este shell UEFI tiene su propia forma de referirse a los dispositivos. Nada de /dev/sda ni hd0: al arrancar suele mostrar una “mapping table” donde vemos unidades marcadas como FS0, FS1, FS2…, que vienen a corresponder con /dev/sda, /dev/sdb, etc.

Para moverse por estos sistemas de archivos se usan rutas con barras invertidas (\) en lugar de /, y el teclado se considera en distribución inglesa, por lo que la posición de caracteres como dos puntos, barra, etc. cambia respecto al teclado español.

Desde este entorno se pueden listar dispositivos, cambiar de unidad, navegar hasta la partición EFI y localizar los binarios .efi de los bootloaders. Hay herramientas y comandos (e incluso un editor llamado edit) que permiten retocar la configuración de arranque, añadir o modificar entradas y volver a apuntar el firmware al cargador correcto.

Eso sí, toquetear el arranque UEFI sin saber exactamente lo que hacemos puede dejar la máquina peor de lo que estaba, así que conviene actuar con precaución y seguir documentación específica (como el manual oficial de UEFI Shell) si no tenemos experiencia previa.

“Máquina del tiempo” en Linux: snapshots con TimeShift

Quienes vienen de Windows suelen echar en falta algo parecido a Restaurar sistema o Time Machine de macOS. En Linux existen soluciones que cumplen una función muy similar, y una de las más populares en escritorios basados en Debian/Ubuntu es TimeShift.

TimeShift permite definir una ubicación donde guardar instantáneas (snapshots) del sistema y programar automáticamente cada cuánto se crearán: por ejemplo, cada dos semanas, conservando únicamente las dos últimas para no llenar el disco.

Durante la configuración inicial podemos elegir qué directorios excluir de las instantáneas, de forma que el sistema se concentre en los archivos de sistema y configuración, sin duplicar datos personales que ya estemos guardando con otra herramienta.

Una vez configurado, crear un “punto de restauración” es tan sencillo como abrir la aplicación y pulsar el botón Crear. El programa se encargará de generar la instantánea y, cuando termine, podremos verla listada junto al resto de snapshots disponibles.

Restaurar el sistema desde uno de esos puntos también es muy directo: seleccionamos la instantánea y pulsamos Restaurar en la interfaz, o trabajamos desde la terminal ejecutando comandos como timeshift –list para ver las snapshots disponibles y timeshift –restore para volver el sistema a un estado anterior concreto.

Recuperación de datos en sistemas Linux

A veces el problema principal no es que el sistema no inicie, sino haber perdido ficheros importantes por borrados accidentales o fallos en el sistema de archivos. En estos casos hablamos propiamente de recuperación de datos sobre sistemas Linux, más que de recuperación del sistema operativo.

Linux puede usar distintos tipos de sistemas de archivos, aunque en la práctica en entornos de escritorio y servidores generalistas predominan las familias ext2, ext3 y ext4. Diferentes distribuciones históricamente han optado por uno u otro por defecto.

Por ejemplo, Debian GNU/Linux o Slackware se han apoyado en ext2, mientras que Red Hat, Fedora, Ubuntu o CentOS han utilizado ext3 en muchas versiones, y versiones más nuevas de distribuciones como Arch, Ubuntu 9, Fedora 11, CentOS 6 o Debian 7 adoptaron ext4 como sistema de archivos de referencia.

En función del sistema de archivos y la forma en que se hayan perdido los datos (borrado lógico, partición dañada, disco con sectores defectuosos, etc.), usaremos herramientas distintas: desde fsck para reparar estructuras básicas, hasta utilidades más avanzadas de análisis y recuperación forense, siempre priorizando no escribir en el disco afectado para maximizar las probabilidades de éxito.

En escenarios especialmente críticos con datos de alto valor, suele ser más prudente recurrir a servicios profesionales de recuperación que cuenten con experiencia en sistemas Linux y conozcan bien las particularidades de cada distribución y sistema de archivos.

Mirando todo este conjunto de técnicas y herramientas, se ve claramente que Linux ofrece un abanico muy amplio de posibilidades para evitar reinstalaciones traumáticas: desde restaurar copias completas con tar o ReaR, usar snapshots cómodos con TimeShift, apoyarse en los modos de rescue y emergencia de systemd y GRUB, hasta entrar al detalle en GRUB o UEFI Shell cuando la cosa se complica, sin olvidar que siempre está la opción de recuperar datos en sistemas de archivos ext2/3/4 cuando el sistema ya no tiene arreglo pero aún queremos salvar la información importante.