Включил шифрование задания в Veeam 13: почему пошёл новый full, а старые копии остались открытыми

Эта статья для тех, кто администрирует Veeam Backup & Replication и однажды поставил галочку «Enable backup file encryption» на живом задании — а наутро получил переполненный репозиторий и упавшее расписание. Разберу по пунктам: что именно делает Veeam при смене настроек шифрования, почему включение и отключение дают полный бэкап, а смена пароля — нет, что происходит со старой цепочкой (спойлер: ничего, она остаётся читаемой) и как я разворачиваю шифрование на боевом стенде, чтобы не выгрести ночью. С разбором проекта в музыкальной школе на 17 рабочих мест, цифрами, командами PowerShell и тем, что будет с данными при потере пароля или KMS-сервера.

«Поставили галочку — за ночь кончился репозиторий»

Звонок в субботу в 08:20. Задание бэкапа упало ночью, в логе — «Not enough free space on the backup repository». Репозиторий на 4 ТБ, вечером на нём было свободно 0,9 ТБ, и последние полгода суточный инкремент укладывался в 50–70 ГБ. Запаса хватало на пару недель вперёд — и он исчез за один сеанс.

Смотрю историю изменений задания: в пятницу вечером администратор школы открыл Advanced → Storage и поставил галочку «Enable backup file encryption», выбрал пароль. Логика понятна: после проверки по защите персональных данных учеников и сотрудников школе порекомендовали «зашифровать резервные копии», а галочка называется ровно так. Задание сохранилось без предупреждения о том, что следующий сеанс будет больше обычного в двадцать с лишним раз.

Так и вышло. При включении шифрования на существующем задании Veeam не дописывает ключ к текущей цепочке — в следующем же сеансе он создаёт новый полный файл. Инкремент на 60 ГБ превратился в full на 1,6 ТБ, место кончилось на второй из пяти виртуалок, задание встало, и точки восстановления за пятницу не появилось вовсе.

Это не баг и не особенность конкретной сборки. Это документированное поведение, оно описано ровно одной строчкой в пользовательском руководстве — и именно эту строчку никто не читает, потому что галочка выглядит как обычная настройка задания, а не как операция уровня «пересоздать цепочку».

• Задание упало с «Not enough free space» на середине сеанса — точка за пятницу не создана ни для одной ВМ.
• На репозитории остался недописанный хвост нового полного файла, который ещё и занимает место.
• Галочка шифрования осталась включённой: следующая ночь без вмешательства снова пойдёт в full и снова упадёт.
• Старая незашифрованная цепочка цела и читается — единственная хорошая новость того утра.

Четыре правила, которые Veeam применяет к настройкам шифрования

В документации Veeam Backup & Replication 13 (страница «Encrypting Backup Jobs», содержимое актуально для сборки 13.1.1.18) поведение при изменении настроек шифрования существующего задания описано четырьмя пунктами. Их стоит выучить наизусть, потому что они несимметричны и на первый взгляд нелогичны.

Формулирую по-русски, максимально близко к тексту руководства; сами пункты — в списке ниже. Та же страница ссылается на KB1885 «How to Start a New Backup Chain» — на случай, если вы хотите явно отделить старую незашифрованную цепочку от новой.

Обратите внимание на асимметрию. Включение и выключение шифрования начинают новую цепочку с полного файла. Смена пароля или переход с пароля на ключи KMS даёт обычный инкремент: по описанию механизма в разделе «How Backup Data Encryption Works» пароль превращается в секретный ключ, которым обёрнуты ключи шифрования данных, а ключи данных и так разные в каждом сеансе — рвать цепочку незачем. Почему именно так устроены включение и отключение, мануал не объясняет, это моя интерпретация. Практика ей соответствует: смена пароля на боевом задании у меня ни разу не приводила к внеплановому full.

Ещё один момент: в руководстве написано просто «full backup file», без оговорок про схему цепочки — forward incremental, reverse incremental, forever forward, синтетика по расписанию. На практике этот full собирается чтением данных с источника, как активный: собрать зашифрованный синтетический full из незашифрованных блоков старой цепочки Veeam не может, поэтому экономия fast clone/reflink на этом сеансе не работает. Это и ответ на частый вопрос, почему задание, которое годами обходилось без активных full, вдруг нагрузило продуктив на всю ночь.

