Отключил задание Veeam 13, а точки восстановления всё равно удаляются: как работает background retention

Сервер выводят из эксплуатации, задание Veeam выключают «чтобы архив не трогался», а через месяц в репозитории вместо сорока точек лежат три файла — или не лежит ничего. Разбираю на практике, как устроена фоновая ретенция в Veeam Backup & Replication 13, почему расписание задания на неё не влияет, чем job-linked копии отличаются от orphaned и какими способами архив замораживается по-настоящему.

«Я же выключил задание» — и почему это ничего не гарантирует

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

В Veeam Backup & Replication применение ретенции разнесено на две независимые вещи. Первая — ретенция внутри сессии задания: отработал бэкап, задание посчитало точки, слило или удалило лишнее. Вторая — фоновая ретенция, background retention, отдельный механизм, который живёт своей жизнью и к сессиям задания не привязан вообще. Механизм появился в Veeam Backup & Replication 12 и в тринадцатой версии работает по тем же правилам. В документации VBR 13 (страница «Background Retention», актуально для сборки 13.1.1.18) написано прямым текстом: фоновая ретенция стартует автоматически каждые 24 часа в 00:30 и работает в фоне. Никакого «задание выключено — значит пауза» там нет.

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

Фоновая ретенция — это не одна операция, а пакет. За один ночной проход в 00:30 Veeam последовательно выполняет несколько активностей, и часть из них удаляет файлы безвозвратно.

• Background basic retention — анализирует срок хранения файлов и удаляет протухшие;
• Background GFS retention — снимает истёкшие GFS-флаги и после этого отдаёт файл на удаление по короткой ретенции;
• Background log retention — подчищает логи БД, чей image-level бэкап уже удалён;
• Backup cleanup — применяется только к orphaned-копиям: после удаления всей цепочки сносит .VBM и папку;
• Deleted Agent retention — ретенция копий удалённых агентов;
• Storage system snapshot retention — ретенция снапшотов СХД.

Что фоновая ретенция удаляет, а что не трогает вообще

Здесь начинается самое важное — и самое неочевидное. Поведение зависит от двух параметров: связана копия с заданием или уже осиротела, и в чём задан срок хранения — в днях или в количестве точек восстановления. Четыре комбинации, четыре разных исхода.

Если копия привязана к заданию и ретенция задана в днях, Veeam оставит минимум три файла в цепочке независимо от того, насколько они просрочены. Это то самое «правило трёх точек», о которое спотыкается половина админов: они видят три оставшихся файла и решают, что это баг или что «Veeam что-то не дочистил». Нет, это документированное поведение: механизм всегда оставляет 3 restore point, даже если все они устарели. Если же ретенция у привязанной копии задана в количестве точек, минимальное число оставленных файлов равно текущему значению ретенции — то есть при 30 точках у вас останется 30 файлов.

А вот с orphaned-копиями, то есть отсоединёнными от задания (в консоли они видны в узле с постфиксом (Orphaned)), гуманизма меньше. Для них Veeam берёт последние известные настройки хранения того задания, которое их создало. И если ретенция была в днях — механизм может удалить все просроченные файлы цепочки целиком, а затем backup cleanup снесёт .VBM и папку. Копии просто перестанут существовать. Если же ретенция была в количестве точек — цепочка останется, минимум равен значению ретенции, и удалять придётся руками. Ровно об этом говорит и KB1885 «How to Start a New Backup Chain»: при ретенции в днях фоновый процесс удаляет отсоединённые копии по сроку, а при ретенции в restore points — не удаляет, чистите вручную.

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

Отдельно подчеркну путаницу, на которой спотыкаются часто: в списке исключений стоят copied backups — результат ручной операции Copy Backup, а не задания Backup Copy. Вторичная цепочка от Backup Copy живёт по тем же правилам, что и основная: пока задание привязано, минимум три файла при ретенции в днях или столько, сколько точек задано; если её отсоединить — работает логика orphaned-копий. Иммутабельные файлы фоновая ретенция тоже не удаляет немедленно, а ждёт окончания срока блокировки, и файлы, заблокированные другим процессом, пропускает до разблокировки.

