Application Backup Repository в Veeam 13.1: как защитить дампы приложения, которое умеет писать только в сетевую папку

Приложение делает свой родной дамп и кладёт его в сетевую папку. Плагина под Veeam для него нет и не будет. Папка живёт на дешёвом NAS, доступна на запись той же учёткой, что и само приложение, и потому доступна шифровальщику, кривому скрипту ротации и уволенному админу. В Veeam 13.1 под этот сценарий сделали Application Backup Repository. Ниже — как я его разворачивал на боевом стенде, какие поля в мастере реально важны, где я споткнулся и сколько это стоит в лицензиях.

«Дамп есть, а бэкапа нет» — как это выглядит на практике

Звонок в пятницу вечером: товароучётная система после обновления не поднимается, откатите базу на вчера. Идём в сетевую папку, куда три года складывались дампы. Папка на месте. Файлов в ней — один, сегодняшний, и он битый, потому что процесс дампа падал последние двое суток. Разбор занял двадцать минут: месяцем раньше кто-то поправил скрипт ротации, переменная с путём не подставилась, и строка вида find $BACKUP_DIR -mtime +7 -delete отработала от корня шары. Никто ничего не заметил, потому что мониторился ровно один факт — «скрипт завершился с кодом 0». Он и завершался с нулём.

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

Общий корень один. У приложения нет плагина под систему резервного копирования. Оно умеет ровно одно действие — положить свой родной экспорт в каталог. Всё, что дальше, никто не проектировал: каталог просто «есть». В Veeam Backup & Replication 13.1 (документация на момент написания относится к билду 13.1.1.18) под этот кейс появился отдельный тип репозитория, Application Backup Repository, дальше ABR. Он не делает бэкап вместо приложения. Он делает так, чтобы папка перестала быть просто папкой.

• Скрипт ротации с непроверенной переменной пути удаляет всё содержимое шары, а мониторинг смотрит только на код возврата.
• Учётка приложения имеет на папку полный доступ — значит, его имеет и шифровальщик, запущенный от её имени.
• Дамп пишется, но никто не проверяет, что файл полный и из него реально поднимается база.
• Единственная копия лежит на одном NAS в той же серверной, что и прод.
• Срок хранения задаёт скрипт на стороне приложения, и Veeam о нём ничего не знает.

Что такое Application Backup Repository и чем он точно не является

ABR — это, если коротко, «умная» NFS-шара, поднятая на Veeam Hardened Repository, который развёрнут из ISO образа Veeam Infrastructure Appliance (VIA). VIA — это собственный Linux-дистрибутив Veeam в формате JeOS, загрузочный ISO, где нет ничего лишнего: только то, что нужно для роли. Когда вы создаёте ABR, Veeam выделяет на ZFS-пуле отдельный dataset, экспортирует его по NFS и сам открывает нужные порты в фаерволе аплайнса. Приложение монтирует эту шару и пишет туда свои дампы ровно так же, как писало на NAS, — оно вообще не в курсе, что рядом есть Veeam.

Дальше начинается то, ради чего всё затевалось. По расписанию, которое вы задали в репозитории, VBR снимает снимок этого dataset. Снимок фиксирует полное состояние шары на момент времени и становится одной точкой восстановления. Сразу после создания Veeam накладывает на снимок hold на срок, равный сроку retention: удалить снимок раньше нельзя ни из консоли, ни руками с хоста. Затем репозиторий отправляет на backup-сервер уведомление о рескане, VBR подтягивает данные о новой точке, пишет их в конфигурационную БД и показывает в консоли.

И теперь честно про границы. ABR — не приложение резервного копирования. Он не знает, что у вас за файлы, не умеет их квиесцировать, не запускает pg_dump и не проверяет целостность архива. Расписание дампов, их формат, полнота и корректность — по-прежнему на вашей стороне. Veeam берёт на себя только хранение: снимки, неизменяемость, права доступа и копирование дальше. Это не замена плагину. Это замена папке на NAS.

