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

Почему в Veeam 13 immutability на 7 дней превращается в 17 дней блокировки объектов

Автор: Семёнов Евгений Сергеевич, директор ООО «АйТи-Фреш» · · ~29 мин чтения
Почему в Veeam 13 immutability на 7 дней превращается в 17 дней блокировки объектов
Иллюстрация к статье «Почему в Veeam 13 immutability на 7 дней превращается в 17 дней блокировки объектов».

Вы поставили в свойствах объектного репозитория «Make recent backups immutable for 7 days», прикинули место на неделю ретенции — а через месяц бакет забит на 85 %, фоновая очистка ничего не удаляет, и `aws s3api get-object-retention` показывает дату на десять дней дальше, чем вы ожидали. Это не баг и не глюк MinIO. Это Block Generation, и в Veeam 13 формула расчёта фактического хранения изменилась по сравнению с 12-й версией. Ниже — как считается реальный срок жизни объектов, откуда берутся 10 или 30 лишних дней, как я планирую ёмкость под прямой бэкап в object storage и что делать, если место уже кончилось.

Семь дней в интерфейсе — семнадцать на диске

Начну с механики, потому что 90 % споров вокруг «Veeam не удаляет старые бэкапы» заканчиваются на этом абзаце. Когда вы включаете immutability на объектном репозитории, Veeam не просто ставит объектам object lock на указанное число дней. К этому сроку он автоматически добавляет служебный период — Block Generation. В документации это описано прямым текстом: «Block Generation is a time period within which all blocks in backup files (both full and increment backup files) have the same immutability period… You do not have to configure it, the Block Generation setting is applied automatically». То есть настройки этого периода в интерфейсе нет вообще. Он просто есть.

Зачем он нужен. Без него каждый инкремент, наследующий блоки от предыдущей точки, заставлял бы Veeam продлевать лок на этих блоках — а это вызовы PutObjectRetention, ListObjectVersions и деньги у провайдера. Block Generation склеивает все блоки, записанные внутри окна, в одну «генерацию» с общей датой истечения. Блок, приехавший на девятый день генерации, получает ту же дату, что и блок первого дня. Расплата за экономию — часть объектов лежит под локом дольше, чем формально нужно.

Дальше — самое важное. В Veeam 13 фактический срок хранения зависит от того, какой из двух режимов выбран в свойствах репозитория: «For the entire duration of their retention policy» или «For the minimum immutability period only». В первом случае берётся большее из ретенции задания и минимального периода immutability, во втором ретенция задания игнорируется. К результату в обоих случаях прибавляется Block Generation. Формулы и официальные сценарии собраны в списке ниже.

Официальные сценарии из документации 13-й версии, на них удобно проверять свои расчёты. Во всех трёх минимальный период immutability — 7 дней, Block Generation — 10 дней, первый бэкап сделан 01.07.2025, меняется только ретенция задания и режим.

Обратите внимание на сценарий 2: retention задания три дня, а объекты живут семнадцать. Ретенция задания в режиме minimum immutability вообще не участвует в расчёте — доку тут читают невнимательно чаще всего. Плюс отдельная оговорка: для точек с GFS-флагами, для VeeamZIP и для экспортированных файлов применяется immutability репозитория, а их собственная ретенция при расчёте не учитывается.

Цифра в поле «Make recent backups immutable for N days» — это не срок, на который у вас занято место. Это нижняя граница. Верхняя — плюс Block Generation, а для целых цепочек ещё и плюс продления.

Block Generation — 10 дней или 30, зависит от того, куда вы пишете

Вот здесь чаще всего и промахиваются с расчётами. Block Generation — не константа. Veeam подставляет разные значения по умолчанию в зависимости от типа объектного хранилища: 30 дней для Amazon S3, IBM Cloud, Google Cloud и 11:11 Cloud и 10 дней для всех остальных типов, включая любые S3-совместимые хранилища. Полный перечень — в списке ниже.

Разница принципиальная. Immutability 7 дней на локальном MinIO или Object First — это 17 дней реального лока. Те же 7 дней в бакете Amazon S3 — это 37 дней. В пять с лишним раз больше, чем цифра в поле. Если вы посчитали место по интерфейсу и заказали объём в облаке под неделю хранения, счёт за месяц вас удивит.

