АйТи Фреш
Главная / Статьи / Серверы и хостинг
Серверы и хостинг

Добавили vTPM в Windows-ВМ — и Veeam ушёл с HotAdd на NBD. Что чинить на прокси

Автор: Семёнов Евгений Сергеевич, директор ООО «АйТи-Фреш» · · ~26 мин чтения
Добавили vTPM в Windows-ВМ — и Veeam ушёл с HotAdd на NBD. Что чинить на прокси
Иллюстрация к статье «Добавили vTPM в Windows-ВМ — и Veeam ушёл с HotAdd на NBD. Что чинить на прокси».

Ситуация, которую я разбирал уже у трёх клиентов подряд. Безопасники раскатали baseline, включили BitLocker с привязкой к TPM, виртуальным машинам добавили vTPM. Диски те же, сеть та же, задания в Veeam никто не трогал — а окно резервного копирования из двух часов выросло в шесть с половиной. И самое противное: ни одна задача не упала, всё зелёное. В статье — почему vTPM автоматически делает машину «зашифрованной» с точки зрения Veeam, как за минуту доказать, что прокси свалился в NBD, два рабочих способа это вылечить (с честным сравнением цены каждого) и что обязательно проверить в восстановлении, пока не стало поздно.

vTPM — это и есть шифрование ВМ. Просто вам об этом не сказали

Первое, что нужно уложить в голове: виртуальный TPM в vSphere не существует сам по себе. Он паразитирует на механизме VM Encryption. Документация VMware по vSphere 8 формулирует это без вариантов: «A vTPM depends on virtual machine encryption to secure vital TPM data, thus, it requires that you configure a key provider. When you configure a vTPM, the virtual machine files are encrypted but not the disks». То есть чтобы добавить vTPM, у вас уже должен быть настроен key provider — Standard KMS или vSphere Native Key Provider, — и в момент добавления устройства vCenter шифрует файлы VM Home: .vmx, .nvram, файлы подкачки, логи. Виртуальные диски при этом остаются незашифрованными, если вы явно не назначили машине политику VM Encryption Policy.

Отсюда и берётся ложное ощущение «мы же ничего не шифровали». Формально — не шифровали, диски как были в открытом виде, так и остались. Фактически машина в инвентаре vCenter имеет KeyId в конфигурации и является encrypted VM со всеми вытекающими. Ещё раз, дословно из документации VMware: «By default, no storage policy is associated with a virtual machine that has been enabled with a vTPM. Only the virtual machine files (VM Home) are encrypted».

Veeam эту тонкость не разделяет и делает правильно. В руководстве Veeam Backup & Replication 13 в разделе Encrypted VMs первая же строка — примечание: «All limitations and considerations below also apply to a VM with a Virtual Trusted Platform Module (vTPM) as vTPM requires VM encryption to be enabled». Страница помечена как применимая к билду 13.1.1.18. Это значит, что весь список ограничений для зашифрованных машин — целиком ваш, ровно с того момента, как вы нажали «Add New Device → Trusted Platform Module» на первой же виртуалке.

И главное ограничение звучит так: прокси должен работать в режиме Virtual appliance или Network, а прокси в режиме Virtual appliance «must be deployed on an encrypted VM». Прочитайте ещё раз. Не «желательно», не «рекомендуется». Прокси, который хочет забирать данные зашифрованной машины через HotAdd, сам обязан быть зашифрованной виртуалкой. Если он обычный — HotAdd для этих ВМ отваливается, и начинается самое интересное.

Проверьте прямо сейчас: если у вас появились Windows 11 или Server 2022/2025 с включённым Secure Boot и BitLocker «как положено» — почти наверняка у них есть vTPM, и половина парка у вас уже зашифрована, хотя в отчётах по шифрованию она не светится.

Как за две минуты доказать, что прокси свалился в NBD

