Iniciar o Hetzner Rescue System - guia passo-a-passo para administradores de servidores

Vou mostrar-lhe como iniciar o sistema de resgate hetzner em apenas alguns minutos, como SSH inicie sessão e introduza o seu Servidor reparação de uma forma direcionada. Este guia leva-o passo a passo desde a ativação até à recuperação, incluindo verificações do sistema de ficheiros, cópias de segurança e reinstalação.

Pontos centrais

Os seguintes aspectos fundamentais ajudá-lo-ão a começar e a trabalhar em modo de recuperação sem quaisquer desvios.

• Início do resgateAtivação no Robot ou na Nuvem e, em seguida, reinicialização.
• Acesso SSHIniciar sessão com chave ou palavra-passe e direitos de root.
• Análise de errosVerificar o fsck, os registos e as partições.
• Cópia de segurança dos dadosrsync, tar, scp para backups rápidos.
• Nova instalaçãoinstallimage para sistemas novos.

O que faz o Rescue System

O Rescue System carrega um ambiente Linux independente na memória de trabalho e dá-me acesso imediato ao Raiz-acesso, mesmo que o Sistema operativo falha. Arranco independentemente de carregadores de arranque defeituosos, pacotes danificados ou configurações defeituosas. Isto permite-me verificar os sistemas de ficheiros, recuperar dados, analisar registos e reiniciar serviços. O ambiente permanece simples, mas oferece todas as ferramentas importantes para diagnóstico e recuperação. Isto permite-me manter o controlo, mesmo que o sistema normal fique completamente em baixo.

O que é prático é que o ambiente de recuperação é deliberadamente volátil: as alterações desaparecem após a reinicialização, o que significa que posso testar com segurança. Se necessário, instalo ferramentas temporárias (por exemplo, smartmontools, mdadm, lvm2, btrfs-progs ou xfsprogs) sem alterar o sistema produtivo. A versão do kernel é moderna e suporta o hardware mais recente, incluindo NVMe, UEFI, GPT, RAID de software (mdraid), LVM e encriptação LUKS. Isso me permite cobrir até mesmo configurações de armazenamento complexas e isolar até mesmo padrões de erro raros de forma reproduzível.

Requisitos e acesso

Para começar, preciso de aceder à interface do cliente e à minha Chaves SSH ou um temporário palavra-passe. Gerencio sistemas dedicados de forma cómoda através do Robô Hetznerenquanto eu controlo as instâncias na nuvem através da consola. Ambas as interfaces oferecem uma opção clara para ativar o modo de recuperação. Verifico antecipadamente o IP correto do servidor, a disponibilidade do IPv6 e, se necessário, as funções fora de banda para a reposição. Esta preparação reduz significativamente o tempo de inatividade.

Quando inicio sessão no SSH pela primeira vez, confirmo conscientemente a nova impressão digital e actualizo a minha entrada de anfitriões conhecidos, se necessário, para que as ligações subsequentes não falhem devido a avisos. Para as equipas, guardo chaves adicionais especificamente para a operação de salvamento e retiro-as novamente após a conclusão. Se apenas estiver disponível uma palavra-passe temporária, altero-a imediatamente após o início de sessão e substituo-a pelo Key-Auth - desativo sistematicamente os inícios de sessão com palavra-passe no final do trabalho.

Ativar o sistema de salvamento - passo a passo

Abro a janela de detalhes do servidor, selecciono a opção "Rescue" e defino a arquitetura para linux64 para os sistemas actuais, depois deposito o meu Chave SSH. Dependendo da situação, apenas inicio o modo de recuperação e desencadeio a reinicialização separadamente ou utilizo "Activate Rescue & Power Cycle" para uma reinicialização direta. Se a máquina ficar suspensa, efectuo um hard reset através da interface. Após o arranque, a interface mostra uma palavra-passe de raiz temporária se não tiver introduzido uma chave. Assim que o servidor arranca, responde ao SSH e posso começar a trabalhar.

Em situações complexas, planeio uma sequência clara: Ativar, ciclo de energia, testar o início de sessão SSH e, em seguida, iniciar a resolução de problemas. Um ciclo de energia manual pode ser mais necessário em servidores dedicados, enquanto as instâncias de nuvem geralmente mudam para o modo de recuperação imediatamente. Importante: Após uma reparação bem sucedida, desligo novamente o modo de recuperação para que a máquina reinicie a partir do disco rígido local.

Ligação SSH e primeiras verificações

