ВМ уже работает из бэкапа. Почему Stop publishing — это не «завершить восстановление»

Ситуация знакомая: упал хост или развалился массив, вы за шесть минут подняли сервер прямо из бэкапа, люди работают, тикет закрыт. Через два дня кто-то открывает консоль Veeam, видит незакрытую сессию Instant Recovery и жмёт Stop publishing — «ну сервис же уже работает, надо прибраться». В этот момент вы теряете два дня работы всей компании. Разбираю, что физически происходит при Instant Recovery, где лежат изменения, чем Migrate to production отличается от Stop publishing, сколько это стоит по простою и как я закрываю такие восстановления у себя.

«Сервис поднялся» — это ещё не восстановление

Разберём механику, потому что почти все ошибки растут именно отсюда. Когда вы запускаете Instant Recovery to VMware vSphere, Veeam не распаковывает бэкап на боевое хранилище. Он монтирует образ рабочей нагрузки хосту напрямую из сжатых и дедуплицированных файлов бэкапа, лежащих в репозитории. В документации Veeam это названо честно: создаётся полностью работоспособная «временная запаска» (temporary spare) с ограниченной производительностью ввода-вывода. Ограниченной — потому что чтение идёт через vPower NFS из дедуплицированного контейнера, а не с вашего SAN-LUN.

Отсюда первый вывод, который надо проговорить руководителю ещё в момент аварии: сервис вернулся, а восстановление — не закончено. Сам исходный образ в бэкапе открыт только на чтение, Veeam туда ничего не пишет. Всё, что пользователи наработали после старта ВМ, живёт отдельно, в служебных файлах. Пока эти файлы не слиты с образом и не перенесены на боевой датастор, у вас нет восстановленного сервера — у вас есть конструкция из бэкапа и дельты, которая держится на живой сессии Instant Recovery.

Второй вывод — про производительность. Я не раз видел, как после Instant Recovery 1С начинает «тупить», админ лезет искать блокировки в SQL, а причина в том, что база физически читается из бэкапа через NFS-шару, поднятую бэкап-сервером. Это нормально и это временно. Не надо в этот момент чинить производительность — надо планировать миграцию на боевое хранилище, она и есть лечение.

И третье, чисто организационное. Опубликованная ВМ, поднятая в новую локацию, не входит ни в одно задание резервного копирования. То есть пока вы «живёте на запаске», у вас нет свежих бэкапов этого сервера. Двое суток на Instant Recovery без переноса — это двое суток без точек восстановления. Об этом почему-то никто не думает, пока не случается вторая авария подряд.

• Instant Recovery = ВМ запущена из бэкапа, а не восстановлена на боевой датастор.
• Исходный образ бэкапа — read-only, изменения пишутся в отдельные файлы.
• Производительность ввода-вывода заведомо ниже боевой, это ожидаемо.
• Опубликованная ВМ не бэкапится, пока вы её не перенесёте и не добавите в задание.

Где на самом деле лежат ваши два дня работы

Изменения запущенной ВМ Veeam складывает в redo log — вспомогательные файлы, которые хранят всё, что произошло с момента старта из бэкапа. По умолчанию они лежат на vPower NFS-сервере, физически — в папке IRCache на томе бэкап-сервера или mount-сервера с наибольшим количеством свободного места, обычно это что-то вроде C:\ProgramData\Veeam\Backup\IRCache. То есть данные вашего боевого сервера за последние двое суток лежат на системном диске бэкап-сервера. Документация Veeam формулирует судьбу этих файлов прямо: изменения отбрасываются, как только восстановленная ВМ удалена, и сливаются с образом, если ВМ мигрирована в продакшен. Осознайте это один раз — и дальше вы никогда не будете жать лишние кнопки не глядя.

