ZFS для корпоративного файл-сервера: 30 ТБ CAD-файлов

Архитектурное бюро «ПроектБюро» обратилось к специалистам itfresh.ru после инцидента: RAID-контроллер на файловом сервере вышел из строя, унеся с собой 3 ТБ данных — чертежи, 3D-модели в форматах AutoCAD, Revit и ArchiCAD, рендеры и проектную документацию. Бэкап оказался двухнедельной давности. Потеря двух недель работы команды из 25 архитекторов обошлась компании в 1.2 миллиона рублей.

Требования к новому хранилищу:

• Объём: 30 ТБ данных с ростом 5-8 ТБ в год.
• Надёжность: защита от выхода любых двух дисков из строя одновременно.
• Версионирование: возможность откатить любой файл до состояния на любой день за последние 90 дней.
• Производительность: 25 пользователей работают одновременно, открывая файлы размером от 50 МБ до 2 ГБ.
• Offsite backup: копия данных в удалённом офисе на случай пожара или кражи оборудования.

Мы выбрали ZFS — файловую систему, изначально разработанную в Sun Microsystems и объединяющую функции файловой системы, менеджера томов и средства защиты данных в одном решении.

ZFS работает с тремя уровнями абстракции, которые важно понимать перед настройкой.

Vdev (virtual device) — группа физических дисков, объединённых для обеспечения избыточности. Это аналог RAID-массива, но реализованный на уровне файловой системы, а не аппаратного контроллера. Типы vdev:

• mirror — зеркало из двух дисков (аналог RAID 1).
• raidz1 — один диск на чётность (аналог RAID 5), выдерживает потерю одного диска.
• raidz2 — два диска на чётность (аналог RAID 6), выдерживает потерю двух дисков.
• raidz3 — три диска на чётность, для особо критичных данных.

Pool (пул) — один или несколько vdev, объединённых в единое хранилище. Данные распределяются между vdev по принципу: каждый блок целиком на одном vdev, но последующие блоки могут попасть на другой vdev.

Dataset (датасет) — логический раздел внутри пула с собственными настройками (сжатие, квоты, размер блока). Каждый датасет можно настраивать независимо.

Для «ПроектБюро» мы собрали следующую конфигурацию:

# Сервер: Supermicro X12, Xeon E-2388G, 128 ГБ ECC RAM
# Диски: 8x 8TB Seagate Exos (HDD) + 2x 1TB Samsung 990 PRO (SSD)

# Создаём пул из двух vdev RAIDZ2 по 4 диска
zpool create -o ashift=12 datapool \
    raidz2 /dev/sda /dev/sdb /dev/sdc /dev/sdd \
    raidz2 /dev/sde /dev/sdf /dev/sdg /dev/sdh

# ashift=12 — секторы 4K (обязательно для современных дисков)
# Два vdev RAIDZ2 = потеря до 2 дисков в каждой группе
# Полезная ёмкость: 2 * (4-2) * 8TB = 32 TB

# Проверяем статус пула
zpool status datapool

При объёме диска 8 ТБ перестроение массива после выхода одного диска (resilver) занимает 12-24 часа. В это время массив работает без избыточности: потеря второго диска означает полную потерю данных. Вероятность некорректируемой ошибки чтения (URE) для SATA-дисков составляет ~10¹⁴ бит, что при чтении 8 ТБ данных даёт ненулевую вероятность сбоя.

RAIDZ2 устраняет эту проблему: два диска на чётность позволяют потерять один диск и получить URE на другом — массив всё равно восстановится. Для дисков 8 ТБ и выше RAIDZ2 — минимально разумная конфигурация.

ZFS принципиально отличается от аппаратного RAID в подходе к целостности данных. Традиционный RAID не знает, что хранится на дисках — он работает с блоками. ZFS использует дерево Меркла: контрольная сумма каждого блока хранится в родительском блоке, вплоть до корня (uberblock). Это позволяет обнаруживать «тихую» порчу данных (bit rot), которую аппаратный RAID пропустит.

# Принудительная проверка целостности всех данных (scrub)
zpool scrub datapool

# Статус scrub
zpool status datapool
#  scan: scrub in progress since Sat Apr  5 02:00:00 2026
#        18.5T scanned at 1.2G/s, 12.3T issued at 856M/s
#        0 repaired, 66.5% done

# Расписание scrub через cron — раз в две недели
# /etc/cron.d/zfs-scrub
0 2 1,15 * * root /sbin/zpool scrub datapool

ZFS использует многоуровневую систему кэширования, критически важную для производительности файл-сервера с HDD-дисками.

