Linux: btrfs: моментальное архивирование и другие чудеса.

Формат статьи: сначала описание возможностей, потом код.

Заинтересовавшись тем простым фактом, что btrfs ("модная" файловая система) предоставляет простым пользователям большиство нужных им возможностей крутой промышленной ZFS, я решил освоить эти возможности. К сожалению, прежде чем понял, что именно делать НЕ НАДО, пришлось по разу переустановить систему...

Сначала основные выводы, в первую очередь что НЕ надо делать. Основной disclamer в конце статьи.
НЕ СТОИТ ставить btrfs на нескольких дисках/разделах под "/" (корневую ФС). Имеется в виду количество разделов, перечисляемых в команде mkfs.btrfs. У меня загрузчик такого выверта просто не понял, пришлось переставлять систему (так как с GRUB разбираться без доступа к консоли вышло бы сильно дольше).

Старьё. привлекаемое для экспериментов, допустимо использовать разве что в формате RAID1 на 2-3 дисках/разделах. Что-то слетит обязательно...

Перед началом экспериментов с btrfs рекомендую освоить mdadm (хотя без него можно обойтись - и я покажу как!) и настроить дублирование наиболее старых из ваших дисков. Как только какой-то из дисков в составе RAID сдох, прекращаем эксперименты, ищем и добавляем замену, ждём конца восстановления массива и лишь потом продолжаем издеваться над железками!

Формально: прошу также обратить внимание на дисклеймер в конце статьи.

А теперь простыня...

Вкратце, воможности btrfs для обычных пользователей включают:

1. МОМЕНТАЛЬНОЕ полной архивной копии системы.

     НЕ НАДО ждать долгие часы, чтобы сделать бекап перед установкой сомнительной программы! Сделал снепшот - установил. Понравилось - продолжаешь, не понравилось - откатил к исходному состоянию, напримет, сделав 3 простых команды из консоли (либо отредактировав одну фразу в /etc/fstab)

2. Получите скорость SSD + объём HDD в одном флаконе!

    btrfs позволяет объединить в одну файловую систему дисков с разной скоростью: медленных, быстрых, SSD и RAID из HDD... ОЧЕНЬ РЕКОМЕНДУЮ для папки /home. IMHO НЕЖЕЛАТЕЛЬНО для корневой ФС. Плюсы от данного решения: наиболее часто используемые файлы (личные настройки рабочего стола, обои, наиболее часто используемые документы и т.п.) btrfs САМА поместит на наиболее быстрый из имеющихся дисков.

               ПОЧЕМУ НЕ СТОИТЬ СТАВИТЬ многодисковые варианты btrfs на "корень" ("/"). Я попробовал - и у меня GRUB глюканул, пришлось систему переставлять. Благо на SSD это быстро происходит, и был запасной пустой раздел. Потерявшееся хранилище на 3 дисках потом вполне успешно само "нашлось" в /dev/md127 и /dev/md/home, но осадок остался... 

               В текущей системе я объединил под папку /home 50-ГБ раздел SSD и 465-ГБ RAID1 на 2 HDD. Для больших объёмов данных (5 ТБ и более) ) предпочтительней будет использовать RAID6 минимум на 4 дисках.

3. Программный рейд на базе btrfs - легко и просто. Но только не для "/"

Эксперименты не проводились, так как мне это не надо. Но по идее, подводных камней быть не должно.

Применение: Если нет желания разбираться с mdadm и нет желания делать сбалансированное хранилище, объединяющее файлопомойку со старыми архивами и основные пользовательские директории /home, то можно просто (и изящно) создать из обычных HDD RAID1 (минимум 2 диска, НАДЁЖНОСТЬ), RAID5 (минимум 3 диска, НАДЁЖНОСТЬ и СКОРОСТЬ) или RAID6 (супер-надёжность и скорость для любителей старья - не страшна порча ДВУХ дисков из массива).

Примеры и код создания многодисковой конфигурации на btrfs