Задание не падает — вот в чём подлость. Veeam честно пытается взять HotAdd, не может, и тихо переключается на сеть. Ровно это описал администратор на R&D-форуме Veeam в ветке про Linux-прокси и Windows 11 с vTPM: «It would always fail over to NBD when trying to backup Windows 11 which I now understand is due to the fact they are encrypted. Veeam says we should use proxies that are encrypted to back up encrypted VMs». Человек полгода ловил плавающие ошибки прокси и упёрся именно в это.

Смотреть надо в статистику задания, в детализацию по конкретной ВМ. Строка вида Using backup proxy VMware Backup Proxy for disk Hard disk 1 [nbd] — приговор. Было [hotadd], стало [nbd]. Раскройте задание в консоли, ткните в нужную машину и пробегитесь по правой панели: там будет и режим, и реальная скорость обработки. Если хочется быстрее и по всему парку — грепните логи на бэкап-сервере.

Отдельно о том, что именно видно, когда HotAdd не сработал. Отдельного красного сообщения об ошибке в сессии нет: задание получает статус Success, а в строке по диску вместо [hotadd] стоит [nbd] — это и есть след срабатывания опции failover to network mode. В подробных логах задания на бэкап-сервере рядом с выбором прокси появляются записи о том, что Virtual appliance для этой машины недоступен и выбран сетевой режим; точная формулировка отличается от билда к билду, поэтому я ищу не текст ошибки, а сам маркер режима в квадратных скобках. Если же failover выключен, задание упадёт на этой ВМ с ошибкой обработки диска — и тогда уже есть что отдать в поддержку Veeam вместе с логами (Help → Support Information).

Прежде чем винить шифрование, отсеките банальные причины, из-за которых HotAdd отваливается и у обычных машин. По руководству Veeam для Virtual appliance прокси и обрабатываемые ВМ должны находиться в одном datacenter vCenter, на прокси обязан быть контроллер SCSI 0:X, а IDE-диски в этом режиме не обрабатываются вовсе. Если у «пострадавших» машин всё это в порядке, а общее у них одно — появившийся vTPM, диагноз можно считать поставленным.

# Linux-based backup server / Veeam Software Appliance
grep -rhoE 'for disk .* \[(hotadd|nbd|nbdssl|san|nfs)\]' /var/log/veeam/Backup/ \
  | sed -E 's/.*\[(.*)\]/\1/' | sort | uniq -c | sort -rn
# Windows-based backup server
Select-String -Path 'C:\ProgramData\Veeam\Backup\*\*.log' -Pattern '\[(hotadd|nbd|nbdssl|san)\]' |
  ForEach-Object { $_.Matches.Value } | Group-Object | Sort-Object Count -Descending

Параллельно составьте список машин с vTPM — чтобы понимать масштаб, а не гадать. Через PowerCLI это одна строка. Обратите внимание: проверять надо именно наличие устройства VirtualTPM, а не «зашифрована ли ВМ» в интерфейсе, потому что по политике хранения такая машина может выглядеть совершенно обычной.

Get-VM | Where-Object {
  $_.ExtensionData.Config.Hardware.Device | Where-Object { $_ -is [VMware.Vim.VirtualTPM] }
} | Select-Object Name, PowerState, @{N='HasKeyId';E={ $null -ne $_.ExtensionData.Config.KeyId }}
Опция «Failover to network mode if primary mode fails, or is unavailable» в настройках прокси — ваш друг и ваш враг одновременно. Она спасает задания от падения и она же прячет от вас деградацию транспорта. Не выключайте её, но заведите отчёт по режимам транспорта, иначе узнаете о проблеме от бухгалтерии, а не от мониторинга.
Добавили vTPM в Windows-ВМ — и Veeam ушёл с HotAdd на NBD. Что чинить на прокси — схема
Схема к статье. Открыть схему в полном размере

Разбор с проекта: вязальное производство «Тёплая вязка», 24 рабочих места