На шаге Datastore мастера Instant Recovery (в User Guide 13 он называется Select Destination for Virtual Disk Updates и доступен только при восстановлении в новую локацию или с другими настройками) есть галка Redirect write cache: она перенаправляет redo log на выбранный датастор виртуальной инфраструктуры. Veeam при этом делает снимок ВМ и кладёт его в каталог Veeam IR на выбранном датасторе вместе с метаданными изменений. Я ставлю её всегда, когда восстановление не тестовое. Причины две. Во-первых, место: требование Veeam — свободного места в vPower NFS-датасторе должно быть не меньше объёма оперативной памяти восстанавливаемой ВМ плюс 200 МБ, а дальше расход растёт вместе с записью внутрь ВМ. Для сервера с 32 ГБ RAM это 32,2 ГБ только на старте, на системном диске бэкап-сервера столько обычно нет. Во-вторых, надёжность: держать дельту боевого сервера на C: бэкап-сервера — плохая идея сама по себе. Плата за редирект одна, и о ней ниже: финализировать такую ВМ через Storage vMotion уже не получится, только через Quick Migration.

Есть отдельная засада: если вы собираетесь финализировать восстановление через Veeam Quick Migration в режиме SmartSwitch, требование по свободному месту в vPower NFS-датасторе увеличивается ещё на объём RAM ВМ. И отдельно — не кладите redo log на vSAN-датастор, если суммарный размер дисков восстанавливаемой ВМ больше 2 ТБ: Veeam не сможет создать снимок, и восстановление свалится. Плюс миграция с vSAN идёт заметно медленнее, потому что Veeam не может вычислить разницу между источником и целью и вынужден читать диски целиком, а не дельту.

И ещё одно, что редко читают: redo log удаляются автоматически после завершения задания проверки восстановления (recovery verification job, он же SureBackup). Для боевого Instant Recovery это не работает — там сессию закрываете вы руками, и от того, какой кнопкой вы её закроете, зависит судьба этих файлов.

• redo log по умолчанию — vPower NFS, папка IRCache на бэкап/mount-сервере.
• Свободного места нужно ≥ RAM ВМ + 200 МБ, и ещё + RAM, если финализировать через SmartSwitch.
• Redirect write cache на шаге Datastore переносит дельту на нормальный датастор.
• vSAN под redo log при дисках >2 ТБ — снимок не создастся, восстановление упадёт.
• vVol в качестве места под изменения использовать нельзя.
• С Redirect write cache финализация через Storage vMotion недоступна — только Veeam Quick Migration.

Разбор из практики: «ПереплётЦех», 38 рабочих мест, двое суток на запаске

Переплётная мастерская «ПереплётЦех»: 38 рабочих мест — приём заказов, препресс, производство и бухгалтерия. Два хоста ESXi 8.0 U3 под vCenter 8.0.3, дисковая полка по iSCSI, Veeam Backup & Replication 13 на отдельном физическом сервере с репозиторием на ReFS. Сервер PC-AP01: 8 vCPU, 32 ГБ RAM, диск ОС 120 ГБ и диск данных 400 ГБ, на нём MS SQL и сервер 1С с базой заказов и бухгалтерией. В четверг утром на полке умирает RAID-контроллер, LUN отваливается, оба хоста видят датастор как inaccessible. Классика.

Instant Recovery запустили за шесть минут: точка восстановления с ночи, восстановление в новую локацию — на локальный датастор второго хоста, потому что общее хранилище лежало. Галку Redirect write cache поставили сразу и указали тот же локальный датастор второго хоста, где было около 900 ГБ свободно. На vPower NFS оставлять не стали: на бэкап-сервере на C: было около 24 ГБ свободно, а по требованию нужно было 32,2 ГБ — ВМ просто не стартовала бы. Люди сели работать через 20 минут после звонка.

