Recuperación del sistema tras una actualización fallida o corrupción del sistema de archivos

Objetivo:

Comprender y aplicar los procedimientos críticos de recuperación de un sistema Linux tras una actualización fallida de paquetes o una corrupción severa del sistema de archivos, utilizando un entorno de rescate Live USB, cambio de raíz (chroot), reparación de bloques con fsck y reconstrucción de paquetes rotos mediante el gestor APT.

Escenario:

  • Herramientas: Live USB de rescate, terminal Linux, comandos chroot, mount, fsck, dpkg y apt.
  • Conceptos analizados: Consistencia de sistemas de archivos ext4/XFS, gestión de dependencias de paquetes rotos, puntos de montaje virtuales y recuperación de entornos de producción colapsados.
  • Proceso clave: Arranque mediante medio externo, vinculación de particiones internas, reparación de la integridad de almacenamiento, entrada en entorno chroot y reconfiguración del gestor de paquetes para reparar el sistema operativo.

Escenario Real: Servidor con actualización interrumpida y arranque bloqueado

Un administrador ejecutó una actualización masiva del sistema operativo en un servidor de producción que se interrumpió de forma abrupta debido a un corte de red y una caída de tensión. Al reiniciar, el sistema de ficheros presenta corrupción masiva y el gestor de paquetes se encuentra en un estado inconsistente, impidiendo el arranque normal del equipo. Debes utilizar un entorno de rescate externo para recuperar la integridad de los datos y reparar el sistema de paquetes.

Por defecto, los gestores de paquetes y los sistemas operativos están protegidos frente a interrupciones menores. Sin embargo, un corte durante una fase crítica de actualización puede dejar el disco en un estado inutilizable. Dominar las técnicas de recuperación de entornos mediante chroot y la reparación de paquetes es el recurso definitivo para un administrador de sistemas.

NOTA: Para realizar esta práctica de simulación de rescate, asegúrate de disponer de una máquina virtual o un entorno de prácticas con acceso a un medio Live USB o ISO de rescate.

Instrucciones:

Fase 1: Arranque externo (Live USB) e identificación de volúmenes:

  • Arrancar el equipo utilizando un medio de rescate externo (Live USB).
  • Abrir una terminal en el entorno Live y listar las particiones de almacenamiento para localizar la partición raíz dañada (ej. /dev/sda2) mediante: lsblk o sudo fdisk -l

Fase 2: Comprobación y reparación del sistema de archivos con fsck:

  • Asegurarse de que la partición afectada NO se encuentra montada.
  • Ejecutar una comprobación exhaustiva y reparación automática de bloques y metadatos dañados sobre la partición raíz: sudo fsck -f -y /dev/sda2
  • Crear un directorio temporal de montaje y montar la partición raíz reparada: 
    sudo mkdir -p /mnt/rescate
sudo mount /dev/sda2 /mnt/rescate
  • Si el sistema utiliza una partición EFI independiente, móntala en su ruta correspondiente dentro del directorio de rescate: sudo mount /dev/sda1 /mnt/rescate/boot/efi

Fase 3: Vinculación de directorios virtuales y cambio de raíz (chroot):

  • Montar los sistemas de archivos virtuales del kernel para compartirlos con el entorno de rescate: 
    sudo mount --bind /dev /mnt/rescate/dev
sudo mount --bind /proc /mnt/rescate/proc
sudo mount --bind /sys /mnt/rescate/sys
sudo mount --bind /run /mnt/rescate/run
  • Acceder al interior del sistema dañado mediante el comando de cambio de raíz: sudo chroot /mnt/rescate

Fase 4: Reparación de paquetes rotos y actualización del sistema:

  • Una vez dentro del entorno chroot, forzar la reconfiguración de paquetes pendientes o interrumpidos: dpkg --configure -a
  • Corregir posibles dependencias rotas y completar las instalaciones interrumpidas utilizando el gestor de paquetes APT: apt --fix-broken install
  • Actualizar y limpiar la caché de paquetes para asegurar la consistencia del software instalado: apt update && apt upgrade -y
  • Salir del entorno chroot y desmontar ordenadamente todos los directorios vinculados antes de reiniciar: 
    exit
