Btrfs: подтома, снимки и ограничения¶
Btrfs поддерживает контрольные суммы, подтома (subvolume), снимки и ряд встроенных механизмов управления данными. В архиве SPEC имеется btrfs-progs, однако это не подтверждает, что каждая установленная НАЙС.ОС CLOUD использует Btrfs для корневой ФС или поддерживает конкретную схему атомарного отката. Сначала исследуйте реальный профиль разделов и загрузки.
1. Определите, где применяется Btrfs¶
Если файловая система ext4 или XFS, команды управления подтомами к ней неприменимы.
2. Подтома — это не обычные каталоги¶
Subvolume похож на каталог при обычном просмотре, но имеет собственный идентификатор Btrfs. Снимок (snapshot) создаёт новое поддерево, начально разделяющее экстенты с исходным за счёт COW. Это быстрый локальный механизм, но не страховка от выхода диска из строя.
# Только если точка монтирования действительно Btrfs
btrfs subvolume list /
btrfs filesystem show
btrfs filesystem df /
Не путайте btrfs filesystem df с обычным df -hT: физическое распределение Btrfs сложнее, чем свободные байты файла.
3. Создание снимка пользовательского тома¶
Допустим, отдельная тестовая Btrfs ФС смонтирована в /srv/btrfs-test, внутри есть подтом data. Включите в план проверку назначения:
После подтверждения на тестовом томе снимок можно создать так:
# Создание read-only снимка, если источник — подтом
btrfs subvolume snapshot -r \
/srv/btrfs-test/data \
/srv/btrfs-test/data-snapshot-20261022
-r делает snapshot доступным только для чтения. Дата в имени иллюстративная — подставляйте дату операции. Перед выполнением проверьте, что исходный путь — подтом, а цель ещё не существует. Snapshot консистентен на уровне ФС, но не обязательно транзакционно консистентен для работающей базы данных.
4. Снимок ≠ бэкап¶
Если диск недоступен физически, локальные snapshots недоступны тоже. Для восстановления после потери носителя резервная копия должна быть на отдельном хранилище. При критичных приложениях сначала обеспечьте согласованность данных (остановка записи, snapshot API приложения, логическая выгрузка и т.п.).
5. Обслуживание¶
btrfs scrub, balance, device add/remove и операции удаления снимков могут создавать значительную I/O-нагрузку или требовать специального резерва свободного пространства. На боевом сервере сначала определите тип устройства, профиль данных/метаданных и время обслуживания. Не используйте btrfs check --repair как стандартное средство диагностики: это потенциально разрушительная операция.
6. Что с откатом НАЙС.ОС¶
Наличие Btrfs и пакета ostree не доказывает наличие rpm-ostree или совместимой схемы bootloader rollback. Перед публикацией пошагового «отката системы» необходимы точный manifest установленного образа, subvolume layout, конфигурация GRUB и проверенный сценарий восстановления. См. обновления и откат.
Источники: Core/btrfs-progs/SPECS/btrfs-progs.spec; официальная документация Btrfs.