Полку чинили полтора дня, потом ещё полдня собирали массив и раскатывали LUN заново. Всё это время мастерская работала «на запаске». 1С заметно подтормаживала на тяжёлых отчётах по заказам — это ровно то самое ограничение ввода-вывода, и я честно предупредил директора, что до субботы будет так. За двое суток дельта в redo log выросла до 11 ГБ: это заказы, накладные на материалы, документы бухгалтерии, служебные базы SQL и логи. Одиннадцать гигабайт живой работы приёма заказов, производства и бухгалтерии — вот их и убивает Stop publishing.

Финализировали в субботу вечером. Migrate to production, целевой датастор — восстановленный LUN. И вот тут важная штука, к которой надо готовиться заранее. Во-первых, раз изменения были перенаправлены с vPower NFS, Storage vMotion для финализации не годится — Veeam прямо пишет, что он применим, только если изменения остались на NFS-датасторе. Во-вторых, у ВМ 32 ГБ RAM, а Veeam Quick Migration переключается в режим ColdMigration, если RAM больше 8 ГБ или процессоры хостов несовместимы. То есть SmartSwitch с «подвисанием» на секунды нам не светил в принципе — был честный простой. Основной объём (около 350 ГБ занятого места) Veeam вычитал из репозитория при работающей ВМ за 27 минут, а собственно даунтайм — остановка ВМ и досинхронизация дельты — занял 6 минут. В 22:50 сервер уже работал с боевого LUN, в 23:05 я добавил его в задание резервного копирования и погасил сессию.

• Порядок был такой: Instant Recovery в новую локацию → Redirect write cache → работа на запаске → Migrate to production в окно → добавление в задание бэкапа.
• Ошибка, которой избежали: оставить redo log на C: бэкап-сервера, где не хватало места под 32 ГБ RAM.
• Ошибка, которую чуть не сделали: планировать миграцию «без простоя» при RAM 32 ГБ — ColdMigration тут неизбежен, а Storage vMotion после редиректа недоступен.

Что делает Migrate to production и почему это не Storage vMotion

Правый клик по ВМ в узле Instant Recovery → Migrate to production запускает мастер Quick Migration. Дальше Veeam сам анализирует инфраструктуру и выбирает способ переезда. Если vSphere-лицензия позволяет и хосты подходят — используются штатные vMotion и Storage vMotion. Но у Storage vMotion при финализации Instant Recovery есть жёсткое условие: он работает, только если изменения ВМ остались на vPower NFS-датасторе без редиректа. Тогда исходные данные тянутся с NFS на боевое хранилище и консолидируются с дельтой без выключения ВМ. Если нет (нет лицензии на vMotion, standalone-хосты без vCenter, несовместимые CPU) — включается собственная технология Veeam Quick Migration с двумя режимами: SmartSwitch (ВМ приостанавливается, переносится конфиг и дельта, ВМ возобновляется на целевом хосте) и ColdMigration (ВМ выключается, копируется дельта, ВМ включается на целевом хосте).

Ключевой момент, который экономит нервы при планировании окна: между хостами с совместимыми процессорами Veeam использует SmartSwitch, а между несовместимыми CPU или если у ВМ больше 8 ГБ RAM — ColdMigration. Восемь гигабайт. Любой ваш нормальный сервер 1С или SQL под это правило попадает. Не обещайте бизнесу миграцию без простоя — обещайте короткое окно и назовите честную цифру.

Второй момент, который часто понимают неправильно. При финализации Instant Recovery Quick Migration не тянет данные из vPower NFS-датастора. Он регистрирует ВМ на целевом хосте, восстанавливает её содержимое из файла бэкапа в репозитории и синхронизирует восстановленное с работающей ВМ. Практический смысл: скорость финализации определяется скоростью вашего репозитория и прокси, а не скоростью запущенной запаски. Если репозиторий — медленный NAS по одному гигабиту, окно миграции будет считаться часами, и это надо знать до аварии, а не в субботу вечером.