• копии на репозиториях со сменными дисками (rotated drives);
• копии в archive tier SOBR; в capacity tier фоновая ретенция ничего не удаляет напрямую, но если она удалила локальную копию, объект помечается и вычищается при следующем offload;
• импортированные копии (imported backups), VeeamZIP и реплики, включая CDP;
• экспортированные копии (узлы … (Exported)) и копии, созданные операцией Copy Backup; задания Backup Copy в исключения не входят — к ним фоновая ретенция применяется, GFS-ретенция тоже;
• копии, выгруженные политиками Kasten, а также созданные Veeam Plug-Ins for Enterprise Applications и облачными плагинами (AWS, Google Cloud, Azure);
• для копий Veeam Agent for Windows в standalone-режиме или в режиме Managed by agent basic retention к привязанным копиям не применяется — у них своя Deleted Agent retention по сроку «устаревших» бэкапов из настроек агента.

Машина исключена из задания: Remove deleted items data after и чем это отличается от Disable

Есть второй сценарий «архив пропал сам», и фоновая ретенция к нему отношения не имеет. Вместо того чтобы отключать задание целиком, админ убирает выведенную виртуалку из списка объектов задания или удаляет её на хосте, а задание продолжает работать для остальных машин. Здесь срабатывает настройка уровня задания: Storage → Advanced job settings → вкладка Maintenance → флажок Remove deleted items data after с числом дней. По User Guide VBR 13 данные машины, которая удалена или исключена из задания, хранятся в репозитории указанное число дней, после чего удаляются. По умолчанию срок — 14 дней, и Veeam сам рекомендует не ставить меньше трёх, чтобы не потерять данные случайно.

Для практики это означает простую вещь: две недели после исключения машины из задания — и её точки уходят, хотя задание зелёное и само по себе ничего «не удаляло». Если архив по выведенной машине нужен дольше, его надо экспортировать до того, как вы уберёте её из задания, либо осознанно увеличить срок на вкладке Maintenance. Обратите внимание, где что лежит: срок для удалённых объектов — настройка конкретного задания, а выключатель фоновой ретенции в VBR 13 находится не в General Options, а на узле Backups в представлении Home. Искать «Background retention» в общих настройках сервера бесполезно.

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

• Disable задания: новые точки не создаются, просроченные удаляет фоновая ретенция в 00:30, у привязанной копии с ретенцией в днях остаётся минимум 3 файла;
• исключение машины из работающего задания: её данные удаляются через срок Remove deleted items data after (по умолчанию 14 дней);
• Remove from → Job: копии становятся (Orphaned) и при ретенции в днях могут быть удалены целиком вместе с .VBM и папкой;
• Export Backup: независимый полный файл со своим сроком хранения, фоновая ретенция к нему не применяется.

Разбор из практики: магазин одежды «Мода у дома», 19 рабочих мест

Магазин одежды «Мода у дома»: 19 рабочих мест — торговый зал с кассами, склад, офис с бухгалтерией. Серверная часть скромная: хост с тремя виртуалками и отдельный сервер-репозиторий в офисе — Windows Server 2022, ReFS с размером кластера 64К, том 4 ТБ. VBR 13, сборка 13.1.1.18. Задание SRV-FILE-Daily для файлового сервера: forever forward incremental, ретенция 30 дней, плюс GFS monthly с хранением 6 месяцев. Рядом задание Backup Copy, кладущее копии на отдельный USB-том под ReFS, и там ретенция была задана не в днях, а в 30 точках — историческое наследие, которое в итоге всех и спасло.