Те же четыре правила действуют для Backup Copy Job — страница «Encrypting Backup Copy Jobs» повторяет их практически дословно. Там же две полезные детали: если в копировании участвуют WAN-ускорители, шифрование выполняет целевой WAN accelerator, а для хранения копий в Veeam Data Cloud Vault шифрование задания обязательно. Для остальных типов заданий с job-level шифрованием (file backup, object storage backup, VeeamZIP, configuration backup) правила надо проверять по их страницам документации и не переносить выводы по аналогии.

• Включили шифрование на существующем задании — в следующем сеансе Veeam автоматически создаст полный файл резервной копии. Этот full и все последующие инкременты будут зашифрованы указанным паролем или ключом KMS.
• Ранее созданную цепочку Veeam НЕ шифрует. Она остаётся лежать в репозитории в том виде, в каком была, и остаётся читаемой без пароля.
• Сменили пароль (или перешли с пароля на KMS) на уже зашифрованном задании — в следующем сеансе будет создан новый инкрементный файл, не полный. Он и все следующие за ним шифруются новым ключом.
• Отключили шифрование — в следующем сеансе Veeam снова автоматически создаст полный файл.

Разбор: музыкальная школа «Крещендо», 17 рабочих мест, репозиторий 4 ТБ

Тот самый клиент, с которого начался рассказ. Музыкальная школа «Крещендо»: 17 рабочих мест у администрации, бухгалтерии и преподавателей, один хост ESXi и пять продуктивных виртуалок — контроллер домена, 1С:Бухгалтерия и ЗУП на MS SQL, файловый сервер с нотной библиотекой, записями отчётных концертов и видео уроков, сервер электронного журнала и расписания, плюс служебная мелочь. Veeam Backup & Replication 13.1.1.18, репозиторий — Hardened Linux Repository на Ubuntu 24.04, XFS с reflink, иммутабельность 14 дней. Схема: forward incremental, синтетический full по субботам, ретенция 28 дней, GFS — 4 недельные и 6 месячных точек.

Источник — 2,9 ТБ provisioned, полный бэкап после компрессии Optimal ложился в 1,6 ТБ, основную массу давали видео и аудиозаписи. Инкременты в будни — 50–70 ГБ. Свободно на репозитории было 0,9 ТБ, и до включения шифрования этого хватало с запасом: синтетический full на XFS с reflink почти не ест место, он собирается ссылками на уже записанные блоки.

Здесь вторая ловушка. Новый full после включения шифрования не выигрывает от reflink: предыдущая цепочка не зашифрована, склеить из её блоков зашифрованный файл нельзя. Veeam читает данные с продуктива заново и пишет полноценные 1,6 ТБ новых байт. Поэтому 0,9 ТБ свободного места кончились в первую же ночь.

Как разруливали. Первым делом отключили задание, чтобы оно не запускалось каждую ночь и не плодило недописанные файлы. Потом посчитали честно: 1,6 ТБ новый full + 3,1 ТБ уже занятых старой цепочкой и GFS-точками (часть под иммутабельностью, удалить нельзя) + инкременты новой цепочки за четыре недели + 15 % запаса — около 5,7 ТБ при томе 4 ТБ. Не проходило никак. В сервере репозитория был свободный слот: поставили диск на 2 ТБ, добавили его в LVM, растянули XFS до 6 ТБ и только после этого запустили задание вручную в субботу днём.

• Первый полный бэкап после включения шифрования шёл 3 часа 10 минут против 12–15 минут обычного инкремента.
• Скорость упёрлась не в шифрование, а в чтение с дисков хоста: прокси держал 150–170 МБ/с, загрузка CPU на прокси выросла примерно на 10–12 процентных пунктов.
• Обычная незашифрованная цепочка ушла по ретенции через 28 дней. Всё это время в репозитории лежали читаемые без пароля копии всех пяти виртуалок, включая базы 1С с персональными данными.
• Месячные GFS-точки, созданные до включения шифрования, остались незашифрованными и уйдут только по своему сроку — последняя через полгода. Это мы отдельно записали в отчёт директору.
• Через месяц занятое место стабилизировалось на 3,4 ТБ из 6, инкременты снова 55–65 ГБ.

Старая цепочка остаётся открытой — и это опаснее, чем переполненный диск