И маленькое, но злое: Veeam не сохраняет настройки шифрования, если ВМ переносится через VMware vMotion — включать VM Encryption после переезда придётся руками. Плюс Quick Migration невозможна для ВМ с разделяемой SCSI-шиной (SCSI bus sharing), потому что нужен снимок, а VMware его для таких ВМ не поддерживает. Если у вас кластер MSCS на общих дисках — сценарий финализации там другой, планируйте отдельно.

• vMotion / Storage vMotion — если есть лицензия и redo log не перенаправлялся с vPower NFS.
• Veeam Quick Migration SmartSwitch — совместимые CPU и RAM ВМ не больше 8 ГБ (плюс ещё RAM ВМ свободного места в vPower NFS).
• Veeam Quick Migration ColdMigration — несовместимые CPU или RAM ВМ > 8 ГБ, то есть почти всегда.
• Данные при финализации читаются из репозитория, а не из работающей запаски.
• SCSI bus sharing — Quick Migration недоступна; шифрование ВМ после vMotion надо включать заново.

Что делает Stop publishing: прямой ответ на вопрос

Stop publishing удаляет опубликованную ВМ с того хоста, который вы выбрали целью восстановления. Формулировка Veeam в документации предельно недвусмысленная: все изменения, сделанные в восстановленной ВМ, будут потеряны. Не «останутся в бэкапе», не «сольются автоматически», не «поднимутся при следующем запуске» — потеряны. Эта кнопка предназначена для случая, когда тест провалился: подняли ВМ проверить бэкап, посмотрели, что ОС бутится и приложение живо, и погасили. Для этого сценария она идеальна.

Теперь самое опасное, о чём знают единицы. Если Instant Recovery выполнялось в исходную локацию (Restore to the original location), то при Stop publishing удаляются и восстановленная, и исходная ВМ. Логика простая и беспощадная: при восстановлении в исходное расположение Veeam удаляет оригинальную ВМ ещё на старте, чтобы не было конфликта. Значит, к моменту, когда вы жмёте Stop publishing, оригинала уже нет, а вы своими руками убираете единственную запущенную копию. Остаётся только бэкап и обычное долгое восстановление — с потерей всего, что наработали после точки восстановления.

Я специально проверял это на лабораторном стенде, прежде чем писать регламент для инженеров: поднял тестовую ВМ Instant Recovery в исходную локацию, поработал в ней, нажал Stop publishing — из инвентаря vCenter исчезло всё. Отдельного предупреждения «оригинал тоже будет удалён» я в консоли не увидел; оно чётко прописано в разделе Finalizing Instant Recovery документации, и для Hyper-V там стоит ровно такое же Important. Не рассчитывайте, что интерфейс вас остановит.

Поэтому ответ на вопрос из заголовка: нет, нажимать Stop publishing, чтобы «завершить восстановление», нельзя. Завершает восстановление Migrate to production. Stop publishing — это «отменить и выбросить». Две кнопки, стоящие рядом в одном контекстном меню, делают противоположные вещи, и цена ошибки — вся работа компании с момента аварии.

• Stop publishing = отмена восстановления, все изменения в опубликованной ВМ теряются.
• При восстановлении в исходную локацию удаляются обе ВМ: и восстановленная, и оригинальная.
• Легитимные сценарии Stop publishing: проверка бэкапа, тест DR, неудачный запуск, ошибочная точка восстановления.
• Нелегитимный сценарий: «прибраться в консоли, сессия висит уже вторые сутки».

Мой регламент закрытия Instant Recovery

Регламент простой, но его надо иметь на бумаге до аварии, потому что во время аварии думать некогда. Первое: сразу после запуска Instant Recovery заводится задача в трекере с текстом «восстановление НЕ завершено, сессия открыта, финализация до <дата>». Мы такие вешаем в Планфикс с дедлайном не больше 72 часов. Пока задача жива — никто не трогает узел Instant Recovery в консоли Veeam.

