Archlinux BTRFS, снапшоты в GRUB

Начнём!
Поводом для написании темы послужила очередная установка Убунты (здесь я рассматриваю дистрибутив, только как готовое решение, попробовать и сделать выводы), на посмотреть, куда движется Линукс для массового десктопа.
Кроме браузера в снап-пакете и кислотных обоев, установщик также предлагает установить систему на ZFS, что я и сделал. Во время выпиливания snap пакетов, заметил, что при удалении и установке запускается какой-то скрипт и создаются снапшоты. Почитал обзоры и особо не придал внимания, однако в очередной раз, удаляя снап-ядро, забыл какую-то команду - то ли, нужно было демонтировать loop0..loop7, толи удалить папки - система была повреждена и переустановка снап-пакета ничего не дала, стало только хуже. Тут я и вспомнил про механизм отката, который предоставляет набор скриптов + снапшоты на ZFS. Загрузившись, через выбор в груб, на нужном срезе системы, понял насколько удобное техническое решение получилось. Погрузившись в тему, также понял, что удобства предоставлялись самой файловой системой ZFS + обвязка скриптов.
Конечно, же захотел это повторить на другом своём неттопе с Арчлинукс, что очень кстати, т.к. использую связку старых драйверов nvidia+ядро и при его обновлении - всегда лотерея - загрузится ли графическая оболочка?.. Маскирование обновлений пакета, downgrade из aur - всё это пройденный этап, периодически пользуюсь или просто жду, когда придут обновления. Признаться, я прочно застрял в теме разметок файловой системы и копий образов систем на уровне разбивки / и /home на ext4 и rsync архивов, которые можно было копировать на какие-то внешние носители. В общих чертах я понимал как и что, но городить и делать из этого системное решение смысла было мало. Здесь же никаких дополнительных движений не требуется, + всё замкнуто в одном диске, просто и удобно, этим и привлекло.

Итак, финальный результат определён, осталось дело за малым!

За пару вечеров провёл основательный ликбез в теме современной организации файловых систем Линукс дистрибутивов, выводы сделал такие:
1. LVM - мощная вещь, но немного не про то - как мне кажется.. Это скорее про организацию отказоустойчивых систем (серверов), подключения/удаления жестких дисков и опять же, для того, чтобы пользоваться во всю мощь - нужны несколько жестких дисков, что для домашнего использования является избыточным.
2. ZFS для линукса - продвигает для повседневного использования в основном компания Каноникал и в других популярных массовых дистрибутивах (например, Fedora) не представлена. Среди обзорщиков дистрибутивов считается пока что технологией, которая "залочена" за одной компанией (как и технология snap пакетов) и решения малопереносимы. Плюс есть нарекания по расходу оперативной памяти.
3. BTRFS - ровно то, что советуют именно для линукс дистрибутивов, не хуже по показателям и сочетает преимущества первых двух пунктов. Единственный минус - находится в активной разработке, поэтому необходимо отслеживать изменения и обновлять методики её использования.
Стало быть, нужно сделать решение на основе BTRFS с учётом стремительности её разработки. Погрузился в чтение объёмных wiki, инструкций, также обратил внимание, что да, инструкции могут сильно отличаться друга от друга, в зависимости от того, когда они написаны, одна история со swap чего стоит - я думал, выделение раздела под свап давно в прошлом, однако почти все, делают это поголовно, причём кто выделяет 1гб, кто 2, почему и зачем такие размеры - особо не рассказывают. Поэтому я стал пристально обращать внимание на дату обзоров и инструкции. Поискал также видеоинструкции на ютубе. На русском языке есть несколько монотонных обзоров установки в лучшем случае статье с сайта или по устаревшему вики. Другое дело англоязычные видеообзорщики! Нашёл несколько крупных каналов, авторы которых практикуют ежемесячные установки Арча, для обзора новых программ. Сравнив нескольких, нашёл одного, который делает это регулярно, устанавливает новинки и прочее, но и самое главное: объясняет каждый свой шаг, при этом придерживается основного вики Арча.