Код НЕ ПРОВЕРЯЛСЯ! Если что не будет срабатывать, пишите комментарии, буду исправлять. Тем не менее, всё написано после личного опыта работы с btrfs и mdadm и после изучения документации и примеров кода в инете.

Допустим, предполагается совместное использование на одном ПК Linux и Windows.

Пусть у вас имеется следующий зоопарк. Цифры условные.

2 диска на 500 Гб  - сильно б/у (sda и sdb)

1 диск на 1000 Гб - б/у (sdc)

1 диск на 2000 Гб (sdd)

1 диск SSD на 128 Гб (sde)

Буквы в кодировке типа /dev/sda условные и в вашей системе порядок букв будет другой!!!

Пример отказоустойчиовой конфигурации без применения mdadm

Код НЕ ПРОВЕРЯЛСЯ! Если что не будет срабатывать, пишите комментарии, буду исправлять. Пишу по документации и статьям в инете, я сам RAID средствами btrfs не создавал. Но по идее, подводных камней быть не должно.

Итак, как бы я их разбил "как для себя" без mdadm ? 

(Допустим, я о mdadm ещё не узнал).

У конфигурации без mdadm есть и плюсы и минусы,

Из плюсов - минус один программный уровень, и сокращённое время подключения новых дисков вместо убитых.

Из минусов — меньшая протестированность RAID-массива под btrfs (утилита mdadm гораздо более заслуженная), и не используются возможности btrfs по автоматической балансировке нагрузки на накопители с разной скоростью: я так понял, для btrfs возможен или встроенный рейд, или балансировка. Мы выбрали raid...

Мне однозначно предпочтительно решение с mdadm, но так как статья про btrfs, начну с чисто-btrfs решения.

1. Бъём 128-ГБ SSD поровну. Ставим винду на 64-гб раздел.

Здесь и далее — разбиение дисков на разделы производится, например, с помощью консольного приложения cfdisk командой типа

%# cfdisk /dev/sda

Обязательно убедитесь, что это имено тот диск, который вы хотите менять! Для начала сверьте общий размер диска со своей «шпаргалкой» о будущем плане разметки.

2. На второй раздел 64 Гб ставим Linux. Всё, базовая система готова. Начинаем настраивать HDD.

Диск sdd1 обнаруживаем и форматируем средствами Windows. Всё, о нём можно забыть.

3. Отгрызаем от 2000 Гб (самый большой, и предположительно - самый быстрый, новый и надёжный) раздел порядка 1000 Гб под игрушки в Windows. "Помните нашу щедрость" (с). А рухнет - не жалко. Это будет раздел sdd1. Делаем на этом диске ещё 2 раздела - sdd2 и sdd3 - по 500 Гб.

4. Делим 1000-ГБ диск sdc пополам. Получаем разделы sdc1 и sdc2.

5. Диски sda и sdb размечаем так, что под единственный основной раздел приходится весь диск. Получаем разделы sda1 и sda2.

Disclamer. Я отлично знаю, что во многих случаях можно вполне использовать не разделы, а диски целиком, но мне с разделами как-то привычей... унифицированней. И тому IT-специлисту, который будет смотреть, что же стоит в системе, тоже будет проще, если при прочих равных всё будет сделано традиционно. 

6. Делаем «большую-быструю» файловую систему btrfs на разделах /dev/sda1, /dev/sdb1, /dev/sdc2, /dev/sdd3 итоговым размером 1000 Гб с именем диска BTRFS6 в рейде RAID6:

%# mkfs.btrfs -L BTRFS6 -d raid6 /dev/sda1 /dev/sdb1 /dev/sdc2 /dev/sdd3

Как определяется итоговый размер ФС? Из 4 дисков по 500 Гб ДВА будут зарезервированы для исправления ошибок и контроля чётности. Остаются 2 диска по 500 Гб = 1000 Гб. В такой конфигурации мы получим где-то 2-кратное ускорение скорости линейного чтения и записи по сравненению с худшим из дисков, и 2-кратное ускорение работы с мелкими файлами.

