Tutoriais de VPS
Como usar o modo de resgate do VPS (2026): Rescue Mode, chroot, fsck e autorrecuperação do GRUB quando o SSH não entra
Quando o SSH do VPS não entra, o sistema não inicializa, você esqueceu a senha de root, o fstab está errado, o GRUB quebrou ou o sistema de arquivos precisa de fsck, reinstalar o sistema não é a única opção. Este artigo explica o fluxo real do modo de resgate: primeiro decidir quando entrar no Rescue Mode, depois montar as partições do sistema original, entrar com chroot para corrigir a configuração, redefinir a senha de root, reparar o GRUB, rodar fsck e explicar quais operações têm risco de dados.
Como usar o modo de resgate do VPS (2026): Rescue Mode, chroot, fsck e autorrecuperação do GRUB quando o SSH não entra
Quando um VPS dá problema, o que mais causa pânico não é um 502 no site, mas não conseguir entrar por SSH de jeito nenhum. Por exemplo, você configurou errado o /etc/fstab e, após reiniciar, o sistema trava na tela de inicialização; ou escreveu uma regra de firewall errada e bloqueou a própria porta SSH; ou esqueceu a senha de root, o GRUB está danificado ou o sistema de arquivos precisa de fsck. Esses problemas não podem ser diagnosticados com SSH normal porque o sistema nunca subiu corretamente.
Não reinstale como primeira reação. Muitos consoles de VPS oferecem Rescue Mode / modo de resgate: ele inicializa a partir de um sistema temporário, expõe o disco do sistema original e permite reparar o sistema original da perspectiva de um "sistema externo". Bem usado, pode recuperar configurações, redefinir senhas, reparar entradas de inicialização e até copiar dados importantes primeiro.
O modo de resgate não é o seu sistema original nem um simples terminal web. Normalmente é um ambiente Linux temporário fornecido pelo provedor; após inicializar, ele apresenta o disco original do VPS como um disco de dados.
Você pode entender assim:
- O sistema original quebrou, então primeiro não inicialize a partir dele.
- O provedor inicializa um sistema mínimo limpo para você.
- Você monta o disco original dentro desse sistema mínimo.
- Depois modifica arquivos do sistema original, repara a inicialização e copia dados.
Também é diferente do VNC/console. O VNC mostra a tela do sistema original; o Rescue Mode troca para um sistema temporário para reparar o disco original. Muitas vezes os dois são usados juntos: primeiro use o VNC para ver onde a inicialização travou, depois entre no modo de resgate para corrigir.
Estes cenários são adequados para o Rescue Mode:
| Cenário | Adequado? |
|---|---|
| Esqueceu a senha SSH, precisa redefinir a senha de root | Sim |
/etc/fstab errado, o sistema não inicializa | Sim |
| GRUB / initramfs anormal, o VPS não entra no sistema | Sim |
| Sistema de arquivos corrompido, precisa de fsck offline | Sim |
| Configuração de firewall/SSH errada, você se trancou para fora | Sim |
| Site com 502, erro de configuração do Nginx | Normalmente não precisa; diagnostique primeiro com SSH normal |
| Disco cheio, mas o SSH ainda funciona | Não necessariamente; limpe online primeiro |
Uma regra simples: se o sistema original ainda pode ser acessado por SSH, priorize o diagnóstico online; se o sistema original não pode ser acessado, não inicializa ou a partição raiz não pode ser reparada com segurança, considere o modo de resgate.
Primeiro, faça um snapshot se puder. O modo de resgate modifica arquivos do sistema original; se você apagar algo por engano ou executar fsck incorretamente, pode perder dados.
Segundo, verifique primeiro o console/VNC. Confirme se o sistema trava na inicialização, se é problema de senha, de firewall ou de sistema de arquivos. Não saia executando fsck às cegas de imediato.
Se suspeitar de invasão, preserve primeiro as evidências: não reinicie imediatamente, não apague os logs e tente fazer um snapshot ou imagem de disco primeiro. O modo de resgate altera o estado de montagem e alguns timestamps, então em cenários forenses é preciso ter mais cuidado.
Os acessos variam conforme o provedor, mas os nomes costumam ser parecidos:
- Rescue Mode
- Boot to rescue
- Recovery mode
- Rescue ISO
- VNC + ISO
Após ativar, o VPS reinicia no sistema temporário. Alguns provedores enviam a senha temporária de root por e-mail; outros mostram as informações de login no console. Depois de entrar no sistema de resgate, verifique primeiro os discos:
lsblk
fdisk -l
Nomes comuns de disco incluem:
/dev/vda/dev/sda/dev/nvme0n1
As partições podem ser /dev/vda1, /dev/sda1, /dev/nvme0n1p1. Não copie os nomes de dispositivo dos tutoriais; confirme primeiro com lsblk.
Suponha que a partição raiz seja /dev/vda1:
mkdir -p /mnt/sysroot
mount /dev/vda1 /mnt/sysroot
Se o sistema tiver uma partição /boot separada, monte também:
mount /dev/vda2 /mnt/sysroot/boot
Se for LVM, ative primeiro o grupo de volumes:
vgscan
vgchange -ay
lsblk
Depois monte o volume lógico correspondente.
Após montar, confirme se é o sistema original:
ls /mnt/sysroot
cat /mnt/sysroot/etc/os-release
Se você conseguir ver etc, var, home, usr, é basicamente a raiz do sistema original.
Muitas operações de reparo precisam ser executadas no ambiente do sistema original, então é preciso vincular alguns diretórios do sistema:
mount --bind /dev /mnt/sysroot/dev
mount --bind /proc /mnt/sysroot/proc
mount --bind /sys /mnt/sysroot/sys
mount --bind /run /mnt/sysroot/run
chroot /mnt/sysroot /bin/bash
Após entrar, o / que você vê é a raiz do sistema original. Agora você pode alterar a configuração como se estivesse logado no sistema original.
Execute dentro do chroot:
passwd root
Se o sistema desabilitou o login SSH de root, verifique também:
nano /etc/ssh/sshd_config
Observe:
PermitRootLogin
PasswordAuthentication
Não deixe o login de root por senha habilitado a longo prazo só por conveniência. O mais seguro é redefinir, fazer login uma vez, reconfigurar as chaves e depois desabilitar o login por senha.
Se você configurou errado o /etc/fstab, o sistema pode travar no emergency mode. Após entrar no chroot, verifique:
nano /etc/fstab
Para diagnóstico temporário, você pode comentar primeiro as linhas de montagem suspeitas. Especialmente discos de dados recém-adicionados, discos de rede, montagens de armazenamento de objetos e UUIDs incorretos.
Ver UUIDs de partição:
blkid
Após confirmar, grave de volta no fstab. Não trate os nomes de dispositivo do sistema de resgate como configuração permanente; prefira UUIDs.
Tenha cuidado com fsck. O princípio é: nunca execute fsck em uma partição já montada.
Se você já montou a partição raiz, saia do chroot e desmonte primeiro:
exit
umount /mnt/sysroot/run
umount /mnt/sysroot/sys
umount /mnt/sysroot/proc
umount /mnt/sysroot/dev
umount /mnt/sysroot
Depois execute:
fsck -f /dev/vda1
Se tiver certeza de que quer responder yes automaticamente:
fsck -fy /dev/vda1
Mas, para discos de dados importantes, não vá direto para -y. Leia primeiro o erro e depois decida se repara automaticamente.
Se no VNC você vê grub rescue>, o kernel não é encontrado ou a inicialização falha após atualizar o kernel, tente reinstalar o GRUB.
Primeiro remonte e entre no chroot:
mount /dev/vda1 /mnt/sysroot
mount --bind /dev /mnt/sysroot/dev
mount --bind /proc /mnt/sysroot/proc
mount --bind /sys /mnt/sysroot/sys
mount --bind /run /mnt/sysroot/run
chroot /mnt/sysroot /bin/bash
Reparo comum para inicialização BIOS:
grub-install /dev/vda
update-grub
Atenção: grub-install normalmente é seguido do disco /dev/vda, não da partição /dev/vda1.
Em máquinas UEFI, os caminhos e comandos podem ser diferentes; confirme se a partição EFI está montada em /boot/efi. Se não tiver certeza, verifique primeiro:
lsblk -f
findmnt /boot/efi
Se você configurou errado a porta SSH, as regras de firewall ou o sshd_config, pode corrigir no chroot:
nano /etc/ssh/sshd_config
Também pode desabilitar primeiro regras de firewall perigosas. Por exemplo, UFW:
ufw disable
Se você usa iptables/nftables, o ambiente de resgate pode não refletir completamente o estado de execução do sistema original. O mais confiável é modificar os arquivos de regras ou scripts de inicialização do sistema original, e não apenas olhar o ambiente temporário atual.
Após reparar, não clique direto em reiniciar no painel; saia e desmonte na ordem:
exit
umount /mnt/sysroot/run
umount /mnt/sysroot/sys
umount /mnt/sysroot/proc
umount /mnt/sysroot/dev
umount /mnt/sysroot/boot 2>/dev/null
umount /mnt/sysroot
Se indicar busy, verifique primeiro quem está usando:
lsof +f -- /mnt/sysroot
Após confirmar que a desmontagem terminou, vá ao painel do provedor, desative o Rescue Mode, volte para a inicialização pelo disco e reinicie o VPS.
Após inicializar, verifique imediatamente:
systemctl --failed
journalctl -b -p warning
ss -lntp
Confirme que SSH, o site e o banco de dados estão funcionando, depois remova as senhas fracas temporárias e restaure o firewall, o grupo de segurança e os planos de backup.
Sua máquina pode ser /dev/vda1, ou /dev/sda1 ou /dev/nvme0n1p1. Sempre verifique primeiro lsblk.
É uma das operações erradas mais perigosas. Ou desmonte primeiro, ou confirme que a partição não está montada.
Se você não voltar para a inicialização pelo disco após reparar, a próxima inicialização ainda entra no sistema de resgate, parecendo que "não foi corrigido".
Serve para emergências, mas não é recomendado a longo prazo. Após recuperar, reconfigure as chaves SSH, desabilite o login por senha e restrinja as origens de login.
O modo de resgate não é uma panaceia, mas é o último seguro que todo usuário de VPS precisa conhecer. Ele é mais adequado para três tipos de problema: falha de inicialização, você se trancar para fora e necessidade de reparar arquivos do sistema original offline.
O fluxo realmente confiável é: verificar primeiro o console para diagnosticar o problema, fazer um snapshot, entrar no Rescue Mode, montar o sistema original, usar chroot se necessário e, após reparar, desmontar corretamente e voltar para a inicialização pelo disco. Desde que você não execute fsck -y às cegas nem apague arquivos sem cuidado, a maioria dos cenários de "não consigo entrar por SSH, só resta reinstalar" na verdade ainda tem solução.