mergerfs и SnapRAID: домашнее хранилище без RAID

MAATRIX

У вас в столе три старых диска на 2, 4 и 6 терабайт — разных производителей, разного возраста, купленные в разное время. Классический RAID их не примет: нужны диски одинакового объёма, иначе массив соберётся по размеру самого маленького, а остальное место пропадёт. mergerfs вместе со SnapRAID решают именно эту задачу — объединяют разнородные диски в единое пространство и защищают их от отказа без требований RAID к однородности массива.

Почему классический RAID здесь не подходит

RAID проектировался для другой задачи — для серверов с одинаковыми дисками, где нужна постоянная, непрерывная защита данных в реальном времени. Массив пишет данные сразу с учётом избыточности: в RAID 1 — дублирует на второй диск, в RAID 5/6 — распределяет блоки и чётность по всем дискам массива (страйпинг). Это даёт защиту без задержки: диск отвалился — массив продолжает работать в деградированном режиме, ничего не потеряно на момент отказа.

Но у этого подхода есть цена, которая для домашнего архива часто избыточна:

• Диски должны быть одного объёма (или массив урежет всех до размера меньшего диска) — доукомплектовать массив старым диском другой ёмкости нельзя.
• Ребилд после замены диска нагружает весь массив и на большом объёме занимает много часов, в течение которых массив уязвим к второму отказу — эта проблема разобрана в статье как работает RAID при отказе диска.
• RAID не защищает от ошибок пользователя — удалили файл, затёрли не тот том — реплицируется мгновенно на все диски массива; подробно про это заблуждение — в статье RAID — это не резервная копия.
• Для небольшого домашнего NAS с разнородным набором дисков — RAID зачастую избыточен по сложности и негибок по составу дисков.

Если у вас однородный набор новых дисков и требования к постоянной защите (базы данных, виртуалки, активная рабочая нагрузка) — RAID или ZFS всё ещё лучший выбор, о чём мы честно скажем в конце статьи. Но для домашнего архива с преимущественно статичными данными есть более гибкая альтернатива.

Как устроен mergerfs: объединение без страйпинга

mergerfs — это FUSE-файловая система, которая объединяет несколько независимо смонтированных дисков (каждый со своей файловой системой — ext4, xfs, btrfs, неважно) в единую точку монтирования. Принципиальное отличие от RAID: mergerfs не распределяет содержимое файла по дискам. Каждый файл целиком физически лежит на одном конкретном диске из объединённых — так же, как если бы вы вручную раскладывали файлы по разным папкам на разных дисках, но с единым логическим деревом каталогов сверху.

Это значит:

• Диски могут быть любого объёма и любой файловой системы — mergerfs не заботится о равенстве размеров.
• Отказ одного диска убивает только файлы на этом диске, а не весь объединённый пул — данные на остальных дисках остаются доступны и читаемы напрямую, даже без mergerfs.
• Скорость чтения/записи одного файла ограничена скоростью одного физического диска — параллелизма RAID-страйпинга здесь нет и не будет.

Установка на Debian/Ubuntu:

curl -fsSL https://github.com/trapexit/mergerfs/releases/latest/download/mergerfs_amd64.deb -o mergerfs.deb
sudo apt install ./mergerfs.deb

Смонтируйте физические диски в отдельные точки (например, /mnt/disk1, /mnt/disk2, /mnt/disk3), затем добавьте в /etc/fstab строку объединения:

/mnt/disk1:/mnt/disk2:/mnt/disk3 /mnt/storage fuse.mergerfs defaults,nonempty,allow_other,use_ino,cache.files=partial,dropcacheonclose=true,category.create=mfs,moveonenospc=true,minfreespace=250G 0 0

Ключевой параметр — category.create, политика выбора диска для НОВОГО файла:

moveonenospc=true заставляет mergerfs перенести файл на другой диск с местом, если текущий диск переполнился прямо во время записи — полезная страховка от ENOSPC посреди копирования большого файла.

Смонтируйте и проверьте:

sudo mount -a
df -h /mnt/storage
mergerfs-tests  # опционально: если ставили tools, проверяет корректность конфигурации

