Когда останавливается узел Proxmox, вместе с ним могут стать недоступны все размещённые на нём виртуальные машины. Перезагрузка иногда возвращает сервисы в работу, но при повторных остановках нужно разбираться с причиной и одновременно готовить способ восстановления.
Сам факт зависания ещё не доказывает неисправность железа. Даже стабильная работа после замены сервера не позволяет точно назвать причину прежних сбоев без результатов диагностики. Для владельца проекта в этот момент главное — сохранить данные и понять, как вернуть сервисы пользователям.
Что проверить в первую очередь
- Определите масштаб сбоя. Проверьте доступность виртуальных машин отдельно от панели Proxmox. Если приложения работают, а веб-интерфейс управления не открывается, перезагрузка всего узла может создать дополнительный простой.
- Сохраните сведения об остановке. Запишите время и часовой пояс, симптомы, последние изменения. При наличии доступа сохраните журналы системы и сообщения удалённой консоли IPMI/KVM.
- Проверьте последнюю резервную копию. Где она находится, когда завершилось копирование, доступна ли она независимо от проблемного сервера.
- Откройте обращение в поддержку. Укажите повторяемость сбоя и его влияние на проекты. До переустановки или операций с дисками согласуйте сохранение данных.
Для обращения можно использовать такой шаблон:
Сервер [ID] повторно стал недоступен [дата, время, часовой пояс]. Недоступны [панель, SSH, виртуальные машины или отдельные сервисы]. Предыдущая остановка была [дата]. Последняя внешняя резервная копия — [дата либо «нет»]. Просим сохранить данные на дисках, сообщить результаты диагностики и возможные варианты восстановления. Если точного срока пока нет, укажите следующий этап работ и время обновления статуса.
Какие сроки уточнять у поддержки
Во время аварии важно различать несколько этапов:
| Этап | Что должно произойти |
|---|---|
| Начало реакции | Инженер принимает обращение и приступает к проверке. |
| Ремонт или замена | Восстанавливается работоспособность оборудования либо предоставляется другой сервер. |
| Восстановление проекта | Возвращаются данные, запускаются виртуальные машины и проверяются приложения. |
Выдача исправного сервера ещё не означает, что проект восстановлен. На перенос данных и проверку сервисов требуется отдельное время. Уточните, кто выполняет эти работы, есть ли подходящее оборудование и можно ли начать восстановление из копии параллельно с диагностикой старого узла.
Если причина пока неизвестна, полезнее получить план следующего действия и время нового сообщения, чем неподтверждённое обещание «скоро всё заработает».
Отдельная резервная копия должна пережить отказ основного узла
RAID может помочь при отказе отдельных дисков в пределах возможностей массива. Снимок виртуальной машины на том же хранилище удобен для отката изменений. Но при потере всего узла или хранилища такие меры могут оказаться недоступны вместе с рабочими данными.
Для Proxmox можно организовать копирование на отдельный Proxmox Backup Server или другое подходящее внешнее хранилище. Его размещение нужно проверить: ещё одна виртуальная машина на том же физическом сервере сохраняет зависимость от этого сервера. Для защиты от аварии всей площадки нужна копия за её пределами.
Заранее определите, данные за какой период допустимо потерять. Если максимум за час, одной ночной копии недостаточно. Настройте расписание, хранение нескольких версий и уведомления об ошибках. Убедитесь, что в задания включены все нужные диски и данные приложений.
Доступы к резервам и ключи расшифровки храните так, чтобы получить их можно было и при недоступности основного узла. Права на удаление копий лучше отделить от повседневного доступа рабочего сервера.
Проверьте восстановление до настоящей аварии
Успешный статус задания подтверждает выполнение копирования, но готовность проекта к восстановлению нужно проверять отдельно. Восстановите одну из важных виртуальных машин в изолированной сети. Проверьте загрузку, вход в приложение, базу данных и необходимые файлы. Тестовая копия не должна отправлять реальные письма или повторно выполнять рабочие задания.
Замерьте время восстановления. Оно зависит от объёма данных, скорости чтения и передачи, а также доступных вычислительных ресурсов. Если допустимый простой короче полученного времени, потребуется менять схему: например, заранее готовить резервный узел и порядок переключения.
Как организовать восстановление и резервирование с HSTQ
В HSTQ можно подобрать выделенный сервер для рабочей нагрузки или восстановления, а также Storage VPS под резервные копии. При подборе укажите, где находится основной узел: размещение хранилища отдельно от него нужно согласовать.
Через услугу администрирования можно согласовать диагностику, настройку резервного копирования, мониторинг и работы по переносу. До начала определяются поддерживаемые системы, доступы, объём работ и условия реакции.
Базовая аренда сама по себе не означает, что копирование и восстановление приложений уже настроены. По условиям HSTQ заказчик хранит резервные копии вне арендуемой услуги, если отдельный backup-сервис не указан в заказе.
Обсудить восстановление или отдельное хранилище резервных копий
Сообщите количество виртуальных машин, объём данных, состояние текущего сервера, наличие копий и допустимый простой. По этим данным мы оценим доступные варианты и согласуем необходимые работы. Если исходные данные и пригодные копии недоступны, один новый сервер не восстановит их содержимое.