Стенд: вязальное производство «Тёплая вязка», 24 рабочих места — офис, склад пряжи и цех с программируемыми вязальными машинами. Два ESXi 8.0 U3 на общем iSCSI-датасторе, vCenter 8, Veeam Backup & Replication 13.1.1.18. Всего 18 виртуальных машин: контроллер домена, 1С, файловый сервер с раскладками узоров, терминальный сервер, сервер управления машинами цеха и несколько служебных. Прокси — одна обычная виртуалка Windows Server 2022, 4 vCPU / 8 ГБ, в режиме Virtual appliance с включённым failover в сеть. Репозиторий — hardened на отдельном сервере. Окно копирования: 21:00–06:00, полный бэкап в субботу, инкременты по будням. До событий full 1,6 ТБ укладывался в 1 час 5 минут, будничный инкремент — 12–15 минут.

Весной подрядчик по ИБ прогнал свой baseline: Secure Boot, BitLocker с привязкой к TPM, Credential Guard. Под это 6 машин (терминальный сервер, 1С, файловый сервер и три Windows 11 для технологов и бухгалтерии) получили vTPM. Key provider — vSphere Native Key Provider, развёрнутый в тот же день. Никто не считал это изменением инфраструктуры резервного копирования. Инженер, который добавлял устройства, вообще не знал, что vTPM тянет за собой шифрование.

Через сутки прилетел первый алерт «job runs longer than expected». Через неделю будничный инкремент шёл 50 минут вместо 15, полный бэкап в субботу — 3 часа 20 минут. Ни одной ошибки, все задания Success. Разбор занял двадцать минут: в детализации по этим 6 машинам стояло [nbd], у остальных 12 — [hotadd]. Скорость обработки по «пострадавшим» ВМ упала примерно с 450 МБ/с до 90–100 МБ/с. Дальше арифметика: management-интерфейс vmk0 на хостах был на 1 Гбит/с, потолок ~110 МБ/с на хост, и через него же ходил мониторинг.

Первая попытка починки была неправильной, и я про неё честно рассказываю, потому что так делают почти все. Мы включили галку «Enable host to proxy traffic encryption in Network mode (NBDSSL)» — рассудив, что раз машины зашифрованные, то и транспорт надо шифровать, и, может, Veeam перестанет капризничать. Стало хуже: −18 % к скорости и заметный рост CPU на хостах. Логично: NBDSSL не возвращает HotAdd, он просто добавляет TLS поверх того же NBD. Документация Veeam прямо предупреждает: «traffic encryption puts more stress on the CPU of an ESXi host and can decrease performance».

Что сработало: подняли второй прокси — отдельную ВМ Windows Server 2022, 4 vCPU / 8 ГБ, выключили её, назначили политику хранения «VM Encryption Policy», включили. Машина стала зашифрованной, и HotAdd для зашифрованных ВМ ей открылся. Потом вынесли 6 vTPM-машин в отдельное задание и в его настройках на шаге Storage выбрали только этот прокси (Backup proxy → Choose → Use the selected backup proxy servers only), чтобы Veeam не отдавал их «обычному» прокси и не сваливался обратно в NBD. Инкремент вернулся к 15–17 минутам, полный — 1 час 15 минут. CPU-надбавка на хосте, где живёт зашифрованный прокси, в окне копирования — несколько процентов. Управляемо. Коммутатор на 10 Гбит/с под management-сеть заложили в план закупок на следующий год — это задел на случай, когда машины всё-таки уходят в сеть.

Дельта между 15 минутами и часом кажется терпимой ровно до того дня, когда субботний full наезжает на утреннюю смену. У «Тёплой вязки» цех загружает программы в вязальные машины с файлового сервера в 06:30, и растущий объём копий через год-полтора упёрся бы именно в это время.
Порядок действий: Разбор с проекта: вязальное производство «Тёплая вязка», 24 рабочих места — схема
Порядок действий: Разбор с проекта: вязальное производство «Тёплая вязка», 24 рабочих места. Открыть схему в полном размере

