Cómo recuperar un servidor Debian que no arranca tras actualizar el kernel conservando la configuración de Docker y los contenedores
Por Kevin Marcondes · Publicado el · 9 min de lectura
¿Necesitas recuperar un servidor Debian que no arranca después de actualizar el kernel y quieres mantener la configuración de Docker y los contenedores? Esta guía práctica muestra cómo restaurar el arranque con chroot, reparar GRUB, reconstruir el initramfs y, si hace falta, volver al kernel anterior sin perder volúmenes ni parámetros de Docker.
Señales del problema y qué está en riesgo
Los fallos de arranque tras actualizar el kernel suelen manifestarse como errores de GRUB, initramfs que cae en BusyBox o kernel panic. Antes de actuar, el objetivo es restaurar el arranque sin perder datos. Evita reinstalar el sistema a la ligera, ya que eso puede sobrescribir particiones y borrar volúmenes de Docker.
La estrategia segura es iniciar en modo rescue, montar el disco, entrar en chroot y reparar el gestor de arranque y el initramfs. Solo después deberías decidir si hacer rollback del kernel.
- Errores del GRUB o retorno al menú de arranque
- Prompt de BusyBox (initramfs) pidiendo contraseña de root
- Mensaje de kernel panic al montar la raíz
- Bucle de arranque al seleccionar el kernel
- Servicios Docker inaccesibles, pero los datos siguen presentes
¿Qué provoca que Debian no arranque tras actualizar el kernel?
Las causas más comunes son GRUB mal configurado, initramfs sin los controladores de almacenamiento o de cifrado necesarios, y cambios en el orden de arranque provocados por la virtualización. También puede darse incompatibilidad con el kernel nuevo. La tabla siguiente ayuda a decidir la ruta de corrección.
| Síntoma | Causa probable | Acción recomendada |
|---|---|---|
| prompt interactivo grub> | GRUB corrupto o no instalado en el disco correcto | Reinstalar GRUB desde el chroot y actualizar la configuración |
| error: no such device/UUID | UUID cambiado (LVM/LUKS) o /etc/fstab incorrecto | Revisar /etc/fstab, regenerar initramfs y ejecutar update-grub |
| initramfs BusyBox (Cannot mount /) | initramfs sin módulos de storage/cripto | update-initramfs -u y verificar los módulos requeridos |
| kernel panic: VFS: Unable to mount root fs | Falta el driver del filesystem/controlador | Regenerar initramfs y confirmar los módulos del rootfs |
| Vuelta al menú al elegir kernel | Entrada de arranque rota o BLS inválido | update-grub; si procede reinstalar un kernel estable |
Cómo montar el disco y entrar en chroot con la partición raíz
El chroot proporciona un entorno de tu sistema para reparar GRUB e initramfs. Arranca en modo rescue o con un Live ISO compatible con tu arquitectura. Si usas LUKS o LVM, deberás desbloquear y activar volúmenes antes de montar.
Identifica las particiones, desbloquea LUKS, activa LVM, monta la raíz y realiza los bind mounts de /dev, /proc, /sys y /run. Después entra en el chroot.
# Identifique dispositivos
lsblk -f
# Se houver LUKS
cryptsetup luksOpen /dev/sdXn cryptroot
# Ative LVM (se usar)
vgchange -ay
# Monte a raiz (ajuste o caminho do LV/partição)
mount /dev/mapper/vg0-root /mnt
# Monte /boot e /boot/efi se existirem
mount /dev/sdXn /mnt/boot
mount /dev/sdYn /mnt/boot/efi
# Bind mounts essenciais
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
mount --bind /run /mnt/run
# Entre no sistema
chroot /mnt /bin/bash
Reinstalar GRUB y reconstruir el initramfs
Reparar GRUB y el initramfs resuelve la mayoría de los arranques rotos. Seleccionar el disco equivocado en grub-install puede sobrescribir el cargador de arranque de otro volumen: confirma el destino antes de ejecutar.
Tras reinstalar GRUB (BIOS o UEFI), actualiza la configuración y regenera el initramfs para incluir los módulos necesarios para rootfs, LUKS y LVM.
# Dentro do chroot
# BIOS (Legacy): instale no disco (ex.: /dev/sda)
grub-install /dev/sda
# UEFI: instale apontando para a ESP (ajuste /boot/efi)
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=debian
# Recrie config do GRUB
update-grub
# Reconstrua initramfs (todos os kernels instalados)
update-initramfs -u -k all
¿Cómo volver de forma segura al kernel anterior?
Si el kernel nuevo es la causa, usar el kernel anterior es un rollback sencillo. En el chroot, lista las versiones disponibles e instala la anterior estable. Después actualiza GRUB y valida la entrada de arranque en el próximo reinicio.
Otra opción es instalar un kernel conocido estable y marcar el metapaquete para evitar actualizaciones no planificadas hasta la próxima ventana de mantenimiento.
# Dentro do chroot
apt-get update
apt-cache policy linux-image-amd64 | sed -n '1,10p'
# Instale uma versão anterior específica (ajuste o nome)
apt-get install linux-image-<versao-anterior>
# Atualize o GRUB
update-grub
# Opcional: segurar atualizações automáticas do kernel
apt-mark hold linux-image-amd64 linux-headers-amd64
Preservar la configuración de Docker y los contenedores durante la recuperación
Los datos de los contenedores residen en volúmenes Docker en /var/lib/docker/volumes y en bind mounts. La configuración del daemon está en /etc/docker/daemon.json y los servicios pueden vivir en unit files de systemd. No uses apt purge docker sin un backup previo.
Si necesitas reorganizar el almacenamiento, consulta cómo mover volúmenes en la guía de mover volúmenes Docker a otro disco. Reinstalar el paquete normalmente conserva los datos, pero haz un respaldo local por seguridad.
- Directorios críticos: /var/lib/docker, /etc/docker y directorios de proyectos/Compose
- Evita modificar overlay2; prioriza copiar volúmenes y bind mounts
- Asegura consistencia de UID/GID al migrar datos a otro host
# Ainda no chroot (ou no rescue montado em /mnt)
# Faça um backup rápido (compressão opcional) dos dados do Docker
cd /
tar -C / -cpf /root/backup-docker.tar \
var/lib/docker \
etc/docker 2>/root/backup-docker.log
# Exporte também diretórios de projetos (ajuste caminhos)
tar -C / -cpf /root/backup-compose.tar opt/projects srv/apps home/*/apps
Y si el sistema no vuelve: cómo rescatar datos de los contenedores
Si el arranque no se recupera, aún puedes extraer datos montando el disco en otro host o usando el modo rescue. Enfócate en /var/lib/docker/volumes y en los bind mounts de los servicios críticos. Para migrar rápido, sigue la guía de migrar un host Docker a otra VPS.
Evita copiar las capas de overlay2. Recrea los contenedores a partir de las mismas imágenes y vuelve a anexar los volúmenes copiados en el Compose. Valida rutas y permisos antes de levantar los servicios.
- No copies capas de overlay2; recrea contenedores desde las imágenes
- Valida las rutas de volúmenes en docker-compose.yml antes de levantar
- Haz checksums muéstrales para validar integridad tras la copia
# No modo rescue (fora do chroot), copie os volumes para outro host
rsync -aHAX --numeric-ids /mnt/var/lib/docker/volumes/ \
user@novo-host:/backup/volumes/
# No novo host, posicione os volumes e suba o Compose
# (ajuste docker-compose.yml para apontar os volumes corretos)
Checklist post-recuperación y prevención de nuevas fallas
Tras restaurar el arranque, estabiliza el entorno y reduce riesgos. Implementa snapshots y backups con LVM snapshots + Restic en S3 (Debian). Refuerza las prácticas de la Checklist de seguridad para VPS Linux.
Crea ventanas de mantenimiento para los kernels: prueba el kernel nuevo como secundario y promuévelo solo tras validarlo. Monitoriza la salud del host, el espacio en /boot y los logs de GRUB e initramfs.
- Instalar un kernel nuevo sin cambiar el default; probar y luego promover
- Crear snapshot/backup antes de actualizaciones de kernel
- Revisar /etc/fstab por UUIDs correctos y timeouts para LUKS/LVM
- Monitorizar espacio en /boot y logs de initramfs/GRUB
- Documentar un runbook de rollback de kernel
# Exemplo: manter kernel antigo como padrão até validar o novo
grub-set-default 0 # Ajuste para a entrada validada
update-grub
Lecturas relacionadas sobre migración, volúmenes y backups
Si optas por migrar a otra VPS o reorganizar volúmenes tras el incidente, estos guías ayudan a hacerlo con seguridad y mínima indisponibilidad. También conviene estandarizar una política de backups fuera del host.
- Backups incrementales y cifrados en S3: Implementación de backups incrementales y cifrados en S3‑compatible
Preguntas frecuentes
¿Qué pasos rápidos tomar cuando Debian no arranca tras actualizar el kernel?
Inicia en modo rescue, monta la partición raíz, haz bind mounts y entra en chroot. Reinstala GRUB, ejecuta update-grub y update-initramfs -u. Si es necesario, instala el kernel anterior, actualiza GRUB y prueba la entrada de arranque antes de promoverla.
¿Reinstalar Docker borra mis contenedores y volúmenes?
No si reinstalas normalmente; sí si usas purge con eliminación de datos. Por lo general, /var/lib/docker conserva volúmenes y capas. Haz backup de /var/lib/docker y /etc/docker antes de actuar. Evita alterar overlay2 y prioriza volúmenes nombrados y bind mounts.
¿Cómo saber si debo volver al kernel anterior?
Si el arranque solo funciona con el kernel antiguo o hay regresiones conocidas, el rollback es la opción más segura. Prueba desde Advanced options en GRUB. Si es estable, pon el kernel antiguo como predeterminado y marca el metapaquete para evitar actualizaciones hasta investigar la causa.
¿Puedo copiar el directorio overlay2 para recuperar contenedores?
No es recomendable. overlay2 contiene capas internas no portables. Copia únicamente volúmenes y bind mounts con datos de la aplicación. Recrea los contenedores a partir de las mismas imágenes y vuelve a montar los volúmenes en el docker-compose.yml válido.
¿Es obligatorio descifrar LUKS para reparar el arranque?
Sí: si la raíz está dentro de LUKS, necesitas desbloquearla para montarla y entrar en chroot. Usa cryptsetup luksOpen, activa LVM si aplica y monta las particiones. Después ejecuta grub-install, update-grub y update-initramfs desde el entorno chroot.
¿Necesitas asegurar que el servidor vuelva a operar sin perder datos?
Si quieres revisar los pasos de recuperación, validar un rollback de kernel o planificar backups y snapshots antes de próximas actualizaciones, contáctame para evaluar tu escenario.
Hablar sobre recuperación y prevenciónVer también
- 502 Bad Gateway intermitente en Docker Compose con Nginx y PHP‑FPM: cómo diagnosticar y corregir timeouts y exceso de conexiones
- Cómo diagnosticar y capturar paquetes por intermitencias de red entre contenedores Docker en Debian
- Cómo detectar y corregir inconsistencias de SKUs duplicados entre WooCommerce y ERP sin perder pedidos
- Cómo resolver el error 'Too many open files' en Linux en servidores PHP‑FPM durante picos de carga