Recuperar un servidor inaccesible

Clasifique el fallo antes de actuar

Primero distinga un problema de estado de cuenta de un problema de conectividad. Un estado PROVISIONING o SUSPENDED, una dirección pendiente o un servidor que ha superado su tiempo pagado requiere una respuesta diferente a la de un servidor accesible que rechaza SSH. Registre el mensaje exacto en lugar de resumirlo como caído.

Comprueba desde una segunda red de confianza si es práctico, pero no ejecutes escaneos agresivos. Si la dirección es accesible pero la autenticación falla, confirma el nombre de usuario y la clave privada correspondiente. Si la clave del host cambió sin una reinstalación aprobada, detente y trátalo como un problema de identidad.

Elija la acción más pequeña

No seleccione Apagar a menos que el operador haya acordado cómo se volverá a encender la máquina. El cliente actual API no expone una acción de encendido. La rotación de la contraseña de root también es solo una solicitud en cola y el API no devuelve una contraseña generada, por lo que hoy no es una ruta de recuperación de autoservicio.

1. Capture el estado actual del servidor y todos los identificadores visibles antes de poner en cola cualquier cosa.
2. Si el sistema operativo puede estar simplemente colgado, ponga en cola una solicitud de Reinicio y anote su sufijo de acción.
3. Si se sospecha de la configuración de red o arranque, ponga en cola KVM y pida al operador que proporcione acceso a la consola.
4. Si se requieren medios de rescate, prepara una ISO personalizada confiable y su suma de comprobación, luego coordina su montaje con el operador.
5. Utilice la reinstalación solo cuando la recuperación de datos esté completa o se haya verificado una copia de seguridad independiente.

Proteja los datos durante la recuperación

Prefiera la inspección de solo lectura antes de la reparación. Identifique discos, particiones, sistemas de archivos y puntos de montaje antes de seleccionar un dispositivo. Los nombres pueden diferir tras arrancar desde medios alternativos, especialmente en NVMe y sistemas de almacenamiento multidisco. Si el fallo puede implicar RAID o daños en el sistema de archivos, capture diagnósticos y consulte a un operador cualificado antes de ensamblar matrices o ejecutar herramientas de reparación.

Nunca inicialice un disco, cree un nuevo sistema de archivos, reconstruya una matriz o reinstale simplemente para ver si ayuda. Esas operaciones pueden sobrescribir metadatos necesarios para la recuperación. Mantenga los datos recuperados fuera del servidor afectado y verifíquelos antes de realizar trabajos destructivos.

lsblk --fs
ip -brief address
ip route show
ip -6 route show

Resultado esperado y paquete de escalamiento

Una recuperación exitosa restaura una ruta de administración verificada sin pérdida innecesaria de datos, o produce un plan controlado para restaurar en un sistema limpio. Debido a que las acciones en cola no tienen estado de finalización visible para el cliente, mantenga una línea de tiempo que contenga cada sufijo de acción y la confirmación del operador.

Al escalar, incluya el servidor y la región, la última hora conocida en buen estado en UTC, el estado visible, la red de origen, el error exacto de SSH o de la consola, los cambios recientes, las referencias de acciones y si se ha probado una copia de seguridad fuera del servidor. Excluya contraseñas, claves privadas, códigos de recuperación y URL de consola activas. Si el operador no puede restablecer un acceso seguro, acuerde los límites de captura y borrado de datos antes de reinstalar.