Вариант А: зашифрованный прокси и возвращённый HotAdd

Это мой рабочий вариант по умолчанию, если у вас больше пары-тройки машин с vTPM или они крупные и общий датастор. Логика простая: у Veeam всего два разрешённых режима, из них быстрый — один, и цена входа в него — одна зашифрованная виртуалка. Порядок действий на боевом кластере такой.

1. Key provider уже есть (иначе vTPM бы не добавился) — убедиться, что он в состоянии Active
   и хосты кластера доверяют ему: vCenter → Configure → Key Providers
2. Развернуть отдельную ВМ под прокси (или взять существующую), выключить её
3. VM → Edit Settings → VM Options → Encryption (или назначить политику
   хранения VM Encryption Policy на VM Home и диски)
4. Включить ВМ, дождаться завершения фонового шифрования дисков
5. В Veeam: Backup Infrastructure → Backup Proxies → Add/Edit → Transport mode →
   Virtual appliance, галка Failover to network mode — оставить
6. Задание для машин с vTPM: шаг Storage → Backup proxy → Choose →
   Use the selected backup proxy servers only → только этот прокси
7. Прогнать активный full и проверить, что в детализации снова [hotadd]

Отдельно про права. Учётка, под которой Veeam ходит в vCenter, должна иметь привилегии группы Cryptographic operations — как минимум Encrypt, Encrypt new, Migrate, Register VM и Direct Access. VMware перечисляет их как обязательные для операций с vTPM-машинами, и это очень частая причина того, что «всё настроили, а прокси всё равно не может». Стандартная роль read-only плюс пара галок тут не проходит. Проверяйте под тем же аккаунтом, что и Veeam, а не под администратором SSO — иначе получите ложноположительный результат.

Где эта схема ломается. Первое: все хосты кластера обязаны иметь доступ к key provider, иначе при DRS-миграции зашифрованного прокси на «неправильный» хост вы получите неожиданный отказ; и помните, что прокси и обрабатываемые ВМ по требованиям Veeam должны быть в одном datacenter. Второе: Direct storage access для зашифрованных ВМ Veeam не допускает — на странице Encrypted VMs разрешены только Virtual appliance и Network, так что для остального парка оставьте отдельный, незашифрованный прокси. Третье, про роль прокси на «коробочных» компонентах: по таблице Transport Mode Limitations Veeam Hardened Repository в роли прокси умеет только Network mode, а Veeam Software Appliance — Virtual appliance и Network, но без Direct storage access. Если сервер Veeam у вас физический или hardened-репозиторий назначен прокси, HotAdd для vTPM-машин с него не получить — нужна отдельная зашифрованная прокси-ВМ.

Не забудьте про сам прокси в плане восстановления. Зашифрованная прокси-ВМ без доступного key provider — это кирпич. Если вы восстанавливаете инфраструктуру с нуля, поднимайте key provider раньше, чем прокси, иначе получите классическую петлю: чтобы восстановить, нужен прокси, а чтобы запустить прокси, нужны ключи.

Вариант Б: остаться в Network mode и выжать из него всё

Если машин с vTPM две-три и они по 60 ГБ — не надо городить зашифрованный прокси. Оставьте NBD и займитесь тем, что реально влияет на скорость. Veeam про Network mode пишет прямо: «The Network mode has low data transfer speed over LAN», а в таблице режимов по типам хранилищ добавляет, что этот режим не рекомендуется на 1 Gb Ethernet, но хорошо работает на 10 Gb Ethernet. Вот в эту нишу и надо целиться.