ARC (Adaptive Replacement Cache) — кэш в оперативной памяти. В отличие от простого LRU-кэша, ARC отслеживает два списка: недавно использованные (MRU) и часто запрашиваемые (MFU) данные. Это позволяет эффективно кэшировать как активные проекты (MRU), так и часто открываемые шаблоны и библиотеки (MFU).

Из 128 ГБ RAM сервера мы выделили 96 ГБ под ARC:

# /etc/modprobe.d/zfs.conf
options zfs zfs_arc_max=103079215104  # 96 ГБ в байтах
options zfs zfs_arc_min=53687091200   # 50 ГБ минимум

# Проверка текущего состояния ARC
cat /proc/spl/kstat/zfs/arcstats
# Или через arc_summary
arc_summary
# ARC Size: 89.3 GiB (Target: 96.0 GiB)
# Hit Rate: 94.2%

L2ARC (Level 2 ARC) — расширение кэша на SSD. Данные, вытесненные из ARC, попадают на SSD перед обращением к медленным HDD. Мы установили один из SSD как L2ARC:

# Добавляем L2ARC (SSD для кэша чтения)
zpool add datapool cache /dev/nvme0n1

# Проверяем, что L2ARC используется
zpool iostat -v datapool
# NAME                   STATE     READ WRITE
# datapool               ONLINE    1.2G  456M
#   raidz2-0             ONLINE     612M  228M
#   raidz2-1             ONLINE     618M  228M
# cache
#   nvme0n1              ONLINE     2.1G    0

SLOG (Separate ZFS Intent Log) — выделенный SSD для журнала синхронных записей (ZIL). При сохранении файла приложение ожидает подтверждения записи на диск. ZIL буферизирует эти записи на быстром SSD, возвращая подтверждение мгновенно:

# Добавляем SLOG (SSD для журнала синхронных записей)
zpool add datapool log mirror /dev/nvme1n1p1 /dev/nvme1n1p2

# SLOG зеркалируем: потеря журнала при отключении питания
# приведёт к потере последних незакоммиченных транзакций

ZFS поддерживает прозрачное сжатие на уровне файловой системы. Алгоритм LZ4 обеспечивает скорость сжатия 800 МБ/с на ядро при записи и 4.5 ГБ/с при чтении — на HDD-массиве узким местом будут диски, а не CPU.

# Создаём датасеты для разных типов данных
zfs create datapool/projects
zfs create datapool/archive
zfs create datapool/renders
zfs create datapool/templates

# Включаем сжатие LZ4 (по умолчанию)
zfs set compression=lz4 datapool

# Для архивных данных — более агрессивное сжатие
zfs set compression=zstd datapool/archive

# Настраиваем размер блока под CAD-файлы (большие файлы)
# По умолчанию 128 КБ, увеличиваем до 1 МБ для больших файлов
zfs set recordsize=1M datapool/projects
zfs set recordsize=1M datapool/renders

# Для мелких файлов (текстовые документы, спецификации)
zfs set recordsize=128K datapool/templates

# Квоты и резервирование
zfs set quota=25T datapool/projects
zfs set reservation=5T datapool/projects  # Гарантированное место
zfs set quota=10T datapool/archive

# Проверяем коэффициент сжатия
zfs get compressratio datapool
# NAME       PROPERTY       VALUE  SOURCE
# datapool   compressratio  1.42x  -

# Для CAD-файлов сжатие 1.3-1.5x типично
# Для текстовых файлов и спецификаций — до 3-4x

Относительно дедупликации: мы сознательно не включили её. Дедупликация в ZFS требует огромного количества RAM (около 5 ГБ на 1 ТБ данных) для хранения таблицы хешей в памяти. При 30 ТБ данных потребовалось бы 150 ГБ RAM только на дедупликацию. Кроме того, CAD-файлы редко содержат дублирующиеся блоки — выигрыш был бы минимальным.

Снапшоты ZFS — одна из ключевых причин выбора этой файловой системы. Создание снапшота занимает доли секунды независимо от объёма данных, потому что ZFS не копирует данные. Благодаря механизму copy-on-write снапшот «замораживает» текущее состояние дерева блоков, а изменённые блоки записываются в новое место.

# Автоматические снапшоты через zfs-auto-snapshot
apt install zfs-auto-snapshot

# Настройка политики хранения в /etc/cron.d/zfs-auto-snapshot:
# Каждые 15 минут — хранить 4 (последний час)
# Каждый час — хранить 24 (последние сутки)
# Каждый день — хранить 90 (три месяца)
# Каждую неделю — хранить 12 (три месяца)
# Каждый месяц — хранить 12 (год)

# Или ручное создание снапшота перед крупной операцией
zfs snapshot datapool/projects@before-migration-2026-04-05

