Что мне нужно сделать, чтобы восстановить работоспособность ноды после её сбоя?

У меня сервер ESXi версии 6.7.0. Допустим, физический хост полностью вышел из строя — какие данные и конфигурации нужно сохранить, чтобы полностью восстановить работу хоста и всех его виртуальных машин?
  • 27 апреля 2026 г. 10:01
Ответы на вопрос 5
Кратко — нужно регулярно сохранять две группы вещей: 1) все файлы виртуальных машин (VMDK, VMX и др.) и/или снапшоты/бекупы самих ВМ и 2) конфигурацию ESXi-хоста (сетевые настройки, storage‑мэппинг, RDM, лицензии, сертификаты и т.д.). Тогда при полном выходе железа вы сможете быстро поставить новый хост, подключить/подмонтировать сторидж и вернуть ВМ в работу без потери конфигурации.

Ниже — подробный чек‑лист что именно хранить и как восстанавливать.

1) Что обязательно сохранить (приоритет)
- Файлы виртуальных машин (на datastore):
  - .vmx (параметры VM),
  - .vmdk (диски: -flat.vmdk / -sparse.vmdk и т. п.),
  - .nvram (BIOS/UEFI VM),
  - .vmsd / .vmsn (снапшоты),
  - .vmxf, .log и др.
  Если datastore находится на SAN/NFS/общем хранилище — эти файлы уже вне хоста и достаточно просто иметь доступ к хранилищу.