Отличие от привычного NFS-репозитория тоже стоит проговорить, потому что путаются постоянно. В классическом NFS-репозитории Veeam выступает клиентом к чужой шаре и складывает туда свои VBK/VIB. В ABR всё наоборот: Veeam сам является NFS-сервером, а на шаре лежат чужие файлы в чужом формате, которые Veeam даже не парсит.

• Oracle RMAN с incremental merge — в What's New 13.1 поддержка Incremental Merge с ABR прямо указана среди новинок плагина для RMAN.
• pg_dump и mysqldump из контейнеров и из БД, до которых плагин не дотягивается.
• Выгрузки MongoDB и разного рода DBaaS-платформ.
• vzdump и экспорт LXC-контейнеров с Proxmox VE.
• Конфиги сетевого железа, которые собирает oxidized/rancid или самописный скрипт.
• Данные и телеметрия с промышленных контроллеров, СКУД, видеоаналитики — всё, у чего плагина не будет никогда.

Стенд детского магазина «Растём вместе»: железо, установка VIA и включение режима

Разбор делаю на живом внедрении. Детский магазин «Растём вместе»: 43 рабочих места — торговый зал, склад, пункт выдачи интернет-заказов и небольшой офис. Хозяйство, которое требовалось защитить: товароучётная система на Ubuntu 22.04 с PostgreSQL 16 (ночной pg_dump -Fc, около 12 ГБ на выходе), Proxmox VE с шестью LXC-контейнерами под сайт, обмен с маркетплейсами и вспомогательные сервисы (vzdump раз в сутки), и конфиги сетевого железа — 7 коммутаторов и роутер, которые собирает oxidized. Всё это годами складывалось на один QNAP, часть по SMB, часть по NFS, ротация — самописными скриптами.

Под ABR взяли отдельную машину: HP DL380 Gen9, один E5-2630 v4, 48 ГБ памяти, контроллер P440ar с батарейкой, шесть дисков SAS 4 ТБ в аппаратном RAID6. Формальные требования Veeam к ABR заметно скромнее — минимум 4 ядра (vCPU) от 1 ГГц, 8 ГБ RAM, первый диск от 120 ГБ и сеть от 1 Гбит/с. Но 8 ГБ — это «чтобы включилось»: под ZFS память нужна как воздух, и я бы ниже 32 ГБ на боевом стенде не опускался. Первый диск сделали 200 ГБ, потому что на нём живут JeOS, софт VBR и кэш instant recovery — 120 ГБ там впритык.

Стенд ABR у «Растём вместе»
----------------------------------------
Шасси      : HP DL380 Gen9, 1 x E5-2630 v4, 48 GB RAM
Контроллер : Smart Array P440ar + FBWC 2 GB (кэш с батареей/конденсатором)
Диск 1     : 200 GB (JeOS + VBR + instant recovery cache), мин. по докам 120 GB
Пул данных : 6 x 4 TB SAS -> RAID6 -> один ZFS pool ~14 TB
Сеть       : 2 x 1 GbE LACP в сегмент серверов (мин. по докам 1 Гбит/с)
Софт       : Veeam Infrastructure Appliance ISO 13.1, билд 13.1.1.18

Дальше — ограничение, которое ломает планы чаще всего. ABR нельзя разместить на удалённых дисках по iSCSI или Fibre Channel. Только локальные диски и аппаратный RAID, точка. То есть идея «а положим-ка мы это на нашу СХД, там полки и репликация» не пройдёт: аплайнс её просто не увидит. Дополнительные пустые диски при развёртывании можно автоматически собрать в один storage pool, но это должны быть локальные диски. И да, контроллер с кэшем на батарее или конденсаторе Veeam рекомендует прямым текстом — по производительности и по надёжности.

