
Привет, Хабр!
Не все инсталляторы linux могут установить систему на btrfs subvolume. Ни один инсталлятор не может установить систему с применением nocow и compress только для определенных subvolume.
На примере Astra linux 1.8.4 с максимальным уровнем защищенности (включен МКЦ и МРД) и написанных мною скриптов для автоматизации я покажу, как перенести установленную систему на btrfs subvolume, а также установить nocow только у необходимых subvolume. Дополнительно будет описан второй скрипт для создания и восстановления снимков.
В скриптах есть полное описание кода, если кто захочет разобраться, как они работают или модифицировать их.
Часть 1. Перенос системы на btrfs subvolume через скрипт btrfs-autocreate-subvol
Скрипт может не удовлетворять всем вашим потребностям. Например, не поддерживается работа с шифрованными разделами (LUKS) и системой установленной в MBR режиме.
Работа скрипта проверена на live инсталляторе Astra linux 1.8.4.48.
Мною проверен перенос следующих систем: Astra linux 1.8.4.48 и Debian 13. Рекомендуется переносить систему сразу после установки, т.е. до первого запуска ОС. Например, ОС Astra linux с включенным МКЦ после первого запуска не получится перенести на subvolume.
Изображение (пример разметки)

Рекомендуется использовать последнее доступное ядро, т.к. в новых версиях обычно есть различные улучшения для btrfs. Пакет btrfs-progs в репозитории обычно соответствует последней доступной версии ядра.
После установки системы, если используется live инсталлятор, не перезагружайте ПК.
ОС, установка которых выполняется не из live инсталлятора (например, установщик Debian installer), необходимо установить в��полнив разбивку по аналогии с изображением выше, создав как минимум ESP раздел с точкой монтирования «/boot/efi» и btrfs раздел c точкой монтирования корня «/». После установки перезагрузитесь в live систему и выполните скрипт.
Описание основных параметров скрипта
-nsa) (no security attribute) Не выставлять атрибут безопасности security.PDPL на корень btrfs раздела для Astra linux. Укажите этот параметр, только если не будете использовать МКЦ/МРД. Timeshift на Astra linux корректно создает, но не восстанавливает снимки, если на корень раздела при переносе будет выставлен security.PDPL. Для работы со снимками, с учетом МКЦ/МРД, используйте родные команды btrfs или написанный мной скрипт btrfs-snapshot.
-f) (first) Автоматический выбор первого доступного btrfs раздела. Если этот параметр не указан, то должен быть указан -sbp.
-ceb) (copy efi boot) Заменить файл /EFI/boot/bootx64.efi в ESP разделе файлом grubx64.efi созданным при установке grub.
-neb "Значение") (name efi boot) Имя efi загрузчика для установки grub. Обязательный параметр. Имена текущих загрузочных записей вы можете посмотреть через команду efibootmgr. Начиная с astralinux 1.8.3 в системе используется наименование загрузочной записи «astra».
-rg "Значение"). (reinstall grub) Параметр для переустановки grub (Перенос системы на subvolume будет пропущен). В значении необходимо указать имя subvolume в котором находится система. Пример команды:
./btrfs-autocreate-subvol.sh -f -neb "astra" -ceb -rg "@"
-sbp "Значение") (select btrfs part) Имя btrfs раздела с системой (например, nvme0n1p4). Если параметр не указан, то должен быть указан параметр -f.
-sp "Значение") (subvolume param) Значение в специальном формате для добавления строки монтирования в fstab и создания указанных subvolume (точка монтирования;имя subvolume;параметры монтирования;признак использования nocow;тип сжатия). Параметр может быть указан более 1 раза.
Пояснения к параметру '-sp'
Точка монтирования — Обязательное поле.
Имя subvolume — Обязательное поле.
-
Параметры монтирования — если не указать, то будет использоваться defaults. Многие параметры монтирования, например, nodatacow, nodatasum, compress не могут быть выставлены для отдельных subvolume, а применяются ко всей файловой системе.
Ссылка: Параметры монтирования btrfs
-
Признак использования nocow — Обязательное поле (0/1):
0 - Не выполнять изменения;
1 - Выставить атрибут nocow для subvolume. Атрибут добавляется командой chattr +C. nocow отключает копирование при записи и сжатие.
Тип сжатия — Необязательное поле. Может принимать следующие значения:
lzo
zlib
zstd
no - отключить сжатие (эквивалент chattr +m)
пустое значение - ничего не делать
Если значение сжати�� указано, то будет добавлен атрибут файловой системы командой: btrfs property set <PATH> compression <VALUE>. Атрибут установленный через btrfs property имеет приоритет над глобальными настройками монтирования, т.е., при установлении атрибута, параметр сжатия в fstab для этого subvolume учитываться не будет.
Если не будет указан параметр «-sp» с точкой монтирования корня '/', то будет использоваться значение по умолчанию: '/;@;defaults;0;'.
Рекомендуется:
вынести /home, /tmp, /var/cache, /var/log, /var/tmp в отдельные subvolume;
к /tmp, /var/cache, /var/log, /var/tmp указать признак использования nocow со значением 1;
Если используется swap файл, создать его на отдельном subvolume с применением nocow.
Примеры полной команды:
./btrfs-autocreate-subvol.sh -f -ceb -neb "astra" -sp "/;@;space_cache=v2,nodiscard,relatime,compress=zstd;0;" -sp "/home;@home;nodiscard,relatime;0;" -sp "/tmp;@tmp;nodiscard,relatime;1;" -sp "/var/cache;@varcache;nodiscard,noatime;1;" -sp "/var/log;@varlog;nodiscard,noatime;1;" -sp "/var/tmp;@vartmp;nodiscard,relatime;1;" -sp "/swap;@swap;nodiscard,noatime;1;"
Изображения (выполнение скрипта и итог)