# Список снапшотов
zfs list -t snapshot -o name,used,creation datapool/projects
# NAME                                          USED  CREATION
# datapool/projects@autosnap_2026-04-05_00:00   156M  Sat Apr  5  0:00 2026
# datapool/projects@autosnap_2026-04-05_00:15    89M  Sat Apr  5  0:15 2026
# datapool/projects@autosnap_2026-04-05_00:30    45M  Sat Apr  5  0:30 2026

# Восстановление удалённого файла из снапшота
# Снапшоты доступны как скрытая директория .zfs/snapshot
ls /datapool/projects/.zfs/snapshot/
cp /datapool/projects/.zfs/snapshot/autosnap_2026-04-04_12:00/project42/plan.dwg \
   /datapool/projects/project42/plan.dwg

# Полный откат датасета до снапшота (осторожно!)
zfs rollback datapool/projects@autosnap_2026-04-04_12:00

Для пользователей Windows, подключающихся по SMB (Samba), ZFS-снапшоты автоматически отображаются как «Предыдущие версии» в Проводнике — через модуль vfs_shadow_copy2:

# /etc/samba/smb.conf
[projects]
    path = /datapool/projects
    vfs objects = shadow_copy2
    shadow:snapdir = .zfs/snapshot
    shadow:sort = desc
    shadow:format = autosnap_%Y-%m-%d_%H:%M

ZFS send/receive — механизм передачи снапшотов между серверами. Первая передача содержит полный снапшот, последующие — только инкрементальные изменения. Это позволяет реплицировать 30 ТБ хранилища, передавая по сети только 10-50 ГБ в день (объём реальных изменений).

# Первичная репликация (полный снапшот)
zfs snapshot datapool/projects@initial
zfs send datapool/projects@initial | \
    ssh backup-server zfs receive backuppool/projects

# Инкрементальная репликация (только изменения)
zfs snapshot datapool/projects@daily-2026-04-05
zfs send -i datapool/projects@daily-2026-04-04 \
          datapool/projects@daily-2026-04-05 | \
    ssh backup-server zfs receive backuppool/projects

# Автоматизация через скрипт
#!/bin/bash
# /usr/local/bin/zfs-replicate.sh
SRC_POOL="datapool"
DST_HOST="backup-server"
DST_POOL="backuppool"
DATE=$(date +%Y-%m-%d)
YESTERDAY=$(date -d yesterday +%Y-%m-%d)

for dataset in projects archive templates; do
    # Создаём новый снапшот
    zfs snapshot ${SRC_POOL}/${dataset}@replicate-${DATE}

    # Отправляем инкрементально
    zfs send -i ${SRC_POOL}/${dataset}@replicate-${YESTERDAY} \
             ${SRC_POOL}/${dataset}@replicate-${DATE} | \
        ssh ${DST_HOST} zfs receive -F ${DST_POOL}/${dataset}

    # Удаляем позавчерашний снапшот на обоих серверах
    OLD=$(date -d "2 days ago" +%Y-%m-%d)
    zfs destroy ${SRC_POOL}/${dataset}@replicate-${OLD} 2>/dev/null
    ssh ${DST_HOST} zfs destroy ${DST_POOL}/${dataset}@replicate-${OLD} 2>/dev/null
done

Важная деталь: при наличии нативного шифрования ZFS (включено с версии 0.8) данные передаются в зашифрованном виде через флаг --raw. Принимающий сервер хранит данные зашифрованными, не имея доступа к ключу — идеально для offsite-резервных копий на чужом оборудовании:

zfs send --raw -i @snap1 @snap2 | ssh backup zfs receive pool/data

Мы развернули хранилище «ПроектБюро» на Ubuntu Server 24.04 LTS с OpenZFS 2.2. Альтернативой был FreeBSD, где ZFS — нативная файловая система.

Практические отличия:

• ZFS on Linux — ставится как модуль ядра через DKMS или kmod. Обновление ядра требует пересборки модуля. В Ubuntu и Debian пакет zfsutils-linux делает это автоматически.
• ZFS on FreeBSD — интегрирован в ядро, поддержка boot-from-ZFS из коробки. Выше стабильность на специфических конфигурациях (дедупликация, большие ARC).
• Функциональный паритет: с 2020 года оба варианта развиваются в рамках проекта OpenZFS, feature flags идентичны.

Мы выбрали Linux из-за лучшей поддержки Samba для Windows-клиентов и доступности инженеров.

Результаты после трёх месяцев эксплуатации:

Если вашей компании нужно надёжное хранилище для больших файлов с версионированием, сжатием и offsite-репликацией — обращайтесь к специалистам itfresh.ru. Мы спроектируем и развернём ZFS-хранилище, настроим снапшоты, мониторинг и автоматическую репликацию.