И наконец, предлагаю вашему вниманию два command-list, один на основе snapper (более универсальный), второй - на основе timeshift (больше зависит от Gnome).

Оба скрипт-листа покомандно прогнал несколько раз на виртуальных машинах, вроде работают как ожидаются. Длинное предисловие написал, для того, чтобы объяснить логику разбития файловой системы и применяемых технологий. Старался делать каждую команду максимально необходимой, атомарной, минимально зависимой от других компонентов и моих пристрастий в софте. Хоть они выглядят как bash скрипты, не рекомендую их делать исполняемыми и запускать, без внимательной вычитки. Лучше покомандно воспроизводить на интересуемой машине, и лучше через SSH, для удобства копирования и переноса команд. Как это сделать через SSH - оставил комментарии.

Максимально приближенным к результату получается вариант с timeshift, для варианта со snapper - нужно будет предварительно сделать желаемый снапшот доступным для записи. Команды приведены в комментарии. Из пункта меню GRUB система грузится в режиме только для чтения, поэтому нужно будет проводить дополнительные манипуляции.

Пока всё. Призываю всех, кто уже работает с BTRFS, поделитесь опытом, как можно улучшить результат, как, например, сразу сделать снапшоты доступными для записи, или какими инструментами пользуетесь для похожего результата или какие опции монтирования нужно использовать и прочее.
Nebulosa
например, сразу сделать снапшоты доступными для записи,
Как обычно, командой btrfs subvolume snapshot.
Лично я, snapper и timeshift не использую, так как глюки мне не нужны, поэтому предпочитаю, своим скриптом.
Никогда не понимал, зачем для снапшотов делать отдельный subvolume, как и @var.
Но как говорится, кому как удобно, так и лепит.

Nebulosa
одна история со swap чего стоит - я думал, выделение раздела под свап давно в прошлом, однако почти все, делают это поголовно,
Со свопом тоже всё просто, раздел или отдельный subvolume для своп.
С разделом проще настраивать гибернацию и полное шифрование диска.
Использую в гноме timeshift-autosnap. Никаких глюков, во время любого обновления через хук пакмана делается снимок и в грабе создаётся соответсвующий пункт для загрузки. Количество снимков по умолчанию 3, но можно настроить сколько нужно. Единственное неудобство - timeshift требует меток @ для корня и @home для хомяка (необязательно) - пришлось поменять.
RusWolf
ZFS для линукса - продвигает для повседневного использования в основном компания Каноникал и в других популярных массовых дистрибутивах (например, Fedora) не представлена. Среди обзорщиков дистрибутивов считается пока что технологией, которая "залочена" за одной компанией (как и технология snap пакетов) и решения малопереносимы. Плюс есть нарекания по расходу оперативной памяти.
Сидел какое-то время на ZFS. Возможности у неё интересные, например, можно RAID'ы собирать... даже блог по установке здесь написал, но... Через несколько месяцев начались жуткие тормоза файловой подсистемы. Не стал дальше разбираться, ушёл на btrfs.
RusWolf
Лично я, snapper и timeshift не использую, так как глюки мне не нужны, поэтому предпочитаю, своим скриптом.
Никогда не понимал, зачем для снапшотов делать отдельный subvolume, как и @var.
Но как говорится, кому как удобно, так и лепит.
Пришлось разбраться в том числе и с этими программами, как с конечными решениями для работы со снапшотами. Конечно же работать напрямую также можно, продолжу разбор полётов, пропишу команды, т.к. текущие решения работы со снапшотами предполагают загрузку в снапшот в режиме чтения и нужно делать дополнительные движения. Простота улетучивается).

По моим исследованиям инструкций и вики - вынесение в отдельный subvolume требует snapper, а необходимость вынесения var вытекает опять же из механики загрузки снапшота через пункт grub - система грузится в режиме readonly и программы перестают работать нормально, кому нужно писать какие-то логи и прочее. На своей виртуальной машине я также сталкивался с данным эффектом, когда ненужные снапшоты перестают удаляться, т.к. остаются cмонтированные подпапки.

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

