Puesta en marcha del sistema Hetzner Rescue - guía paso a paso para administradores de servidores

Le mostraré cómo iniciar el sistema de rescate hetzner en sólo unos minutos, cómo SSH conéctese e introduzca su Servidor reparación de forma selectiva. Esta guía le lleva paso a paso desde la activación hasta la recuperación, incluyendo comprobaciones del sistema de archivos, copias de seguridad y reinstalación.

Puntos centrales

Los siguientes aspectos clave le ayudarán a ponerse en marcha y trabajar en modo rescate sin rodeos.

• Inicio del rescateActivación en Robot o Nube, luego reiniciar.
• Acceso SSHInicie sesión con clave o contraseña y derechos de root.
• Análisis de erroresComprueba fsck, logs, particiones.
• Copia de seguridad de datos: rsync, tar, scp para copias de seguridad rápidas.
• Nueva instalacióninstallimage para sistemas frescos.

Qué hace el Sistema de Rescate

El sistema de rescate carga un entorno Linux independiente en la memoria de trabajo y me proporciona acceso inmediato al Raíz-acceso, incluso si el Sistema operativo falla. Arranco independientemente de cargadores de arranque defectuosos, paquetes dañados o configuraciones defectuosas. Esto me permite comprobar sistemas de archivos, recuperar datos, analizar registros y reiniciar servicios. El entorno sigue siendo sencillo, pero ofrece todas las herramientas importantes para el diagnóstico y la recuperación. Esto me permite mantener el control, incluso si el sistema normal se cae por completo.

Lo práctico es que el entorno de rescate es deliberadamente volátil: los cambios desaparecen tras el reinicio, lo que significa que puedo hacer pruebas con seguridad. Si es necesario, instalo herramientas temporales (por ejemplo, smartmontools, mdadm, lvm2, btrfs-progs o xfsprogs) sin cambiar el sistema productivo. La versión del kernel es moderna y soporta el hardware más reciente, incluyendo NVMe, UEFI, GPT, RAID por software (mdraid), LVM y encriptación LUKS. Esto me permite cubrir incluso configuraciones de almacenamiento complejas y aislar incluso patrones de error raros de forma reproducible.

Requisitos y acceso

Para empezar, necesito acceder a la interfaz de cliente y a mi Claves SSH o un contraseña. Gestiono sistemas dedicados cómodamente a través del Robot Hetznermientras que yo controlo instancias en la nube a través de la consola. Ambas interfaces ofrecen una opción clara para activar el modo de rescate. Compruebo de antemano la IP correcta del servidor, la disponibilidad de IPv6 y, si es necesario, las funciones fuera de banda para el restablecimiento. Esta preparación acorta significativamente el tiempo de inactividad.

Cuando me conecto a SSH por primera vez, confirmo conscientemente la nueva huella digital y actualizo mi entrada de hosts conocidos si es necesario para que las conexiones posteriores no fallen debido a advertencias. Para los equipos, almaceno claves adicionales específicamente para la operación de rescate y las vuelvo a eliminar una vez finalizada. Si sólo dispongo de una contraseña temporal, la cambio inmediatamente después de conectarme y luego la sustituyo por Key-Auth - desactivo sistemáticamente los inicios de sesión con contraseña al final del trabajo.

Activación del sistema de rescate - paso a paso

Abro la ventana de detalles del servidor, selecciono la opción "Rescate" y establezco la arquitectura en linux64 para los sistemas actuales, entonces deposito mi Clave SSH. Dependiendo de la situación, sólo inicio el modo de rescate y activo el reinicio por separado o utilizo "Activar Rescate y Ciclo de Energía" para un reinicio directo. Si la máquina se cuelga, realizo un hard reset a través de la interfaz. Tras el arranque, la interfaz muestra una contraseña temporal de root si no he introducido ninguna clave. En cuanto el servidor arranca, responde a SSH y puedo empezar.

En situaciones complejas, planifico una secuencia clara: activar, apagar y encender, probar el inicio de sesión SSH y, a continuación, empezar a solucionar problemas. Un ciclo de encendido manual puede ser más necesario en servidores dedicados, mientras que las instancias en la nube suelen cambiar al modo de rescate inmediatamente. Importante: Tras una reparación satisfactoria, vuelvo a desactivar el modo de rescate para que la máquina se reinicie desde el disco duro local.

Conexión SSH y primeras comprobaciones