Место — проблема на один вечер. Настоящая проблема в другом: после включения шифрования у людей в голове щёлкает «всё, архив защищён». А защищена только новая цепочка. Все .vbk и .vib, созданные до момента переключения, лежат ровно там же и открываются любым инстансом Veeam без единого пароля — достаточно импортировать файл через Import Backup и он развернётся.

Дальше начинается интересное. Раз «всё зашифровано», старый архив спокойно выносят за периметр: копируют на внешний USB-диск и увозят домой, выгружают на NAS у подрядчика, перекладывают в облачное объектное хранилище «для холодного хранения», отдают на диагностику уходящему подрядчику. Такие сценарии я видел в трёх организациях за последние два года, и во всех трёх админ искренне считал, что вывозит зашифрованные копии, — потому что в задании стояла галочка.

Проверять надо не галочку в задании, а сами файлы. На «родном» backup-сервере это не видно по запросу пароля: ключи шифрования данных хранятся в конфигурационной базе, и расшифровка идёт в фоне. Надёжнее импортировать файлы на тестовый сервер Veeam: зашифрованные бэкапы появляются в узле Backups → Disk (Encrypted) и требуют Specify Password, а незашифрованные сразу оказываются в Backups → Disk (Imported). Список ключей, заведённых на сервере, смотрится через PowerShell:

# Все ключи шифрования на backup-сервере
Get-VBREncryptionKey

# Конкретный ключ по описанию
Get-VBREncryptionKey -Description 'SCHOOL-VBR-PROD-2026Q3'

И отдельно: если вы включили шифрование ради требования регулятора или ради пункта в договоре с заказчиком, формально требование выполнено только с момента первого зашифрованного full. Всё, что старше, — не выполнено. Об этом честно стоит написать в отчёте, а не делать вид, что архив однороден.

• Дождаться, пока старая цепочка уйдёт по ретенции. Самый спокойный путь, если срок хранения разумный и репозиторий не выезжает за периметр. Не забудьте про GFS-точки: у них свой, обычно куда более длинный срок.
• Отделить старые точки от задания через Detach from job по KB1885 (с v12 этот пункт заменил Remove from configuration) и удалить их из репозитория — если политика хранения это позволяет и иммутабельность истекла.
• Если старые точки нужны для отчётности, но хранить их открытыми нельзя, — это отдельные работы: штатной перешифровки цепочки нет, и копирующее задание не перекладывает историю задним числом. Остаётся ограничить физический доступ к репозиторию до конца срока хранения.
• Если старый архив уже уехал на внешний носитель — считать его раскрытым с точки зрения конфиденциальности и разбираться с этим отдельно, а не задним числом.

Как я включаю шифрование на боевом задании

Порядок, к которому я пришёл за несколько таких внедрений. Он скучный, но за счёт этого ни разу не привёл к падению ночного окна.

Сначала — арифметика. Смотрю фактический размер последнего полного файла задания и фактическое свободное место на томе репозитория. Для Linux-репозитория это две команды прямо на хосте:

df -h /mnt/veeam-repo
du -sh --apparent-size /mnt/veeam-repo/'Backup VMware - PROD'
ls -lh /mnt/veeam-repo/'Backup VMware - PROD'/*.vbk | tail -3

Дальше вопрос: свободного места больше, чем размер последнего .vbk, умноженный на 1,2? Если да — можно работать. Если нет — сначала расширяем том или чистим ретенцию, и только потом трогаем настройки. Никаких «ну оно как-нибудь разложится».

Затем — сам ключ. Я всегда завожу ключ отдельной операцией с осмысленным описанием, а не набираю пароль в диалоге задания: описание потом видно в списке ключей, и через полгода понятно, что это за пароль и от чего. В PowerShell это выглядит так:

# 1. Создаём ключ шифрования
$sec = Read-Host -Prompt 'Encryption password' -AsSecureString
Add-VBREncryptionKey -Password $sec -Description 'SCHOOL-VBR-PROD-2026Q3'

# 2. Забираем его обратно как объект
$key = Get-VBREncryptionKey -Description 'SCHOOL-VBR-PROD-2026Q3'

# 3. Вешаем на задание
$job = Get-VBRJob -Name 'Backup VMware - PROD'
Set-VBRJobAdvancedStorageOptions -Job $job -EnableEncryption $true -EncryptionKey $key

Параметры сверены со справочником PowerShell для сборки 13.1.1.18: у Set-VBRJobAdvancedStorageOptions это -EnableEncryption <Boolean> и -EncryptionKey <PSCryptoKey>, для KMS — отдельный -KMSServer <VBRKMSServer> (объект берётся из Get-VBRKMSServer). Add-VBREncryptionKey принимает пароль только как SecureString, поэтому Read-Host -AsSecureString или ConvertTo-SecureString обязательны. Учтите, что KMS-серверы добавляются и настраиваются только в десктопной консоли, веб-интерфейс v13 этого не умеет.

И последнее по порядку, но не по важности: запускать первый зашифрованный сеанс надо вручную и в удобное время, а не отдавать его ночному расписанию. Полный бэкап идёт в разы дольше инкремента, он может залезть в рабочее окно и упереться в снапшоты на продуктиве. Я ставлю его на субботу днём и смотрю глазами.

• Отключить расписание задания (Disable), чтобы ночной запуск не начался раньше вас.
• Посчитать место: свободно ≥ размер последнего full × 1,2. Учесть иммутабельность.
• Создать ключ с внятным описанием и сразу положить пароль в менеджер паролей организации.
• Включить шифрование в задании (GUI или PowerShell).
• Запустить задание руками, дождаться зелёного статуса и проверить размер нового .vbk.
• Проверить восстановление: смонтировать одну точку из новой цепочки и убедиться, что пароль подходит.
• Вернуть расписание и записать в документацию дату, с которой архив стал зашифрованным.

Пароль, KMS и что будет, если ключ потеряют

Криптографию под капотом стоит знать хотя бы в общих чертах, от неё зависят решения. Секретный ключ Veeam выводит из пароля 600 000 итерациями HMAC-SHA256 с 512-битной солью — по рекомендации NIST для вывода ключа из пароля. Ключи шифрования данных оборачиваются этим секретным ключом алгоритмом AES-256 в режиме CBC. Если вместо пароля используется внешний KMS-сервер, ключи данных шифруются асимметрично (RSA, 4096 бит): публичный ключ хранится в конфигурационной базе Veeam, приватный — только на KMS, ротацию ключей выполняет сам KMS по своим политикам, а системное задание Veeam раз в 24 часа забирает обновления.

600 тысяч итераций — это, по-человечески, защита от перебора: подбор слабого пароля обходится атакующему на порядки дороже. Но она не спасает от пароля вида «Veeam2026». Требования, которые Veeam прямым текстом пишет в мануале, я привожу списком ниже — и да, я действительно прогоняю по ним пароль, а не ставлю то, что удобно набирать.

Теперь неприятное. Документация говорит прямо: если пароль потерян или ключи KMS недоступны из-за отказа KMS-сервера, данные из бэкапов и с лент не восстановить — если в процессе шифрования не участвовали ключи Enterprise Manager. Это и есть Password Loss Protection: Enterprise Manager при установке генерирует пару RSA-4096, публичный ключ после включения защиты уходит на backup-сервер, и Veeam шифрует ключи данных одновременно секретным (или KMS) ключом и публичным ключом Enterprise Manager. Условия из руководства: платная лицензия (не Community Edition), все backup-серверы, на которых расшифровываете, подключены к одному экземпляру Enterprise Manager, и сама защита включена в Enterprise Manager (Settings → Configuration → Key Management → Enable encryption password loss protection). Раз ключ EM подмешивается в момент шифрования, точки, созданные до включения защиты, этого ключа не содержат, поэтому включать её нужно заранее. И отдельно: если умрёт сам Enterprise Manager, вместе с ним пропадут приватные ключи. Keyset надо экспортировать и хранить вне сервера.

Про KMS тоже без иллюзий. Интеграция требует лицензии Veeam Data Platform Advanced или Premium и KMS-сервера с поддержкой KMIP Profile v1.4; в списке протестированных — Thales CipherTrust Manager, Fortanix DSM и IBM GKLM. При отказе KMS-сервера задания с KMS-ключами падают, а расшифровка без KMS снова возможна только через Enterprise Manager. Конфигурационный бэкап KMS-ключами не шифруется вообще — только паролем. Поэтому для школы или офиса на 15–50 рабочих мест, где нет ни KMS, ни Enterprise Manager, мой вариант такой: пароль в корпоративном менеджере паролей плюс распечатка в запечатанном конверте в сейфе у директора. Звучит архаично, работает безотказно. Подсказка к паролю (password hint) не должна содержать пароль или его часть — это прямое требование вендора, и нарушают его постоянно.

И последнее про ротацию, о чём забывают. Старые пароли выбрасывать нельзя. Если пароль менялся несколько раз или вы переходили на KMS, то при импорте цепочки на другой сервер по метаданным (VBM) нужен последний пароль или KMS-ключ, а при импорте полного файла (VBK) — весь набор паролей и KMS-ключей, которыми шифровались ключи данных. В менеджере паролей я храню историю: дату смены и задания, к которым относился каждый пароль.

• Не короче 12 символов.
• Прописные и строчные буквы вместе.
• Смесь букв, цифр и знаков пунктуации.
• Существенно отличается от предыдущего пароля.
• Никаких реальных данных о вас: дат рождения, кличек, логинов.
• Подсказка не содержит пароля.
• Регулярная ротация — и помните, что ротация стоит всего один инкремент.

Побочные эффекты, которых нет в чек-листах

Первое и самое дорогое — дедупликация на хранилище. Veeam использует разные ключи шифрования данных на каждый сеанс задания. Для дедуплицирующего аплайнса это означает, что одинаковые по содержимому блоки из разных сеансов выглядят как разные, и коэффициент дедупликации падает. Если ваш репозиторий — HPE StoreOnce, Dell Data Domain, ExaGrid или любая другая железка, которая продавалась под лозунгом «сожмём в десять раз», включение шифрования на стороне Veeam этот эффект убивает. Правильный ход — не шифровать на стороне задания, а включить шифрование на самом хранилище. Это ровно то, что рекомендует вендор.

Второе — компрессия. Если и компрессия, и шифрование включены, Veeam сначала сжимает данные, потом шифрует сжатые блоки, обе операции идут на стороне источника. Но если в настройках репозитория стоит галочка «Decompress backup data blocks before storing», то сжатия перед шифрованием не происходит — и в статистике задания счётчик Transferred окажется заметно выше, чем у такого же незашифрованного задания. Это не аномалия, это ожидаемое следствие. Люди на этом счётчике регулярно поднимают панику про «шифрование раздуло трафик».

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

Четвёртое, и для небольших организаций я бы поставил его первым, — конфигурационный бэкап самого Veeam. Здесь частое заблуждение работает наоборот. Незашифрованный configuration backup не содержит учётных данных, ключей шифрования и сертификатов, но после восстановления из него доступ к инфраструктуре и к зашифрованным бэкапам придётся настраивать заново. В нём по-прежнему могут быть адреса серверов и прочая чувствительная информация. Если же в Password Manager на backup-сервере есть хотя бы один пароль (а он появится с первым зашифрованным заданием), v13 не запустит конфигурационный бэкап, пока вы не включите его шифрование. Только зашифрованный configuration backup сохраняет учётные записи и ключи, и его пароль нужен ровно тогда, когда сам backup-сервер недоступен. Храните этот пароль вне Veeam.

Пятое — уровень применения. Job-level шифрование поддерживают backup job, backup copy job, file backup, object storage backup, VeeamZIP и конфигурационный бэкап. Storage-level шифрование со своими настройками работает для capacity tier, archive tier, бэкапов standalone-приложений в репозиториях, внешних репозиториев и медиа-пулов на лентах. Одно другое не заменяет: зашифрованное задание и зашифрованный медиа-пул — две разные галочки в двух разных местах. Есть и исключение: если Veeam Data Cloud Vault подключён как capacity extent в SOBR, нужно именно storage-шифрование, а не job-level.

• На дедуп-аплайнсе шифруйте на аплайнсе, не в задании.
• Рост счётчика Transferred после включения шифрования на репозитории с «Decompress backup data blocks» — норма.
• Backup Copy Job с зашифрованным источником всегда платит за расшифровку, даже если сам не шифрует.
• Ленты и capacity tier требуют отдельной настройки storage-level шифрования.
• Конфигурационный бэкап VBR шифруйте обязательно: без шифрования в нём нет учётных записей и ключей, а при наличии паролей в Password Manager v13 его просто не запустит.

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