• Ставим VIA с ISO, в меню установщика выбираем роль Veeam Hardened Repository.
• После установки логинимся в веб-интерфейс Veeam Host Management как Host Administrator (данные для входа аплайнс печатает на консоли).
• Backup Infrastructure → секция Application Backup Repository → жмём Submit Request рядом с «Allow this host to function as both a Hardened and an Application Backup repository».
• Ждём одобрения Security Officer. Если учётка Security Officer не настроена — режим включится мгновенно.
• Добавляем в сервер локальные диски под данные, идём в Storage → вкладка Devices → Rescan Storage.
• Выделяем новые устройства → Add Storage → проходим мастер, собираем ZFS-пул.
• Добавляем VIA в Veeam Backup & Replication как managed server — только после этого новый тип репозитория появится в консоли.

Мастер репозитория: ZFS-пул, mount path, права и версии NFS

New Application Backup Repository, шаг Repository. Здесь три вещи. Поле ZFS pool — выбираем пул, под полем сразу видно ёмкость и свободное место. Поле Mount path — путь, по которому шара будет смонтирована на самом репозитории. Под полем Veeam показывает полный путь монтирования и даёт кнопку Copy path: вот его и отдавайте владельцу приложения, не собирайте путь руками по кусочкам, ошибётесь в регистре — потом полдня будете ловить «permission denied».

Права доступа по умолчанию — deny all. Ни один NFS-клиент не подключится, пока вы явно не разрешите. Разрешения добавляются в таблицу «Grant permissions to access the NFS share» кнопкой Add: в окне Add host or IP mask вводится либо полное DNS-имя (erp01.shop.example), либо маска с подстановкой (*.shop.example), либо подсеть, и рядом выбирается Permission — Read или Read/Write. Мы дали Read/Write только самому серверу учётной системы и Read — рабочей станции инженера, чтобы он мог глазами проверить, что дамп на месте, и при этом ничего не мог удалить.

# монтирование ABR-шары на сервере учётной системы (Ubuntu 22.04)
# ВАЖНО: <путь_из_Copy_path> — ровно то, что выдала кнопка Copy path в мастере
mkdir -p /mnt/backup/erp
mount -t nfs -o vers=4.2,hard,timeo=600,retrans=2,noatime \
  10.20.30.10:<путь_из_Copy_path> /mnt/backup/erp

# в /etc/fstab, чтобы переживать перезагрузку
10.20.30.10:<путь_из_Copy_path> /mnt/backup/erp nfs vers=4.2,hard,timeo=600,retrans=2,_netdev 0 0

Версии NFS — самое неочевидное место, и именно на нём я потерял вечер. Если права раздаются по хосту или IP-маске, поддерживаются NFSv3, NFSv4.1 и NFSv4.2. Если включаете Kerberos-аутентификацию — только NFSv4.1 или NFSv4.2, и хост ABR обязан быть введён в домен. А вот если клиент — Windows со штатным Client for NFS, то доступен ТОЛЬКО NFSv3, из-за ограничений самой ОС. В магазине oxidized крутится на Linux, а вот выгрузку старой программы лояльности делает Windows-сервер — там пришлось делать отдельный ABR под NFSv3 и править реестр.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default
  AnonymousUid = 399   (DWORD 32-bit, десятичное)
  AnonymousGid = 399   (DWORD 32-bit, десятичное)

Ещё две тонкости, которые надо знать заранее. Первая: когда доступ раздан по хосту/IP без Kerberos, все операции чтения и записи на шаре Veeam выполняет от служебного пользователя veeam-usr-abr-nfs. То есть владельцем файлов будет он, а не ваш postgres, и наивные проверки прав в скриптах ротации на этом ломаются. При Kerberos identity пользователя сохраняется. Вторая: ограничения по IP и по Kerberos комбинируются логическим И. Если в списке IP есть хотя бы один адрес, керберос-пользователь с другого адреса получит отказ. Если IP не указаны совсем, в списке будет значиться «All hosts are allowed» — и керберос-пользователь зайдёт откуда угодно.

