Проектирование собственного файлового архива на сервере: ZFS, ext4, RAID и масштабирование

Собственный файловый архив на сервере стоит разворачивать, когда данных становится больше 10 ТБ, доступ нужно контролировать на уровне сети и прав, а копии требуется держать в своём контуре. Тогда вы покупаете или арендуете железо, собираете пул, отдаёте файлы через Nginx и сами отвечаете за бэкапы и восстановление.

Ниже разбираем полный цикл проектирования: критерии выбора между своим архивом и облаком, сравнение ZFS, ext4 и объектного хранилища, расчёт полезной ёмкости и уровня RAID, схему с разделением фронтенда и бэкенда, закладку масштабирования вместе с бэкапами и чек-лист проверок перед вводом в эксплуатацию.

Зачем проектировать файловый архив своими силами

Файловый архив компании хранит документы, сканы, медиафайлы, выгрузки из внутренних систем и архивные копии баз данных. От обычной шары его отличают единая точка доступа, разграничение прав, версионирование и предсказуемое время восстановления после сбоя.

Своя система даёт контроль над данными: вы выбираете, где физически лежат диски, кто имеет сетевой доступ, чем шифруется трафик и сколько копий уезжает на другую площадку. Взамен вы берёте на себя железо, замену дисков, мониторинг, бэкапы и разбор инцидентов.

Когда собственный архив оправдан, а когда нет

Решение упирается в четыре фактора: объём данных, требования к контролю доступа, ограничения на вынос данных за контур и бюджет на администрирование.

Порог, после которого свой сервер выигрывает по деньгам, начинается примерно на 10-20 ТБ активных данных, особенно если архив читают часто и много скачивают наружу: у облачных провайдеров отдельно тарифицируется исходящий трафик.

Считайте TCO на три года: диски и сервер, дисковую полку, резервные накопители, электричество, место в стойке, часы инженера на настройку и поддержку. Сравнивайте с суммой абонентской платы, платежей за исходящий трафик и запросы. Для мусорных данных с нулевой ценностью, вроде временных артефактов сборки, свой архив не нужен: дешевле выбросить.

Ключевые требования к архиву: надёжность, доступность, масштабируемость

До выбора файловой системы зафиксируйте RPO (сколько данных допустимо потерять), RTO (за какое время нужно поднять сервис) и целевую доступность. Типовой набор для архива выглядит так:

Эти цифры определяют технику. RPO в один час требует снапшотов каждые 15-30 минут и репликации, а не ежедневного rsync. RTO в 8 часов заставляет держать готовый стенд для восстановления и проверенный план действий. Требование доступности 99.9% означает отсутствие единой точки отказа: два контроллера, два блока питания, резервный фронтенд.

Выбор файловой системы для хранилища: ZFS, ext4 или объектное хранилище

Три подхода закрывают разные задачи. Перед сравнением разложите стек по уровням: диски, контроллер, RAID или vdev, пул, файловая система, кэш, сеть, репликация. Так проще увидеть, где именно вы теряете производительность и на каком уровне защищаете данные. Разбор уровней и типовых узких мест есть в материале о том, как устроено программное хранилище.

ZFS: возможности и требования к железу

ZFS объединяет файловую систему и менеджер томов. Вы создаёте пул из vdev-ов (зеркала или RAIDZ), внутри - датасеты с независимыми настройками: квотами, компрессией, размером записи, снапшотами. Контрольные суммы считаются для каждого блока, поэтому повреждённый блок читается с зеркала или восстанавливается по чётности в RAIDZ.

zpool create archive mirror /dev/sda /dev/sdb
zpool create archive raidz2 /dev/sda /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf
zfs create archive/docs
zfs set compression=lz4 archive
zfs set recordsize=1M archive/media
zfs snapshot archive/docs@daily-2026-09-23

Требования к железу:

• Память: минимум 8 ГБ на хост плюс примерно 1 ГБ на каждый терабайт пула под ARC. ECC-память формально не обязательна, но при её отсутствии ошибка в оперативной памяти приводит к записи повреждённого блока.
• Отдельный SSD или NVMe под SLOG для синхронной записи и под L2ARC для чтения, если рабочий набор файлов не влезает в RAM.
• Контроллер в режиме HBA, без аппаратного RAID: ZFS нужен прямой доступ к дискам.

Дедупликацию включайте только при явном повторении данных. Таблица DDT живёт в памяти и при неудачном профиле данных съедает заметную долю RAM, а без запаса памяти пул теряет скорость. Компрессия lz4 почти не нагружает CPU и поднимает эффективную ёмкость, zstd даёт больший выигрыш на текстах и логах.

ext4 и LVM: простота и предсказуемость

ext4 остаётся разумным выбором для простого файлового сервера: стабильная кодовая база, предсказуемая производительность на последовательных операциях, поддержка в любом дистрибутиве. Контрольных сумм данных здесь нет, целостность после сбоя проверяет e2fsck, а восстанавливать повреждённый блок не из чего.

pvcreate /dev/sdb /dev/sdc
vgcreate archive /dev/sdb /dev/sdc
lvcreate -l 100%FREE -n files archive
mkfs.ext4 /dev/archive/files
lvextend -l +100%FREE /dev/archive/files && resize2fs /dev/archive/files

LVM добавляет гибкость: тома расширяются на лету, снапшоты снимаются на уровне блоков и требуют места в группе под изменения. Снапшот LVM не заменяет бэкап: он лежит на тех же дисках и при отказе пула исчезнет вместе с основными данными. Запас свободного места в группе держите не меньше 10-15%.

Объектное хранилище: S3-совместимые решения (MinIO, Ceph)

Объектное хранилище отдаёт данные по HTTP API, совместимому с S3: put, get, list, multipart. Вместо дерева каталогов здесь бакеты и объекты с метаданными, версионированием и правилами жизненного цикла. Горизонтальное масштабирование заложено в саму модель: ёмкость растёт добавлением узлов и дисков, клиенты этого не замечают.

MinIO проще в развёртывании: один бинарник, режим single-node для тестов и distributed для продакшна с erasure coding. Ceph мощнее и тяжелее: RADOS, мониторы, OSD, карта CRUSH, отдельная сеть для репликации, минимум три узла, а на практике пять. Для архива со сроком жизни данных в годы Ceph даёт гибкость раскладки, но требует инженера, который будет им заниматься. Как выбрать между файловым, блочным и объектным уровнем и развернуть MinIO или Ceph, разбираем в статье о проектировании хранилища документов.

Сценарии для объектного хранилища: доступ из приложений по API, объёмы в сотни терабайт, несколько площадок, версионирование и lifecycle-политики на стороне хранилища. Для отдачи файлов браузеру по постоянной ссылке с разграничением прав ближе остаётся файловая система за Nginx. Подробное сравнение уровней с таблицей критериев приведено в обзоре объектного, блочного и файлового хранилищ.

• Архив документов с высокой ценностью данных: ZFS с RAIDZ2 или зеркалами.
• Простые SMB/NFS-шары до 20-30 ТБ: ext4 на LVM.
• API-доступ, версионирование, рост за сотни терабайт: MinIO, при высоких требованиях к распределённости Ceph.

Расчёт ёмкости и подбор уровня RAID

Raw capacity - суммарный объём всех дисков. Usable capacity - то, что видит файловая система после вычета чётности, служебных структур и запаса на рост. На массиве из 12 дисков разрыв между этими числами измеряется десятками терабайт, поэтому считайте заранее, а не после закупки.

Формулы и примеры расчёта полезной ёмкости

Обозначим N - число дисков, S - объём одного диска.