Me conecto a través de SSH con ssh root@ y compruebe primero la red, los soportes de datos y los registros para obtener una visión rápida de la Estado. Con ip a y ping Compruebo la disponibilidad; journalctl --no-pager -xb o los archivos de registro de los discos montados muestran los últimos mensajes de error. Los comandos lsblk, blkid y fdisk -l aportan claridad sobre la disposición y los sistemas de archivos. Para RAID utilizo cat /proc/mdstat y mdadm --detail para la condición. Para los indicadores de hardware iniciales smartctl -a y un corto hdparm -Tt-prueba.

LVM, RAID, LUKS y sistemas de archivos especiales

Muchos servidores utilizan LVM, RAID por software o cifrado. Primero activo todas las capas relevantes:

• mdraid: mdadm --assemble --scan muestra las matrices existentes; compruebo el estado con cat /proc/mdstat.
• LUKS: Abro volúmenes encriptados con cryptsetup luksOpen /dev/.
• LVMCon vgscan y vgchange -ay Activo los grupos de volumen y los veo a través de lvs/vgs/pvs.

Con Btrfs, presto atención a los subvolúmenes y monto específicamente con -o subvol=@ respectivamente -o subvolid=5 para el nivel superior. Compruebo XFS con xfs_repair (nunca en volúmenes montados), mientras que Ext4 se utiliza clásicamente con fsck.ext4 -f se reorganiza. Me oriento por el GUID/UUID de blkidporque los nombres de dispositivo para NVMe (/dev/nvme0n1p1) y puede variar con el cambio de orden. Corregiré el /etc/fstab.

Reparación del sistema de archivos y copia de seguridad de datos

Antes de reparar, hago una copia de seguridad Datos con rsync, scp o alquitrán a un objetivo externo o a un objetivo local Copia de seguridad-directorio. Para las comprobaciones utilizo fsck sólo en particiones desmontadas, por ejemplo fsck -f /dev/sda2para corregir las incoherencias limpiamente. A continuación, monto el sistema en /mntpor ejemplo con mount /dev/sda2 /mnty adjuntar sub-rutas como /proc, /sys y /dev cuando quiero hacer chroot. Los archivos de configuración individuales como /etc/fstab o ajustes de red directamente en el sistema montado. Procediendo con cuidado, evito daños consecuentes y minimizo el tiempo de inactividad.

Para hacer copias de seguridad fiables, confío en comandos repetibles: rsync -aHAX --info=progreso2 recibe derechos, hardlinks, ACLs y xattrs. Si la línea es débil, acelero con --bwlimit y paralelizar la compresión con tar -I pigz. Si es necesario, hago una imagen de los soportes de datos críticos y defectuosos en bloques con ddrescue para trasladar el trabajo lógico a una imagen. Compruebo cuidadosamente los sistemas Btrfs con btrfs check --readonly y utilizar btrfs scrubpara detectar errores silenciosos. XFS a menudo requiere una reparación fuera de montaje en caso de incoherencias (xfs_repair) - Siempre hago primero una copia de seguridad de la partición.

Reparación de UEFI/BIOS, GPT/MBR y bootloader

Muchos problemas de arranque son causados por la interacción del firmware, el esquema de particiones y el gestor de arranque. Primero aclaro si el servidor arranca en modo UEFI o en modo BIOS heredado (ls /sys/firmware/efi). Con UEFI monto la partición EFI (típico /dev/sdX1 o /dev/nvme0n1p1) a /mnt/boot/efi. Entonces chrooteo en el sistema:

mount /dev/ /mnt
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt /bin/bash

Reinstalo el gestor de arranque adecuadamente (grub-install al dispositivo correcto) y regenerar la configuración e initramfs: actualizar-grub y update-initramfs -u -k todos (para sistemas basados en dracut dracut -f). Si el orden de los dispositivos no es correcto, utilizo la función /etc/default/grub UUID y comprobar /etc/fstab para las entradas correctas. Al cambiar GPT/MBR, compruebo si existe una partición de arranque BIOS (para GRUB/BIOS) o una partición de sistema EFI válida.

Peligros de la red en Rescue