• Права по хосту/IP-маске: NFSv3, NFSv4.1, NFSv4.2.
• Права через Kerberos: только NFSv4.1 / NFSv4.2, хост ABR — в домене, протоколы krb5p, krb5i, krb5.
• Windows Client for NFS: только NFSv3 + правка AnonymousUid/AnonymousGid = 399.
• Учётка или группа для Kerberos должна резолвиться и с backup-сервера, и с хоста ABR — в одном домене/realm или в доверенном.
• Если на одном сервере несколько ABR, данные каждого изолированы, и права надо выдавать отдельно для каждого.

Расписание снимков, retention и что здесь на самом деле означает иммутабельность

Шаг Schedule. Первым делом — чекбокс «Create repository snapshots». Если его не поставить, снимки не создаются, и — внимание — политика retention к репозиторию тоже не применяется. Вариантов расписания три: Daily at this time (ежедневно в указанное время, по будням или с заданной периодичностью дней), Monthly at this time (раз в месяц в конкретные дни) и Periodically every (с интервалом внутри суток, с опциональным окном разрешённых часов).

У периодического расписания есть механика, о которую спотыкаются: Veeam всегда отсчитывает интервалы от 12:00 AM. Поставили интервал 4 часа — снимки будут в 00:00, 04:00, 08:00, 12:00, 16:00, 20:00, и никак иначе. Сдвинуть можно только полем Start time within an hour или окном разрешённых часов: если запрещённый интервал закончился, Veeam сделает снимок немедленно и дальше пойдёт по сетке. И отдельно: расписание работает по локальному времени хоста репозитория, а не backup-сервера. Проверьте таймзону аплайнса до того, как будете объяснять клиенту, почему «ночной» снимок случился в обед.

Поле Retention policy — количество дней хранения снимков. Здесь же спрятан главный смысл всей фичи: этот же срок является сроком неизменяемости. Veeam накладывает на снимок hold ровно на указанное количество дней, и до истечения срока снимок не удалить — ни из консоли VBR, ни с самого хоста, ни скриптом, ни под рутом. Вот это и есть та самая разница между «папкой на NAS» и защищённым хранилищем: скрипт ротации, который в магазине когда-то съел месяц дампов, физически не смог бы тронуть точки восстановления.

Как я нарезал в «Растём вместе». Дамп учётной системы делается раз в сутки в 01:30, после закрытия кассовых смен и ночного обмена с сайтом, снимки ABR — Periodically every 6 hours, retention 21 день. Получается 84 точки восстановления при одном новом дампе в сутки. Наивно ожидалось, что снимки почти ничего не займут: новых данных-то один файл в день. По факту за три недели пул под этот ABR разросся до ~350 ГБ вместо расчётных 250 ГБ — потому что pg_dump -Fc даёт сжатый поток, который между днями практически не дедуплицируется, и каждый суточный дамп ложится целиком. Планируйте объём по формуле «размер дампа × число дней retention × коэффициент 1,4», а не по надеждам на ZFS.

Отдельно есть ручные снимки: Backup Infrastructure → Application Backup Repositories → выбрать репозиторий → Backup now. Ретеншен у них тот же, что в мастере, и как точка восстановления они ничем не отличаются от плановых. Пользуюсь этим перед каждым обновлением приложения — тридцать секунд, а нервов экономит много.

• Не поставили «Create repository snapshots» — нет ни снимков, ни ретеншена.
• Periodically every отсчитывается от 00:00, сдвиг — только через Start time within an hour.
• Расписание — по локальному времени хоста ABR, не backup-сервера.
• Retention в днях = срок хранения = срок иммутабельности (hold на снимке).
• Ручной снимок — кнопка Backup now, ретеншен наследуется.

Восстановление: revert против export — и почему «один ABR = одно приложение»