Второе: доступ к консоли Veeam на время аварии сужается. У нас на бэкап-серверах роль Veeam Backup Operator раздаётся только тем, кто занят инцидентом. Причина банальна: Stop publishing — это одно нажатие в контекстном меню без подтверждения последствий, а в аварийном режиме в консоль лезут все подряд, включая подрядчиков и «а я просто посмотреть».

Третье: следим за местом там, где лежит redo log, и за размером дельты. Если места перестанет хватать, ВМ встанет колом, и вы получите вторую аварию поверх первой. Заодно размер дельты — это ваша прикидка длительности простоя при финализации.

Четвёртое: финализация в согласованное окно, Migrate to production, а после переезда — проверить, что ВМ работает с боевого датастора, и обязательно добавить её в задание резервного копирования. Если Instant Recovery выполнялось в новую локацию, восстановленная ВМ в старом задании не появится сама: Veeam прямо пишет, что добавлять её в задание нужно вручную. Пятое: только после этого закрывать сессию.

Для тех, кто автоматизирует, вот командлеты Veeam PowerShell из официального справочника v13. Обратите внимание на опечатку в имени параметра -DeleteSorceVmFiles — она реально живёт в продукте, это не мой промах при наборе. И не называйте переменную $host: это встроенная переменная PowerShell только для чтения, скрипт упадёт на присваивании.

# посмотреть все открытые сессии Instant Recovery и их Id
Get-VBRInstantRecovery | Format-List *

# финализация: перенос ВМ на боевой датастор через Veeam Quick Migration
$vm  = Find-VBRViEntity -Name 'PC-AP01'
$esx = Get-VBRServer -Name 'esxi-02.example.local'
$ds  = Find-VBRViDatastore -Server $esx -Name 'PROD-LUN01'
Start-VBRQuickMigration -Entity $vm -Server $esx -Datastore $ds -ForceVeeamQM

# ОТМЕНА восстановления (= Stop publishing): изменения будут потеряны безвозвратно
$session = Get-VBRInstantRecovery -Id '<Id сессии из вывода выше>'
Stop-VBRInstantRecovery -InstantRecovery $session

-DeleteSorceVmFiles я в боевом сценарии в новую локацию не ставлю: по справочнику он удаляет исходную ВМ после получения heartbeat от ВМ на целевом хосте, и при финализации в исходную локацию поведение зависит от способа миграции и этой галки — Veeam отдельно отсылает к шагу Finish Working with the Quick Migration Wizard. Сначала убедитесь, что понимаете, какая ВМ для Veeam здесь «исходная».

• Задача в трекере «восстановление не завершено» с дедлайном ≤72 часов.
• Ограничить доступ к консоли Veeam на время инцидента.
• Мониторить свободное место под redo log и рост дельты.
• Финализация Migrate to production в окно, затем ВМ в задание бэкапа.
• Сессию закрывать последней, после проверки, что ВМ живёт на боевом датасторе.

Hyper-V и Proxmox VE: другие потроха, те же две кнопки

В Instant Recovery to Microsoft Hyper-V нет vPower NFS. Veeam читает конфигурацию из файла бэкапа, создаёт на целевом хосте dummy-ВМ с пустыми дисками (поколение выбирает по исходной ВМ или по разметке: EFI или GPT — Gen 2, BIOS — Gen 1), делает защитный снимок и запускает ВМ. На репозитории и на хосте поднимается пара Veeam Data Mover, а собственный драйвер Veeam на хосте перенаправляет обращения к ещё не восстановленным блокам в файл бэкапа. Производительность такой ВМ тоже ограничена, и Veeam так же требует переносить её в продакшен.