4 февраля старый файловый сервер вывели из эксплуатации: данные переехали на новый, машину погасили. Внутренний админ магазина отключил задание в консоли Veeam и написал в чат «архив заморожен, храним три года по регламенту документооборота». Дальше пять недель тишины. 10 марта бухгалтерия попросила восстановить папку с договорами поставщиков в состоянии на 28 января. Открываем узел Backups → Disk: от ежедневной цепочки остались один .vbk и два .vib плюс пять месячных GFS-полных. Из 37 точек осталось 8, и нужной даты среди них нет. Ретенция была в днях, копия оставалась привязанной к заданию — сработало правило трёх файлов, а всё, что старше 30 дней, ночной процесс выгреб. Самый старый GFS-полный, за август, ушёл отдельно: его флаг истёк по шестимесячному сроку, background GFS retention флаг снял, и файл удалился по короткой ретенции. Оставшиеся месячные точки приходятся на концы месяцев и 28 января не покрывают.

Дату восстановили точно: в History → System видны ночные сессии фоновой ретенции, по одной в сутки, все около 00:30 по времени сервера бэкапа. Никакой аварии, никакого сбоя — механизм честно делал ровно то, что ему предписано. Данные достали из Backup Copy. Исключением фоновой ретенции это задание не является; цепочку спасло то, что ретенция там была в 30 точках: при таком способе Veeam оставляет в цепочке минимум столько файлов, сколько задано, и последние 30 ежедневных точек до 4 февраля остались на месте. Восстановили папку на 27 января вместо 28-го — разница в один рабочий день, бухгалтерию устроило. Если бы на втором томе ретенция тоже была в днях, разговор был бы совсем другой.

Второй эпизод у того же магазина месяцем позже, уже показательнее. Задание старого сервера складской базы было отключено ещё в декабре. Чтобы «начать новую цепочку» на новом сервере под тем же заданием, админ сделал Remove from → Job для старого набора — по инструкции из KB1885, всё правильно. Копии ушли в (Orphaned). Только вот последние известные настройки хранения у них были в днях, а все точки к этому моменту были старше 30 дней. Следующей же ночью background retention удалил всю просроченную цепочку (96 ГБ, 34 точки), а backup cleanup добил .VBM и папку. Восстанавливать было нечего: файлов на томе физически не осталось. Именно с этого случая у нас в чек-листе появился отдельный пункт про orphaned.

• исходно: 37 точек (31 ежедневная + 6 месячных GFS), ретенция 30 дней, forever forward incremental;
• через пять недель с выключенным заданием: 3 файла цепочки (1 × .vbk + 2 × .vib) и 5 GFS-полных;
• GFS monthly 6 месяцев: самый старый полный удалён после истечения флага;
• orphaned-цепочка складского сервера 34 точки / 96 ГБ: удалена за одну ночь целиком вместе с .VBM;
• спасло вторичное задание Backup Copy с ретенцией в 30 точках — не исключение, а правильно выбранный тип ретенции.

Как заморозить архив по-настоящему: четыре рабочих способа

Мой порядок приоритетов такой. Первое и лучшее — экспорт нужных точек. Экспорт синтезирует из выбранной точки самостоятельный полный .vbk, который живёт в узле Disk (Exported), и, что критично, экспортированные копии входят в список исключений фоновой ретенции. В документации прямо сказано, что фича сделана в том числе для legal hold и архивирования, когда нужно не дать конкретным точкам удалиться по ретенции основного задания. При экспорте вы отдельно задаёте, до какой даты хранить файл — и это ваш собственный, осознанный срок, а не унаследованный от задания.

Второе — вынести файлы за периметр Veeam и при необходимости импортировать обратно. Скопировали .vbk/.vib/.vbm на отдельный том или на ленту, удалили из конфигурации (не с диска!), при надобности сделали Import Backup. Импортированные копии фоновая ретенция тоже не трогает. Способ грубый, зато железобетонный: то, что не значится в базе как управляемая копия, никто не удалит. Для небольшого магазина это обычно внешний диск в сейфе у директора или второй репозиторий на другой площадке.

Третье — если очень хочется оставить как есть, переведите ретенцию задания из дней в количество точек восстановления перед тем, как задание отключать. Тогда и для job-linked, и для orphaned-копий Veeam оставит минимум столько файлов, сколько указано в ретенции, и дальше не пойдёт. Поведение документировано в разделе Considerations страницы Background Retention, но это не «функция заморозки», а следствие правил: удалить лишнее руками всё равно придётся, и для GFS-флагов действуют свои сроки. Я отношусь к нему как к костылю — но костыль рабочий и не раз выручал, когда экспортировать полтора терабайта было некуда.