- Конфигурация ESXi-хоста (ключевой файл — /etc/vmware/esx.conf и сопутствующие файлы):
  - esx.conf (вся конфигурация hostd: сеть, vSwitch/portgroup, datastore UUID, устройства, настройки multipath),
  - сертификаты /etc/vmware/ssl/* (если кастомные),
  - конфиг hostd, vpxa и др. (при необходимости),
  - state.tgz — архив конфигурации, создаваемый средствами ESXi/vCLI (см. ниже).
- Информация о сетевой привязке:
  - имена vSwitch/portgroup, VLAN ID, физические NIC ↔ порт,
  - NIC teaming/политики,
  - MAC-адреса (если важно сохранить идентичность NIC для ОС внутри ВМ).
- Storage‑информация:
  - LUN ID / WWN / serial номеров LUN, подписи VMFS, multipath конфигурация (claim rules),
  - RDM mappings (если используются).
- vCenter / vSphere DVS / host profiles:
  - База данных vCenter (если есть vCenter) — обязательно бэкапить vCenter/PSC,
  - Конфигурация vDS (Distributed Switch) хранится в vCenter; если вы потеряете и vCenter — понадобится его бэкап.
- Лицензии и ключи, скрипты/документация по BIOS/firmware (особенно MAC/NIC ordering).
- Бекап ВМ (на уровне образов): регулярные резервные копии (Veeam, Nakivo, прочие), если локальные диски хоста — единственное место хранения ВМ.

2) Как регулярно брать бэкап конфигурации ESXi
- Использовать средство бэкапа конфигурации:
  - из vSphere CLI / vSphere Management Assistant (vCLI): vicfg-cfgbackup --server <ESXi> -s cfg.tgz
  - или на самом ESXi: vim-cmd hostsvc/firmware/backup_config — команда создаст архив (и выдаст URL для скачивания).
- Также можно скопировать вручную ключевой файл:
  - scp root@ESXi:/etc/vmware/esx.conf .
- Бэкап vCenter (база данных, PSC) по расписанию — критично, если у вас vDS/HA/DRS.

3) Восстановление после полного выхода хоста — пошагово
a) Оцените состояние сториджа:
  - Если сторидж (SAN/NFS/shared datastore) доступен: файлы ВМ целы — восстановление намного проще.
  - Если сторидж был локальным на том хосте и он сгорел — надо иметь внешние бекапы ВМ (Veeam/снимки массива).
b) Установите ESXi (та же версия/patch level предпочтительна) на новый хост или замените железо.
c) Восстановите конфигурацию хоста:
  - восстановите state.tgz / esx.conf через vicfg-cfgbackup или API → вернутся настройки vSwitch, VMkernel интерфейсы, т. п.;
  - если конфигурацию восстановить не получается (разное железо) — вручную воссоздайте vSwitch/portgroup/NIC mapping/VMkernel, соблюдая прежние имена и VLAN.
d) Подключите сториджи:
  - подключите SAN LUN/подмонтируйте NFS datastores / подключите FC zoning, проверьте VMFS UUID и видимость LUN.
e) Зарегистрируйте ВМ:
  - если VMX/файлы на datastore — через vSphere Client: Browse datastore → правой кнопкой register .vmx,
  - или через CLI: vim-cmd solo/registervm /vmfs/volumes/<datastore>/<vm>/<vm>.vmx <folder>
  При регистрации VMX идентификаторы VM (UUID, MAC, настройка) сохранятся.
f) Восстановите RDM/специфичные маппинги при необходимости.
g) Присоедините хост к vCenter и/или восстановите vDS через бэкап vCenter (если использовался vDS).
h) Включите ВМ, проверьте сетевую/сторидж работоспособность и целостность приложений.

4) Тонкости и подводные камни
- Если при повторной регистрации VMware сгенерирует новые MAC/UUID — внутри гостевой ОС может появиться новое сетевое устройство (особенно Linux), возможно придётся поправить конфиги сети.
- Восстановление esx.conf на хост с иным оборудованием может привести к несоответствиям (например, привязки vmnicX → phys NIC). Всегда проверьте и поправьте физические привязки.
- vDS управляется vCenter; если у вас бэкап только ESXi, но нет vCenter — придётся воссоздавать распределённые сети вручную или восстанавливать vCenter из бэкапа.
- Локальные datastores, которые были на вышедшем хосте, если диски повреждены/потеряны — единственный путь — восстановление из копий/снэпшотов.

5) Рекомендуемая политика резервного копирования
- Регулярно (например, ежедневно/еженедельно) делать:
  - бэкап конфигурации ESXi (state.tgz / esx.conf),
  - бэкап vCenter (полный бэкап DB + файлы),
  - бэкап ВМ на уровне образов (критичные ВМ — чаще).
- Документировать сетевые/сторидж схемы, VLANы, WWN/LUN ID, привязки NIC → порты свитчей.
- Хранить копии SSL-сертификатов и лицензий.
- Тестировать процедуру восстановления (DR drill).

6) Полезные команды/действия (пример)
- Создать бэкап конфигурации (на удалённой машине с vCLI):
  vicfg-cfgbackup --server <ESXi_IP> -s esxi-backup.tgz
- На ESXi:
  vim-cmd hostsvc/firmware/backup_config
  (потом скачать сгенерированный архив через https://<esxi>/downloads/...)
- Скопировать файл конфигурации:
  scp root@<esxi>:/etc/vmware/esx.conf .
- Просмотреть содержимое datastore:
  ls /vmfs/volumes/<datastore>/<VM_folder>/
- Зарегистрировать VM из .vmx (пример):
  vim-cmd solo/registervm /vmfs/volumes/<datastore>/<VM_folder>/<vm>.vmx

Если нужно, могу:
- прислать точные команды для вашего окружения (в т.ч. vicfg-cfgbackup/vim-cmd) с примерами,
- помочь составить план бэкапа/восстановления под ваш конкретный стек (используемые типы хранилищ, vCenter/vDS/HA/DRS, backup‑решение).
Диски вм(если не схд), конфиги вм, конфиги сети ноды(с виртуальными коммутаторами), конфиги прав доступа ноды, возможно конфиг подключения внешних дисков(схд), возможно конфиг маршрутизации и файрвола, возможно конфиг софт рейда <br/> Ps самое простое образ настроенной системы esxi и образ хранилища вм(если он в самом сервере)
у нас в своё время Veeam так же жил на том же хосте. Настрой Backup Copy Job — скинет копии на внешний репозиторий (NAS, отдельный сервер, S3). Конфиг самого ESXi сними: <code>vim-cmd hostsvc/firmware/sync_config</code> потом <code>vim-cmd hostsvc/firmware/backup_config</code> , выдаст ссылку скачать tgz. ВМ это главное, хост пересоздать за 10 минут.
'правильный' с точки зрения production ready подхода, разделять хранилище и сервер приложений, т.е. у вас должен быть отдельный nas под данные (образы ОС) и резервные копии делать уже средствами этого nas (потому что только он сможет к примеру давать эффективные инкрементальные копии), конечно резервированием машин (данных) могут заниматься сами виртуальные машины изнутри своими средствами. <br/> <br/> Бакап конфига делать штатными инструментами, теми же скриптами PowerCLI из PowerShell, восстановление будет из файла одной командой (сервер перезагрузится и все работает). <br/> <br/> p.s. на сколько я знаю у vmware есть HA кластер, можно заранее настроить backup сервер, и либо планово либо по обнаружению сбоя, переносить туда сервера, время отключения в этом случае будет секунды-минуты. <br/> <br/> это благодаря выносу образов на отдельно стоящий nas, но это накладывает свои требования к сети до него (спасибо 10гб сетевые карты сейчас очень доступны) <br/> <br/> p.p.s. если у вас образы хранятся локально на той же машине, то как я нагуглил (я думал что у ESXi этого нет) VMware VADP + CBT (эффективно инкрементальные копии) но это вопрос наличия лицензии на соответствующие компоненты. <br/> <br/> всегда задаю вопрос, почему именно ESXi и VMware? что вас заставляет ограничивать себя проприетарным функционалом и забористыми ценами? чем не угодили открытые и простые как валенок lxc/kvm/vbox? virtmanager/proxmox? когда собираешь из открытых компонентов себе конструкцию, как из лего, можно получить очень эффективные решения, позволяющие в т.ч. сэкономить и на железе, но само собой не отменяет оплату человеку, который у тебя все это будет поддерживать... но бизнесу, особенно в долгосроке, выгодно платить своему сотруднику, ведь у тебя после этого останется созданное им (особенно если следить за этим и не порождать локальный вендорлок) и даже может быть сам сотрудник, т.е. вложенные деньги останутся в компании как ресурс, а вот оплата лицензий и абонентки (если облака) улетает в никуда, не оставляя после себя ничего кроме 'сожалений'.
отдельный veeam или другая бекапилка. <br/> Хранить бекапы отдельно от виртуальной инфраструктуры. <br/> Использовать для MS SQL always on или patrony с  pgbounser для postgresql. <br/> Максимально идти по пути IaC, gitOps, то есть если тачки типовые, то не проще ли их из кода разворачивать через vagrant. Приложения через кубер, ну или если вы любители standalone решений, то ansible. <br/> Я к тому, что если вы можете из кода воспроизвести инфраструктуру и сервисы, то это очень хорошо. Бекапы конечно всё равно нужны, но они не так критичны.
Похожие вопросы