Миграция на Hyper-V устроена иначе, чем на vSphere: запускается вторая пара Data Mover, которая в фоне копирует данные из репозитория и наполняет диски работающей ВМ, а драйвер перестаёт перенаправлять запросы к уже скопированным блокам — ВМ по ходу миграции ускоряется. Но кнопки финализации те же, и предупреждения в документации те же: Stop publishing удаляет восстановленные ВМ, все изменения теряются, а при восстановлении в исходную локацию удаляются и восстановленная, и исходная ВМ. Ещё одна мелочь: если после Migrate to production целевая локация отличается от исходной, старые ВМ остаются в Hyper-V, и убирать их нужно руками.

Proxmox VE Veeam поддерживает через Veeam Plug-in for Proxmox VE, который идёт с Veeam Backup & Replication начиная с версии 12.2. Бэкапы Proxmox-ВМ входят в список типов, которые можно поднять через Instant Recovery to VMware vSphere и Instant Recovery to Microsoft Hyper-V. Порядок работы с сессией не меняется: ВМ живёт на запаске, пока вы не нажали Migrate to production, а Stop publishing по-прежнему означает «выбросить». Для других сценариев с Proxmox сверяйтесь с User Guide плагина под вашу версию: механика у разных направлений восстановления отличается.

• Hyper-V: dummy-ВМ + защитный снимок + драйвер Veeam, чтение недостающих блоков из бэкапа через Data Mover.
• Hyper-V: миграция наполняет диски в фоне, ВМ ускоряется по ходу переноса.
• Hyper-V: Stop publishing при восстановлении в исходную локацию удаляет обе ВМ — как и на vSphere.
• Proxmox VE: плагин с VBR 12.2; бэкапы Proxmox-ВМ поднимаются через Instant Recovery на vSphere или Hyper-V.
• На любой платформе регламент один: Migrate to production → ВМ в задание бэкапа → закрытие сессии.

На что можно забить, а на что нельзя

Забить можно на просадку производительности в первые часы. Да, ВМ читается из дедуплицированного бэкапа, да, отчёты в 1С будут собираться дольше обычного. Это не поломка и не повод срочно что-то крутить. Объясните людям, что это временный режим, и спокойно готовьте окно миграции. Крутить SQL-планы и индексы, пока база живёт на vPower NFS, — потраченное время: после переезда цифры будут другими.

Забить можно и на желание «сделать всё красиво сразу» — восстановить в исходную локацию с исходными настройками, когда хранилище ещё не починено. Восстановление в новую локацию (Restore to a new location, or with different settings) даёт вам гибкость по датастору и сети и, что важно, не удаляет оригинальную ВМ. Единственная плата — потом руками поправить сетевые настройки и добавить ВМ в задание бэкапа.

А вот на что забивать нельзя. На место под redo log — кончится, встанет ВМ. На срок жизни сессии — чем дольше живёте на запаске, тем больше дельта и тем дольше простой при финализации, плюс всё это время нет свежих бэкапов. И на дисциплину доступа к консоли: одна кнопка Stop publishing стоит дороже, чем весь остальной сценарий вместе взятый.

Отдельно — про ограничения, которые лучше проверить заранее, на учениях, а не в бою: восстановление CSV-дисков кластера не поддерживается (кластерные диски автоматически исключаются), для Linux-нагрузок нужны dracut/mkinitrd/initramfs и монтирование ФС по UUID в /etc/fstab, иначе восстановленная ВМ может не загрузиться, а для vSphere 8.0 и новее Veeam требует, чтобы у исходной ВМ не было дисков на vVol-датасторе и чтобы она не находилась на хосте ESXi 8.0 или новее, — иначе восстановление упадёт; vVol нельзя выбрать и как место для изменений дисков. Проверять это надо один раз, в спокойной обстановке, прогоном SureBackup — и потом спать нормально.

• Проверьте на учениях: загрузку Linux-ВМ после IR (dracut/initramfs, fstab по UUID).
• Проверьте место под redo log для самой жирной по RAM ВМ.
• Посчитайте реальную скорость чтения из репозитория — это ваше окно финализации.
• Пропишите в регламенте, кто и когда имеет право на Stop publishing.

Частые вопросы