sudo umount /mnt/rescate/dev /mnt/rescate/proc /mnt/rescate/sys /mnt/rescate/run
sudo umount /mnt/rescate/boot/efi # Si procede
sudo umount /mnt/rescate
sudo reboot

Verificación:

  • Comprobar que tras retirar el medio externo y reiniciar el equipo, el sistema operativo arranca con normalidad y permite iniciar sesión sin errores de paquetes.
  • Verificar mediante sudo apt status o ejecutando una comprobación de estado que el sistema de paquetes se encuentra totalmente consistente y operativo.

Posibles errores y resolución de problemas:

Si al intentar ejecutar comandos de APT dentro del entorno chroot obtienes un error persistente de resolución de nombres o incapacidad para conectar a los repositorios, se debe a la falta de conectividad de red.

  • Solución: Copia temporalmente el fichero de resolución DNS del sistema Live al directorio de rescate para habilitar el acceso a Internet: sudo cp /etc/resolv.conf /mnt/rescate/etc/resolv.conf

Alternativa directa: Limpieza rápida de paquetes bloqueados

Si el sistema operativo arranca con normalidad pero muestra errores continuos al intentar instalar nuevo software debido a un bloqueo previo del gestor APT causado por una actualización interrumpida, puedes desbloquearlo ejecutando directamente la limpieza de ficheros de bloqueo:

sudo rm /var/lib/dpkg/lock*
sudo dpkg --configure -a

Preguntas de reflexión:

  1. ¿Por qué es un requisito indispensable ejecutar el comando fsck con el sistema de archivos completamente desmontado o en modo de solo lectura?
  2. ¿Qué función concreta realiza el comando dpkg --configure -a al reparar un sistema operativo que sufrió una interrupción durante una actualización de paquetes?
  3. ¿Por qué es necesario copiar o enlazar el fichero /etc/resolv.conf dentro del entorno de rescate antes de intentar utilizar el gestor de paquetes APT mediante chroot?
  4. ¿Qué riesgos implica para la estabilidad del sistema forzar la reparación de dependencias rotas en entornos de producción sin realizar previamente una copia de seguridad?
Haz clic aquí para ver las soluciones y explicaciones

1. ¿Por qué es un requisito indispensable ejecutar el comando fsck con el sistema de archivos completamente desmontado o en modo de solo lectura?

Porque si el sistema de archivos está montado en modo de lectura y escritura, el kernel y las aplicaciones continúan modificando bloques y metadatos de forma activa en el disco. Lanzar una reparación de estructuras con fsck en ese estado generaría una corrupción masiva e irreversible de los datos al interferir con las operaciones de escritura en curso.

2. ¿Qué función concreta realiza el comando dpkg --configure -a al reparar un sistema operativo que sufrió una interrupción durante una actualización de paquetes?

Revisa la base de datos interna del gestor de paquetes en busca de aquellos paquetes que quedaron a mitad de su proceso de instalación o configuración (etiquetados como unpacked o half-configured) y reanuda de forma secuencial los scripts de configuración pendientes para devolver el sistema a un estado consistente.

3. ¿Por qué es necesario copiar o enlazar el fichero /etc/resolv.conf dentro del entorno de rescate antes de intentar utilizar el gestor de paquetes APT mediante chroot?

Porque el entorno chroot aísla el directorio raíz, haciendo que los binarios del sistema dañado no tengan acceso a la configuración de red y servidores DNS del sistema Live externo. Sin el fichero resolv.conf adaptado, el sistema no podrá resolver nombres de dominio ni conectar con los repositorios oficiales en Internet.

4. ¿Qué riesgos implica para la estabilidad del sistema forzar la reparación de dependencias rotas en entornos de producción sin realizar previamente una copia de seguridad?

Forzar la resolución o eliminación de paquetes con dependencias conflictivas puede provocar la desinstalación masiva de librerías críticas o componentes esenciales del sistema operativo (como entornos gráficos, demonios de red o herramientas del kernel), dejando el servidor en un estado aún más inoperativo o inaccesible de forma remota.