Смысл этих значений хорошо виден по независимому замеру, который Фалько Банашак опубликовал летом 2026 года: он включил аудит-лог S3 и посчитал вызовы API у 12-й и 13-й версий на одинаковой нагрузке. За выходные инкрементов число PutObjectRetention (именно им продлеваются локи) упало с 1770 до 299, то есть на 83 %, ListBucketObjectVersions — на 53 %. На тесте с одним active full вызовы ListObjects/ListObjectsV2 сократились на 87 %. Для облака это прямая экономия на запросах, для локального S3 — заметно меньшая нагрузка на метаданные. Так что Block Generation — не костыль, а осознанный размен места на число запросов и деньги.

Отдельно про GFS, там своя логика и свои грабли. Для GFS-точек Veeam назначает Block Generation, только если он длиннее минимального периода GFS-ретенции — на практике это значит, что при значениях по умолчанию Block Generation получают недельные точки, а месячные и годовые — нет. И есть совсем неочевидный момент: если в одном объектном хранилище лежат точки сразу с несколькими GFS-флагами (weekly + monthly + yearly), Block Generation не назначается вообще ни для одной из них. То есть добавление месячной GFS-точки может внезапно сократить фактическое хранение недельных. Это поведение описано в разделе Considerations and Limitations, так что это не баг. Но строить на нём расчёт ёмкости я бы не стал: достаточно поменять набор GFS-флагов в задании, и фактическая глубина недельных точек изменится.

Не путайте слагаемые в примере из документации: там «30 + 10 = 40» означает 30 дней immutability, заданных в репозитории, плюс 10 дней Block Generation для хранилища «прочего» типа. Для бакета в Amazon S3 те же 30 дней дадут 30 + 30 = 60. Считайте по таблице типов хранилищ и проверяйте фактическую дату лока в бакете — ниже покажу как.
Почему в Veeam 13 immutability на 7 дней превращается в 17 дней блокировки объектов — схема
Схема к статье. Открыть схему в полном размере

Разбор из практики: «Рекламный цех», MinIO на 44 ТБ и переполнение на 38-й день

Стенд, на котором я это ловил руками. Рекламное агентство «Рекламный цех», 40 рабочих мест: дизайнеры, видеомонтаж, аккаунт-менеджеры и бухгалтерия. Два хоста Proxmox VE, семь виртуалок: 1С с SQL, файловый сервер с макетами и видеоисходниками, почта, терминальный сервер, пара служебных. Резервное копирование — Veeam Backup & Replication 13 (build 13.1.1.18), прямой бэкап в object storage без scale-out и без performance tier. Приёмник — свой MinIO на отдельном сервере, восемь дисков по 8 ТБ, erasure coding, полезной ёмкости около 44 ТБ. Бакет создан заранее с Object Lock и Versioning, default retention отключён — как и требует Veeam.

Настройки, с которыми стенд поехал в прод: репозиторий добавлен как S3 Compatible, immutability включён на 7 дней, режим — «For the entire duration of their retention policy». Задание forever forward incremental, ретенция 14 точек, плюс GFS weekly на 4 недели. Полный бэкап всех семи машин — 5,4 ТБ, суточный инкремент гулял от 240 до 310 ГБ (основной вклад — файловый сервер, куда дизайнеры и монтажёры каждый день сохраняют новые версии проектов, и почта с тяжёлыми вложениями).

Расчёт, который сделал их админ до запуска, выглядел так: 5,4 ТБ полного + 14 суток × 0,28 ТБ ≈ 9,3 ТБ на основную цепочку, плюс четыре недельных точки — итого «около 21 ТБ, вдвое запас есть». Логика понятная и абсолютно неверная. На 38-й день эксплуатации бакет показывал 36,8 ТБ и 84 % заполнения, у меня в мониторинге сработал порог, а фоновая очистка Veeam честно писала, что удалять нечего.

