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:

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 диска: в 2 раза быстрее по случайному IO, но usable = 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-бэкапов типовое значение 4-8, для общих файлов 1.1-1.3.

ARC и L2ARC

ARC (Adaptive Replacement Cache) — RAM-кэш ZFS. По умолчанию ZFS берёт до 50% RAM. Для бэкап-сервера с 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 секунды), занимает 0 дополнительного места.

Интеграция с 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 ZFS может быть использован как Datastore — PBS ставится прямо на ZFS-сервер, тот же сервер хранит дедуплицированные бэкапы. Это одна из самых эффективных схем.

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

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

Что сделали:

1. Собрали Supermicro 826 с 12 × 12 ТБ WD Ultrastar (CMR), 2 × 480 ГБ SSD под ОС, 1 × 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 эффективное хранилище в ~7x раз больше.
4. PBS Installation на том же сервере, 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 тыс руб работа. Экономия на дисках по сравнению с классическим NAS — 3-4 раза.

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

• Использование 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 тыс руб.