1,9 ТБ бэкапа при 20 ГБ занятых данных: как NetFlow раздувал инкременты

Бэкап-репозиторий Veeam подошёл к 95% заполнения. Смотрим свойства задания, сортируем по размеру — и одна виртуалка занимает почти половину всего репозитория: цепочка на 1,9 ТБ в 20 точках восстановления. При этом в самой VM данных — от силы пара десятков гигабайт. Диск провижен на 256 ГБ, занято по df около 20 ГБ. Откуда 1,9 ТБ?

Цифра, которая всё объясняет

Раскрываем цепочку точек по датам. Полные бэкапы (раз в неделю) — по 192 ГБ. А вот инкременты — ежедневно по 80–90 ГБ. Для VM, которая «почти не меняется», это абсурд: суточный инкремент больше, чем всё занятое место на диске.

df и image-level бэкап смотрят на разные уровни. df показывает только живые файлы внутри файловой системы, а Veeam обрабатывает блоки виртуального диска. После удаления часового буфера файл исчезает из df, но без эффективного исключения удалённых блоков записанные данные могут оставаться в блоках vmdk до их TRIM/reclaim. Поэтому 20 ГБ живых файлов и полный бэкап на 192 ГБ друг другу не противоречат.

Ключ — в колонке data reduction. У полных бэкапов она 1,3x (ОС и конфиги нормально сжимаются), а у инкрементов — 1,1x. Это не доказательство само по себе, но сильный признак плохо сжимаемых или уже сжатых данных. Что на этой машине генерирует десятки гигабайт такого содержимого в сутки?

Это NetFlow-коллектор. nfcapd принимает флоу с полутора десятков экспортёров и пишет файлы в локальный каталог-буфер. Раз в час крон сливает накопленное на сетевое хранилище и удаляет источник:

nfcapd → /home/netflow/<экспортёр>/…      (локальный буфер, ~1–2 ГБ в моменте)
  ↓ ежечасно
rsync --remove-source-files → NAS         (уехало — локально удалено)

В любой момент времени в буфере лежит немного — час флоу. Но за сутки через этот каталог проходит и удаляется ~80 ГБ. А Veeam работает по CBT (Changed Block Tracking): он считает не «сколько занято сейчас», а сколько блоков изменилось с прошлого бэкапа. Каждый цикл «записали флоу — удалили — записали новый» — это изменённые блоки. Диск остаётся почти пустым, но CBT честно фиксирует десятки гигабайт churn — оборота записи блоков — каждый день. Отсюда и инкременты по 80 ГБ, и цепочка на 1,9 ТБ.

Чего в бэкапе на самом деле нет

Первое желание — «исключить раздел с NetFlow». Но постоянное хранилище флоу (десятки терабайт) примонтировано по NFS с NAS, а image-level бэкап Veeam снимает vmdk через снапшот гипервизора — сетевые монтирования в образ не попадают вовсе. Их исключать не из чего: их там и нет.

Раздувает бэкап именно локальный транзитный буфер — он лежит на системном диске VM и попадает в образ. Значит, задача не «исключить NFS», а «убрать churn буфера из того, что бэкапится».

Два способа исключения — и почему выбран диск

Пофайловое исключение (guest file system exclusion). Для этой Linux-VM вариант не подходит: актуальный механизм Veeam для исключения файлов гостевой ОС работает с Windows NTFS и требует гостевой обработки. На этой машине к тому же не настроен guest processing. Значит, вырезать каталог из образа штатным пофайловым правилом нельзя.

Отдельный диск + disk-level exclusion. Выносим буфер на собственный vmdk и исключаем этот диск из задания целиком — блочно, без гостевого агента и без пофайлового сканирования на каждом прогоне. Заодно churn уходит с системного диска, а снапшоты и CBT системного диска становятся чище.

Выбор очевиден: отдельный диск.

Как перенесли, не тронув ни одного конфига сервиса

Коллектор пишет в конкретные пути (/home/netflow/<экспортёр>), FTP-приёмник — в свой каталог. Менять эти пути в конфигах — значит трогать работающие сервисы. Обошли иначе:

1. Добавили к VM новый vmdk (100 ГБ, thin), отформатировали, смонтировали как staging.
2. Перенесли данные буфера на новый диск.
3. Вернули прежние пути через bind-mount: физически данные лежат на новом диске, а /home/netflow и каталог FTP остаются на своих местах в дереве. Конфиги nfcapd, proftpd и крон-скрипты синхронизации — не тронуты.

/etc/fstab:
  UUID=… /mnt/stage ext4 defaults,noatime 0 2
  /mnt/stage/netflow    /home/netflow         none bind 0 0
  /mnt/stage/ftpbackup  /home/ftpuser/backup  none bind 0 0

Окно простоя сбора — секунды: остановили коллектор, досняли дельту, переключили монтирования, подняли коллектор обратно. В задании Veeam для этой VM выставили Disks to process → System disk only: бэкапится только системный диск, новый диск с буфером пропускается.

Реклейм: что освободилось сразу, а что — по расписанию

Дальше — убрать из репозитория уже накопленную раздутую цепочку. Здесь всплыла особенность hardened-репозитория: immutability. Последние точки защищены от удаления на 7 дней (это и есть смысл immutable-бэкапов — их не сможет стереть ни оператор, ни шифровальщик).

Поэтому удаление отработало ровно настолько, насколько позволила защита: старые, уже разблокированные точки удалились сразу — репозиторий с 95% упал до 59%, освободилось ~1,1 ТБ. Шесть свежих файлов (~0,67 ТБ) остались заблокированными до конца окна immutability и уходят автоматически, как только защита снимается. Ломать immutability ради быстрой уборки — плохой размен: это то самое, что спасает бэкапы при атаке.

Результат

Следующий же ночной прогон подтвердил фикс: VM отработала как новый полный бэкап на ~30 ГБ вместо прежних 192 ГБ, а дальнейшие инкременты стали копеечными — в образе больше нет транзитного флоу. Всё задание — 26 из 26 VM, без ошибок.

Что стоит забрать из этого кейса

• CBT считает churn, а не занятое место. Пустой на вид диск с интенсивной перезаписью коротко живущих файлов раздувает инкременты сильнее, чем большой, но статичный. «Занято 20 ГБ» и «в бэкап уходит 80 ГБ/сутки» прекрасно уживаются.
• Диагноз читается в свойствах бэкапа. Data reduction 1,1x на инкрементах — маркер плохо сжимаемых или уже сжатых данных (медиа, архивы, флоу). Это подсказка, где искать churn.
• Транзитные и уже-реплицированные данные бэкапить не нужно. Флоу и так постоянно уезжает на NAS — держать его ещё и в цепочке образов VM значит платить дважды. Правильная граница: буфер — на отдельный, исключённый из бэкапа диск.
• Bind-mount переносит данные, не трогая сервисы. Пути в конфигах остаются, а физически данные уже на другом диске — минимально инвазивно на боевой машине.
• Immutability ограничивает мгновенный реклейм — и это нормально. Часть места освобождается сразу, остальное — по истечении окна защиты. Обходить защиту ради скорости не стоит.

---

Итог не про Veeam и не про NetFlow по отдельности, а про то, что «большой бэкап» и «много данных» — не одно и то же. Полтора десятка строк диагностики, один новый диск и пара bind-mount’ов освободили около 1,8 ТБ по мере окончания immutability и остановили рост — не потому, что удалили что-то важное, а потому, что перестали бэкапить то, что и так надёжно лежит в другом месте.