Реальная арифметика оказалась другой. Ретенция задания (14) больше immutability (7), режим entire duration → фактическое хранение основной цепочки = 14 + 10 = 24 дня. Это не 14 суток инкрементов, а 24: примерно 6,7 ТБ вместо 3,9. Недельные GFS-точки: ретенция 28 дней + Block Generation 10 = 38 дней, то есть в хранилище живьём лежало шесть недельных полных вместо четырёх. Каждая недельная — в среднем 4,9 ТБ уникальных блоков. Вот вам и разница между 21 и 36,8 ТБ.

Что я сделал. Во-первых, перевёл репозиторий в режим «For the minimum immutability period only» и оставил immutability 7 дней — фактическое хранение основной цепочки стало 7 + 10 = 17 дней вместо 24. Во-вторых, срезал суточную ретенцию с 14 до 10 точек: 10 дней оперативного отката для этой компании достаточно, глубина закрывается недельными и месячными. В-третьих, недельные GFS сократил с 4 до 3 (3 × 7 = 21 + 10 = 31 день фактически). Через полный цикл вымывания старых генераций — а это заняло ровно столько, сколько было записано в старых локах, никакого способа ускорить нет — бакет вышел на 24,1 ТБ, 55 % заполнения. Заодно повесил в Zabbix триггер на используемую ёмкость бакета с порогом 70 %, а не 85 %: при immutability запас нужен больше обычного, потому что аварийно освободить место вы не сможете физически.

Отдельно про честность. Я сначала полез искать «как уменьшить Block Generation» — и правильный ответ здесь «никак из интерфейса». Настройки в интерфейсе нет. В разделе ограничений Veeam вскользь упоминает «изменение значений Block Generation по умолчанию», но штатного поля для этого нет, а крутить недокументированные параметры на боевом backup-сервере ради экономии десяти дней я считаю плохим разменом: вы получаете нестандартную конфигурацию, которую придётся объяснять поддержке при первом же инциденте. Дешевле пересчитать ёмкость.

Место, занятое immutable-объектами, нельзя освободить срочно. Ни удалением задания, ни удалением репозитория из консоли, ни правкой ретенции. Объекты в режиме COMPLIANCE не удалит даже владелец бакета — это и есть смысл технологии. Планируйте запас заранее.
Цифры и версии: Разбор из практики: «Рекламный цех», MinIO на 44 ТБ и переполнение на 38-й день — схема
Цифры и версии: Разбор из практики: «Рекламный цех», MinIO на 44 ТБ и переполнение на 38-й день. Открыть схему в полном размере

Как я считаю ёмкость под прямой бэкап в object storage

Формула, которую я держу в шаблоне расчёта. Сначала определяем фактическую глубину хранения в днях — отдельно для основной цепочки и отдельно для каждого типа GFS:

; режим For the entire duration of their retention policy
D_факт = max(retention_задания_в_днях, immutability_дней) + BlockGeneration

; режим For the minimum immutability period only
D_факт = immutability_дней + BlockGeneration

; BlockGeneration = 30 для Amazon S3 / IBM Cloud / Google Cloud / 11:11
; BlockGeneration = 10 для S3 Compatible / Wasabi / Azure Blob / VDC Vault

Дальше — объём. Для forever forward incremental прямо в объектное хранилище я считаю так: полный бэкап один раз, плюс фактическая глубина, умноженная на суточный объём уникальных блоков, плюс живые GFS-точки со своей глубиной. Суточный объём уникальных блоков — не размер VIB-файла на диске из старой инсталляции, а именно то, что реально приезжает в бакет; если истории нет, я закладываю 4–6 % от полного объёма в сутки для 1С+SQL 1–2 % для обычных файловых серверов и 3–5 % для файлового хранилища дизайн-студии или видеопродакшена, где каждый день появляются новые исходники, а через две недели пересчитываю по факту.

Объём ≈ Full_уник
      + D_факт_основной × Δ_суточный
      + N_GFS_живых × Full_уник_GFS

N_GFS_живых = ceil( (GFS_ретенция_дней + BlockGeneration) / период_GFS )

На примере «Рекламного цеха» в исходной конфигурации: 5,4 + 24 × 0,28 + 6 × 4,9 = 41,5 ТБ теоретического максимума. Реальные 36,8 ТБ — это тот же порядок с поправкой на дедупликацию общих блоков между недельными точками. Если бы этот расчёт сделали до запуска, разговора про переполнение не было бы вообще.