• RAID 5 и RAIDZ1: (N - 1) x S
• RAID 6 и RAIDZ2: (N - 2) x S
• RAIDZ3: (N - 3) x S
• RAID 10 и зеркала: (N / 2) x S

Из результата вычитайте резерв. Держите заполнение пула ZFS ниже 80%: при приближении к пределу растёт фрагментация метаданных и падает скорость записи. Для ext4 оставьте 5% зарезервированных блоков под root и отдельно 10-15% свободного места. Пример: 12 дисков по 8 ТБ в RAIDZ2 дают 80 ТБ, рабочий порог 80% - это 64 ТБ, дальше планируйте расширение.

Влияние нагрузки на выбор RAID

SMR-диски подходят для последовательной записи и холодных архивов, но при ребилде и случайной записи проваливаются по скорости. В пул ZFS их лучше не ставить: производительность пула определяется самым медленным vdev.

Почему RAID 5 опасен на больших дисках

При ребилде RAID 5 массив читает все оставшиеся диски целиком. Если на одном из них встретится неисправимая ошибка чтения (UERE), данные теряются: одной чётности не хватает, чтобы восстановить и сбойный блок, и заменяемый диск. Паспортная частота для потребительских дисков - 1 ошибка на 10 в 14-й степени прочитанных бит, для корпоративных - 1 на 10 в 15-й степени.

Числа в таблице получены по модели независимых ошибок, реальная картина зависит от партии дисков, температуры и вибрации. Вывод от этого не меняется: для дисков от 2 ТБ берите RAID 6 или RAIDZ2, для дисков от 8 ТБ - RAIDZ2 как минимум, а лучше RAIDZ3 или зеркала. RAID 5 оставляйте для SSD небольшой ёмкости и массивов из 3-4 дисков.

Архитектура файлового архива: разделение фронтенда и бэкенда

Схема: клиент, затем балансировщик или Nginx, затем кэш, затем бэкенд-хранилище. Фронтенд занимается TLS, авторизацией, лимитами и отдачей байтов, бэкенд отвечает за диски, целостность и снапшоты. Разделение даёт две независимые точки масштабирования и упрощает безопасность: снаружи виден только фронтенд. Пошаговый план построения системы хранения с аудитом источников, расчётом IOPS и командами для ZFS и Ceph описан в материале о построении системы сбора и хранения данных.

Фронтенд-слой: Nginx как reverse proxy и отдача файлов

location /files/ {
  alias /mnt/archive/;
  autoindex off;
  sendfile on;
  tcp_nopush on;
  limit_rate 20m;
  limit_conn perip 8;
  add_header X-Content-Type-Options nosniff always;
}

Директива autoindex off закрывает листинг каталогов: открытый autoindex превращает архив в публичную папку и часто становится причиной утечек. sendfile и tcp_nopush снижают нагрузку на CPU при отдаче крупных файлов, limit_rate и limit_conn защищают канал от одного качающего пользователя.

Авторизацию оставьте приложению и используйте X-Accel-Redirect: бэкенд проверяет права, отдаёт внутренний заголовок, а Nginx читает файл с диска, не пропуская байты через приложение. Для горячих файлов включите proxy_cache с ключом по URI, статику с хешем в имени отдавайте с immutable-кэшем. Ограничение по источникам добавьте через valid_referers или одноразовый токен в ссылке, тогда чужой сайт не встроит ваши файлы и не съест трафик.

Бэкенд-хранилище: ZFS-пул или объектное хранилище

На ZFS разложите данные по датасетам: archive/docs, archive/media, archive/backup. Размер записи и компрессия задаются на каждом отдельно: 1M для медиа, 128 КБ по умолчанию, 16 КБ для мелких файлов и баз. Квота на датасет не даст одному отделу занять весь пул, а снапшоты снимаются на уровне датасета и не копируют неизменившиеся блоки.