Практический список по убыванию отдачи. Первое и главное — management-интерфейс хостов на 10 Гбит/с, потому что NBD ходит именно через него, и на гигабите вы упрётесь в ~110 МБ/с на хост независимо от того, что там за СХД. Второе — раскидать прокси и параллельные задачи так, чтобы на один хост не приходилось слишком много одновременных потоков NBD (у меня на практике комфортная граница — 3–4 диска на хост): management-стек ESXi не рассчитан на роль транспорта данных, и при переподписке вы начнёте ловить не только медленный бэкап, но и подтормаживание самого vCenter. Третье — разнести машины с vTPM в отдельное задание с собственным расписанием, чтобы они не конкурировали за окно с остальными.

Теперь про NBDSSL, вокруг которого больше всего путаницы. Галка «Enable host to proxy traffic encryption in Network mode (NBDSSL)» живёт в окне Transport Mode настроек прокси. Ключевой момент, который надо проговорить вслух: то, что исходная ВМ зашифрована, никак не шифрует трафик между хостом и прокси. Это два независимых механизма. Если ваши требования по ИБ говорят «данные не ходят по сети открытым текстом» — галку надо ставить осознанно и закладывать просадку. Если такого требования нет, а трафик и так живёт в изолированном сегменте — не ставьте, вы просто отдадите CPU хостов ни за что.

Мой критерий выбора между А и Б, если совсем коротко. Суммарный объём машин с vTPM меньше 500 ГБ и инкремент влезает в окно с двукратным запасом — живите на NBD, не усложняйте. Больше терабайта, или окно уже впритык, или парк vTPM-машин будет расти (а он будет расти, потому что Windows 11 и Server 2025 подталкивают к этому по умолчанию) — делайте зашифрованный прокси, это разовая работа на полдня.

Никакая настройка Veeam не заменит гигабитный vmk0. Если после всех правок скорость упорно стоит около 110 МБ/с на хост — вы упёрлись не в Veeam, а в физику management-сети, и дальше настраивать нечего.
Цифры и версии: Вариант Б: остаться в Network mode и выжать из него всё — схема
Цифры и версии: Вариант Б: остаться в Network mode и выжать из него всё. Открыть схему в полном размере

Восстановление: место, где vTPM аукается по-настоящему

Медленный бэкап — это неприятно. Невозможность восстановиться — это конец бизнеса. И вот тут vTPM подкидывает пару сюрпризов, о которых думают в последнюю очередь. VMware пишет: «When you back up a virtual machine enabled with a vTPM, the backup must include all virtual machine data, including the *.nvram file. If your backup does not include the *.nvram file, you cannot restore a virtual machine with a vTPM. Also, because the VM home files of a vTPM-enabled virtual machine are encrypted, ensure that the encryption keys are available at the time of a restore».

Разложу на практические следствия. Первое: копия на уровне гостевой ОС (агент внутри Windows) машину с vTPM как машину с vTPM не вернёт — нет .nvram, нет виртуального устройства, нет ключей BitLocker внутри гостя. Если у вас парк на агентах и вы только что включили BitLocker с привязкой к TPM — вы получили ситуацию, где восстановленная машина попросит recovery key при первой же загрузке. Ключи должны быть в AD или Entra, и это надо проверить до, а не после.

Второе: ключи шифрования должны быть доступны на момент восстановления. Если вы используете vSphere Native Key Provider — экспортируйте его резервную копию и храните её отдельно от кластера, лучше вообще вне виртуализации. Восстанавливать зашифрованную ВМ в кластер, где нет провайдера ключей, бессмысленно: файлы вы вернёте, машина не поедет. Это самая частая дыра в планах DR у тех, кто внедрил vTPM за месяц до того, как начал думать о восстановлении.