И последнее по планированию: закладывайте не 10–15 % свободного места, как на обычном репозитории, а 30 %. Причина простая — при immutable-хранилище у вас нет аварийного рычага. На обычном Windows- или Linux-репозитории вы в 3 часа ночи удалите пару старых цепочек и доживёте до утра. Здесь — нет. Единственное, что вы можете сделать в момент переполнения, это остановить задания и ждать, пока истекут локи.

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

Что ломается при апгрейде с Veeam 12 на 13

Смена формулы — самое неприятное в этом переходе, потому что она тихая. В 12-й версии фактическая ретенция считалась как сумма трёх слагаемых: ретенция задания + период immutability + Block Generation. В документации 12-й версии прямо приведён пример: ретенция 30 дней, immutability 14 дней, Block Generation 10 дней — планируйте хранилище на 30 + 14 + 10 = 54 дня. В 13-й версии immutability и ретенция задания больше не складываются: берётся большее из двух и к нему прибавляется Block Generation. Для той же конфигурации это уже 30 + 10 = 40 дней.

На первый взгляд это хорошая новость — стало меньше. Но есть подвох, о котором надо помнить: immutable-файлы, созданные предыдущими версиями Veeam Backup & Replication, удаляются по прежней модели. Обновление сервера не переводит уже записанные объекты на новую формулу. Значит, после апгрейда у вас в одном бакете какое-то время сосуществуют две популяции объектов с разной логикой освобождения, и «старый хвост» будет уходить по старым, более длинным срокам. Если вы планировали место по новой формуле сразу после апгрейда — вы промахнётесь ровно на этот хвост.

Второй сюрприз — режим по умолчанию. После обновления до версии 13.0.1.P1 (build 13.0.1.1071) Veeam выставляет режим immutability по умолчанию так, чтобы он соответствовал всему периоду ретенции, заданному в политике задания, то есть «For the entire duration of their retention policy». Если у вас была длинная ретенция задания и короткий immutability, после апгрейда фактическое хранение вырастет само собой. Я после каждого обновления прохожу по всем объектным репозиториям и явно проверяю выбранный режим — это тридцать секунд на репозиторий и очень неприятный сюрприз, если не сделать.

Третье: режим «For the entire duration of their retention policy» не поддерживается для объектных репозиториев, используемых как capacity tier в scale-out. Если вы добавите такой репозиторий как capacity extent, Veeam молча переключит его на minimum immutability. Это не ошибка конфигурации, а документированное поведение, но фактическое хранение при этом изменится — и снова не в ту сторону, в которую вы считали.

Перед апгрейдом снимите текущее заполнение бакета и режим immutability по каждому репозиторию в отдельный файл. Через месяц после апгрейда это единственный способ понять, где рост — от новой формулы, а где — от старого хвоста.

Как проверить, что реально лежит в бакете

Не верьте ни расчёту, ни интерфейсу — посмотрите фактическую дату лока на объектах. Это занимает пять минут и снимает все споры. Через AWS CLI против любого S3-совместимого хранилища:

# список версий объектов в папке Veeam (ключи и version-id)
aws --endpoint-url https://s3.backup.example.lan:9000 \
  s3api list-object-versions \
  --bucket veeam-prod --prefix "Veeam/Archive/" --max-items 10

# фактический режим и дата снятия лока по конкретной версии объекта
aws --endpoint-url https://s3.backup.example.lan:9000 \
  s3api get-object-retention \
  --bucket veeam-prod \
  --key "Veeam/Archive/.../06a1c3f0e2.blk" \
  --version-id "c1f0a9b7-..."

Ответ выглядит примерно так, и именно RetainUntilDate надо сравнивать с датой записи объекта — разница и есть ваше фактическое хранение:

{
  "Retention": {
    "Mode": "COMPLIANCE",
    "RetainUntilDate": "2026-09-24T03:11:07+00:00"
  }
}

Обратите внимание на Mode: COMPLIANCE. Veeam использует именно compliance-режим object lock для каждого загружаемого объекта — это значит, что объект не удалит и не разблокирует никто, включая root-аккаунт хранилища, до наступления даты. Если у вас в голове был план «в крайнем случае админ MinIO почистит» — плана нет.

На MinIO то же самое короче делается родным клиентом:

mc ls --versions backup/veeam-prod/Veeam/Archive/ | head -20
mc retention info --versions backup/veeam-prod/Veeam/Archive/<object>
mc du backup/veeam-prod

Со стороны Veeam список объектных репозиториев и их типы удобно снимать PowerShell — тип важен, потому что именно от него зависит Block Generation:

Get-VBRObjectStorageRepository | Select-Object Name, Type, Id
Get-VBRObjectStorageRepository -Type AmazonS3Compatible | Select-Object Name, Id

И совсем базовое, что почему-то делают редко: в консоли Veeam откройте Home → Backups, правой кнопкой по бэкапу → Properties, выберите объект в списке Objects. Там видны все точки восстановления с их периодом immutability. По документации точки с immutable-данными остаются видимыми в интерфейсе весь срок защиты — даже если по ретенции задания они давно должны были уйти. Если в списке точек больше, чем задано в задании, это не сбой очистки, а ровно та самая фактическая ретенция с Block Generation.

Проверять надо не один объект, а выборку из разных дней — в том числе из середины генерации. Блок, приехавший на девятый день генерации, имеет ту же дату истечения, что и блок первого дня, и по одному объекту вы этого не увидите.
Порядок действий: Как проверить, что реально лежит в бакете — схема
Порядок действий: Как проверить, что реально лежит в бакете. Открыть схему в полном размере

Hardened Linux Repository: Block Generation нет, но свои правила

Если вместо объектного хранилища вы пишете на Hardened Repository — Linux-сервер с локальными дисками, — всё сказанное про Block Generation к нему не относится. Это механизм только object storage. Неизменяемость на hardened держит атрибут immutable файловой системы плюс файл .veeam.N.lock рядом с каждым бэкап-файлом. Ставит и снимает атрибуты служба Veeam Immutability Service (veeamimmureposvc): она работает с правами root как дочерний процесс Veeam Data Mover и проверяет атрибуты раз в 20 минут. Сам Data Mover (veeamtransport, порт 6162) работает от непривилегированного пользователя. Период задаётся от 7 до 9999 дней — нижняя граница заметно выше, чем у объектного репозитория, где минимум 1 день.

Отсчёт идёт от последней точки активной цепочки, и это главный источник перерасхода на hardened. Пример из документации: full создан 12 января, инкременты — 13 и 14 января, immutability 10 дней. Вся цепочка, включая full, неизменяема до 24 января, и с каждым новым инкрементом срок сдвигается дальше. Неактивные цепочки не продлеваются. Отсюда требование Veeam: на hardened допускается только forward incremental с периодическим active или synthetic full. Forever forward и reverse incremental выбрать нельзя, потому что immutable-файл нельзя смёрджить до истечения срока. Место я считаю так: длина самой длинной цепочки между полными бэкапами плюс период immutability — и только потом ретенция.

С GFS на hardened логика жёстче, чем в S3. Для полных бэкапов с GFS-флагом Veeam берёт большее из двух сроков: периода immutability репозитория и срока жизни GFS-точки. Пример из документации: у репозитория 10 дней, у GFS-точки 3 года — full будет неизменяем 3 года, а инкременты от него — 10 дней от последнего инкремента. Для «Рекламного цеха» это значило бы, что годовая точка с архивом видеопроектов занимает место три года без права передумать. Ещё одна деталь: чтобы у backup copy job на hardened работала неизменяемость, в задании должна быть включена GFS-ретенция.

Требования к самому серверу, на которых чаще всего спотыкаются. Файловая система должна поддерживать immutable-атрибуты и расширенные атрибуты (chattr и setxattr). Veeam рекомендует XFS: она поддерживает block cloning (Fast Clone). Без него каждый synthetic full на hardened пишется полным объёмом, а удалить его до конца срока нельзя — ёмкость растёт в разы. Хранилище только блочное: NFS- и SMB-шары не подходят. Hardened нельзя делить между несколькими серверами Veeam, на нём не должно быть Veeam Agent for Linux, а каталог с бэкапами должен принадлежать учётке подключения и иметь права 0700 без sticky bit. Подготовка тома у меня выглядит так:

# XFS с reflink — нужен для Fast Clone (block cloning)
mkfs.xfs -b size=4096 -m reflink=1,crc=1 /dev/sdb
mkdir -p /mnt/veeam
mount /dev/sdb /mnt/veeam
xfs_info /mnt/veeam | grep reflink   # должно быть reflink=1

# каталог под бэкапы: владелец и группа — учётка подключения, права 0700
mkdir -p /mnt/veeam/backups
chown veeamrepo:veeamrepo /mnt/veeam/backups
chmod 700 /mnt/veeam/backups

# проверка после первого задания: флаг 'i' = файл неизменяем
lsattr /mnt/veeam/backups/*/*.vbk

Отдельно про учётные данные. При добавлении сервера выбирайте single-use credentials: логин и пароль используются один раз, чтобы развернуть Veeam Data Mover, и не сохраняются в инфраструктуре Veeam. Дальше сервер бэкапов общается с репозиторием по самоподписанным сертификатам SHA256RSA с ключом 2048 бит. Даже если сервер Veeam скомпрометирован, злоумышленник не вытащит оттуда пароль к hardened. После добавления я отключаю SSH на сервере и убираю учётку из sudo — иначе смысл single-use теряется. На Veeam Hardened Repository, развёрнутом из ISO Veeam Infrastructure Appliance, аутентификация только по сертификатам, SSH там не используется, и сервер нельзя вводить в домен.

Служба неизменяемости на hardened следит за сдвигом времени. Если системное время или RTC «прыгнули» больше чем на 24 часа или сервер был выключен дольше суток, операции ретенции блокируются, и атрибуты не ставятся и не снимаются. Настройте NTP заранее и не оставляйте репозиторий выключенным на выходные: снимать блокировку придётся через Reset time shift protection в консоли Host Management или вручную под root.

Что делать в первую очередь, а на что можно забить

Порядок действий, если вы сейчас читаете это с забитым бакетом. Первое — определите режим immutability на репозитории и тип хранилища, посчитайте фактическую глубину по формуле. Второе — посмотрите GFS: в моей практике именно недельные точки с Block Generation дают основной перерасход, а не суточная цепочка. Третье — примите решение по ретенции задания и режиму: перевод в «minimum immutability period only» при коротком immutability обычно самый быстрый выигрыш, но помните, что в этом режиме ретенция задания на immutability не влияет вообще. Четвёртое — дождитесь вымывания старых генераций, никакого способа ускорить нет.

На что можно спокойно забить. На попытки уменьшить Block Generation — это не настраивается и не стоит нестандартной конфигурации. На тонкую подгонку immutability под 5 или 6 дней вместо 7 — вы экономите проценты, а рискуете тем, что при инциденте не хватит окна на реакцию. На переживания «а вдруг compliance-лок навсегда» — при корректно отключённой default retention на бакете Veeam ставит конечные даты, всё истекает само.

И одна вещь, которую я считаю важнее всех расчётов. Смысл immutability — пережить сценарий, в котором злоумышленник получил админку Veeam и переставил ретенцию на один день. Именно поэтому короткий immutability опасен: три дня лока означают, что у вас три дня на обнаружение атаки, иначе восстанавливать будет не из чего. Семь дней — минимально разумно для компании, где кто-то смотрит в почту мониторинга каждый рабочий день. Четырнадцать — если инфраструктура живёт без ежедневного присмотра. Место дешевле, чем непережитый инцидент; просто посчитайте это место честно, с Block Generation, а не по цифре в поле ввода.

Ещё пара вещей из чек-листа, которые не относятся к арифметике, но ломают всё целиком. Default retention на бакете должен быть отключён — при включённом поведение непредсказуемо вплоть до потери данных. Versioning и Object Lock после добавления бакета в инфраструктуру Veeam не трогать ни в какую сторону. Lifecycle-правила на бакете не поддерживаются и приводят к сбоям бэкапа и восстановления (исключение — те два правила, которые Google Cloud создаёт сам при включении версионирования). Данными в бакете должен управлять только Veeam — это не рекомендация, а условие работоспособности.

Единого мнения по «правильному» периоду immutability в отрасли нет: кто-то ориентируется на 7 дней, кто-то на глубину ретенции целиком. Я считаю, что отталкиваться надо от времени обнаружения инцидента в конкретной компании, а не от круглой цифры.
Порядок действий: Что делать в первую очередь, а на что можно забить — схема
Порядок действий: Что делать в первую очередь, а на что можно забить. Открыть схему в полном размере

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

Можно ли отключить или уменьшить Block Generation?

Из интерфейса — нет. В документации Veeam прямо сказано: настраивать Block Generation не нужно, значение применяется автоматически, и никакого поля в мастере репозитория для него не предусмотрено. Значение по умолчанию зависит только от типа хранилища: 30 дней для Amazon S3, IBM Cloud, Google Cloud и 11:11, 10 дней для всех остальных, включая S3 Compatible, Wasabi и Azure Blob. Практический вывод: планируйте ёмкость с учётом Block Generation, а не пытайтесь его убрать.

Я поставил immutability 7 дней, но бакет заполнен объектами возрастом больше месяца. Это нормально?

Скорее всего да. Проверьте три вещи. Первая — режим репозитория: при «For the entire duration of their retention policy» и ретенции задания 30 дней фактический срок будет 30 + Block Generation, а не 7. Вторая — тип хранилища: в Amazon S3 Block Generation равен 30 дням, то есть даже режим minimum immutability даст 7 + 30 = 37 дней. Третья — GFS: недельные точки получают собственный Block Generation, и их фактическая глубина считается отдельно.

Как срочно освободить место на immutable-бакете, если он переполнился?

Никак. Veeam ставит объектам object lock в режиме COMPLIANCE — такой объект нельзя удалить или разблокировать досрочно ни через консоль Veeam, ни средствами хранилища, ни под root-аккаунтом бакета. Единственные варианты — расширить хранилище, временно перенаправить задания в другой репозиторий и ждать истечения локов. Именно поэтому свободный запас на immutable-репозитории я закладываю в районе 30 %, а алерт ставлю на 70 % заполнения.

Изменилась ли формула расчёта при переходе с Veeam 12 на 13?

Да, и это ключевое отличие. В 12-й версии фактическая ретенция считалась как ретенция задания + immutability + Block Generation (официальный пример: 30 + 14 + 10 = 54 дня). В 13-й берётся большее из ретенции задания и минимального периода immutability, к нему прибавляется Block Generation. При этом immutable-файлы, записанные предыдущими версиями, продолжают удаляться по прежней модели — обновление сервера их не переводит на новую формулу, и переходный хвост нужно учитывать в расчёте места.

Есть ли Block Generation на Hardened Linux Repository?

Нет, это механизм только объектных хранилищ. На hardened файлы неизменяемы в течение заданного периода (от 7 до 9999 дней), который отсчитывается от последней точки активной цепочки: пока в цепочку пишутся инкременты, срок для всех её файлов сдвигается. GFS-full получает большее из двух значений — период репозитория или срок жизни GFS-точки. Поэтому на hardened основной перерасход дают длинные цепочки между полными бэкапами и годовые GFS, а не лишние десять дней.

Как посмотреть реальную дату снятия блокировки с объекта?

Через S3 API. Сначала получите список версий объектов: `aws --endpoint-url <ваш endpoint> s3api list-object-versions --bucket <bucket> --prefix "Veeam/"`. Затем по конкретной версии: `aws s3api get-object-retention --bucket <bucket> --key <key> --version-id <id>`. В ответе поле RetainUntilDate и есть фактическая дата освобождения объекта. На MinIO то же самое делается через `mc retention info --versions`. Смотрите выборку объектов из разных дней, а не один: внутри одной генерации даты у всех блоков одинаковые.

Какой период immutability выставлять для небольшой компании?

Я исхожу из времени обнаружения инцидента, а не из круглых цифр. Если мониторинг и почта просматриваются каждый рабочий день — 7 дней разумный минимум. Если инфраструктура живёт без ежедневного присмотра или в компании бывают длинные праздничные простои — 14 дней. Меньше трёх дней ставить бессмысленно: злоумышленник с админкой Veeam переставит ретенцию, и у вас просто не останется времени заметить это. Единого отраслевого стандарта тут нет, и любой, кто называет одну «правильную» цифру, не знает вашей ситуации.

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

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

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

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

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

Источники

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