7. Аналогично, ещё один RAID, на этот раз типа raid1 (зеркало) размещается на оставшихся разделах 2 более новых дисков. Этот массив будет ещё более быстрый, но лишь на чтение. На запись его скорость будет равна скорости худшего из 2 дисков.

%# mkfs.btrfs -L BTRFS1 -d raid1 /dev/sdc1 /dev/sdd2

Поскольку размер диска под RAID1 равен размеру наименьшего диска, то итоговый размер раздела составит 500 Gb.

8. ВАЖНО! Перед работой с /etc/fstab ВСЕГДА создавайте работающую копию этого файла примерно следующей командой:

%# cp [-f] /etc/fstab /etc/fstab.backup

ключ «-f» опциональный, он нужен, если вы хотите переписать предыдущий файл с тем же именем. Квадратные скобки в Linux означают, что данный ключ нужен не всегда.

Если /etc/fstab сформирован с ошибками, то система вывалится в консоль и у вас будет возможность поправить его. Если есть бекап, это делается так:

%# cp [-f] /etc/fstab.backup /etc/fstab

и можно перезагружаться

%# reboot

9. Раздел /dev/sdd2 (или любой другой из входящих в состав RAID1) подключаем на папку /home, а для раздела /dev/sdd3 создаём папку /video и монтируем его туда. Делается это редактированием файла /etc/fstab

Примерные строки fstab:

#файловая система для коренной ФС — ДАННУЮ СТРОКУ НЕ ПРАВИМ!

UUID=a57a4265-4d85-4c1c-9826-03de915716ac / btrfs defaults 0 1

#ФС с быстрым чтением для папки /home

/dev/sde2 /home btrfs defaults 0 2

#ФС для быстрого чтения/записи больших файлов

/dev/sdd2 /video btrfs defaults 0 2

Символом # обозначены комментарии. Количество пробелов значения не имеет.

10. На случай дальнейших изменений в подключённых дисках, имена разделов рекомендуется заменить на их UUID, который можно посмотреть с помощью программы blkid. Вывод blkid можно даже записать в текстовый файл командой:

%/etc#blkid > blkid.out

В папке /etc будет создан маленький файл blkid.out , из которого можно будет взять соответствие нормальных кодов дисков и UUID разделов.

Т.е. из вывода blkid нужно будет вручную верезать кавычки, так как там UUID (среди прочего) обозначен как

UUID="a57a4265-4d85-4c1c-9826-03de915716ac"

Как отмечалось ранее, редактировать системные файлы удобно программой nano из-под суперпользователя. Команда Ctrl+R вставит в текущее место файла нужные вам строки того же blkid.out

А как бы я сделал это с mdadm

Это именно тот путь, которым я пошёл. Всё прелестно работает, правда с немного иной конфигурацией дисков. Все команды испытаны автором.

Комментарии курсивом, общие с предыдущей инструкцией, вырезаны.

Пункты 1-5 остаются прежние.

6. Делаем «большую-быструю» файловую систему btrfs на разделах /dev/sda1, /dev/sdb1, /dev/sdc2, /dev/sdd3 итоговым размером 1000 Гб с именем диска BTRFS6 в рейде RAID6. Назовём новый массив homedata, система сама сгенерирует ему системное имя типа /dev/md163. (могу ошибаться какое именно). Команда mdam --create позволяет работать с «именами» массивов, что поначалу может быть гораздо удобней.

%# mdadm --create homedata --level=6 --raid-devices=4 /dev/sd[a-b]1 /dev/sdc2 /dev/sdd3

Если всё написано без ошибок, то по команде

%# ls /dev/md*

мы увидим, что появился новый диск (условно) md163. ОН ЖЕ будет виден как /dev/md/homedata .

7. Аналогично, ещё один RAID, на этот раз типа raid1 (зеркало) размещается на оставшихся разделах 2 более новых дисков. Этот массив будет ещё более быстрый, но лишь на чтение. На запись его скорость будет равна скорости худшего из 2 дисков.