Отдельно — восстановление на другой vCenter, например на резервную площадку или на заново развёрнутый vCenter после аварии. Native Key Provider живёт в конкретном vCenter, и на новом его нет. Broadcom описывает путь так: резервная копия NKP выгружается в файл формата PKCS#12 (опционально с паролем), а на целевом vCenter провайдер возвращается через Configure → Security → Key Providers → Restore с указанием этого файла и пароля; для операции нужны привилегии Cryptographic operations → Manage key servers. Без этого файла ключ на другом vCenter взять неоткуда: Veeam вернёт файлы машины, но vCenter не сможет расшифровать VM Home, и машина с vTPM не запустится. Требования к стенду для NKP — vCenter и ESXi не ниже 7.0 Update 2; TPM 2.0 на хостах не обязателен, если вы не включили опцию «только для хостов с TPM».

Со стороны Veeam для восстановления зашифрованных ВМ действует то же правило, что и для бэкапа: инфраструктура шифрования на целевой стороне должна быть настроена заранее, а прокси — работать в Virtual appliance (зашифрованная ВМ) или Network. Veeam позволяет восстановить зашифрованную машину как незашифрованную, но для vTPM это слабое утешение: состояние виртуального TPM хранится в зашифрованном .nvram, и без ключей гость потеряет привязку BitLocker и попросит recovery key. Поэтому мой порядок при DR на чужой vCenter такой: восстановить NKP из .p12, создать или проверить политику VM Encryption Policy на целевом датасторе, развернуть зашифрованный прокси и только потом запускать restore.

Третье, из документации Veeam: если восстанавливаете ВМ как зашифрованную в выбранную локацию, целевой датастор должен быть под узлом VM Encryption Policy. И отдельная сноска, которую легко пропустить: «Guest OS file restore for encrypted VM replicas is not supported» — то есть достать один файлик из реплики зашифрованной машины у вас не получится, придётся восстанавливать из бэкапа. Для репликации между площадками требование ещё жёстче: общий KMS или кластеры KMS с общими ключами на обеих сторонах. А если KMS на целевой стороне не настроен вовсе, задание не упадёт, но реплики приедут незашифрованными — Veeam про это честно предупреждает отдельной фразой.

Практика: раз в квартал делайте тестовое восстановление одной машины с vTPM в изолированную сеть. Не Instant Recovery ради галочки, а полноценный restore с проверкой, что гость загрузился, BitLocker не запросил recovery key и доменная привязка жива. Занимает час, экономит выходные.

Экспорт Native Key Provider, лежащий на файловой шаре внутри того же кластера, который вы собираетесь восстанавливать, — это не резервная копия ключей. Это самообман. Выносите наружу.

Чек-лист и приоритеты: что делать сегодня, а на что можно забить

Соберу всё в порядок действий. Если у вас уже появились машины с vTPM и вы не знаете, в каком состоянии транспорт, — вот последовательность на ближайшие пару часов, отсортированная по отдаче.

И честно про то, на что можно забить. Не надо срочно снимать vTPM с машин ради скорости бэкапа — это шаг назад по безопасности ради получаса в окне, и вы всё равно вернётесь к нему через год. Не надо переводить весь парк прокси на зашифрованные ВМ — достаточно одного выделенного под vTPM-машины. Не надо включать NBDSSL «для порядка», если у вас нет соответствующего требования: вы заплатите процентами CPU хостов за шифрование трафика, который и так не покидает изолированный сегмент. И совершенно точно не надо паниковать: задания не падают, копии есть, проблема в производительности, а не в целостности данных.

Что действительно критично и не терпит отлагательств — это восстановление. Проверьте, что в задании включён режим, при котором копируются все файлы ВМ, что ключи выгружены и лежат снаружи, и что вы хотя бы один раз руками восстановили vTPM-машину и она загрузилась. Всё остальное — вопрос настройки, который можно решить в плановом порядке.

Заведите в мониторинге простую проверку: доля задач, отработавших в hotadd, к общему числу. Один график — и вы узнаёте о смене транспорта в день, когда это произошло, а не через месяц по жалобам на «медленное утро».
Порядок действий: Чек-лист и приоритеты: что делать сегодня, а на что можно забить — схема
Порядок действий: Чек-лист и приоритеты: что делать сегодня, а на что можно забить. Открыть схему в полном размере

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