Четвёртое — глобально выключить фоновую ретенцию. В VBR 13 это делается штатно, без правки реестра: Home → правый клик на узле Backups → Disable retention (или кнопка Disable Retention на ленте). Обратно включается тем же способом. Пользоваться этим я не советую, и вот почему: во-первых, Veeam будет ежедневно слать письмо-напоминание, что ретенция отключена; во-вторых, документация предупреждает, что при отключённой фоновой ретенции и работающих заданиях перестаёт вычищаться вспомогательная информация в object storage-репозиториях, и производительность заданий со временем деградирует. Это выключатель на час, а не на квартал.

• Export Backup → отдельный .vbk в Disk (Exported), собственный срок хранения — основной способ;
• вынести файлы наружу + Import Backup при необходимости — способ для «холодного» архива;
• перевести ретенцию задания из дней в restore points до отключения задания — костыль, но рабочий;
• Disable retention на узле Backups — только как временная мера на время работ.

Проверка своего стенда за двадцать минут

Начинаю всегда с инвентаризации того, что вообще лежит в репозиториях и по каким правилам. Открываем консоль, узел Backups, включаем колонки с заданием и репозиторием, отдельно смотрим всё, что помечено (Orphaned) — это первая группа риска. Дальше по каждому заданию проверяем, в чём выражена ретенция. Быстрее всего это делается из PowerShell на сервере бэкапа.

Мой стартовый набор команд в консоли PowerShell на сервере бэкапа, запускается из-под учётки с правами администратора Veeam:

# что за копии лежат и к какому заданию привязаны (пустой JobName — повод насторожиться)
Get-VBRBackup | Select-Object Name, JobName, @{n='Points';e={($_ | Get-VBRRestorePoint).Count}} | Sort-Object Name

# в чём задана ретенция заданий: Days или Cycles (точки); свойства объектной модели, сверьте на своей сборке
Get-VBRJob | Select-Object Name, @{n='RetentionType';e={$_.BackupStorageOptions.RetentionType}}, @{n='Days';e={$_.BackupStorageOptions.RetainDaysToKeep}}, @{n='Points';e={$_.BackupStorageOptions.RetainCycles}}

# поставить задание на паузу (копии это НЕ защищает)
Get-VBRJob -Name "SRV-FILE-Daily" | Disable-VBRJob

# убрать копию только из конфигурации, файлы оставить на диске
Get-VBRBackup -Name "SRV-FILE-Daily" | Remove-VBRBackup -WhatIf

# полное и необратимое удаление с диска — трижды подумать
# Get-VBRBackup -Name "SRV-FILE-Daily" | Remove-VBRBackup -FromDisk -IncludeGFS

Обратите внимание: Disable-VBRJob кладёт задание на паузу, но не удаляет ни его, ни настройки — и, как мы уже выяснили, не защищает копии. А Remove-VBRBackup без ключа -FromDisk убирает копию только из конфигурационной базы, оставляя файлы в репозитории; с ключом -FromDisk удаление полное и необратимое. Разница в один параметр, а последствия разные на порядок, поэтому я всегда прогоняю такие команды с -WhatIf. Учтите ещё, что при включённой four-eyes authorization Remove-VBRBackup не выполнится вовсе — это нормальная защита, а не ошибка.

Второй заход — история. History → System, ищем ночные сессии фоновой ретенции: они идут раз в сутки около 00:30 по времени сервера бэкапа, и по ним видно, что и когда было удалено. Если у вас пропали точки и вы не понимаете почему — это первое место, куда смотреть, до того как писать в поддержку. И третий пункт, который регулярно всплывает у клиентов с забитыми томами: фоновой ретенции нужно свободное место в репозитории под метафайл .VBM. Если места нет, задача упадёт — включая ручной запуск Apply retention. То есть переполненный репозиторий сам себя не почистит, замкнутый круг придётся разрывать руками.