%# mdadm --create r1data --level=1 --raid-devices=2 /dev/sdc1 /dev/sdd2

8. Создадим файловую систему btrfs, общую для обоих дисков.

%# mkfs.btrfs /def/md/homedata /dev/md/r1data

9. Сделайте бекап etc.tab (как — см. в варианте инструкции без mdadm п. 8

10. Пора подключать новую комбинированную ФС в /etc/fstab. Подключать можно по «адресу» любого из разделов, предоставлнных для данной ФС. Естественно, монтировать будем в /home.

Раздел r1data на RAID1 устроен проще (требует меньше дисков), пусть мы решили что он прослужит дольше. Используем его для подключения новой ФС в /etc/fstab

Примерные строки fstab:

#файловая система для коренной ФС — ДАННУЮ СТРОКУ НЕ ПРАВИМ!

UUID=a57a4265-4d85-4c1c-9826-03de915716ac / btrfs defaults 0 1

#Система хранения на 4 дисках: 2 раздела по 500 Гб в RAID1 формируют диск объёмом 500 Гб и 4 раздела по 500 гб в RAID6 формируют диск размером 1000 Гб. Подключать можно через указание любого раздела.

/dev/md/r1data /home btrfs defaults 0 2

Так как имена новых разделов (например, /dev/md/bigdata или /dev/md163) сформированы утилитой mdadm, можно НЕ прописывать UUID для нового диска — он останется неизменным, предположительно, даже если подключение данных дисков изменится. По крайней мере, должен остаться неизменным «ник» раздела (т. е. адрес «/dev/homedata»).

Примеры и код создания "архивов" (снепшотов!) системы и данных.

Рекомендации данного раздела проверены автором на своей шкуре, статья написана на личном опыте. Автор остался глубоко доволен: НИКОГДА ЕЩЁ полный бекап системы на тот же физический диск не занимал ОДНУ СЕКУНДУ.

Для создания архива корневой файловой системы (неважно, это файловая система, подключённая к "/" или куда-либо ещё, нужн сделать её СНЕПШОТ.

Терминология btrfs.

Подраздел - это отдельное, независимое "дерево" файлов и каталогов, хранящееся в файловой систме корневого раздела файловой системы диска, в другом подразделе или снепшоте. Подраздел ПОЛНОСТЬЮ НЕЗАВИСИМ от других подразделов, кроме тех, которые входят в его состав и тех, в состав которых он входит :-)

Снепшот - это, если аккуратно выражаясь, команда системе начать запись ВСЕХ изменений определённого снепшота или подраздела ФС (или даже всей ФС) в формате дополнения к текущему состоянию, "сфотографированному" в снепшоте. Сам по себе снепшот использует данные ПОДРАЗДЕЛА либо другого снепшота и может быть создан только из них.

Для btrfs с момента создания снепшота снепшот и подраздел почти идентичны, хотя есть и различия. Например, для передачи данных раздела в другую ФС btrfs (грубо, для ФС, созданной на других накопителях), нужен именно снепшот, созданный "только для чтения" (опция -r при содании снепшота).

Психологически меня как-то мучает вопрос, что "первично" - скопированная система (подраздел/снепшот системы) или её снепшот. Особенно с учётом того, что работать можно и там и там!!! Правильный ответ - они идентичны, это разные версии одних и тех же данных. Это можно сравнить с копированием файлов: после копирования оба файла имеют полностью идентиное содержимое, но мы можем править любой из них. Весь фокус в том, что в btrfs при "копировании" "корневой директории", подразделов или снепшотов дополнительное место НЕ ТРЕБУЕТСЯ - оно требуется лишь по мере того, как накапливаются изменения между этими версиями и новые файлы.

С точки зрения пользователей, снепшот и подраздел выглядят как обычные папки в файловой системе. Главная особенность в том, что мы можем выбирать ТОЧКИ МОНТИРОВАНИЯ файловой системы btrfs в свою операционную систему, но этими "точками монтирования" могут быть лишь имеющиеся подразделы и снепшоты.

Пример такой логики "из жизни". На (корпоративном) сервере есть предоставляемые пользователям файловые системы. Мы можем подключить на какую-либо букву диска в Windows как корневую папку, предоставляемую пользователям, так и её суб-директорию.

btrfs позволяет задаватьтакую "точку монтирования" двумя способами - как через опции монтирования, так и через точку монтирования "по умолчанию", настраиваемую командой btrfs subvolume set-default ... .

Итак, предположим, мы сконфигурировали и настроили компьютер, файлохранилище, подключили все диски (как описано выше) и теперь обеспокоились возможностью бекапа. Начнём с папки /home — предположим, она расположена на корневом разделе отдельной файловой системы btrfs. Например, на ранее созданном физическом разделе /dev/md/homedata (для данного примера расположение этого физического раздела будет видно только на этапе редактирования /etc/fstab).

Сейчас мы это вместе сделаем, я прокомментирую весь код.

1. Перезагржаем компьютер и — ЭТО ВАЖНО — не входим в своего пользователя в графическом режиме (чтобы открытые файлы не заблокировали нужную нам ФС). Вместо этого, переключаемся из графического режима в текстовую консоль — например, в первую консоль:

Ctrl+Alt+F1

логин: root

Пароль: введите пароль суперпользователя

и переходим в папку файловой системы, с которой мы будем работать.

%~# cd /home

Проверяем содержимое папки

%/home# ls

(тут система отобразит список ваших пользователей и все дополнительные папки, которые созданы вами в /home , если они есть)

И создаём в данной директории снепшот корневой системы диска, подмонтированного к /home

%/home# btrfs subvolume snapshot /home /home/home-data

Create a snapshot of '/home' in '/home/home-data'

ВУАЛЯ! Мы в течение СЕКУНДЫ одной командой сделали ПОЛНЫЙ АРХИВ файловой системы! Ну разве что данные физически где лежали, там и лежат... но с этого момента мы можем работать с ними как с двумя независимыми наборами данных.

В данной команде «путь» задаётся ОТНОСИТЕЛЬНЫЙ в рамках иерархии субвольюмов, снепшотов и директорий файловой системы btrfs, подмонтированной к /home ! Т.е. «/» означает «коренная папка файловой системы, подключённой к /home».   В  команде btrfs snapshot create путь всё-таки абсолютный, от текущего корня Линукс!!! Прошу прощения за неточность... Код и комментарии исправлены по мере опыту работы с субвольюмами...

Например, используя данные примера с mdadm выше, это может быть «корневая папка файловой системы, разложенной на 3 дисках, в т.ч. два в RAID1 на /dev/md/r1data и один в RAID6 на /dev/homedata .

В btrfs индикатор «раздела» для корневой папки равен 5, поэтому в данной команде можно заменить / на «5» и всё сработает так же.

Проверим.

%/home# ls

%/home# cd home-data

%/home/home-data# ls

Если всё ОК, должна появиться «папка» home-data , содержимое которой будет идентичным прежнему содержанию коренного раздела данной ФС.

Теперь достаточно лишь чуть подкорректировать /etc/fstab — нужно добавить опцию монитрования, указывающую на новый раздел.

Уточняем строку fstab, отвечающую за монтирование каталога /home файловой системы Linux:

/dev/md/r1data /home btrfs subvol=/home-data 0 2

Вуаля. Перезагрузка и проверка, в папке /home папка /home-data должна отсутствать. Если так, значит, мы успешно подмонтировали свою систему именно в раздел /home-data файловой системы, с которой только что «сняли» снепшот.

Может возникнуть вопрос, как делать дальнейшие архивы...

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

%/home# btrfs subvolume snapshot /home-data /home-data1

Create a snapshot of '/home-data' in '//home-data1'

При необходимости очистки диска от старых архивов просто удаляйте ненужные «номерные» архивы командой

%/home# btrfs subvolume snapshot delete /home-data1

А при необходимости переключиться с текущей версии сохранённых данных на снепшот, созданный некоторое время назад, можно уточнить имя снепшота в /etc/fstab, например:

/dev/md/r1data /home btrfs subvol=/home-data1 0 2

В заключение: подразделы можно создавать и для важных рабочих директорий, и даже для отдельных ПРОЕКТОВ. Т.е. этот способ резервирования довольно универсален. Разве что удалитьт подраздел может быть непросто, и перемещение большого объёма файлов в другой подраздел сравнимо по времени с копированием на другой диск (и оно почти что так и есть).

Ровно аналогичным образом — через создание подразделов и редактировани /etc/fstab — можно создавать «снимки» и корневой ФС ОС Линукс. Но это непросто, см далее курсивом. Код целенаправленно не даю, это почти "высший пилотаж" - тут самому дойти надо :-)