Восстановление живёт в мастере Instant Application Backup Repository Recovery, и на шаге Restore Mode есть ровно два варианта. Revert snapshot — снимок экспортируется по оригинальному NFS-пути, доступен на чтение и запись, права наследуются оригинальные, а данные, которые сейчас лежат в исходной папке, перезаписываются. Важная деталь: сам откат ничего из цепочки не удаляет — по завершении сессии восстановления все существующие снимки остаются доступны как точки восстановления. Второй вариант — Export snapshot via temporary path: Veeam монтирует выбранный снимок как отдельную временную NFS-шару, доступную только для чтения, оригинальная папка не трогается вообще, а права на временный путь настраиваются отдельно на шаге Permissions.

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

А вот дальше — самое важное проектное следствие, и его надо понять до того, как вы начнёте создавать репозитории. Revert откатывает ВЕСЬ dataset целиком, всю шару. Именно поэтому в ограничениях Veeam стоит прямое требование: под каждое приложение — свой отдельный ABR, и нельзя настраивать несколько приложений на запись в один репозиторий. Технически это возможно, но делает невозможным гранулярное восстановление отдельного приложения после revert.

Мы на этом обожглись ровно так, как описано. Изначально, экономя лицензии, сложили в один ABR и дампы учётной системы, и vzdump с Proxmox, и конфиги коммутаторов. Через две недели подрядчик накатил неудачное обновление учётной системы, потребовался откат на позавчерашнюю точку — и выяснилось, что вместе с базой уедут назад и конфиги двух дней, включая свежий VLAN для терминалов пункта выдачи. В итоге разложили на три отдельных ABR, каждый со своим расписанием и своим сроком хранения. Стоило это трёх лицензий вместо одной, но иначе решение просто не работает как решение.

И маленькая история про тестовое восстановление, потому что тесты надо делать до боевого. Учебный revert делали в 11 утра, забыв, что накануне подрядчик повесил внеплановую выгрузку остатков для маркетплейса. Процесс, писавший в примонтированную шару, получил под собой подменённый экспорт и красиво упал, оставив мусор. Вывод простой: перед revert останавливаем пишущий процесс и, по-хорошему, размонтируем шару на клиенте.

• Один ABR = одно приложение. Это не рекомендация, это требование из документации.
• Разные сроки хранения — тоже повод разнести: конфиги сетевого железа держим 90 дней, дампы БД — 21.
• Разные версии NFS (Linux-клиент против Windows Client for NFS) — тоже повод на отдельный репозиторий.
• Export via temporary path — рабочая лошадка, revert — аварийный инструмент.
• Ручные операции со снимками (zfs destroy, правка датасета) не поддерживаются и ведут к непредсказуемому поведению и потере данных.

Backup Copy, лицензии и куда я советую тратить силы в первую очередь

ABR сам по себе — это одна копия на одной железке в одной стойке. Правило 3-2-1 он не закрывает, и делать вид, что закрывает, нельзя. Закрывается оно Backup Copy Job: в мастере New Backup Copy Job на шаге Objects выбирается сам application backup repository, и дальше Veeam инкрементально переносит содержимое снимков в обычную цепочку VBK/VIB на другой репозиторий — hardened-репозиторий на второй площадке, объектное хранилище, Veeam Data Cloud Vault. Оттуда данные уже штатно уезжают на ленту, если вам нужен настоящий air gap. В «Растём вместе» копия уходит на второй hardened-репозиторий на удалённой площадке, ленты у магазина нет и для его масштаба не нужно.

Теперь про деньги, потому что это решающий фактор. По Considerations and Limitations один ABR потребляет одну лицензию Veeam Universal License на Veeam Data Platform Advanced или Premium — Foundation для ABR не годится. Socket-based лицензирование не поддерживается вообще — если у вас старая сокетная лицензия, ABR вам недоступен, и это надо выяснить до проектирования, а не после. Три приложения = три ABR = три VUL. И ещё: как только лицензия у ABR отзывается, расписание снимков автоматически отключается, ручное создание снимков тоже становится недоступно. То есть закончившаяся лицензия — это не «работает с предупреждением», это остановка защиты.

