ZFS как бэкап-хранилище с дедупликацией: в 5-12 раз меньше дисков для тех же данных

Меня зовут Семёнов Евгений, директор АйТи Фреш. Расскажу про реальную боль: бэкапы 20 виртуалок за месяц — 4.8 ТБ, за три — 14 ТБ, за год — 60 ТБ. Диски заканчиваются быстрее, чем успеваешь их заказывать. Выход — ZFS с дедупликацией и zstd-сжатием. У клиента-логиста бэкапы 18 ТБ в Veeam на ZFS-хранилище ужались до 2.2 ТБ. Ниже — как это собрать, когда включать dedup, и где легко ошибиться.

Почему именно ZFS для бэкапов

В бэкапах работают три особенности ZFS:

• Дедупликация. Одинаковые блоки хранятся один раз. У бэкапов VM — 70-90% блоков повторяются. Реальная экономия 4-10x.
• Inline-сжатие zstd. Поверх dedup ещё 30-50% сжатия. Опция compression=zstd — почти бесплатно по CPU.
• Snapshots и zfs send/receive. Мгновенные снимки, инкрементальная репликация на второй сервер (off-site) почти бесплатно.
• Checksumming. Каждый блок подписан sha256 — bit-rot ловится автоматически, при scrub чинится.
• Scrub. Раз в месяц проверяет все данные на целостность. В бэкап-хранилищах это обязательно.

Железо и размерность

Важно про SMR-диски (Shingled Magnetic Recording): ZFS с ними формально работает, но медленно и нестабильно. Только CMR. У Seagate — Exos и IronWolf Pro, у WD — Ultrastar и Red Pro. Проверяйте перед покупкой.

Структура пула: raidz или mirror

Для бэкапов стандартный выбор — raidz2, аналог RAID6. Выдержит одновременный отказ двух дисков, и данные не потеряются.

# 8 дисков по 12 ТБ в raidz2
zpool create -o ashift=12 backup raidz2 \
  /dev/disk/by-id/ata-WDC_WD120EDAZ-... \
  /dev/disk/by-id/ata-WDC_WD120EDAZ-... \
  ... (итого 8)
# Usable = (8-2) × 12 = 72 ТБ до сжатия

Для особо критичных бэкапов берём raidz3: три parity-диска. Нужна скорость? Два vdev по raidz2 — получаете полосатый IO.

zpool create -o ashift=12 backup \
  raidz2 ata-1 ata-2 ata-3 ata-4 \
  raidz2 ata-5 ata-6 ata-7 ata-8

Два vdev по 4 диска: скорость вдвое выше по случайному IO. Но полезный объём — 48 ТБ вместо 72. Компромисс очевидный.

Настройка dataset для бэкапов

# Dataset для VM-бэкапов
zfs create backup/vms
zfs set compression=zstd backup/vms
zfs set dedup=on backup/vms
zfs set atime=off backup/vms
zfs set recordsize=1M backup/vms  # для больших файлов
zfs set xattr=sa backup/vms
zfs set sync=standard backup/vms

# Dataset для файлов (без dedup)
zfs create backup/files
zfs set compression=zstd backup/files
zfs set dedup=off backup/files
zfs set recordsize=128K backup/files

На нашей практике устоялось правило: VM-бэкапы — с dedup, файлы и логи — без. Файлы у пользователей разные: jpg, docx, pdf, архивы. Dedup на них даёт 1.1–1.3x коэффициент, а RAM жрёт нехило. Не стоит.

Проверка, стоит ли включать dedup

Перед тем как включить dedup на существующий пул — обязательно проверьте через zdb. Не пропускайте этот шаг.

zdb -S backup
# Выведет ожидаемый deduplication ratio
# Если больше 2.0 — включаем
# Если меньше 1.5 — не включаем, не стоит RAM-расходов

Для VM-бэкапов типовое значение dedup ratio — 4–8x. Для общих файлов — 1.1–1.3x. Разница принципиальная.

ARC и L2ARC

ARC (Adaptive Replacement Cache) — это RAM-кэш ZFS. По умолчанию он забирает до 50% памяти. На бэкап-сервере с dedup эту планку лучше поднять — иначе производительность падает заметно.

# /etc/modprobe.d/zfs.conf
options zfs zfs_arc_max=85899345920  # 80 ГБ из 128
options zfs zfs_arc_min=21474836480  # 20 ГБ

# Применить
update-initramfs -u
reboot

Проверить статус ARC:

arc_summary | head -30
# ARC size:  78 GiB
# Hit ratio:  94.2 %
# DDT entries:  1.2M / 1.5M

Hit ratio ниже 85% — сигнал тревоги. Добавьте RAM или подключите L2ARC на NVMe как расширение ARC. Тянуть с этим не стоит.

Snapshots и incremental send/receive

Главная фишка — снимки и репликация:

# Создать snapshot
zfs snapshot backup/vms@hourly-2026-03-16-10

# Инкрементальная отправка на off-site сервер
zfs send -i backup/vms@hourly-2026-03-16-09 \
         backup/vms@hourly-2026-03-16-10 | \
  ssh offsite.example.ru "zfs receive backup/vms"

# Полная отправка (первый раз)
zfs send backup/vms@initial | ssh offsite "zfs receive backup/vms"

Автоматизацию снимков удобно строить через sanoid/syncoid — пакет есть в Debian, ставится штатно.

# /etc/sanoid/sanoid.conf
[backup/vms]
  use_template = production
[template_production]
  frequently = 0
  hourly = 48
  daily = 30
  monthly = 12
  autosnap = yes
  autoprune = yes

# Репликация через syncoid в cron
syncoid backup/vms offsite:backup/vms