Права настраивайте через POSIX-ACL или NFSv4 ACL в зависимости от того, кто ходит в архив, SMB или NFS. Для веб-доступа фронтенд монтирует датасет только на чтение: тогда скомпрометированный Nginx не сможет перезаписать архив. Для API-сценариев подойдёт MinIO: бакет на отдел, версионирование включено, lifecycle переводит старые объекты в холодный класс.

Сетевая сегментация и безопасность

• Разнесите фронтенд и хранилище по VLAN. Порты хранилища, включая NFS 2049, SMB 445 и S3 9000, доступны только с адресов фронтенда, остальное блокируется на межсетевом экране.
• TLS для внешних и внутренних соединений, для служебных связок mTLS. Сроки сертификатов проверяйте заранее, а не в день истечения.
• Аутентификация через LDAP или OAuth2, поверх неё RBAC: группы читателей, редакторов, администраторов. Права на запись выдавайте поимённо.
• Аудит: auditd на серверах, логи доступа S3, журналы Nginx. Храните их отдельно от архива, иначе при инциденте потеряете следы.
• Шифрование at rest: нативные датасеты ZFS с encryption или LUKS под ext4. Ключи держите вне того же сервера.
• fail2ban на SSH, SELinux или AppArmor в enforcing-режиме, вход только по ключам, root-логин выключен.

Масштабирование и резервное копирование на этапе проектирования

Расширение и бэкапы проектируются до первого файла, потому что и то и другое меняет схему хранения. Если заложить их позже, придётся переносить данные и останавливать сервис.

Горизонтальное и вертикальное масштабирование

Вертикальный путь: добавить диски в существующий сервер. В ZFS RAIDZ нельзя расширить vdev числом дисков, доступны замена дисков на более ёмкие (по одному, с ребилдом) или добавление нового vdev в пул. Второй вариант повышает суммарную пропускную способность, но чётность распределяется по vdev-ам: пул теряет данные при отказе любого vdev выше его уровня защиты, поэтому ширину vdev планируйте заранее. Для mdadm RAID расширение идёт через добавление диска и grow, для LVM через lvextend.

Горизонтальный путь: новые узлы. Распределённые файловые системы Ceph и GlusterFS складывают диски всех узлов в одно пространство имён, объектное хранилище масштабируется добавлением OSD. Шардирование по пространствам имён проще: отделы или проекты живут на своих серверах, фронтенд маршрутизирует запросы по имени бакета или каталога. Репликация между площадками закрывает требование offsite-копии и ускоряет чтение. Как переносить большие объёмы без потерь, разбираем в статье о хранении больших данных и миграции.

Стратегия резервного копирования 3-2-1

Принцип 3-2-1: три копии данных, на двух разных типах носителей, одна копия вне площадки. На ZFS основа - снапшоты и отправка инкрементов.

zfs snapshot archive/docs@daily-2026-09-23
zfs send -i archive/docs@daily-2026-09-22 archive/docs@daily-2026-09-23 | ssh backup-server zfs receive backup/docs

Для файлов без ZFS берите BorgBackup или Restic: дедупликация на стороне репозитория, шифрование и инкрементные архивы. rsync остаётся рабочим вариантом для больших неизменяемых наборов.

Копию вне площадки изолируйте: отдельные учётные данные, доступ только на запись, чтобы шифровальщик на основном сервере не мог затереть бэкапы. Правило неизменяемости (immutable-снапшоты или WORM-носитель) закрывает этот риск.

Тестирование восстановления

Непроверенный бэкап не считается бэкапом. Раз в месяц восстанавливайте случайную выборку файлов на тестовый стенд и сверяйте контрольные суммы, раз в квартал разворачивайте весь архив на запасном пуле и замеряйте фактическое время восстановления. Сравните его с целевым RTO: расхождение в два раза означает, что план не работает.

Целостность самого пула проверяет scrub. Для репозиториев Borg и Restic есть команды проверки: borg check и restic check с чтением части данных. Запускайте их по расписанию через cron или systemd timer и складывайте отчёт туда, где его увидят.