Eu ligo-me através de SSH com ssh root@ e, em primeiro lugar, verificar a rede, os suportes de dados e os registos para obter uma visão geral rápida do Estado. Com ip a e ping Verifico a disponibilidade; journalctl --no-pager -xb ou ficheiros de registo nos discos montados mostram as mensagens de erro mais recentes. Os comandos lsblk, blkid e fdisk -l clarificar a disposição e os sistemas de ficheiros. Para RAID eu uso cat /proc/mdstat e mdadm --detalhe para a condição. Para os indicadores de hardware iniciais smartctl -a e uma curta hdparm -Tt-teste.

LVM, RAID, LUKS e sistemas de ficheiros especiais

Muitos servidores utilizam LVM, software RAID ou encriptação. Começo por ativar todos os níveis relevantes:

• mdraid: mdadm --assemble --scan mostra as matrizes existentes; verifico o estado com cat /proc/mdstat.
• LUKS: abro volumes encriptados com cryptsetup luksOpen /dev/.
• LVMCom vgscan e vgchange -ay Activei os grupos de volumes e vejo-os através de lvs/vgs/pvs.

Com o Btrfs, presto atenção aos subvolumes e monto especificamente com -o subvol=@ respetivamente -o subvolid=5 para o nível superior. Verifico o XFS com xfs_repair (nunca em volumes montados), enquanto o Ext4 é classicamente utilizado com fsck.ext4 -f é reorganizado. Oriento-me pelo GUID/UUID de blkidporque os nomes de dispositivos para NVMe (/dev/nvme0n1p1) e pode variar consoante a alteração da encomenda. Corrigirei o /etc/fstab.

Reparação do sistema de ficheiros e cópia de segurança de dados

Antes de reparar, faço cópias de segurança importantes Dados com rsync, scp ou alcatrão para um destino externo ou um destino local Cópia de segurança-diretório. Para os controlos, utilizo fsck apenas em partições não montadas, por exemplo fsck -f /dev/sda2para corrigir as inconsistências de forma limpa. De seguida, monto o sistema em /mntpor exemplo, com montar /dev/sda2 /mnte anexar sub-caminhos como /proc, /sys e /dev quando eu quero fazer chroot. Ficheiros de configuração individuais, tais como /etc/fstab ou definições de rede diretamente no sistema montado. Ao proceder com cuidado, evito danos consequentes e minimizo o tempo de inatividade.

Para obter cópias de segurança fiáveis, confio em comandos repetíveis: rsync -aHAX --info=progress2 recebe direitos, hardlinks, ACLs e xattrs. Se a linha for fraca, eu estrangulo com --bwlimit e paralelizar a compressão com tar -I pigz. Se necessário, faço a imagem de suportes de dados críticos e defeituosos em blocos com ddrescue para transferir o trabalho lógico para uma imagem. Verifico cuidadosamente os sistemas Btrfs com btrfs check --readonly e utilizar depuração btrfspara detetar erros silenciosos. O XFS frequentemente requer um reparo fora da montagem no caso de inconsistências (xfs_repair) - Faço sempre uma cópia de segurança da partição primeiro.

UEFI/BIOS, GPT/MBR e reparação do carregador de arranque

Muitos problemas de arranque são causados pela interação entre o firmware, o esquema de partições e o gestor de arranque. Primeiro, esclareço se o servidor inicia no modo UEFI ou no modo BIOS legado (ls /sys/firmware/efi). Com UEFI eu monto a partição EFI (típica /dev/sdX1 ou /dev/nvme0n1p1) para /mnt/boot/efi. Em seguida, introduzo o sistema:

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

Reinstalo o carregador de arranque de forma adequada (grub-instalação para o dispositivo correto) e regenerar a configuração e o initramfs: update-grub e update-initramfs -u -k todos (para sistemas baseados em dracut dracut -f). Se a ordem dos dispositivos não estiver correta, utilizo o /etc/default/grub UUIDs e verificar /etc/fstab para obter as entradas corretas. Ao alterar GPT/MBR, verifico se existe uma partição de arranque da BIOS (para GRUB/BIOS) ou uma partição de sistema EFI válida.

Armadilhas da rede no Rescue