Часть 2. Создание и восстановление снимков через скрипт btrfs-snapshot
Написанный мною скрипт для управления снимками btrfs. Работает на Astra linux с включенным МКЦ/МРД (не нужно отключать security.PDPL на корне раздела).
Если корень btrfs раздела будет смонтирован, то скрипт найдет этот путь и будет использовать его для работы с разделом. Если не смонтирован, то скрипт смонтирует раздел, а после выполнения отмонтирует его.
По умолчанию для неинтерактивного режима используется файл /etc/fstab в качестве источника subvolume и UUID разделов на которых они расположены.
Вы можете использовать свой файл добавив путь к нему в переменную окружения file_btrfs_part_list.
export file_btrfs_part_list="путь-к-файлу"
В файле должна быть таже структура, что и в fstab, например:
UUID=98fb74e2-513c-4492-9df5-50c49e3a1539 / btrfs subvol=@
Изображение (пример запуска с указанием файла)

Параметры запуска
Создание снимка (-crw и -cro):
./btrfs-snapshot.sh -crw "Имя-subvolume"- Будет создан снимок (чтение/запись) с именем "@snapshot_дата-время_имя-subvolume"../btrfs-snapshot.sh -cro "Имя-subvolume"- Будет создан снимок (только чтение) с именем "@snapshot_дата-время_имя-subvolume".
Восстановление снимка (--restore и --restore-last):
./btrfs-snapshot.sh --restore "Имя-снимка"- Будет восстановлен снимок с указанным именем вместо subvolume указанного в конце имени снимка../btrfs-snapshot.sh --restore-last "Имя-subvolume"- Будет восстановлен последний по дате снимок к указанному subvolume.
Список снимков (--list-snapshots):
./btrfs-snapshot.sh --list-snapshots "Имя-subvolume"- Будет показан список снимков для указанного вами subvolume.
Перезагрузка после восстановления (--reboot должен быть указан до параметра --restore или --restore-last):
./btrfs-snapshot.sh --reboot --restore "Имя-снимка"- Будет восстановлен снимок с указанным именем вместо subvolume указанного в конце имени снимка и выполнена перезагрузка../btrfs-snapshot.sh --reboot --restore-last "Имя-subvolume"- Будет восстановлен последний по дате снимок к указанному subvolume и выполнена перезагрузка.
Список параметров запуска (-h или --help):
./btrfs-snapshot.sh --help- Будет показан список параметров запуска.
Интерактивный режим (-i):
./btrfs-snapshot.sh -i- Запуск скрипта в интерактивном режиме. При запуске в live системе доступен только интерактивный режим и он запускается по умолчанию.
Изображения (пример выполнения)







Ссылка на репозиторий: Gitflic
Комментарии (13)

temnikov_vasiliy
11.02.2026 11:25как раз сегодня астру1.8.4 установленную на ext4 перенес на btrfs с сжатием zstd:15 так:
создал в виртуалке новый диск, на него установил астру по минимуму на btrfs (эти дурни в инсталляторе не могут добавить строку customs для монтирования, чтобы опции сжатия для btrfs добавить)
запустился с livecd, примонтировал корень старой системы в /mnt/ext4/, и новую в /mnt/btrfs/ с опцией -o compress-force=zstd:15
через mc удалил из /mnt/btrfs/ всё кроме /boot/ и /etc/fstab
и просто скопировал всё кроме /boot/ и /etc/fstab из /mnt/ext4/ в /mnt/btrfs/
копировалось сразу со сжатием
добавил в /mnt/btrfs/etc/fstab опцию для сжатия
в итоге: 40Гб с ext4 сжались в 15Гб на btrfs
виртуальный диск скопировал на физический.
всё загрузилось и не пришлось даже обновлять grub и initramfs (т.к. ядро одинаковое)
кстати, где для астры новое ядро взять ? сейчас 6.12, хотелось бы 6.17
medved0001 Автор
11.02.2026 11:25Астра компилит только lts ядра. Остается надеяться, что скомпилят 6.18 для astra 1.8.

13werwolf13
11.02.2026 11:25можно было чуть проще, ext4 вполне себе конвертируется в btrfs прямо наживую, потом поправить uid раздела в fstab и cmdline, обновить конфиг граба, ребут. после ребута можно удалить созданный блочный сабвол нужный для отката назад и всё.
делал так несколько раз, всё работает отлично