Например, с такого вот снимка я сейчас и пишу эти строки, но достичь этого было ой как непросто. Тут легко всё испортить, поэтому прежде всего озаботьтесь, чтобы у вас была аварийная система на HDD или Flash.

Строго говоря, двигать "корень" на субвольюм - не так уж и просто. Чтобы сделать всё чисто, нужно сделать ряд телодвижений. С другой стороны, если не двигать снепшоты между друг дружкой и не ставить корень на снепшот, то btrfs в Линукс работает бесшовно и стабильно.

Проблема в том, что GRUB умеет смотреть в btrfs, но не может использовать опцию "дефолтной точки монтирования" и потому "зрит в корень". И если видит там "фигу", сильно обижается. Загрузившись с флешки, я попробовал подсунуть ему вместо "настоящих" boot, etc, bin, vmlinuz и initrd.img символические ссылки (симлинки) на те же файлы в  клоне корня - /rootfs - сработало!

Все "ненужные" каталоги  позже переименую по схеме mv boot old.boot

В ходе работы нужно чётко понимать в каком снепшоте ты работаешь. Также нужно проверит командой ls -s , куда ведут созданные тобой симлинки (в ту ли папку, а не "корень" флешки ли?)

БАГ btrfs: команда rm -r * почему-то получает возможность удалить всё даже в "read-only" снепшотах. Из-за этого мне пришлось Линукс перестанавливать. Ну зато я теперь учёный - на корне её применять нельзя :-) 

