Como recuperar servidor Debian que não inicia após atualização de kernel mantendo configurações do Docker e containers

Por · Publicado em · 9 min de leitura

Notebook segurado por uma pessoa com a tela rachada exibindo linhas coloridas
Imagem conceitual de falha de sistema/boot — foco no notebook com a tela danificada. Foto: Beyzanur K. / Pexels

Precisa recuperar servidor Debian que não inicia após atualização de kernel mantendo configurações do Docker e containers? Este guia prático mostra como restaurar o boot com chroot, reparar o GRUB, reconstruir o initramfs e, se necessário, fazer rollback do kernel — sem perder volumes e parâmetros do Docker.

Sinais do problema e o que está em risco

Falhas de boot após atualizar o kernel costumam aparecer como erros do GRUB, initramfs BusyBox ou kernel panic. Antes de agir, o objetivo é restaurar o boot sem perder dados. Evite reinstalar o sistema às pressas, pois isso pode sobrescrever partições e apagar volumes do Docker.

A estratégia segura é inicializar em modo rescue, montar o disco, entrar em chroot, reparar o carregador e o initramfs. Só então decida sobre rollback de kernel.

  • Erros do GRUB ou retorno ao menu de boot
  • Prompt BusyBox (initramfs) pedindo senha de root
  • Mensagem de kernel panic ao montar a raiz
  • Loop de boot após selecionar o kernel
  • Serviços Docker indisponíveis, mas dados ainda presentes

O que causa um Debian não iniciar após atualização de kernel?

As causas mais comuns são GRUB desconfigurado, initramfs sem drivers de storage ou criptografia e ordem de boot alterada pela virtualização. Também ocorre incompatibilidade do kernel novo. O quadro abaixo ajuda a decidir o caminho de correção.

Sintoma Causa provável Ação recomendada
grub> prompt interativo GRUB corrompido ou não instalado no disco correto Reinstalar GRUB a partir do chroot e atualizar configuração
error: no such device/UUID UUID mudou (LVM/LUKS) ou fstab incorreto Checar /etc/fstab, regenerar initramfs e update-grub
initramfs BusyBox (Cannot mount /) initramfs sem módulos de storage/cripto update-initramfs -u e verificar módulos exigidos
kernel panic: VFS: Unable to mount root fs Driver de filesystem/controlador ausente Regerar initramfs e confirmar módulos do rootfs
Volta ao menu ao escolher kernel Entrada de boot quebrada ou BLS inválida update-grub; eventualmente reinstalar kernel estável

Como montar o disco e entrar em chroot com a partição raiz

O chroot fornece um ambiente do seu sistema para reparar GRUB e initramfs. Inicialize em modo rescue ou Live ISO compatível com sua arquitetura. Se usar LUKS ou LVM, será preciso desbloquear e ativar volumes antes de montar.

Identifique partições, desbloqueie LUKS, ative LVM, monte a raiz e faça bind mounts de /dev, /proc, /sys e /run. Em seguida, entre no 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 o GRUB e reconstruir o initramfs

Reparar o GRUB e o initramfs resolve a maioria dos boots quebrados. Selecionar o disco errado no grub-install pode sobrescrever o bootloader de outro volume. Confirme o destino antes de executar.

Após reinstalar o GRUB (BIOS ou UEFI), atualize a configuração e regenere o initramfs para incluir módulos necessários ao rootfs, LUKS e 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

Como voltar para o kernel anterior com segurança?

Se o kernel novo é a causa, usar o kernel anterior é um rollback simples. No chroot, liste versões disponíveis e instale a anterior estável. Em seguida, atualize o GRUB e valide a entrada de boot no próximo reinício.

Outra opção é instalar um kernel conhecido estável e segurar o metapacote. Assim, você evita atualizações não planejadas até a próxima janela de manutenção.

# 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 configurações do Docker e containers durante a recuperação

Os dados dos containers ficam em volumes do Docker em /var/lib/docker/volumes e em bind mounts. As configurações do daemon estão em /etc/docker/daemon.json e serviços podem viver em unit files do systemd. Não use apt purge docker* sem backup prévio.

