Démarrer le système Hetzner Rescue - Instructions pas à pas pour les administrateurs de serveur

Je te montre comment démarrer le hetzner rescue system en quelques minutes, te connecter par SSH et que tu as choisi ton Serveur de manière ciblée. Ce guide te conduit pas à pas de l'activation à la restauration, y compris les vérifications du système de fichiers, les sauvegardes et la réinstallation.

Points centraux

Les aspects clés suivants t'aideront à mettre en œuvre le démarrage et le travail en mode sauvetage sans détours.

• Démarrage de secours: activation dans Robot ou Cloud, puis redémarrage.
• Accès SSH: Login avec clé ou mot de passe et droits root.
• Analyse des erreurs: fsck, vérifier les logs, les partitions.
• Sauvegarde des données: rsync, tar, scp pour des sauvegardes rapides.
• Nouvelle installation: installimage pour les systèmes récents.

Ce que fait le Rescue System

Le système de secours charge un environnement Linux autonome dans la mémoire et me donne un accès immédiat à l'information. Racine-même si le système d'exploitation installé est Système d'exploitation tombe en panne. Je démarre indépendamment des chargeurs de démarrage défectueux, des paquets endommagés ou des configurations erronées. Je vérifie ainsi les systèmes de fichiers, je récupère les données, j'analyse les logs et je remets les services en service. L'environnement reste léger, mais offre tous les outils importants pour le diagnostic et la récupération. Je garde ainsi le contrôle, même si le système régulier est complètement en panne.

Ce qui est pratique, c'est que l'environnement de secours est volontairement éphémère : les modifications disparaissent après le redémarrage, ce qui me permet de tester sans risque. Si nécessaire, j'installe des outils temporaires (par exemple smartmontools, mdadm, lvm2, btrfs-progs ou xfsprogs) sans modifier le système de production. La version du noyau est moderne et prend en charge le matériel actuel, y compris NVMe, UEFI, GPT, RAID logiciel (mdraid), LVM et le cryptage LUKS. Je couvre ainsi des configurations de stockage complexes et je peux même isoler de manière reproductible des images d'erreur rares.

Conditions préalables et accès

Pour commencer, j'ai besoin d'accéder à l'interface client et à mes Clés SSH ou un temporaire Mot de passe. Je gère les systèmes dédiés de manière confortable via le Robot Hetznertandis que je contrôle les instances dans le cloud via la Console. Les deux interfaces offrent une option claire pour activer le mode de secours. Je vérifie au préalable l'IP correcte du serveur, la disponibilité IPv6 et, le cas échéant, les fonctions hors bande pour la réinitialisation. Cette préparation réduit considérablement le temps d'arrêt.

Lors de la première connexion SSH, je confirme sciemment la nouvelle empreinte digitale et, si nécessaire, j'actualise mon entrée Known-Hosts afin que les connexions ultérieures n'échouent pas à cause d'avertissements. Pour les équipes, j'enregistre des clés supplémentaires de manière ciblée pour l'intervention de secours et je les supprime une fois l'intervention terminée. Si je ne dispose que d'un mot de passe temporaire, je le modifie immédiatement après la connexion et le remplace ensuite par Key-Auth - je désactive systématiquement les connexions par mot de passe à la fin des travaux.

Activer le système Rescue - étape par étape

J'ouvre la fenêtre détaillée du serveur, je sélectionne l'option "Rescue" et je définis l'architecture sur linux64 pour les systèmes actuels, alors je dépose mon Clé SSH. Selon la situation, je lance uniquement le mode de sauvetage et déclenche le redémarrage séparément ou j'utilise "Activer le sauvetage & Power Cycle" pour un redémarrage direct. Si la machine reste bloquée, j'effectue un hard reset via l'interface. Après le démarrage, l'interface affiche un mot de passe root temporaire si je n'ai pas saisi de clé. Dès que le serveur démarre, il répond au SSH et je peux commencer.

Dans les situations complexes, je prévois un ordre clair : activer, Power Cycle, tester la connexion SSH, puis seulement commencer le dépannage. Sur les serveurs dédiés, un Power Cycle manuel peut être plus nécessaire, tandis que les instances cloud passent généralement immédiatement en mode de sauvetage. Important : après une réparation réussie, je désactive à nouveau le mode de sauvetage pour que la machine redémarre à partir du disque local.

Connexion SSH et premières vérifications