firegurafiku
11.02.2026 11:25Я ведь правильно понимаю, что проблема, которую вы решаете, в том, что инсталлятор системы поддерживает Btrfs в принципе, но не даёт возможности указать, что на какой сабвольюм ставить и с какими параметрами эти сабвольюмы нужно создать?
Если так, то эту можно поступить немного проще: у тома Btrfs есть параметр "сабвольюм по умолчанию". Он отвечает за поведение при монтировании без явной опции
-o subvol=— а инсталляторы, по всей видимости, монтируют файловые системы именно так. И идея состоит в том, чтобы самостоятельно создать нужную иерархию сабвольюмов, выбрать дефолтный, а потом сказать инсталлятору, чтобы он использовал файловую систему как есть, не форматируя.Я в прошлом году проверял эту идею, когда устанавливал серверную Ubuntu. Выглядело это так. Когда загрузился инсталлятор, я переключился в консоль и вручную разметил диск, создал файловую систему и сабвольюм с нужным именем:
# cfdisk /dev/sda # mkfs.btrfs --label ubuntu --data single --metadata single /dev/sdaX # mount /dev/sdaX /mnt # btrfs subvolume create /mnt/@ # btrfs subvolume set-default /mnt/@ # umount /mntПосле этого вернулся в инсталлятор, выбрал там "Leave formatted as btrfs, mountpoint: /" и установил систему. А уже после перезагрузки в установленную систему перенёс /home на отдельный сабвольюм и поправил fstab (хотя это можно было сделать и сразу, до перезагрузки).
Я сам не проверял (потому что мне не нужно было так сложно), но кажется, что идея останется рабочей, даже если добавить создание дополнительных сабвольюмов
@/home,@/var/tmp,@/var/tmpи т.д. с индивидуальной настройкой их параметров.
13werwolf13
11.02.2026 11:25на убунте и дебиане можно впринципе выкинуть инсталер на мороз и ставить систему при помощи debootstrap получив гораздо больше гибкости чем даёт инсталлер.
впрочем и на других дистрибутивах можно подобное, только в случае с rpm based дистрибутивами вам не нужен отдельный инструмент, пакетные менеджеры dnf и zypper сами могут поставить систему в отдельный корень родив тем самым новую систему.

medved0001 Автор
11.02.2026 11:25Я ведь правильно понимаю, что проблема, которую вы решаете, в том, что инсталлятор системы поддерживает Btrfs в принципе, но не даёт возможности указать, что на какой сабвольюм ставить и с какими параметрами эти сабвольюмы нужно создать?
Да
Если так, то эту можно поступить немного проще:...
С астрой так не получится, т.к. при установке напрямую в subvolume, на корне раздела не будет атрибута security.PDPL, без которого МКЦ/МРД на сабволумах использовать не получится. Т.е. должна быть соблюдена иерархия меток (корень-раздела-->subvolume). Именно поэтому я в скрипте сначала из chroot ставлю метку на корень раздела, а потом разношу всё по сабволумам. В данном случае корректную установку прямо на сабволумы, а не перенос, может сделать только разработчик астры.
А уже после перезагрузки в установленную систему перенёс /home на отдельный сабвольюм и поправил fstab
И опять же нужно будет выполнять перенос в другие сабволумы после установки и править fstab. Просто я это как раз автоматизировал.

firegurafiku
11.02.2026 11:25при установке напрямую в subvolume, на корне раздела не будет атрибута security.PDPL
Возможно, это не будет проблемой — корневой сабвольюм Btrfs-раздела ведь даже никуда не примонтирован, по идее, модуль ядра, отвечающий за контроль этих меток, его даже не видит, и с его точки зрения файловая иерархия начинается с того сабвольюма, куда установлена система.
корректную установку прямо на сабволумы, а не перенос, может сделать только разработчик астры
И я ведь правильно понимаю, что этот
security.PDPL— просто расширенный атрибут файла/каталога, такой же какsecurity.selinux? Его можно перенести с каталога на каталог при помощиsetfattrили каких-то специфичных инструментов Астры?
vadimr
Вроде ж МРД не сертифицировано для BTRFS?
medved0001 Автор
Официально да, Astra не поддерживает Btrfs. В чате астры в телеграме проскакивали сообщения о рассмотрении официальной поддержки.
Сам я использую только МКЦ, но у меня ранее спрашивали работает ли МРД. Чисто технически все работает, т.к. МКЦ/МРД это всего лишь расширенный атрибут на файле/каталоге, т.е. сделать официальную поддержку ничего не мешает.
Но данный скрипт в принципе переносит не только астру.
vadimr
Вопрос в том, что в btrfs могут быть способы получить доступ к информации в обход мандатных меток. Например, через процедуру удалённой репликации и т.д.
medved0001 Автор
Никто не заставляет держать всю систему на одном btrfs разделе. При необходимости можно отделить home с МРД на отдельный раздел или диск с ext4.
linux это своего рода конструктор, который можно настроить под разные задачи. Он не упирается в одну конкретную конфигурацию системы.
vadimr
Линукс-то конструктор, но разграничение доступа не может применяться частично, иначе теряет всякий смысл.