Opérations du serveur
Récupérer un serveur injoignable
Triez la perte d'accès, protégez les données récupérables et choisissez le chemin de récupération assisté par l'opérateur le moins destructeur.
Sur cette page
Avant de commencer
- Le nom du serveur, la région, l'état actuel, l'adresse principale et l'heure du dernier accès réussi.
- Une sauvegarde indépendante récente et une compréhension des données modifiées depuis cette sauvegarde.
- La clé privée locale SSH et tout matériel de récupération de chiffrement de disque ; n'envoyez jamais de clés privées au support.
- Un enregistrement de maintenance pour les changements récents de pare-feu, réseau, démarrage, stockage ou système d'exploitation.
Classifiez la panne avant d'agir
Distinguez d'abord un problème d'état du compte d'un problème de connectivité. Un état PROVISIONING ou SUSPENDED, une adresse en attente ou un serveur dont le temps payé est dépassé nécessite une réponse différente d'un serveur joignable qui rejette SSH. Enregistrez le message exact plutôt que de le résumer comme étant en panne.
Vérifiez à partir d'un second réseau de confiance si possible, mais n'exécutez pas de scans agressifs. Si l'adresse est joignable mais que l'authentification échoue, confirmez le nom de connexion et la clé privée correspondante. Si la clé d'hôte a changé sans réinstallation approuvée, arrêtez et traitez cela comme un problème d'identité.
| Symptôme | Limite possible | Prochaine étape la moins destructive |
|---|---|---|
| Serveur toujours en provisionnement | Livraison non terminée | Demandez à l'opérateur l'état du provisionnement. |
| Délai d'attente SSH | Alimentation, routage, pare-feu ou service SSH | Demandez l'accès KVM avant de réinstaller. |
| Permission refusée | Incohérence de connexion ou de clé | Vérifiez le nom du compte et l'appariement de la clé publique/privée. |
| Clé d'hôte modifiée | Réinstallation, réaffectation ou interception | Vérifiez la nouvelle empreinte hors bande. |
| Erreur de système de fichiers ou de démarrage | Panne de disque, de RAID ou du système d'exploitation | Utilisez d'abord la récupération en lecture seule et préservez les preuves. |
Choisissez la plus petite action
Ne sélectionnez pas Éteindre à moins que l'opérateur n'ait convenu de la manière dont la machine sera rallumée. Le client actuel API n'expose pas d'action de mise sous tension. La rotation du mot de passe root n'est également qu'une requête en file d'attente et le API ne renvoie pas de mot de passe généré, ce n'est donc pas un chemin de récupération en libre-service aujourd'hui.
- Capturez l'état actuel du serveur et tous les identifiants visibles avant de mettre quoi que ce soit en file d'attente.
- Si le système d'exploitation peut simplement être bloqué, mettez en file d'attente une demande de redémarrage et notez son suffixe d'action.
- Si la configuration réseau ou de démarrage est suspecte, mettez en file d'attente KVM et demandez à l'opérateur de fournir un accès console.
- Si un support de secours est nécessaire, préparez un ISO personnalisé de confiance et une somme de contrôle, puis coordonnez son montage avec l'opérateur.
- Utilisez la réinstallation uniquement lorsque la récupération des données est terminée ou qu'une sauvegarde indépendante a été vérifiée.
Protégez les données pendant la récupération
Préférez une inspection en lecture seule avant la réparation. Identifiez les disques, partitions, systèmes de fichiers et points de montage avant de sélectionner un périphérique. Les noms peuvent différer après le démarrage d'un support alternatif, en particulier sur les systèmes de stockage NVMe et multi-disques. Si la panne peut impliquer RAID ou des dommages au système de fichiers, capturez les diagnostics et consultez un opérateur qualifié avant d'assembler des matrices ou d'exécuter des outils de réparation.
N'initialisez jamais un disque, ne créez pas de nouveau système de fichiers, ne reconstruisez pas une matrice et ne réinstallez pas simplement pour voir si cela aide. Ces opérations peuvent écraser les métadonnées nécessaires à la récupération. Gardez les données récupérées hors du serveur affecté et vérifiez-les avant tout travail destructif.
lsblk --fs
ip -brief address
ip route show
ip -6 route showRésultat attendu et dossier d'escalade
Une récupération réussie restaure un chemin d'administration vérifié sans perte de données inutile, ou produit un plan contrôlé pour restaurer sur un système propre. Comme les actions en file d'attente n'ont pas d'état d'achèvement visible par le client, maintenez une chronologie contenant chaque suffixe d'action et la confirmation de l'opérateur.
Lors d'une escalade, incluez le serveur et la région, l'heure du dernier état connu en UTC, l'état visible, le réseau source, l'erreur exacte SSH ou de console, les changements récents, les références d'action, et si une sauvegarde hors serveur a été testée. Excluez les mots de passe, les clés privées, les codes de récupération et les URL de console en direct. Si l'opérateur ne peut pas rétablir un accès sûr, convenez des limites de capture et d'effacement des données avant de réinstaller.