Можно ли оставить vTPM, но отключить шифрование ВМ?

Нет. VMware прямо пишет, что vTPM зависит от механизма шифрования виртуальных машин и требует настроенного key provider. Отключить шифрование VM Home, сохранив vTPM, нельзя — вы можете только удалить vTPM целиком, но тогда потеряете привязку BitLocker к TPM и получите запрос recovery key при загрузке гостя.

Обязательно ли включать NBDSSL, если ВМ и так зашифрованы?

Нет, и это самое частое заблуждение. Network mode по умолчанию использует обычный NBD. Шифрование самой виртуальной машины никак не шифрует трафик между ESXi и прокси — это независимые механизмы. Галка «Enable host to proxy traffic encryption in Network mode (NBDSSL)» включается отдельно и осознанно, потому что Veeam предупреждает о росте нагрузки на CPU хоста и падении производительности.

Почему нельзя использовать Direct SAN для машин с vTPM?

Документация Veeam по зашифрованным ВМ перечисляет только два допустимых режима — Virtual appliance и Network. Direct storage access в этом списке отсутствует. Если ваш прокси настроен на Direct SAN, для vTPM-машин он свалится в резервный режим (обычно Network), и вы получите ровно ту деградацию, о которой эта статья.

Как понять, что задание перестало использовать HotAdd, если оно не падает?

Смотрите детализацию по конкретной ВМ в статистике задания: там будет строка вида «Using backup proxy … for disk Hard disk 1 [nbd]». Массово это удобно проверять грепом по логам бэкап-сервера с подсчётом вхождений [hotadd] / [nbd] / [nbdssl]. Хорошая практика — вывести долю задач в hotadd в мониторинг отдельной метрикой.

Что будет, если восстановить ВМ с vTPM в кластер без key provider?

Файлы вы вернёте, а машина не запустится: файлы VM Home зашифрованы, и без доступных ключей ESXi не сможет их прочитать. Поэтому резервную копию vSphere Native Key Provider нужно экспортировать и хранить вне кластера, а в плане восстановления key provider поднимается раньше, чем прокси и рабочие нагрузки.

Нужно ли шифровать все прокси или достаточно одного?

Достаточно одного выделенного. Заведите отдельную прокси-ВМ, зашифруйте её, вынесите машины с vTPM в отдельное задание и на шаге Storage выберите для него только этот прокси. Остальные прокси оставьте незашифрованными — для незашифрованных машин они продолжат работать в любом доступном режиме.

Можно ли восстановить ВМ с vTPM на другой vCenter, где нет нашего Native Key Provider?

Только после того, как вы перенесёте туда провайдер ключей. Native Key Provider восстанавливается на целевом vCenter из резервной копии в формате PKCS#12 через Configure → Security → Key Providers → Restore. Если файла копии нет, ключ взять неоткуда: Veeam вернёт файлы машины, но расшифровать VM Home и запустить ВМ с vTPM будет нечем. Поэтому выгрузка NKP — обязательный пункт плана DR ещё до первого бэкапа.

Столкнулись с похожей задачей? Обращайтесь — решим

Если у вас происходит что-то из описанного в этой статье — или любая другая проблема с ИТ-инфраструктурой, — обращайтесь в любое время. Мои специалисты и я лично разберём ситуацию, найдём настоящую причину и доведём до решения.

Возьмёмся и за разовую задачу, и за постоянное обслуживание. Первичная консультация — бесплатно и без обязательств.

📞 +7 903 729-62-41 💬 MAX: +7 903 729-62-41 ✈ Telegram @ITfresh_Boss

С уважением, Семёнов Евгений Сергеевич, директор «АйТи Фреш» — IT-аутсорсинг для компаний до 50 рабочих мест, 15+ лет практики

Источники

© ООО «АйТи-Фреш» · Москва · Все статьи