Tutoriales de VPS
Cómo usar el modo de rescate de VPS (2026): Rescue Mode, chroot, fsck y autorrecuperación de GRUB cuando no puedes entrar por SSH
Cuando no puedes entrar por SSH al VPS, el sistema no arranca, olvidaste la contraseña de root, fstab está mal escrito, GRUB está dañado o el sistema de archivos necesita fsck, no siempre hay que reinstalar el sistema. Este artículo explica el flujo real del modo de rescate: primero decidir cuándo entrar en Rescue Mode, luego montar las particiones del sistema original, entrar con chroot para corregir la configuración, restablecer la contraseña de root, reparar GRUB, ejecutar fsck y aclarar qué operaciones conllevan riesgo de datos.
Cómo usar el modo de rescate de VPS (2026): Rescue Mode, chroot, fsck y autorrecuperación de GRUB cuando no puedes entrar por SSH
Cuando un VPS falla, lo que más pánico causa no es un 502 del sitio web, sino no poder entrar por SSH en absoluto. Por ejemplo, modificaste mal /etc/fstab y tras reiniciar el sistema se queda colgado en la pantalla de arranque; o escribiste mal una regla de firewall y te bloqueaste el puerto SSH; o olvidaste la contraseña de root, GRUB está dañado o el sistema de archivos necesita fsck. Estos problemas no se pueden diagnosticar con SSH normal porque el sistema nunca arrancó correctamente.
No reinstales como primera reacción. Muchas consolas de VPS ofrecen Rescue Mode / modo de rescate: arranca desde un sistema temporal, expone el disco del sistema original y te permite reparar el sistema original desde la perspectiva de un "sistema externo". Bien usado, puede recuperar configuración, restablecer contraseñas, reparar entradas de arranque e incluso copiar primero los datos importantes.
El modo de rescate no es tu sistema original ni un simple terminal web. Normalmente es un entorno Linux temporal proporcionado por el proveedor; tras arrancar, presenta el disco original del VPS como un disco de datos.
Puedes entenderlo así:
- El sistema original está roto, así que primero no arranques desde él.
- El proveedor te arranca un sistema mínimo limpio.
- Tú montas el disco original dentro de ese sistema mínimo.
- Luego modificas archivos del sistema original, reparas el arranque y copias datos.
También es distinto de VNC/consola. VNC muestra la pantalla del sistema original; Rescue Mode cambia a un sistema temporal para reparar el disco original. Muchas veces se usan juntos: primero con VNC ves dónde se atasca el arranque, luego entras en modo de rescate para arreglarlo.
Estos escenarios son adecuados para Rescue Mode:
| Escenario | ¿Adecuado? |
|---|---|
| Olvidaste la contraseña SSH, necesitas restablecer la contraseña de root | Sí |
/etc/fstab mal escrito, el sistema no arranca | Sí |
| GRUB / initramfs anómalo, el VPS no entra al sistema | Sí |
| Sistema de archivos dañado, necesita fsck offline | Sí |
| Configuración de firewall/SSH mal escrita, te quedaste fuera | Sí |
| Sitio web 502, error de configuración de Nginx | Normalmente no hace falta; diagnostica primero con SSH normal |
| Disco lleno pero SSH sigue funcionando | No necesariamente; limpia en línea primero |
Una regla simple: si el sistema original todavía es accesible por SSH, prioriza el diagnóstico en línea; si el sistema original no es accesible, no arranca o la partición raíz no se puede reparar de forma segura, considera el modo de rescate.
Primero, haz una instantánea si puedes. El modo de rescate modifica archivos del sistema original; si borras algo por error o realizas fsck incorrectamente, puedes perder datos.
Segundo, revisa primero la consola/VNC. Confirma si el sistema se atasca en el arranque, si es un problema de contraseña, de firewall o del sistema de archivos. No ejecutes fsck a ciegas de inmediato.
Si sospechas una intrusión, conserva primero las pruebas: no reinicies de inmediato, no borres los registros y trata de hacer una instantánea o imagen de disco primero. El modo de rescate cambia el estado de montaje y algunas marcas de tiempo, así que en escenarios forenses hay que ser más cuidadoso.
Los accesos varían según el proveedor, pero los nombres suelen ser similares:
- Rescue Mode
- Boot to rescue
- Recovery mode
- Rescue ISO
- VNC + ISO
Tras activarlo, el VPS se reinicia en el sistema temporal. Algunos proveedores envían la contraseña temporal de root por correo; otros muestran la información de inicio de sesión en la consola. Una vez dentro del sistema de rescate, revisa primero los discos:
lsblk
fdisk -l
Nombres de disco comunes incluyen:
/dev/vda/dev/sda/dev/nvme0n1
Las particiones pueden ser /dev/vda1, /dev/sda1, /dev/nvme0n1p1. No copies los nombres de dispositivo de los tutoriales; confirma primero con lsblk.
Supongamos que la partición raíz es /dev/vda1:
mkdir -p /mnt/sysroot
mount /dev/vda1 /mnt/sysroot
Si el sistema tiene una partición /boot separada, móntala también:
mount /dev/vda2 /mnt/sysroot/boot
Si es LVM, activa primero el grupo de volúmenes:
vgscan
vgchange -ay
lsblk
Luego monta el volumen lógico correspondiente.
Tras montar, confirma que es el sistema original:
ls /mnt/sysroot
cat /mnt/sysroot/etc/os-release
Si puedes ver etc, var, home, usr, básicamente es la raíz del sistema original.
Muchas operaciones de reparación deben ejecutarse en el entorno del sistema original, así que hay que enlazar algunos directorios del 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
Tras entrar, el / que ves es la raíz del sistema original. Ahora puedes cambiar la configuración igual que si iniciaras sesión en el sistema original.
Ejecuta dentro del chroot:
passwd root
Si el sistema ha deshabilitado el inicio de sesión SSH de root, revisa también:
nano /etc/ssh/sshd_config
Fíjate en:
PermitRootLogin
PasswordAuthentication
No dejes el inicio de sesión de root por contraseña habilitado a largo plazo solo por comodidad. Lo más seguro es restablecer, iniciar sesión una vez, reconfigurar las claves y luego deshabilitar el inicio de sesión por contraseña.
Si escribiste mal /etc/fstab, el sistema puede quedarse en emergency mode. Tras entrar en chroot, revisa:
nano /etc/fstab
Para diagnóstico temporal, puedes comentar primero las líneas de montaje sospechosas. Especialmente discos de datos recién añadidos, discos de red, montajes de almacenamiento de objetos y UUID incorrectos.
Ver UUID de particiones:
blkid
Tras confirmar, vuelve a escribir en fstab. No tomes los nombres de dispositivo del sistema de rescate como configuración permanente; es mejor usar UUID.
Ten cuidado con fsck. El principio es: nunca ejecutes fsck en una partición ya montada.
Si ya montaste la partición raíz, sal del chroot y desmonta primero:
exit
umount /mnt/sysroot/run
umount /mnt/sysroot/sys
umount /mnt/sysroot/proc
umount /mnt/sysroot/dev
umount /mnt/sysroot
Luego ejecuta:
fsck -f /dev/vda1
Si estás seguro de querer responder yes automáticamente:
fsck -fy /dev/vda1
Pero para discos de datos importantes, no vayas directo a -y. Lee primero el error y luego decide si reparar automáticamente.
Si en VNC ves grub rescue>, no se encuentra el kernel o el arranque falla tras actualizar el kernel, intenta reinstalar GRUB.
Primero vuelve a montar y entra en 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
Reparación común para arranque BIOS:
grub-install /dev/vda
update-grub
Nota: grub-install normalmente va seguido del disco /dev/vda, no de la partición /dev/vda1.
En máquinas UEFI, las rutas y comandos pueden ser distintos; confirma si la partición EFI está montada en /boot/efi. Si no estás seguro, revisa primero:
lsblk -f
findmnt /boot/efi
Si escribiste mal el puerto SSH, las reglas de firewall o sshd_config, puedes corregirlo en chroot:
nano /etc/ssh/sshd_config
También puedes deshabilitar primero reglas de firewall peligrosas. Por ejemplo, UFW:
ufw disable
Si usas iptables/nftables, el entorno de rescate puede no reflejar completamente el estado de ejecución del sistema original. Lo más fiable es modificar los archivos de reglas o scripts de arranque del sistema original, no solo mirar el entorno temporal actual.
Tras reparar, no hagas clic directamente en reiniciar en el panel; sal y desmonta en orden:
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
Si indica busy, revisa primero quién lo está usando:
lsof +f -- /mnt/sysroot
Tras confirmar que el desmontaje está completo, ve al panel del proveedor, desactiva Rescue Mode, vuelve al arranque desde disco y reinicia el VPS.
Tras arrancar, revisa de inmediato:
systemctl --failed
journalctl -b -p warning
ss -lntp
Confirma que SSH, el sitio web y la base de datos funcionan, luego elimina las contraseñas débiles temporales y restaura el firewall, el grupo de seguridad y los planes de copia de seguridad.
Tu máquina puede ser /dev/vda1, o /dev/sda1 o /dev/nvme0n1p1. Revisa siempre primero lsblk.
Es una de las operaciones erróneas más peligrosas. O desmontas primero, o confirmas que la partición no está montada.
Si no vuelves al arranque desde disco tras reparar, el siguiente arranque entra de nuevo en el sistema de rescate y parece que "no se arregló".
Error 4: dejar abierto el inicio de sesión por contraseña a largo plazo tras restablecer la contraseña de root
Sirve para emergencias, pero no se recomienda a largo plazo. Tras recuperar, reconfigura las claves SSH, deshabilita el inicio de sesión por contraseña y restringe las fuentes de inicio de sesión.
El modo de rescate no es una panacea, pero es el último seguro que todo usuario de VPS debe conocer. Es más adecuado para tres tipos de problemas: fallo de arranque, quedarte fuera y necesidad de reparar archivos del sistema original sin conexión.
El flujo realmente fiable es: revisar primero la consola para diagnosticar el problema, hacer una instantánea, entrar en Rescue Mode, montar el sistema original, usar chroot si es necesario y, tras reparar, desmontar correctamente y volver al arranque desde disco. Mientras no ejecutes fsck -y a ciegas ni borres archivos sin cuidado, la mayoría de los escenarios de "no puedo entrar por SSH, hay que reinstalar" en realidad todavía tienen solución.