Je me connecte par SSH avec ssh root@ et vérifie d'abord le réseau, les disques et les journaux pour avoir un aperçu rapide de la situation. Statut. Avec ip a et ping je contrôle l'accessibilité ; journalctl --no-pager -xb ou les fichiers journaux sur les disques montés affichent les derniers messages d'erreur. Les commandes lsblk, blkid et fdisk -l permettent de clarifier la disposition et les systèmes de fichiers. Pour le RAID, j'utilise cat /proc/mdstat et mdadm --detail pour l'état. Pour les premiers indicateurs matériels, aider smartctl -a et un bref hdparm -Tt-test.

LVM, RAID, LUKS et systèmes de fichiers spéciaux

De nombreux serveurs utilisent LVM, RAID logiciel ou le cryptage. Je commence par activer toutes les couches pertinentes :

• mdraid: mdadm --assemble --scan fait remonter les tableaux existants ; je vérifie l'état avec cat /proc/mdstat.
• LUKSJ'ouvre les volumes cryptés avec cryptsetup luksOpen /dev/.
• LVM: Avec vgscan et vgchange -ay j'active les groupes de volumes et je les vois via lvs/vgs/pvs.

Avec Btrfs, je fais attention aux sous-volumes et je les monte de manière ciblée avec -o subvol=@ ou -o subvolid=5 pour le niveau supérieur. Je vérifie XFS avec xfs_repair (jamais sur les volumes montés), alors que Ext4 est classiquement utilisé avec fsck.ext4 -f est assaini. Je m'oriente vers le GUID/UUID de blkidparce que les noms de périphériques sont utilisés pour NVMe (/dev/nvme0n1p1) et peuvent varier en cas de changement d'ordre. En conséquence, je corrigerai plus tard les /etc/fstab.

Réparation du système de fichiers et sauvegarde des données

Avant de réparer, je sécurise les éléments importants Données avec rsync, scp ou tar sur une cible externe ou une cible locale Sauvegarde-dans le répertoire. Pour les contrôles, j'utilise fsck uniquement sur des partitions non montées, telles que fsck -f /dev/sda2pour corriger proprement les incohérences. Ensuite, je monte le système sous /mnt, par exemple avec mount /dev/sda2 /mntet ajouter des sous-chemins comme /proc, /sys et /dev quand je veux chrooter. Les fichiers de configuration individuels comme /etc/fstab ou les paramètres réseau, je les adapte directement dans le système monté. En procédant avec précaution, j'évite les dommages consécutifs et je limite les temps d'arrêt.

Pour des sauvegardes fiables, je mise sur des commandes répétables : rsync -aHAX --info=progress2 reçoit les droits, les hardlinks, les ACL et les xattrs. Si la ligne est faible, j'effectue un drop avec --bwlimit et parallélise la compression avec tar -I pigz. Si nécessaire, je crée les supports de données critiques et défectueux par bloc avec ddrescue pour transférer le travail logique sur une image. Je vérifie prudemment les systèmes Btrfs avec btrfs check --readonly et utilise btrfs scrubpour détecter les erreurs silencieuses. En cas d'incohérence, XFS demande souvent une réparation hors-montage (xfs_repair) - avant cela, je sauvegarde absolument la partition.

Réparation de l'UEFI/BIOS, GPT/MBR et du chargeur de démarrage

De nombreux problèmes de démarrage sont liés à l'interaction entre le micrologiciel, le schéma de partitionnement et le chargeur de démarrage. Je détermine d'abord si le serveur démarre en mode UEFI ou BIOS hérité (ls /sys/firmware/efi). Avec UEFI, je monte la partition EFI (typiquement /dev/sdX1 ou /dev/nvme0n1p1) selon /mnt/boot/efi. Ensuite, je chroote dans le système :

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

Je réinstalle le bootloader de manière appropriée (grub-install sur le bon périphérique) et régénérer la configuration et les initramfs : update-grub et update-initramfs -u -k all (pour les systèmes basés sur dracut dracut -f). Si l'ordre des périphériques n'est pas correct, j'utilise la fonction /etc/default/grub UUID et vérifie /etc/fstab pour vérifier que les entrées sont correctes. Lors des changements de GPT/MBR, je contrôle s'il existe une partition de démarrage BIOS (pour GRUB/BIOS) ou une partition système EFI valide.

Les pièges du réseau dans le Rescue

