Статус та доступність послуг Оплата лише криптовалютою · Реєстрація без KYC

Операції з сервером

Відновіть недосяжний сервер

Сортуйте втрату доступу, захистіть відновлювані дані та виберіть найменш руйнівний шлях відновлення за допомогою оператора.

Tungsto документація · Оновлено · 3 хв читання

На цій сторінці
  1. Перш ніж почати
  2. Класифікуйте збій перед діями
  3. Виберіть найменшу дію
  4. Захистіть дані під час відновлення
  5. Очікуваний результат та пакет ескалації
  6. Пов'язані ресурси

Перш ніж почати

  • Ім'я сервера, регіон, поточний стан, основна адреса та час останнього успішного доступу.
  • Нещодавня незалежна резервна копія та розуміння того, які дані змінилися після її створення.
  • Локальний приватний ключ SSH та будь-які матеріали для відновлення шифрування диска; ніколи не надсилайте приватні ключі до служби підтримки.
  • Запис про обслуговування для нещодавніх змін брандмауера, мережі, завантаження, сховища або ОС.

Класифікуйте збій перед діями

Спочатку відрізніть проблему зі статусом облікового запису від проблеми з підключенням. Стан PROVISIONING або SUSPENDED, адреса Pending або сервер, у якого минув оплачений час, потребують іншої відповіді, ніж досяжний сервер, який відхиляє SSH. Запишіть точне повідомлення, а не узагальнюйте його як недоступний.

Перевірте з другої довіреної мережі, якщо це можливо, але не виконуйте агресивне сканування. Якщо адреса досяжна, але автентифікація не вдається, підтвердьте ім'я для входу та відповідний приватний ключ. Якщо ключ хоста змінився без схваленої перевстановлення, зупиніться та розглядайте це як проблему ідентичності.

СимптомМожлива межаНайменш руйнівний наступний крок
Сервер все ще надаєтьсяДоставку не завершеноЗапитайте оператора про статус надання.
Тайм-аут SSHЖивлення, маршрутизація, брандмауер або сервіс SSHЗапитуйте доступ KVM перед перевстановленням.
Доступ забороненоНевідповідність логіна або ключаПеревірте назву облікового запису та пару відкритого/приватного ключа.
Ключ хоста зміненоПеревстановлення, перепризначення або перехопленняПеревірте новий відбиток поза смугою.
Помилка файлової системи або завантаженняЗбій диска, RAID або ОССпочатку використовуйте відновлення лише для читання та зберігайте докази.

Оберіть найменшу дію

Не вибирайте «Вимкнути живлення», якщо оператор не погодив, як машину буде знову ввімкнено. Поточний клієнт API не надає дії для ввімкнення. Зміна пароля root також є лише запитом у черзі, і API не повертає згенерований пароль, тому наразі це не є шляхом самовідновлення.

  1. Зафіксуйте поточний стан сервера та всі видимі ідентифікатори перед постановкою будь-чого в чергу.
  2. Якщо операційна система може просто зависнути, поставте в чергу один запит Restart і занотуйте його суфікс дії.
  3. Якщо конфігурація мережі або завантаження підозріла, поставте в чергу KVM і попросіть оператора надати доступ до консолі.
  4. Якщо потрібне рятувальне середовище, підготуйте надійний власний ISO та контрольну суму, потім узгодьте його монтування з оператором.
  5. Використовуйте перевстановлення лише тоді, коли відновлення даних завершено або незалежну резервну копію перевірено.

Захистіть дані під час відновлення

Віддавайте перевагу перевірці лише для читання перед ремонтом. Визначте диски, розділи, файлові системи та точки монтування, перш ніж обирати пристрій. Назви можуть відрізнятися після завантаження з альтернативного носія, особливо на NVMe та багатодискових системах зберігання. Якщо збій може стосуватися RAID або пошкодження файлової системи, зберіть діагностичні дані та проконсультуйтеся з кваліфікованим оператором, перш ніж збирати масиви або запускати інструменти ремонту.

Ніколи не ініціалізуйте диск, не створюйте нову файлову систему, не перебудовуйте масив і не перевстановлюйте лише для того, щоб побачити, чи це допоможе. Ці операції можуть перезаписати метадані, необхідні для відновлення. Тримайте відновлені дані поза ураженим сервером і перевірте їх перед руйнівною роботою.

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

Очікуваний результат та пакет ескалації

Успішне відновлення відновлює перевірений шлях адміністрування без непотрібної втрати даних або створює контрольований план відновлення на чистій системі. Оскільки дії в черзі не мають видимого клієнту стану завершення, ведіть одну часову шкалу, що містить кожен суфікс дії та підтвердження оператора.

При ескалації вкажіть сервер і регіон, час останнього відомого робочого стану в UTC, видимий стан, вихідну мережу, точну помилку SSH або консолі, нещодавні зміни, посилання на дії та чи було протестовано резервну копію поза сервером. Не передавайте паролі, приватні ключі, коди відновлення та живі URL-адреси консолі. Якщо оператор не може відновити безпечний доступ, узгодьте межі збору даних і очищення перед перевстановленням.