Чек-лист проверки конфигурации перед вводом в эксплуатацию

Проверка состояния дисков и пула

smartctl -a /dev/sda
zpool status -v
zpool scrub archive
zpool list -o name,size,alloc,free,cap,health
zfs list -o name,used,avail,refer,mountpoint

Смотрите на переназначенные сектора, pending и uncorrectable, температуру и износ SSD. В выводе zpool status -v не должно быть ошибок чтения и записи, состояние всех дисков ONLINE, счётчики в секции errors нулевые. Scrub для холодного архива достаточно запускать раз в месяц, для активно пишущего пула - раз в неделю. Отдельно проверьте, что в конфигурации нет диска, помеченного как spare без надобности, и что пул не собран на USB-переходниках.

Тесты производительности и нагрузки

fio --name=randread --ioengine=libaio --rw=randread --bs=4k --numjobs=4 --size=1G --runtime=60 --group_reporting
fio --name=seqwrite --ioengine=libaio --rw=write --bs=1M --numjobs=1 --size=10G --runtime=60 --group_reporting

Первый тест показывает IOPS на случайном чтении блоками 4 КБ, второй - пропускную способность последовательной записи. Сравнивайте результат с требованиями: каталог с миллионом мелких документов упирается в IOPS, медиатека - в мегабайты в секунду. Добавьте тест случайной записи и прогон с очередью (iodepth), чтобы увидеть поведение под параллельной нагрузкой, и обязательно посмотрите задержку 99-го перцентиля: среднее значение скрывает всплески.

Мониторинг и оповещения

Собирайте метрики через node_exporter и zfs_exporter в Prometheus, стройте графики в Grafana. Минимальный набор алертов:

• Заполнение пула выше 80% и прогноз заполнения меньше 30 дней.
• Ошибки чтения, записи и контрольных сумм в пуле, статус диска отличный от ONLINE.
• SMART-атрибуты: рост переназначенных секторов, температура выше порога, износ SSD выше 80%.
• Недоступность Nginx или S3-эндпоинта дольше двух минут.
• Не выполнился последний бэкап или scrub, возраст самого свежего снапшота превышает регламент.
• Срок действия TLS-сертификата меньше 21 дня.

Перед открытием доступа пользователям пройдитесь и по этим пунктам:

• Проверьте открытые порты снаружи (ss -tulpn на хосте и сканирование с внешнего адреса), лишние закройте.
• Убедитесь, что autoindex выключен, а листинги каталогов недоступны.
• Проверьте права на каталоги: ни один рабочий файл не должен лежать с режимом 777.
• Выполните тестовое восстановление одного файла из последней копии и зафиксируйте время.
• Задокументируйте конфигурацию: схема пула и RAID, точки монтирования, расписание бэкапов, состав VLAN. Храните документ в системе контроля версий или в вики.

Заключение: ключевые выводы и рекомендации

Порядок действий такой: сформулируйте требования по RPO, RTO и объёму, посчитайте TCO на три года и сравните с облаком, выберите файловую систему, рассчитайте полезную ёмкость и уровень RAID с запасом 20%, спроектируйте разделение фронтенда и бэкенда, заложите масштабирование и схему 3-2-1, прогоните чек-лист и только после этого открывайте доступ пользователям.

ZFS выигрывает там, где важна целостность данных и есть запас RAM. ext4 на LVM закрывает простые файловые серверы с минимальными требованиями к администрированию. Объектное хранилище выбирайте под API-доступ и рост за десятки и сотни терабайт. Для архивов на дисках от 2 ТБ ставьте RAIDZ2 или RAID 6, для дисков от 8 ТБ - RAIDZ3 или зеркала.

Схема из статьи - каркас, а не догма. Адаптируйте её под своё железо, число площадок и требования регуляторов, а все расхождения фиксируйте в документации: через год именно она сэкономит часы при разборе инцидента.