• проверить все копии с постфиксом (Orphaned) — что это, чьи, по какой ретенции живут;
• по каждому заданию: ретенция в днях или в точках;
• History → System: есть ли ночные сессии фоновой ретенции и что они удаляли;
• свободное место в репозитории — иначе фоновая ретенция будет падать;
• не отключена ли фоновая ретенция глобально (если отключена — на почту падают ежедневные напоминания).

Мифы, спорные места и что я делаю сам

Миф первый: «три оставшиеся точки — это защита, всегда что-то останется». Не всегда. Три файла Veeam оставляет только для копий, привязанных к заданию, и только когда ретенция задана в днях. У orphaned-копий с ретенцией в днях механизм имеет право снести цепочку целиком. Люди видели правило трёх точек в одном сценарии и уверенно экстраполируют на все — так теряют архивы.

Миф второй: «фоновая ретенция сливает инкременты, значит данные никуда не денутся». Нет. В документации отдельно отмечено, что, в отличие от ретенции задания, фоновая ретенция не мержит данные из одного файла в другой — она просто удаляет файлы. Для forever forward incremental и forward incremental инкременты удаляются только после того, как устареет последний инкремент соответствующей части цепочки, поэтому со стороны кажется, что «Veeam ничего не чистит, а потом резко чистит всё». Это не рывок, это накопленная просрочка, которая схлопнулась за один проход.

А вот где риск, на мой взгляд, преувеличивают — так это в страхе перед самим механизмом. Мне регулярно предлагают «а давайте вообще отключим эту фоновую ретенцию, чтобы спалось спокойнее». Не давайте. Фоновая ретенция — единственный способ удаления устаревших точек и копий, и без неё репозиторий рано или поздно встанет колом, а на object storage начнёт копиться вспомогательный мусор с деградацией скорости заданий. Правильная стратегия — не выключать уборщика, а вынести из-под его юрисдикции то, что вы хотите сохранить.

Отдельно про иммутабельность. Hardened-репозиторий и immutability в объектном хранилище — обязательная вещь, но задачу заморозки архива они не решают. Фоновая ретенция просто ждёт окончания срока блокировки и удаляет файл, как только он перестал быть immutable. Иммутабельность — это защита от злоумышленника и от ошибки оператора, а не замена продуманной политике хранения.

• «Три точки останутся всегда» — только для привязанных копий с ретенцией в днях, у orphaned-копий нет;
• «Фоновая ретенция сливает инкременты» — нет, она только удаляет файлы, без merge;
• «Backup Copy исключён из фоновой ретенции» — нет, исключены copied backups от операции Copy Backup;
• «Immutable-копии не удалятся никогда» — удалятся после окончания срока блокировки и ретенции;
• «Фоновую ретенцию безопаснее выключить» — нет, это единственный механизм удаления устаревших точек, а в object storage копятся служебные данные.

Регламент вывода сервера из эксплуатации, который я даю клиентам

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

Отдельным пунктом мы фиксируем срок хранения в документе: не «храним, пока не понадобится», а «храним до конкретной даты, ответственный — такой-то». Иначе через год никто не помнит, зачем на томе лежит 300 ГБ непонятных .vbk, и их удаляют при первой же нехватке места. И раз в квартал мы проверяем, что экспортированные копии вообще открываются: прогоняем тестовое восстановление одного файла из архивного .vbk. Копия, которую ни разу не проверили, — это не копия, а надежда.

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

• зафиксировать в задаче: что выводим, какие копии сохраняем, до какой даты, кто ответственный;
• экспортировать нужные точки (Export Backup) с явно заданным сроком хранения;
• убедиться, что экспортированные копии видны в узле Disk (Exported);
• только после этого отключать или удалять задание;
• проверить, что оставшиеся копии не превратились в (Orphaned) с ретенцией в днях;
• через сутки после первого прохода фоновой ретенции проверить состав репозитория повторно;
• раз в квартал — тестовое восстановление одного файла из архивного .vbk.

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