Veeam Software Appliance версии 13.1 и новее может не загрузиться после перезапуска на виртуальных хостах с отдельными процессорами AMD EPYC. Причина — сбой FIPS-проверки генератора энтропии в ядре Linux, который заканчивается kernel panic; для ИТ-команд это риск получить недоступный сервер резервного копирования именно во время планового обновления или аварийного рестарта.
О проблеме сообщает BleepingComputer со ссылкой на предупреждение Veeam. Затронуты преднастроенные Linux-виртуальные машины Veeam Software Appliance, предназначенные для запуска Veeam Backup & Replication без ручной установки зависимостей и базовой настройки ОС. В списке процессоров, на которых наблюдается проблема, Veeam прямо называет AMD EPYC 7262, 7302 и 7F72. Это не означает, что каждый запуск на таких CPU обречён: проверка срабатывает нестабильно, а отказ происходит лишь в части перезагрузок.
Сценарий выглядит неприятно знакомо любому администратору: обновление устанавливает новое ядро, ВМ перезагружается и вместо штатного возврата в строй останавливается на ранней стадии старта. В консоли появляется сообщение Kernel panic — not syncing с указанием на ошибку инициализации jitterentropy и несоответствие требованиям хоста. До запуска сервисов резервного копирования дело не доходит.
Jitterentropy — механизм, который помогает ядру получать случайные данные из микроскопических колебаний времени выполнения операций. В FIPS-режиме, востребованном в компаниях и госорганизациях с формализованными требованиями к криптографии, такие механизмы проходят дополнительные проверки работоспособности. В данном случае именно ранний health check в используемом Veeam ядре Linux периодически не проходит на некоторых EPYC. Ядро выбирает безопасный для FIPS-сценария вариант — прекращает загрузку, а не продолжает работу с сомнительным источником энтропии.
Для заказчика это прежде всего операционный, а не функциональный инцидент. По данным Veeam, если ВМ один раз успешно загрузилась, дальнейшая работа Veeam Backup & Replication не должна пострадать. Но окно между «нажали reboot» и «система снова доступна» становится непредсказуемым. Особенно болезненно это для площадок, где backup-сервер обслуживает несколько сред, а перезагрузки привязаны к короткому окну обслуживания.
Рекомендация вендора — перенести appliance на Linux-хост с процессором, не подверженным проблеме. Если миграция невозможна, Veeam предлагает отключить автоматические обновления и ставить их вручную, наблюдая за перезапуском виртуальной машины. В случае kernel panic нужно выключить ВМ и включить её заново: обычный рестарт гостевой ОС, по данным компании, не восстанавливает загрузку. Это важно учесть в runbook: автоматизация, рассчитанная только на мягкий reboot, здесь оставит инцидент без результата.
Российским ИТ-командам имеет смысл проверить не только модель процессора, но и архитектуру размещения backup-инфраструктуры. Veeam Software Appliance часто воспринимается как способ уменьшить объём рутинной работы с Linux, но преднастроенная ВМ всё равно остаётся частью цепочки «гипервизор — CPU — ядро — криптополитика». Для владельцев EPYC 7262, 7302 и 7F72 практичный минимум — заранее протестировать перезагрузку клона или резервного экземпляра, обновить инструкции дежурной смены и убедиться, что есть консольный доступ для полного выключения и включения ВМ.
Предупреждение вышло в тот же день, когда Veeam также сообщила о влиянии критической уязвимости Linux-ядра CVE-2026-98432 на часть продуктов: речь идёт об IPv4 TCP-коде и серверах с MPTCP listener. Компания заявила, что для некоторых компонентов уже подготовлено исправленное ядро, распространяемое приватно либо через Veeam Updater. Совпадение этих двух историй делает ручной контроль обновлений ещё важнее: патч безопасности может требовать перезагрузки, а перезагрузка на уязвимой аппаратной конфигурации — отдельного плана восстановления.
Veeam указывает, что её продуктами пользуются более 550 тысяч клиентов, включая 74% компаний Global 2000 и 82% Fortune 500. Поэтому проблема вряд ли останется частным случаем нескольких лабораторных стендов. Главный вопрос теперь не в том, можно ли перезапустить проблемную ВМ повторно, а в том, как быстро вендор обновит комбинацию ядра и FIPS-проверок так, чтобы плановое усиление безопасности не превращалось в лотерею при загрузке.