Los problemas de red suelen ser la causa de que los servicios "desaparezcan". En Rescue compruebo el estado del enlace (enlace ip), rutas (ip r) y la resolución DNS (estado de resolvectl respectivamente cat /etc/resolv.conf). Pruebo IPv4 e IPv6 por separado (ping -4/ping -6). Para servidores con puentes o bonding, el orden de las interfaces en el sistema productivo puede diferir del entorno de rescate. Tomo nota de las direcciones MAC y las mapeo correctamente. Si el sistema productivo utiliza Netplan, verifico el /etc/netplan/*.yaml y a su vez después de la chroot netplan generar y netplan aplicar en. Para los clásicos /etc/red/interfaces-configuración, presto atención a la coherencia de los nombres de las interfaces (nombres predecibles frente a. eth0).

Reinstalar el sistema operativo

Si las reparaciones ya no tienen sentido, reinicio el sistema con installimage completamente nuevo y ahorrar así valiosos Tiempo. La herramienta me guía a través de la selección de la distribución, el particionado y el gestor de arranque. Incluyo mis propios archivos de configuración y claves SSH en la instalación para que el primer arranque se realice sin problemas. Tras la instalación, arranco el servidor normalmente y compruebo los servicios, el cortafuegos y las actualizaciones. Por último, quito el modo de rescate para que el siguiente arranque se realice de nuevo desde el soporte de datos local.

En las nuevas instalaciones utilizo deliberadamente montajes basados en UUID para descartar problemas posteriores de orden de dispositivos. Para las instalaciones RAID, tengo las matrices creadas desde el principio y compruebo el estado de la reconstrucción antes de restaurar los datos. Si despliegas sistemas similares de forma recurrente, trabajas con plantillas de imágenes de instalación predefinidas y una lógica de particionado clara (raíz, partición de datos independiente, swap, EFI si es necesario). Tras el primer arranque, actualizo las fuentes de los paquetes y los kernels, activo las actualizaciones automáticas de seguridad y aplico mis medidas básicas de refuerzo.

Seguridad, ventana temporal y recaída

El acceso se realiza exclusivamente a través de SSHpor lo que confío constantemente en Claves en lugar de contraseñas estáticas. El modo de rescate permanece listo durante un tiempo limitado tras la activación y vuelve al dispositivo de arranque local en el siguiente reinicio normal. Trabajo con rapidez, documento cada paso y mantengo una segunda sesión abierta para intervenciones mayores. No escribo datos sensibles en los historiales de bash y borro los archivos temporales después de su uso. Tras una recuperación satisfactoria, vuelvo a desactivar el modo en la interfaz.

Tras reactivar el sistema productivo, roturo los datos de acceso, elimino las claves de rescate temporales, restablezco las contraseñas raíz superfluas y hago copias de seguridad de las configuraciones recién generadas. Recopilo información de auditoría (quién hizo qué y cuándo) y documento las desviaciones de la configuración estándar. Así evito que las medidas de emergencia se conviertan en permanentes y cumplo los requisitos de conformidad.

Ejemplo: Rescate del servidor WordPress

Arranco en modo rescate, monto la partición del sistema y hago una copia de seguridad del Base de datos por mysqldump y el wp-contenido-directorio con alquitrán o rsync. A continuación, compruebo el sistema de archivos, reinicio el gestor de arranque y corrijo las configuraciones incorrectas de PHP o NGINX. Si los paquetes están dañados, uso chroot y reinstalo las dependencias. Si eso no es suficiente, reinicio la máquina con installimage y restauro la copia de seguridad y las configuraciones. Por último, verifico el frontend, el inicio de sesión y los cronjobs.

En la práctica, presto atención a la coherencia de InnoDB (MySQL/MariaDB): Fallos mysqld al principio, aseguro el /var/lib/mysql y ejecuto el volcado desde una instancia nueva. Vacío las cachés (caché de objetos, caché de páginas, OPCache) de forma selectiva, establezco los permisos de los archivos de forma coherente (find . -type d -exec chmod 755 {} ;, find . -type f -exec chmod 644 {} ;) y compruebe open_basedir y directorios de carga. Desactivo los plugins críticos como prueba renombrando el directorio de plugins. Después compruebo los pools de PHP FPM, los tiempos de espera de FastCGI, los límites de memoria y los includes de NGINX/Apache. Un breve wp cron event run --due-now (si WP-CLI está disponible) ayuda a procesar los atrasos.

Buenas prácticas para administradores

Antes de las intervenciones profundas, creo un Copia de seguridad y archivos clave seguros como /etcpara poder volver atrás en cualquier momento. Cada paso se registra brevemente, lo que me ayuda más tarde con auditorías o nuevos incidentes. Tras reiniciar el sistema productivo, compruebo a fondo los servicios, los registros, la red y la supervisión. Para las tareas recurrentes, creo un pequeño conjunto de scripts para estandarizar las secuencias de comandos. Si estás planificando un rendimiento adicional o un nuevo hardware, puedes crear los adecuados Alquilar un servidor raíz y la ventana de migración.

También tengo preparada una lista de comprobación del libro de ruta, que contiene las responsabilidades y las vías de escalada. Los "días de juego" planificados (simulaciones de fallos específicos) entrenan al equipo para emergencias. Pruebo regularmente las copias de seguridad como muestra de restauración: una copia de seguridad no probada se considera inexistente. Y versiono las configuraciones de mis sistemas para poder reconocer rápidamente las diferencias entre el estado "bueno" y el "defectuoso".

Nube frente a dedicado: diferencias en el proceso

En la nube, a menudo cambio el modo de arranque directamente en el diálogo de la instancia y utilizo la consola serie para comprobaciones rápidas, mientras que en los servidores dedicados es necesario un ciclo de alimentación y posiblemente un acceso fuera de banda. Los volúmenes en la nube pueden adjuntarse cómodamente a otras instancias, una forma eficaz de realizar copias de seguridad de los datos sin tiempo de inactividad en el host afectado. En los bare metal, presto más atención al orden físico de las unidades, especialmente cuando adquiero módulos SSD/NVMe adicionales. En ambos mundos: Rescue es una herramienta temporal - planifico el camino de vuelta al arranque normal con tiempo.

Comparación: proveedores con sistema de rescate

Además de una buena calidad de trabajo, una rápida recuperación Hardware también un Rescate-características. La siguiente tabla ofrece una visión general compacta de la gama de funciones y manejo. Me he basado en la disponibilidad, la facilidad de acceso y los flujos de trabajo típicos de los administradores. La calificación "Recomendación" refleja mi uso práctico para fallos típicos. Por supuesto, la ponderación puede variar en función del uso previsto.

Proveedor	Sistema de rescate disponible	Facilidad de uso	Actuación	Recomendación
webhoster.de	Sí	Muy buena	Muy alta	Ganador de la prueba
Hetzner	Sí	Muy buena	Alta
Strato	Parcialmente	Bien	Medio
IONOS	No	Medio	Medio

Lista de control: Secuencia de pasos en caso de emergencia

• Activar Rescue, activar reinicio/ciclo de encendido, probar SSH.
• Ver hardware/almacenamiento: smartctl, lsblk, blkid, mdstat, lvm.
• Activar arrays/LUKS/LVM, inspeccionar sistemas de archivos de sólo lectura.
• Crear una copia de seguridad (rsync/tar), luego fsck/Reparaciones.
• Sistema bajo /mnt mount, bind mounts, chroot.
• Reparar bootloader/initramfs, comprobar configuración de red.
• Probar arranque, verificar servicios, comprobar monitorización/alarmas.
• Desactivar Rescue, eliminar claves temporales, actualizar la documentación.

FAQ Sistema de rescate Hetzner

¿Puedo utilizar mi Datos ¿rescate si el sistema ya no arranca? Sí, leo los soportes de datos directamente en el modo de rescate y hago copias de seguridad de los datos importantes. Carpeta o particiones enteras.

¿Cuánto tiempo permanece activo el modo de rescate? Tras la activación, el sistema está disponible durante un tiempo limitado y vuelve al sistema local en el siguiente reinicio normal. Barco-dispositivo, por lo que estoy planeando una rápida Procedimiento.

¿Funciona para servidores dedicados y en la nube? Sí, inicio el modo tanto para máquinas dedicadas como para instancias en la nube en el botón Nube de Hetzner.

¿Qué hago si el gestor de arranque está dañado? Monto root y posiblemente EFI, chroot en el sistema, ejecutar grub-install, actualizar-grub y una reconstrucción del initramf, luego pruebo el reinicio.

¿Cómo manejo LVM/RAID? Primero monto mdraid, activo LVM con vgchange -ay y, a continuación, montar los volúmenes lógicos. Las reparaciones sólo tienen lugar después de una copia de seguridad.

¿Puedo guardar sólo archivos individuales? Sí, monto sólo lectura y copio selectivamente configuraciones, bases de datos (mediante volcado) o directorios - mínimamente invasivo y rápido.

Mensaje central

Con el Hetzner Rescue System, tengo una herramienta rápida que identifica con fiabilidad problemas de arranque, errores del sistema de archivos y configuraciones dañadas. Activo el modo, inicio sesión por SSH, hago una copia de seguridad de los datos y luego decido entre reparar o reinstalar. Esto ahorra Tiempo en caso de emergencia y reduce el tiempo de inactividad al mínimo. Si interioriza estos pocos pasos, podrá gestionar con calma incluso las interrupciones difíciles. Así se puede planificar el funcionamiento del servidor y controlar el reinicio.