Желаю всем удачной работы и успехов.

Disclamer

Автор не принимает никакой ответственности за повреждение данных или оборудования, которые произошли из-за правильного или неправильного применения его рекомендаций.

Запрещается цитирование статьи иначе, чем полными предложениями. Цитирование либо перепечатка возможна только со ссылкой на статью на aftershock.news. Автор оставляет за собой право преследовать нарушителей этих требований согласно законодательству РФ об авторских правах.

Статья написана на основе работы с ОС Linux Debian Jessie с обновлениями уровня stable на момент написания. На других ОС всё может работать там, где у меня не работает, и наоборот. Все мои эксперименты с честью выдержали ssd марки OCZ, других не беру и поручиться за другие марки накопителей не могу.

На ВАШЕМ оборудовании всё может не сработать.

Риск поломок в ходе экспериментов сильно ухудшают осыпающиеся диски, а также плохие контакты, особенно для USB-накопителей. Осыпающиеся диски лучше добивать в составе RAID, а сами по себе они использоваться не должны. В ХОДЕ ЭКСПЕРИМЕНТОВ ВЫБРОШЕНО В ПОМОЙКУ ТРИ НАКОПИТЕЛЯ, ранее отключенные по причине сомнений в их надёжности, но которые было жалко выбросить! СОЗДАВАЙТЕ БЕКАПЫ! Также была выявлена неработоспособность ОДНОГО USB-порта, монитор падал раз 5, и был потерян USB-WiFi-модем. Ни одна кошка в ходе экспериментов не пострадала.