Верно, но непонятно тогда зачем делать его 1 или 2Гб, а не размером с RAM. С версии ядра 5.0 и в btrfs также можно делать это через файл но тогда данный раздел нельзя снапшотить. Видимо напрашивается вывод, что swap файл нужно сделать на том разделе, который мы не снапшотим - например в @var.

Про шифрование диска - для отдельного раздела swap вроде бы требуется совершать дополнительные действия для btrfs?
s-ugra@ya.ru
Использую в гноме timeshift-autosnap. Никаких глюков, во время любого обновления через хук пакмана делается снимок и в грабе создаётся соответсвующий пункт для загрузки. Количество снимков по умолчанию 3, но можно настроить сколько нужно. Единственное неудобство - timeshift требует меток @ для корня и @home для хомяка (необязательно) - пришлось поменять.

Именно это и прописано в инструкции с timeshift :)
Nebulosa
но непонятно тогда зачем делать его 1 или 2Гб
Это, кому не нужна гибернация, но своп делает, что бы было :)

Nebulosa
По моим исследованиям инструкций и вики - вынесение в отдельный subvolume требует snapper, а необходимость вынесения var вытекает опять же из механики загрузки снапшота через пункт grub - система грузится в режиме readonly и программы перестают работать нормально, кому нужно писать какие-то логи и прочее.
Вот поэтому я и не пользуюсь grub-btrfs, предпочитаю ручками переименовать нужный снапшот, в нужный subvolume, так как лишние и бесполезные для меня subvolume не нужны.

Nebulosa
Про шифрование диска - для отдельного раздела swap вроде бы требуется совершать дополнительные действия для btrfs
Не понял сути вопроса.
Каким боком отдельный раздел своп к btrfs?
RusWolf
Никогда не понимал, зачем для снапшотов делать отдельный subvolume,
1. субволуме со вложенными субволумами невозможно удалить.
btrfs subvolume list /
...
ID 48155 gen 3602303 top level 5 path @1111111111111
ID 48156 gen 3602303 top level 48155 path @1111111111111/222222222222222
...

btrfs subvolume delete /mnt/@1111111111111
Delete subvolume (no-commit): '/mnt/@1111111111111'
ERROR: Could not destroy subvolume/snapshot: Directory not empty
2. При бэкапе на другой носитель вложенные субволумы не переносятся, а соответственно при восстановлении с другого носителя даже нет пустых папок от них, а на них могут быть завязаны какие нибудь скрипты/настройки. (после восстановления при серьезном СБОЕ фиг вспомнишь что, как и зачем было)
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
nafanja
субволуме со вложенными субволумами невозможно удалить.
переведи.
у меня только @ и @home, причём тут вложенные?
[sudo] пароль для wolf:
ID 256 gen 55215 top level 5 path @
ID 257 gen 55217 top level 5 path @home
ID 988 gen 54480 top level 5 path root_BACKUP.2021-11-22_08:09:25
ID 989 gen 54482 top level 5 path home_BACKUP.2021-11-22_08:09:25
RusWolf, у тя так, у других может быть по другому (речь не о тебе), людям дали возможности, а они на радостях ими злоупотребляют не прощупав подводные грабли, а потом катят бочку на btrfs.
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
Посмотрел у себя и не пойму - что это за приколы в var/lib, откуда взялись??
sudo btrfs subvolume list /
ID 256 gen 77561 top level 5 path @
ID 258 gen 77561 top level 5 path @home
ID 261 gen 32 top level 256 path var/lib/portables
ID 262 gen 33 top level 256 path var/lib/machines
ID 353 gen 76905 top level 5 path timeshift-btrfs/snapshots/2021-11-19_13-59-42/@
ID 354 gen 76905 top level 5 path timeshift-btrfs/snapshots/2021-11-21_10-01-47/@
ID 355 gen 76905 top level 5 path timeshift-btrfs/snapshots/2021-11-22_10-57-54/@
 
Зарегистрироваться или войдите чтобы оставить сообщение.