Где решение спорное, скажу прямо. Если у приложения есть родной плагин или интеграция Veeam — Oracle RMAN с плагином, PostgreSQL, MySQL, SAP HANA, MS SQL — берите плагин, а не ABR. Плагин знает про транзакции, про журналы, про point-in-time; ABR не знает ничего, он про файлы на шаре. ABR — инструмент для того, у чего плагина нет и не появится: АСУ ТП, СКУД, видеоаналитика, самописная учётка от подрядчика, который растворился, сетевое железо, экспорт LXC. Не тащите его туда, где есть решение поумнее.

У плагинов и требования к хранилищу другие. Veeam Plug-ins для Oracle RMAN, SAP HANA и Microsoft SQL Server пишут не в NFS-шару, а в обычные репозитории Veeam: backup repository или scale-out backup repository, в том числе в объектное хранилище как основной репозиторий — Veeam Data Cloud Vault, Amazon S3, S3-совместимое, Google Cloud Storage, Azure Blob, IBM Cloud, Wasabi, 11:11. Доступ плагина к объектному хранилищу всегда идёт через прокси-компонент — gateway server или mount server (direct connection), и при смене режима подключения плагин должен сначала связаться с backup-сервером, до этого его задания падают. Для S3-совместимого хранилища права на бакет выставляются вручную, а для иммутабельности нужны Versioning и Object Lock с отключённым default retention. Если SQL крутится внутри ВМ, альтернатива обоим вариантам — image-level бэкап с application-aware processing и восстановление через Veeam Explorer for Microsoft SQL Server.

И ещё одна развилка — где живёт retention. В ABR срок хранения задаёт только Veeam: число дней в поле Retention policy, оно же срок hold на снимке, а дампы внутри шары приложение может ротировать как угодно — старые версии всё равно останутся в снимках. У плагинов срок хранения задаётся в политике на стороне Veeam (для RMAN по умолчанию 7 дней, плюс опционально GFS), но приложение должно этому не мешать: для Oracle документация требует, чтобы CONTROL_FILE_RECORD_KEEP_TIME был больше recovery window, иначе записи о бэкапах перезаписываются раньше, чем retention признает их устаревшими. Две политики хранения, которые спорят друг с другом, — классическая причина «бэкапы есть, а восстановить нечего».

И приоритеты, если внедрять начинаете завтра. Первым делом — разложить, какие приложения вообще пишут дампы в папки, и кто имеет к этим папкам доступ на запись. Это бесплатно и уже даёт половину картины. Вторым — под самое ценное поднять один ABR и настроить нормальный retention с иммутабельностью. Третьим — Backup Copy на вторую площадку. А вот на что можно временно забить: на Kerberos (права по IP-маске в изолированном серверном сегменте — вполне рабочая первая итерация), на тонкую настройку почтовых уведомлений и на красивое расписание с окнами разрешённых часов. Это доделывается потом, за час.

• Инвентаризация: какие приложения пишут экспорты в сетевые папки, каким аккаунтом, с какими правами.
• Проверить тип лицензии: VUL на Data Platform Advanced или Premium, сокетная не подойдёт.
• Развернуть VIA с ISO в роли Hardened Repository, локальные диски + аппаратный RAID, никакого iSCSI/FC.
• Включить режим ABR через Submit Request с одобрением Security Officer.
• Создать по отдельному ABR на каждое приложение, права — deny all по умолчанию, добавлять точечно.
• Задать расписание и retention, поставить мониторинг на заполнение пула (алерт на 75 %).
• Настроить Backup Copy Job на вторую площадку и, при необходимости, выгрузку на ленту.
• Провести учебное восстановление обоими способами — и export, и revert — и записать процедуру.
• Убрать у приложения права на удаление в старой папке или увести старую папку целиком.
• Поставить напоминание на срок окончания лицензии: её отзыв гасит расписание снимков.

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