Типовая схема: каждые 48 часовых снимков, 30 суточных, 12 месячных, 3 годовых. Каждый снимок — мгновенный, 1–2 секунды. Дополнительного места на диске он не занимает до тех пор, пока данные не начинают меняться.

Интеграция с Veeam и Proxmox PBS

С Veeam схема простая: ZFS-сервер экспортируется как NFS- или SMB-шара, Veeam цепляет её как backup target и работает в штатном режиме.

# На ZFS-сервере
apt install nfs-kernel-server
zfs set sharenfs='rw=@10.10.0.0/24,no_root_squash' backup/veeam

# В Veeam: Backup Repository → Add → SMB/NFS

С Proxmox Backup Server ещё лучше: PBS ставится прямо на ZFS-сервер, datastore лежит тут же. Одна машина хранит дедуплицированные бэкапы и сама же их обслуживает. Одна из самых эффективных схем, с которыми мы работаем.

Кейс: бэкап-сервер для логистической компании

В январе 2026 к нам пришла логистика: 80 рабочих мест, 30 VM на Proxmox. До нас бэкапы шли в локальный NAS 20 ТБ через Veeam без дедупликации. За 4 месяца он забился на 17 ТБ. Надо было либо докупать диски, либо оптимизировать — выбрали второе.

Что сделали:

1. Собрали Supermicro 826: 12 × 12 ТБ WD Ultrastar (CMR), 2 × 480 ГБ SSD под ОС, Samsung PM9A3 960 ГБ под SLOG+L2ARC, 128 ГБ ECC RAM.
2. Debian 12 + OpenZFS 2.2 + Sanoid.
3. Пул raidz2 на 10 дисках, ещё 2 в hot-spare. Usable — 84 ТБ raw. Включаем compression=zstd и dedup=on — эффективное хранилище вырастает примерно в 7 раз.
4. PBS установлен на том же сервере, datastore указывает на backup/pbs.
5. Veeam-бэкапы перенесли через restore на ZFS, Veeam переконфигурировали на работу через NFS-шару.
6. Off-site репликация: второй сервер в другом здании, syncoid запускается каждые 6 часов.
7. Zabbix следит за zpool status, ARC hit ratio и SMART всех дисков в реальном времени.

Через 3 месяца работы: 18 ТБ исходных данных в Veeam/PBS умещаются в 2.1 ТБ на ZFS. Dedup ratio — 8.6x, compression ratio — 1.4x. Off-site сервер держит полную копию, проверенную тестовым восстановлением одной VM. Стоимость проекта: 385 тыс руб за сервер плюс 72 тыс руб работа. По дискам экономия в 3–4 раза против классического NAS.

Частые ошибки

• Использование SMR-дисков. ZFS с ними работает, но resilver 12 ТБ диска занимает 2 недели вместо 2 дней.
• Слишком большой dedup без RAM. 20 ТБ пула с dedup на 16 ГБ RAM — катастрофа. Если RAM не хватает, DDT не помещается в ARC и каждое обращение читает диск.
• recordsize=128K для VM-бэкапов. Для больших образов VM лучше 1M — меньше метаданных, быстрее scrub.
• Отсутствие scrub. Без регулярного scrub (раз в месяц) bit-rot накапливается и может стоить данных.
• atime=on. Обновление времени доступа при каждом чтении — лишние IOPS. Для бэкапов всегда atime=off.

Мониторинг

• zpool status -v — должно быть ONLINE без ошибок.
• zpool iostat -v 5 — нагрузка на каждый vdev.
• arc_summary | grep ratio — hit ratio ARC.
• zfs list -t snapshot — актуальность снимков.
• zpool scrub backup — запуск в cron раз в месяц.
• SMART каждого диска через smartmontools плюс алерты в Zabbix — стандартный минимум для таких конфигов.

FAQ — ZFS для бэкапов

Нужно ли включать dedup на ZFS?

Для бэкапов виртуальных машин и файловых бэкапов — да, даёт экономию 3-8x. Для общих данных, аудио, видео — нет, зря тратит RAM (1-5 ГБ RAM на 1 ТБ данных). Проверить полезность можно через zdb -S pool — покажет ожидаемый коэффициент. Если меньше 2x — dedup не включайте.

Raidz2 или mirror для бэкапов?

RAIDZ2 (аналог RAID6) — два parity-диска, выдерживает одновременный отказ двух дисков. Используем для бэкапов объёмом от 30 ТБ. Mirror (RAID1/10) — быстрее при записи, но ёмкости в 2 раза меньше. Для малых бэкапов до 10 ТБ — mirror из двух SSD 2×4 ТБ.

Сколько ARC (RAM-кэш) нужно?

Для ZFS без dedup — 1-2 ГБ RAM на 1 ТБ пула. Для ZFS с dedup — 4-5 ГБ на ТБ обязательно. Если на сервере 24 ТБ диск с dedup — минимум 100 ГБ RAM, иначе при переполнении DDT (dedup table) сервер начнёт ложиться на колени. Новое L2ARC на SSD частично помогает.

zfs send/receive или rsync для репликации?

zfs send/receive — native, работает с snapshots, incremental почти бесплатен. Передаёт только изменённые блоки на уровне ФС. rsync работает с файлами и на ZFS теряет смысл — дублирует логику. Для off-site копии: primary backup → zfs send → offsite backup server каждые 6 часов. Идеально.

Сколько стоит собрать ZFS-бэкап на 30 ТБ?

Сервер Dell R730xd б/у с 12 × 8 ТБ SAS HDD — около 320-450 тыс руб. Или простая сборка на Supermicro с 8 × 12 ТБ — 220-280 тыс руб. ZFS софт бесплатный (OpenZFS). Работа под ключ (установка, конфигурация пула, интеграция с Veeam/PBS, мониторинг, обучение) — от 65 тыс руб. Итого 280-520 тыс руб.