Диски можно добавлять и убирать из пула в любой момент простым изменением списка в fstab и перемонтированием — никакого ребилда массива, потому что массива в RAID-смысле не существует.

Как устроена защита SnapRAID: чётность по расписанию

mergerfs сам по себе не даёт никакой защиты от отказа диска — он просто объединяет пространство. Защиту добавляет SnapRAID: он считает информацию чётности по данным на дисках и хранит её на отдельном диске (или нескольких, если нужна защита от двух одновременных отказов).

Ключевое отличие от RAID: SnapRAID защищает данные ПЕРИОДИЧЕСКИ, а не непрерывно. Он не сидит в фоне и не пишет чётность синхронно с каждой операцией записи файла — вместо этого вы запускаете команду snapraid sync по расписанию (например, раз в сутки или после крупного добавления файлов), и только в этот момент SnapRAID пересчитывает и сохраняет чётность для всех изменений, накопившихся с прошлого запуска.

Установка:

sudo apt install snapraid

Конфиг /etc/snapraid.conf:

# Файл(ы) чётности — отдельный физический диск, объёмом НЕ МЕНЬШЕ самого большого диска с данными
parity /mnt/parity/snapraid.parity

# Файл содержимого — храните несколько копий на разных дисках на случай отказа
content /var/snapraid.content
content /mnt/disk1/.snapraid.content
content /mnt/disk2/.snapraid.content

# Диски с данными — те же, что объединены через mergerfs
data d1 /mnt/disk1/
data d2 /mnt/disk2/
data d3 /mnt/disk3/

# Исключения — временные файлы, кэши, не нуждающиеся в защите
exclude *.tmp
exclude /lost+found/
exclude *.bak

Диск чётности физически отдельный от дисков с данными и не участвует в пуле mergerfs — на него ничего не пишут пользовательские файлы, только SnapRAID. Его объём должен быть не меньше самого большого диска данных в наборе, иначе чётность для него не влезет.

Ежедневный запуск через cron:

sudo crontab -e

0 3 * * * /usr/bin/snapraid sync >> /var/log/snapraid-sync.log 2>&1
0 4 * * 0 /usr/bin/snapraid scrub -p 10 >> /var/log/snapraid-scrub.log 2>&1

sync пересчитывает чётность по изменениям. scrub — отдельная команда, которая проверяет целостность уже сохранённых данных и чётности, вычитывая процент блоков (здесь -p 10 — 10% массива за проход) и находя тихое повреждение данных (bit rot) раньше, чем оно станет проблемой при восстановлении.

Перед синхронизацией полезно посмотреть, что изменилось:

snapraid status
snapraid diff

diff покажет список добавленных, изменённых и удалённых файлов с прошлого sync — это ваш шанс заметить аномалию (например, массовое удаление файлов вирусом-шифровальщиком) ДО того, как чётность зафиксирует эти изменения как «нормальные».

Что происходит при отказе диска на практике

Диск в пуле выходит из строя — SMART начинает сыпать предупреждениями (подробнее о том, какие показатели SMART реально предсказывают смерть диска — в отдельной статье SMART: какие показатели предсказывают смерть диска) или диск просто перестаёт монтироваться. Порядок действий:

1. Файлы на остальных дисках пула не пострадали и доступны сразу — это не RAID 0, где потеря одного диска убивает весь массив; здесь mergerfs просто перестанет видеть один branch, остальные продолжат отдавать свои файлы.
2. Физически замените неисправный диск, создайте на новом ту же файловую систему, смонтируйте в ту же точку (/mnt/disk2).
3. Восстановите содержимое из чётности:

snapraid fix -d d2 -l /var/log/snapraid-fix.log

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

snapraid check -d d2

Критический нюанс, который нужно понимать заранее: SnapRAID восстановит диск ровно в то состояние, в котором он был на момент ПОСЛЕДНЕГО успешного sync. Если файл был добавлен, изменён или удалён ПОСЛЕ последней синхронизации, а диск отказал ДО следующей — эти изменения не защищены чётностью и будут потеряны безвозвратно. Чем реже вы синхронизируете, тем шире окно потенциальной потери. Это прямая противоположность RAID, где чётность (или зеркало) обновляется синхронно с каждой записью и окна незащищённости в принципе не существует.

