Recuperar um servidor inacessível

Classifique a falha antes de agir

Primeiro distinga um problema de estado da conta de um problema de conectividade. Um estado PROVISIONING ou SUSPENDED, um endereço Pendente, ou um servidor além do seu tempo pago requer uma resposta diferente de um servidor acessível que rejeita SSH. Registe a mensagem exata em vez de a resumir como em baixo.

Verifique a partir de uma segunda rede de confiança, se prático, mas não execute análises agressivas. Se o endereço estiver acessível, mas a autenticação falhar, confirme o nome de utilizador e a chave privada correspondente. Se a chave do anfitrião mudou sem uma reinstalação aprovada, pare e trate-o como um problema de identidade.

Escolha a ação mais pequena

Não selecione Desligar a menos que o operador tenha acordado como a máquina será ligada novamente. O cliente atual API não expõe uma ação de ligar. A rotação da palavra-passe root também é apenas um pedido em fila e o API não devolve uma palavra-passe gerada, pelo que não é hoje um caminho de recuperação self-service.

1. Capture o estado atual do servidor e todos os identificadores visíveis antes de colocar algo na fila.
2. Se o sistema operativo puder simplesmente estar bloqueado, coloque em fila um pedido de Reinício e anote o sufixo da ação.
3. Se a configuração de rede ou de arranque for suspeita, coloque em fila KVM e peça ao operador para fornecer acesso à consola.
4. Se for necessário suporte de recuperação, prepare uma ISO personalizada fiável e a soma de verificação, e depois coordene a sua montagem com o operador.
5. Use a reinstalação apenas quando a recuperação de dados estiver concluída ou um backup independente tiver sido verificado.

Proteja os dados durante a recuperação

Prefira a inspeção só de leitura antes da reparação. Identifique discos, partições, sistemas de ficheiros e pontos de montagem antes de selecionar um dispositivo. Os nomes podem diferir após arrancar de suportes alternativos, especialmente em NVMe e sistemas de armazenamento com vários discos. Se a falha puder envolver RAID ou danos no sistema de ficheiros, capture diagnósticos e consulte um operador qualificado antes de montar conjuntos ou executar ferramentas de reparação.

Nunca inicialize um disco, crie um novo sistema de ficheiros, reconstrua um array ou reinstale apenas para ver se ajuda. Essas operações podem sobrescrever metadados necessários para a recuperação. Mantenha os dados recuperados fora do servidor afetado e verifique-os antes de trabalho destrutivo.

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

Resultado esperado e pacote de escalonamento

Uma recuperação bem-sucedida restaura um caminho de administração verificado sem perda desnecessária de dados, ou produz um plano controlado para restaurar num sistema limpo. Como as ações em fila não têm estado de conclusão visível para o cliente, mantenha uma linha cronológica contendo cada sufixo de ação e a confirmação do operador.

Ao escalar, inclua o servidor e a região, a última hora conhecida em UTC, o estado visível, a rede de origem, o erro exato de SSH ou da consola, alterações recentes, referências de ações e se foi testada uma cópia de segurança fora do servidor. Exclua palavras-passe, chaves privadas, códigos de recuperação e URLs de consola ativas. Se o operador não conseguir restaurar o acesso seguro, acorde os limites de captura e eliminação de dados antes de reinstalar.