Se precisar reorganizar storage, veja como mover volumes Docker para outro disco. Reinstalar o pacote normalmente mantém dados, mas faça um backup local por segurança.

  • Diretórios críticos: /var/lib/docker, /etc/docker, diretórios de projetos/Compose
  • Evite modificar overlay2; priorize copiar volumes e bind mounts
  • Garanta UID/GID consistentes ao migrar dados para outro 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

E se o sistema não volta? Como resgatar dados dos containers

Se o boot não retorna, você ainda pode extrair dados montando o disco em outro host ou usando o modo rescue. Foque em /var/lib/docker/volumes e nos bind mounts dos serviços críticos. Para migrar rápido, siga o guia de migrar um host Docker em produção para outra VPS.

Evite copiar camadas do overlay2. Recrie containers a partir das mesmas imagens e reanexe os volumes copiados ao Compose. Valide paths e permissões antes de subir os serviços.

  • Evite copiar camadas overlay2; recrie containers a partir das imagens
  • Valide paths de volumes no docker-compose.yml antes de subir
  • Faça checksum amostral para validar integridade após a cópia
# 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 pós-recuperação e prevenção de novas panes

Depois do boot restaurado, estabilize o ambiente e reduza riscos. Implemente snapshots e backups com LVM snapshots + Restic em S3 (Debian). Reforce práticas da sua Checklist de segurança para VPS Linux.

Crie janelas de manutenção para kernels, teste o novo kernel como secundário e promova após validação. Monitore a saúde do host, espaço em /boot e logs do GRUB e initramfs.

  • Instalar novo kernel sem trocar o default; testar e só então promover
  • Criar snapshot/backup antes de upgrades de kernel
  • Revisar /etc/fstab por UUIDs corretos e timeouts para LUKS/LVM
  • Monitorar espaço em /boot e logs de initramfs/GRUB
  • Documentar um 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

Leituras relacionadas para migração, volumes e backups

Se você optar por migrar para outra VPS ou reorganizar volumes após o incidente, estes guias ajudam a fazer isso com segurança e pouca indisponibilidade. Também vale padronizar uma política de backups fora do host.

Perguntas frequentes

Quais passos rápidos tomar quando o Debian não inicia após atualizar o kernel?

Inicialize em modo rescue, monte a partição raiz, faça bind mounts e entre em chroot. Reinstale o GRUB, rode update-grub e update-initramfs -u. Se necessário, instale o kernel anterior, atualize o GRUB e teste a entrada de boot antes de promover.

Reinstalar o Docker apaga meus containers e volumes?

Não ao reinstalar normalmente; sim ao usar purge com remoção de dados. Em geral, /var/lib/docker mantém volumes e camadas. Faça backup de /var/lib/docker e /etc/docker antes de qualquer ação. Evite alterar overlay2 e priorize volumes nomeados e bind mounts.

Como saber se preciso voltar ao kernel anterior?

Se o boot só funciona com o kernel antigo ou há regressões conhecidas, o rollback é o caminho mais seguro. Teste via Advanced options no GRUB. Se estável, promova o antigo a padrão e segure o metapacote até investigar a causa com calma.

Posso copiar o diretório overlay2 para recuperar containers?

Não é recomendado. O overlay2 contém camadas internas não portáveis. Copie apenas volumes e bind mounts com dados da aplicação. Recrie os containers a partir das mesmas imagens e reanexe os volumes ao docker-compose.yml validado.

É obrigatório descriptografar LUKS para reparar o boot?

Sim, se a raiz está sob LUKS, você precisa desbloquear para montar e entrar em chroot. Use cryptsetup luksOpen, ative LVM se aplicável e monte as partições. Depois execute grub-install, update-grub e update-initramfs do ambiente chroot.

Precisa garantir que o servidor volte a operar sem perder dados?

Se quer revisar os passos de recuperação, validar o rollback de kernel ou planejar backups e snapshots antes de novas atualizações, fale comigo para avaliar seu cenário.

Conversar sobre recuperação e prevenção

Veja também