Практический вывод отсюда: частота snapraid sync — это ваш SLA по объёму допустимых потерь. Ежедневная синхронизация ночью означает, что в худшем случае вы теряете файлы, добавленные за последние сутки. Для медиатеки, куда вы закидываете файлы раз в неделю, можно синхронизировать раз в неделю. Для активно пополняемого архива — имеет смысл синхронизировать чаще или сразу после крупных загрузок вручную.

Практическая связка: конфигурация целиком

Типичная домашняя настройка на сервере с 4 дисками разного объёма (2 ТБ + 4 ТБ + 6 ТБ данных, 6 ТБ под чётность) собирается из уже описанных выше блоков: физические диски монтируются в /mnt/disk1, /mnt/disk2, /mnt/disk3 и /mnt/parity через /etc/fstab, поверх дисков с данными поднимается mergerfs-пул, а SnapRAID настраивается отдельным конфигом:

# /etc/snapraid.conf
parity /mnt/parity/snapraid.parity
content /var/snapraid.content
content /mnt/disk1/.snapraid.content
data d1 /mnt/disk1/
data d2 /mnt/disk2/
data d3 /mnt/disk3/
exclude *.tmp
exclude /lost+found/

Обратите внимание: пользователи и приложения (Samba, Jellyfin, торрент-клиент) работают только с /mnt/storage — единой точкой mergerfs, не подозревая, на каком физическом диске лежит конкретный файл. SnapRAID работает напрямую с /mnt/disk1, /mnt/disk2, /mnt/disk3 — то есть SnapRAID и mergerfs — два независимых инструмента, работающих над одним и тем же набором дисков, но не знающих друг о друге напрямую.

Хотите защиту от двух одновременных отказов дисков — SnapRAID поддерживает до 6 дисков чётности (в конфиге добавляются строки 2-parity, 3-parity и так далее), но за каждый дополнительный уровень чётности платите ещё одним физическим диском, который не несёт полезных данных, только избыточность.

Честно о компромиссах против классического RAID

Разберём ограничения без прикрас, потому что решение не универсальное.

Производительность. Чтение и запись одного файла ограничены скоростью ОДНОГО физического диска, на котором он лежит — никакого прироста от параллельного чтения с нескольких дисков, как в RAID 0/5/6/10. Если вам нужна высокая последовательная скорость для одного большого файла или много одновременных случайных операций (базы данных, виртуальные машины) — mergerfs+SnapRAID проигрывает массиву со страйпингом или ZFS-пулу.

Задержка защиты. Уже разобрано выше — это, пожалуй, главное отличие. RAID и ZFS защищают данные непрерывно, SnapRAID — периодически, по расписанию. Для файлов, изменённых между запусками sync, защиты попросту нет.

Нет автоматического обнаружения и исправления повреждений на лету. ZFS и Btrfs с их контрольными суммами на уровне блоков ловят битовую деградацию сразу при чтении. SnapRAID находит такие проблемы только при явном запуске scrub, и то — по выборке процента блоков, а не при каждом обращении к файлу.

FUSE — дополнительный уровень абстракции. mergerfs работает в пространстве пользователя (FUSE), а не в ядре, что добавляет небольшой оверхед на каждую операцию с файлами по сравнению с нативной файловой системой или ZFS. Для последовательного чтения/записи медиафайлов это некритично, для интенсивной работы с мелкими файлами может быть заметно.

Не для активно изменяемых рабочих данных. База данных, репозиторий с частыми коммитами, каталог с документами, редактируемыми ежечасно — плохие кандидаты. Здесь нужна непрерывная защита: классический RAID (обзор уровней и выбора — в статье RAID на сервере: уровни и как выбрать) либо ZFS с его снапшотами и контрольными суммами (см. ext4, xfs, zfs, btrfs: как выбрать).

Таблица для быстрого сравнения:

Частые вопросы