Os problemas de rede são frequentemente a razão pela qual os serviços "desaparecem". No Rescue, verifico o estado da ligação (ligação ip), rotas (ip r) e resolução de DNS (resolvectl status respectivamente cat /etc/resolv.conf). Testei o IPv4 e o IPv6 separadamente (ping -4/ping -6). Para servidores com bridges ou bonding, a ordem das interfaces no sistema produtivo pode ser diferente do ambiente de resgate. Anoto os endereços MAC e mapeio-os corretamente. Se o sistema de produção usa Netplan, eu verifico o /etc/netplan/*.yaml e depois do chroot netplan gerar e netplan aplicar sobre. Para os clássicos /etc/network/interfaces-configurações, presto atenção à consistência dos nomes das interfaces (nomes previsíveis vs. eth0).

Reinstalar o sistema operativo

Se as reparações deixarem de fazer sentido, reinicio o sistema com imagem de instalação completamente novo, poupando assim valiosos Tempo. A ferramenta guia-me através da seleção da distribuição, particionamento e gestor de arranque. Incluo os meus próprios ficheiros de configuração e chaves SSH na instalação para que o primeiro arranque decorra sem problemas. Após a instalação, inicio o servidor normalmente e verifico os serviços, a firewall e as actualizações. Finalmente, removo o modo de recuperação para que o próximo arranque ocorra novamente a partir do suporte de dados local.

Eu uso deliberadamente montagens baseadas em UUID para novas instalações para descartar problemas de ordem de dispositivos mais tarde. Para configurações RAID, tenho os arrays criados desde o início e verifico o estado da reconstrução antes de restaurar os dados. Se implementar sistemas semelhantes de forma recorrente, trabalha com modelos de imagens de instalação predefinidos e uma lógica de particionamento clara (raiz, partição de dados separada, swap, EFI, se necessário). Após o primeiro arranque, actualizo as fontes de pacotes e os kernels, ativo as actualizações automáticas de segurança e executo os meus passos básicos de endurecimento.

Segurança, intervalo de tempo e recaída

O acesso é feito exclusivamente através de SSHpor isso, confio sistematicamente em Chaves em vez de palavras-passe estáticas. O modo de recuperação permanece pronto durante um período de tempo limitado após a ativação e volta ao dispositivo de arranque local no próximo reinício normal. Eu trabalho rapidamente, documento cada passo e mantenho uma segunda sessão aberta para intervenções maiores. Não escrevo dados sensíveis nos históricos do bash e elimino ficheiros temporários após a utilização. Após uma recuperação bem sucedida, desativo novamente o modo na interface.

Depois de reativar o sistema produtivo, faço a rotação dos dados de acesso, removo as chaves de recuperação temporárias, reponho as palavras-passe de raiz supérfluas e faço cópias de segurança das configurações recentemente geradas. Recolho informações de auditoria (quem fez o quê e quando) e documento os desvios da configuração padrão. Desta forma, evito que as medidas de emergência se tornem permanentes e cumpro os requisitos de conformidade.

Exemplo: Recuperar o servidor WordPress

Arranco no modo de recuperação, monto a partição do sistema e faço uma cópia de segurança da Base de dados por mysqldump e o wp-conteúdo-diretório com alcatrão ou rsync. Em seguida, verifico o sistema de ficheiros, reinicio o gestor de arranque e corrijo as configurações incorrectas do PHP ou do NGINX. Se os pacotes estiverem corrompidos, uso o chroot e reinstalo as dependências. Se isso não for suficiente, eu reinicio a máquina com imagem de instalação e restauro a cópia de segurança e as configurações. Por fim, verifico o frontend, o login e os cronjobs.

Na prática, presto atenção à consistência do InnoDB (MySQL/MariaDB): Falhas mysqld no início, eu seguro o /var/lib/mysql e executar o dump a partir de uma nova instância. Esvazio as caches (cache de objectos, cache de páginas, OPCache) seletivamente, defino as permissões dos ficheiros de forma consistente (find . -type d -exec chmod 755 {} ;, find . -type f -exec chmod 644 {} ;) e verificar open_basedir e os diretórios de carregamento. Desactivo os plug-ins críticos como um teste, renomeando o diretório de plug-ins. Em seguida, verifico os pools PHP FPM, os tempos limite FastCGI, os limites de memória e os includes NGINX/Apache. Um breve wp cron event run --due-now (se o WP-CLI estiver disponível) ajuda a processar os atrasos.

Melhores práticas para administradores

Antes de intervenções profundas, crio uma nova Cópia de segurança e ficheiros-chave seguros, tais como /etcpara poder voltar atrás em qualquer altura. Cada passo é registado num pequeno registo, que me ajuda mais tarde com auditorias ou novos incidentes. Depois de reiniciar o sistema produtivo, verifico minuciosamente os serviços, os registos, a rede e a monitorização. Para tarefas recorrentes, construo um pequeno conjunto de scripts para normalizar as sequências de comandos. Se estiver a planear um desempenho adicional ou novo hardware, pode criar scripts adequados Alugar um servidor de raiz e janela de migração.

Também tenho uma lista de controlo do livro de execução pronta, que contém as responsabilidades e as vias de encaminhamento. Os "dias de jogo" planeados (simulações de falhas específicas) treinam a equipa para emergências. Testo regularmente as cópias de segurança como amostra de restauro - uma cópia de segurança não testada é considerada inexistente. E faço o versionamento das configurações do meu sistema para poder reconhecer rapidamente as diferenças entre o estado "bom" e "defeituoso".

Nuvem vs. dedicado: diferenças no processo

Na nuvem, altero frequentemente o modo de arranque diretamente na caixa de diálogo da instância e utilizo a consola de série para verificações rápidas, enquanto que nos servidores dedicados é necessário um ciclo de energia e, possivelmente, um acesso fora de banda. Os volumes da nuvem podem ser convenientemente ligados a outras instâncias - uma forma eficiente de fazer cópias de segurança dos dados sem tempo de inatividade no anfitrião afetado. Em bare metal, presto mais atenção à ordem física das unidades, especialmente quando compro módulos SSDs/NVMe adicionais. Em ambos os mundos: o Rescue é uma ferramenta temporária - planeio o caminho de volta ao arranque normal em tempo útil.

Comparação: fornecedores com sistema de salvamento

Para além de uma boa qualidade de trabalho, uma recuperação rápida Hardware também um Resgate-caraterística. A tabela seguinte apresenta uma visão geral compacta da gama de funções e do seu tratamento. Baseei-me na disponibilidade, facilidade de acesso e fluxos de trabalho administrativos típicos. A classificação "Recomendação" reflecte a minha utilização prática para falhas típicas. A ponderação pode, naturalmente, variar consoante a utilização pretendida.

Fornecedor	Sistema de salvamento disponível	Facilidade de utilização	Desempenho	Recomendação
webhoster.de	Sim	Muito bom	Muito elevado	Vencedor do teste
Hetzner	Sim	Muito bom	Elevado
Strato	Parcialmente	Bom	Médio
IONOS	Não	Médio	Médio

Lista de controlo: Sequência de passos numa emergência

• Ativar o Rescue, ativar a reinicialização/ciclo de energia, testar o SSH.
• Ver hardware/armazenamento: smartctl, lsblk, blkid, mdstat, lvm.
• Ativar arrays/LUKS/LVM, inspecionar sistemas de ficheiros só de leitura.
• Criar uma cópia de segurança (rsync/tar) e, em seguida fsck/Reparações.
• Sistema em /mnt mount, bind mounts, chroot.
• Reparar o bootloader/initramfs, verificar a configuração da rede.
• Testar o arranque, verificar os serviços, verificar a monitorização/alarmes.
• Desativar o Rescue, remover chaves temporárias, atualizar a documentação.

FAQ Hetzner Rescue System

Posso utilizar o meu Dados recuperação se o sistema deixar de arrancar? Sim, leio os suportes de dados diretamente no modo de recuperação e faço cópias de segurança dos dados importantes. Pasta ou partições inteiras.

Durante quanto tempo é que o modo de recuperação permanece ativo? Após a ativação, o sistema está disponível durante um período de tempo limitado e regressa ao sistema local na próxima reinicialização regular. Barco-dispositivo, pelo que estou a planear uma rápida Procedimento.

Isto funciona para servidores dedicados e na nuvem? Sim, eu inicio o modo para máquinas dedicadas e instâncias de nuvem no Nuvem Hetzner.

O que é que eu faço se o carregador de arranque estiver danificado? Monto o root e possivelmente a EFI, faço chroot no sistema, executo grub-instalação, update-grub e uma reconstrução do initramf, depois testo a reinicialização.

Como é que eu lido com LVM/RAID? Primeiro monto o mdraid, ativo o LVM com vgchange -ay e, em seguida, montar os volumes lógicos. As reparações só acontecem depois de um backup.

Posso guardar apenas ficheiros individuais? Sim, monto ficheiros só de leitura e copio seletivamente configurações, bases de dados (via dump) ou diretórios - minimamente invasivo e rápido.

Mensagem principal

Com o Hetzner Rescue System, tenho uma ferramenta rápida que identifica de forma fiável problemas de arranque, erros no sistema de ficheiros e configurações danificadas. Ativo o modo, inicio sessão via SSH, faço uma cópia de segurança dos dados e depois decido entre reparar ou reinstalar. Isto poupa Tempo numa emergência e reduz o tempo de inatividade ao mínimo indispensável. Se interiorizar estes poucos passos, pode lidar calmamente mesmo com falhas difíceis. Isto significa que a operação do servidor pode ser planeada e o reinício é controlado.