Les problèmes de réseau sont souvent à l'origine de la "disparition" de services. Dans Rescue, je vérifie l'état des liens (lien ip), itinéraires (ip r) et la résolution DNS (état de resolvectl respectivement cat /etc/resolv.conf). Je teste IPv4 et IPv6 séparément (ping -4/ping -6). Pour les serveurs avec des ponts ou des liaisons, l'ordre des interfaces dans le système de production peut différer de celui de l'environnement de secours. Je note les adresses MAC et les cartographie correctement. Si le système productif utilise Netplan, je vérifie les /etc/netplan/*.yaml et retourne après le chroot netplan generate et Appliquer netplan de l'entreprise. Pour les classiques /etc/network/interfaces-Dans mes configurations, je veille à ce que les noms d'interface soient cohérents (predictable names vs. eth0).

Réinstaller le système d'exploitation

Si les réparations n'ont plus de sens, je réinitialise le système avec installimage et économise ainsi de précieuses ressources. Temps. L'outil me guide dans le choix de la distribution, du partitionnement et du chargeur de démarrage. J'intègre mes propres fichiers de configuration et clés SSH dans l'installation afin que le premier démarrage se déroule sans problème. Après l'installation, je démarre le serveur normalement et vérifie les services, le pare-feu et les mises à jour. Pour finir, je supprime le mode de sauvetage afin que le prochain démarrage se fasse à partir du disque local.

Lors de la réinstallation, je mise délibérément sur des montages basés sur l'UUID afin d'exclure tout problème ultérieur lié à l'ordre des périphériques. Pour les configurations RAID, je fais créer les tableaux dès le début et je vérifie l'état de la reconstruction avant de restaurer les données. Ceux qui déploient des systèmes similaires de manière récurrente travaillent avec des modèles d'installimage prédéfinis et une logique de partitionnement claire (racine, partition de données séparée, swap, EFI le cas échéant). Après le premier démarrage, je mets à jour les sources de paquets, le noyau, j'active les mises à jour automatiques de sécurité et je déploie mes étapes de renforcement de base.

Sécurité, fenêtre temporelle et récidive

L'accès se fait exclusivement par SSHC'est pourquoi je mise systématiquement sur Clés au lieu des mots de passe statiques. Une fois activé, le mode de sauvetage reste prêt pour une durée limitée et revient sur le périphérique de démarrage local au prochain redémarrage normal. Je travaille rapidement, je documente chaque étape et je garde une deuxième session ouverte en cas d'intervention importante. Je n'écris pas de données sensibles dans les historiques bash et je supprime les fichiers temporaires après l'intervention. Après une restauration réussie, je désactive à nouveau le mode dans l'interface.

Après la réactivation du système de production, je fais une rotation des données d'accès, je supprime les clés de secours temporaires, je réinitialise les mots de passe root superflus et je sécurise les configurations fraîchement générées. Je collecte des informations d'audit (qui a fait quoi et quand) et je documente les écarts par rapport à la configuration standard. Ainsi, les mesures d'urgence ne deviennent pas permanentes et je respecte les directives de conformité.

Exemple de la procédure : Sauver le serveur WordPress

Je démarre en mode de secours, monte la partition système et sauvegarde les Base de données par mysqldump et le wp-content-répertoire avec tar ou rsync. Ensuite, je vérifie le système de fichiers, je réinitialise le chargeur de démarrage et je corrige les configurations PHP ou NGINX erronées. Si des paquets sont endommagés, j'utilise chroot et je réinstalle les dépendances. Si cela ne suffit pas, je redémarre la machine avec installimage et restaure la sauvegarde et les configurations de manière ciblée. Pour finir, je vérifie le frontend, le login et les cronjobs.

Dans la pratique, je veille à la cohérence d'InnoDB (MySQL/MariaDB) : si la base de données échoue, je dois la remplacer. mysqld au départ, j'assure la /var/lib/mysql et j'exécute le dump à partir d'une instance fraîche. Je vide les caches (Object Cache, Page Cache, OPCache) de manière ciblée, je définis les droits des fichiers de manière cohérente (find . -type d -exec chmod 755 {} ;, find . -type f -exec chmod 644 {} ;) et contrôle open_basedir ainsi que les répertoires de téléchargement. Je désactive les plugins critiques à titre de test en renommant le répertoire des plugins. Ensuite, je vérifie les pools PHP-FPM, les délais FastCGI, les limites de mémoire et les inclusions NGINX/Apache. Un bref wp cron event run --due-now (si WP-CLI est disponible) aide à traiter les backlogs.

Meilleures pratiques pour les administrateurs

Avant de procéder à des interventions profondes, je crée un nouveau Sauvegarde et des fichiers de clés sécurisés tels que /etcJe peux ainsi revenir en arrière à tout moment. Chaque étape est consignée dans un bref journal qui m'aidera plus tard en cas d'audit ou de nouveaux incidents. Après le redémarrage dans le système de production, je vérifie minutieusement les services, les logs, le réseau et la surveillance. Pour les travaux récurrents, je me constitue un petit ensemble de scripts afin de standardiser les séquences de commandes. Les personnes qui prévoient des performances supplémentaires ou un nouveau matériel peuvent Louer un serveur racine et préparer proprement les fenêtres de migration.

Je tiens en outre à disposition une liste de contrôle Runbook qui contient les responsabilités et les voies d'escalade. Des "Game Days" planifiés (simulations de pannes ciblées) entraînent l'équipe pour les cas d'urgence. Je teste régulièrement les sauvegardes en tant que test de restauration - une sauvegarde non testée est considérée comme inexistante. Et je versionne mes configurations système afin de pouvoir identifier rapidement les différences entre un "bon" état et un "état défectueux".

Cloud vs. Dedicated : différences dans le processus

Dans le cloud, je change souvent le mode de démarrage directement dans la boîte de dialogue de l'instance et j'utilise la console série pour des vérifications rapides, alors que sur les serveurs dédiés, un cycle de puissance et éventuellement un accès hors bande sont nécessaires. Les volumes cloud peuvent être facilement attachés à d'autres instances - un moyen efficace de sauvegarder les données sans temps d'arrêt sur l'hôte concerné. Sur le bare metal, je fais plus attention à l'ordre physique des disques, notamment en cas d'achat de modules SSD/NVMe supplémentaires. Dans les deux mondes, le principe est le suivant : Rescue est un outil temporaire - je prévois à l'avance le retour au démarrage normal.

Comparaison : fournisseurs avec système Rescue

Pour une restauration rapide, il faut, outre une bonne Matériel informatique également une intégration propre Rescue-La fonction de la caméra. Le tableau suivant donne un aperçu concis de l'étendue des fonctions et de leur utilisation. Je me base sur la disponibilité, la facilité d'accès et les flux de travail typiques des administrateurs. Le classement "Recommandation" reflète mon utilité pratique pour les pannes typiques. La pondération peut bien sûr varier en fonction de l'objectif d'utilisation.

Fournisseur	Système de secours disponible	Confort d'utilisation	Performance	Recommandation
webhoster.de	Oui	Très bon	Très élevé	Vainqueur du test
Hetzner	Oui	Très bon	Haute
Strato	Partiellement	Bon	Moyens
IONOS	Non	Moyens	Moyens

liste de contrôle : Séquence de mesures en cas d'urgence

• Activer le Rescue, déclencher le Reboot/Power Cycle, tester SSH.
• passer en revue le matériel/le stockage : smartctl, lsblk, blkid, mdstat, lvm.
• Activer les tableaux/LUKS/LVM, inspecter les systèmes de fichiers en lecture seule.
• Faire une sauvegarde (rsync/tar), puis seulement fsck/réparations.
• Système sous /mnt monter, bind-mounts, chroot.
• Réparer le bootloader/initramfs, vérifier la configuration du réseau.
• Démarrage test, vérification des services, contrôle du monitoring/des alarmes.
• Désactiver Rescue, supprimer les clés temporaires, mettre à jour la doc.

FAQ Hetzner Rescue System

Est-ce que je peux avoir mon Données si le système ne démarre plus ? Oui, je lis les disques directement en mode de sauvetage et je sauvegarde les données importantes. Dossier ou des partitions entières.

Combien de temps le mode de secours reste-t-il actif ? Après l'activation, le système est disponible de manière limitée et revient au système local lors du prochain redémarrage normal. Bateau-Je prévois donc d'accélérer le processus. Déroulement.

Est-ce que cela fonctionne pour les serveurs cloud et dédiés ? Oui, je démarre le mode aussi bien pour les machines dédiées que pour les instances cloud en Hetzner Cloud.

Que faire si le chargeur de démarrage est endommagé ? Je monte la racine et éventuellement EFI, je chroote dans le système, j'exécute grub-install, update-grub et une reconstruction de l'initramf, puis je testerai le redémarrage.

Comment gérer LVM/RAID ? J'assemble d'abord mdraid, j'active LVM avec vgchange -ay et monte ensuite les volumes logiques. Les réparations ne se produisent qu'après une sauvegarde.

Puis-je seulement récupérer des fichiers individuels ? Oui, je monte en lecture seule et copie sélectivement des configs, des bases de données (via dump) ou des répertoires - de manière peu invasive et rapide.

Message clé

Avec le Hetzner Rescue System, je dispose d'un outil rapide qui identifie de manière fiable les problèmes de démarrage, les erreurs de système de fichiers et les configurations endommagées. J'active le mode, je me connecte via SSH, je sauvegarde les données et je choisis ensuite entre réparation et réinstallation. Cela permet d'économiser Temps en cas d'urgence et réduit les pannes au strict minimum. En assimilant ces quelques étapes, on peut surmonter les pannes les plus difficiles en toute sérénité. Le fonctionnement du serveur reste ainsi planifiable et le redémarrage se déroule de manière contrôlée.