Как сделать снапшот btrfs linux

Добавил пользователь Валентин П.
Обновлено: 04.10.2024

Экспериментируем с файловой системой Btrfs — установка операционной системы Linux на SSD нетбука с компрессией файлов

В отличие от Microsoft Windows, в которой на протяжении многих лет главенствующим и практически единственным типом файловой системы является NTFS (о FAT и о об анонсированной в 2012 году ReFS говорить не будем), в Linux выбор есть. Здесь навскидку можно насчитать более десятка разновидностей файловых систем. Наиболее известными и чаще всего используемыми являются EXT2, EXT3 и, конечно, EXT4. К ним можно добавить btrfs, jfs, reiserfs и ряд других.

Идеальных файловых систем не существует. Каждая из них имеет свои сильные и слабые стороны. Сегодня мы поэкспериментируем с Btrfs, которая считается одной из самых быстрых и перспективных.

Основные особенности файловой системы Btrfs

Файловая система Btrfs (Better FS), основанная на структурах двоичных деревьев (B-Tree), была представлена компанией Oracle в 2007 году.

Перечень достоинств и возможностей btrfs весьма обширен. Перечислю те из них, которые показались мне наиболее интересными для применения на домашнем компьютере и сподвигли в конечном счете на эксперименты с этой ФС:

Высокая скорость;
Поддержка многодисковых конфигураций устройств хранения — можно налету подключать/отключать диски к файловой системе, а также создавать RAID конфигурации различных уровней. Можно создавать конфигурацию с чередованием или зеркалированием и для отдельных каталогов.
Можно включить прозрачное сжатие данных (Zlib – более высокая степень сжатия, LZO – быстрое сжатие, в разработке — snappy, LZ4);
Online дефрагментация файловой системы;
Встроенная поддержка твердотельных накопителей SSD;
Контроль целостности блоков данных и метаданных с помощью контрольных сумм;
Возможность создания подтомов (subvolumes);
Возможность преобразования существующих ext3 / ext4 файловых систем в btrsf;
Пространственно-эффективная (Space-efficient) упаковка мелких файлов;
Эффективное индексирование каталогов;
В числе планируемых возможностей — перемещение наиболее часто используемые данные на самое быстрое устройство.

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

Самым главным недостатком Btrfs на сегодняшний момент времени является ее статус. С одной стороны, актуальная на момент написания данной статьи версия v3.12 считается стабильной, с другой стороны, разработчики откровенно заявляют, что она все еще находится в стадии тестирования и ее не рекомендуется использовать в промышленных целях.

Получается, что при использовании ранних версий Btrsf данные пропадали нестабильно, теперь будут пропадать стабильно (шутка).

Что касается скорости, то ресурсом Phoronix еще в 2011 году были опубликованы данные производительности файловой системы Btrfs при работе без сжатия данных, со сжатием методом ZLib и со сжатием методом LZO.

В двух из трех проведенных тестов (Compile Bench и Dbench Btrfs) вариант с LZO-сжатием уверенно обогнал как вариант без сжатия, так и вариант с ZLib-сжатием. Причем в некоторых случаях разница в скорости отличалась почти на порядок (!).

В тесте Threaded IO Tester LZO проиграл и варианту без сжатия и ZLib от 10% до 33%.

Вообще измерение реальных скоростных характеристик устройства хранения является задачей непростой. Некоторое время назад я пробовал оценить влияние ntfs-сжатия на скорость чтения данных в Windows 7. Результат оказался неоднозначным, как это ни странно, зависящим от типа накопителя. Это не позволило сделать однозначных выводов.

Значительный выигрыш в скорости ФС по результатам двух тестов и незначительный провал в одном из них склоняют к решению выполнить установку операционной системы Linux на том Btrfs с включенным сжатием.

Установка Linux на том Btrfs с включенной компрессией

В качестве подопытного кролика тестового стенда вновь будет выступать старенький ASUS Eee PC 900. Чего он только ни повидал за прошедшие годы. Интересно, много ли у кого сегодня сохранился этот первый представитель окончательно вымершего сегодня семейства нетбуков?

Для запланированного эксперимента с Btrfs это просто идеальный образец.

Во-первых, два крошечных (4 Гб и 8 Гб) SSD накопителя, больший из которых к тому же еще и в два раза медленнее маленького. На самом деле оба флеш-диска очень медленные и не имеют ничего общего, по крайней мере по скорости, с современными твердотельными накопителями.

Во-вторых, само устройство на процессоре Intel Celeron M 900 МГц ну очень небыстрое, что сразу же позволит даже безо всяких тестов просто визуально оценить успех или неудачу данного эксперимента.

Изначально я планировал установить на Eee PC 900 Linux Mint-17.1 xfce. Однако очень скоро с этой идеей пришлось проститься. Инсталлятор Linux Mint требовал минимум 8.2 Гб свободного места на диске и в упор не хотел видеть ни второй диск, ни заранее собранный из двух накопителей том Btrfs объемом почти 12 Гб. О том, чтобы объяснить инсталлятору, что установка будет выполняться на сжатый том и на самом деле одного диска объемом 4 Гб будет достаточно, речь вообще не шла.

Последующая проверка в виртуальной машине VirtualBox показала, что для установки 32-разрядной сборки Linux Mint-17.1 xfce на сжатый с помощью LZO том, нужно всего 2,6 Гб

Задачу можно было бы легко решить с помощью LVM, как это было описано здесь, но очень уж не хотелось добавлять совершенно ненужную в данном случае прослойку между дисками и файловой системой Btrfs – она сама отлично справляется с многодисковыми конфигурациями.

Это исключительно проблема данного нетбука, обусловленная маленьким размером дисков. Вряд ли она повторится на каком-либо другом компьютере. Хотя в дистрибутиве Linux Mint хотелось бы видеть инсталлятор поумнее.

Если соберетесь устанавливать Linux Mint на файловую систему Btrfs, имейте в виду, что в дистрибутив, по крайней мере в тот, о котором здесь идет речь, поддержка этой файловой системы не включена. Для того, чтобы иметь возможность отформатировать разделы с Btrfs, необходимо установить btrfs-tools:

sudo apt-get install btrfs-tools

Так как поддержка Btrfs включена в ядро, Mint после установки загрузится, но для того, чтобы можно было делать некие манипуляции с томами, установку btrfs-tools придется повторить.

В качестве альтернативы я выбрал легкую облачно-ориентированную Peppermint OS с окружением рабочего стола LXDE (Lightweight X11 Desktop Environment). Ранее она уже упоминалась в обзоре дистрибутивов Linux.

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

Последняя на момент написания данной статьи 5-я версия этой ОС базируется на Ubuntu 14.04 LTS с пятилетним сроком поддержки. Возможность работы с файловой системой Btrfs присутствует сразу.

Проблема установки состояла в том, что компрессия включается в Btrfs на стадии монтирования файловой системы (-o compress=lzo / zlib ), а стандартный инсталлятор Linux, по крайней мере в Ubuntu и основанных на ней системах, не дает выбирать расширенные опции.

Очень элегантное и простое решение этой задачи удалось найти в этом руководстве.

Создаем загрузочную флешку с помощью Universal USB Installer. Загружаем компьютер с нее и заходим в терминал:

Переименовываем исполняемый файл mount в mount.bin

mv /bin/mount /bin/mount.bin

Вместо gedit вы можете использовать любой текстовый редактор, входящий в состав Live CD.

Вписываем в mount следующий код:

Во избежание ошибок вы можете заранее создать текстовый файл с указанным содержанием и записать его на Live флешку, или открыть данную страницу непосредственно в Live сеансе и скопировать его с нее.

chmod 755 /bin/mount

Она ничем не отличается от описанной, например здесь.

Разбиение диска нужно выполнить самостоятельно. Для этого на этапе “Тип установки” выбираем “Другой вариант”.

Под /boot необходимо обязательно создать в начале диска раздел размером примерно 200 Мб. В противном случае система со сжатого диска не загрузится.

В данном случае под /home отдельный раздел выделять не нужно – в процессе установки для этого каталога будет автоматически создан подтом (subvolum — /@/home).

Если система устанавливается на обычный (не SSD) диск, нужно сделать раздел подкачки объемом 2 х RAM.

О назначении каталогов операционной системы Linux можно прочитать здесь.

Продолжаем стандартную процедуру установки и дожидаемся ее завершения.

До первой перезагрузки можно сразу же отредактировать fstab (file systems table). Для этого придется смонтировать выделенный при установке под корень файловой системы раздел.

Если это был, например, sda2, то:

mount /dev/sda2 /mnt
gedit /mnt/@/etc/fstab

Обратите внимание, что корневой раздел также попал на подтом и путь к нему включает в себя “@”.

Находим в fstab строки, касающиеся монтирования Btrfs томов и заменяем defaults на compress=lzo (конкретный пример fstab см. ниже).

Перезагружаем компьютер, теперь уже с жесткого диска

Добавление второго диска в файловую систему Btrfs

Как уже было отмечено выше, Btrfs предоставляет широкие возможности для работы с многодисковыми конфигурациями устройств хранения. Можно как создавать RAID массивы различного уровня, так и просто увеличивать доступное пространство существующего раздела за счет подключения к нему новых дисков или дисковых разделов.

Дополнительные диски можно подключить или отключить на работающей системе в любой момент.

По умолчанию при размещении радела на нескольких дисках данные распределяются без резервирования и размер ФС получается равным их суммарному объему. При этом выполняется зеркалирование метаданных на двух устройствах. Если диск один, то копия метаданных размещаются на нём.

Добавим в уже созданный раздел /dev/sda2 дополнительный диск /dev/sdc

sudo btrfs device add /dev/sdb /

где “/” – точка монтирования (path). Так как домашний каталог также смонтирован на том Btrfs, можно использовать “/home”.

Если sdc ранее уже был отформатирован в Btrfs, то, возможно, команда потребует ключа –f.

Непосредственно после добавления нового диска сохранённые на первом диске файлы остаются на месте. Присоединенный диск будет заполняться в процессе работы. Если нужно сразу перераспределить файлы, выполняем балансировку:
sudo btrfs balance start /
В зависимости от объема данных и скоростных характеристик дисков этот процесс может быть продолжительным.
Если использовать диски (или разделы) одинакового размера, то можно на ходу конвертировать single device в RAID массив.
btrfs balance start -dconvert=raid1 -mconvert=raid1 /
В результате получится RAID с зеркалированием данных и метаданных. Аналогичным образом можно построить RAID любого уровня, не забывая при этом о количестве необходимых для этого дисков.

Оценить полученный результат можно выполнив команду:

sudo btrfs filesystem show /

Получить информацию об объеме, занятом метаданными:
btrfs filesystem df /

Балансировку я выполнил не сразу, а через несколько дней после начала активной эксплуатации нетбука. Удивление вызвал тот факт, что Btrfs неожиданно переместила ~85% данных на более медленный диск. Хотелось бы думать, что это правильное решение. В любом случае это очень интересный результат.

Дополнительная оптимизация операционной системы Linux для работы на SSD

Для того, чтобы продлить жизнь твердотельному накопителю, как SSD, так и обычному флеш-накопителю, нужно по-возможности сократить для них количество операций записи в единицу времени. В том числе сделать это можно путем оптимизации опций монтирования в файле fstab.

В качестве файловой системы для каталога /boot была не случайно выбрана нежурналируемая файловая система ext2. Журналируемые ФС, с одной стороны, являются устойчивыми к аварийным ситуациям, но с другой стороны, увеличивают количество записей на жесткий диск.

Для разделов Btrfs, размещенных на SSD, добавляем опцию ssd. Как изменится после этого алгоритм работы с диском досконально неизвестно. Можно предположить, что при старте или в процессе работы на накопителе будут отыскиваться незанятые блоки и регулярно освобождаться. Одним словом, хуже не будет.

Отмечается, что для твердотельных накопителей старого типа более целесообразной может быть опция ssd_spread.

Операции чтения файлов также могут создавать большую нагрузку на твердотельный накопитель, так как при каждом обращении записывается время доступа к файлу или директории (atime). Запись на диск происходит даже при чтении из кеша.

Избежать этого можно добавив опции noatime, nodiratime, которые отключают запись меток времени соответственно для файлов и для директорий (по некоторым источникам noatime включает в себя nodiratime).

Отключение atime не только продлевает жизнь жесткого диска, но и как отмечается в этой статье, на 30% увеличивает скорость системы. Однако не все приложения смогут правильно работать с отключенными временными метками.

Альтернативой им может быть более демократичная опция relatime. При ее использовании метки времени обновляются, но не при каждом обращении к файлу, а только в том случае, если файл был изменен с момента последней записи atime.

Прописываем relatime для всех разделов, расположенных на SSD.

Для того, чтобы еще больше облегчить жизнь SSD, а заодно опять же улучшить быстродействие компьютера, переносим в оперативную память с помощью файловой системы tmpfs временные, служебные и лог-файлы. Для этого добавляем в конец fstab директивы монтирования соответствующих каталогов в tmpfs в соответствии с рекомендациями представленными здесь.

Окончательно у меня получилось так:

Сохраняем fstab и переходим к sysctl.conf

sudo gedit /etc/sysctl.conf

Добавляем в конец файла:

Параметр в сотых долях секунды определяет как часто будет осуществляться запись данных на диск из кеша. В данном случае получится каждые 15 секунд. Таким образом мы опять же уменьшаем количество операций записи на SSD в единицу времени.

При этом, естественно, повышается вероятность потери данных в случае непредвиденного отключения питания. Для ноутбука или нетбука с исправным аккумулятором вероятность такой неприятности крайне невелика.

Это далеко не все. Оптимизационные мероприятия можно продолжить и, например, перенести на RamDisk браузерный кеш.

Опции монтирования файловой системы Btrfs для традиционных механических жестких дисков

Твердотельный накопитель SSD в нетбуке скорее все же исключение, чем правило. Поэтому для тех, кто вслед за мной захочет поэкспериментировать с установкой Linux на Btrfs, приведу некоторые полезные опции монтирования дисковых томов обычных HDD, размеченных с помощью этой файловой системы.

compress — оставляем. Согласно тестам, представленным на сайте Phoronix еще в конце 2010 года, компрессия дает главный выигрыш в скорости дисковых операций.

space_cache – включает кэширование данных о свободных блоках в памяти. Без этой опции в процессе поиска свободного пространства перед записью Btrfs будет всякий раз сканировать все дерево. По результатам большинства тестов Phoronix включение опции space_cache дает выигрыш в скорости работы с диском, хотя и не столь существенный, как опция compress.

autodefrag — дефрагментация файлов на лету.

В конечном счете для HDD должно получиться примерно так:

Заключение

Делать какие-либо заключения по поводу целесообразности использования файловой системы Btrfs я не возьмусь. Продолжительность эксплуатации компьютера с новой файловой системой пока еще невелика, хотя я и стараюсь использовать его активно. Что-то мне подсказывает, что все будет хорошо.

Общее впечатление от скорости и стабильности работы Peppermint OS 5 со сжатой с помощью LZO компрессии файловой системой на Eee PC 900 самые положительные.

Если я скажу, что система летает, вы мне не поверите. И правильно сделаете. Это старенькое устройство на 915-м чипсете с Celeron-M 900 летать не умеет по определению. Но по сравнению с самим собой под другими ОС работает действительно на удивление быстро. Как говорится, результат превзошел ожидания. Пожалуй что эта последняя инсталляция оказалась пока самой удачной.

Опять же не возьмусь утверждать, что главная заслуга в этом принадлежит btrfs compress=lzo. В большей или меньшей степени влияние оказали все оптимизационные настройки. Но то, что файловая система сыграла свою положительную и не последнюю роль, безусловно.

Для того, чтобы вы имели представление о чем идет речь, приведу несколько временных характеристик.

Загрузка компьютера из выключенного состояния до полной загрузки рабочего стола занимает примерно 60 секунд. Из них ~15 секунд занимает POST, и также ~15 секунд — сканирование файловой системы Btrfs. Разницу в скорости между опциями монтирования ssd и ssd_spread заметить не удалось.

Первый после включения компьютера запуск браузера Google Chroome – 12 секунд до появления окна, 20 секунд загрузка начальной страницы Google с подключением к учетной записи и отрисовкой всех изображений.

Повторный запуск браузера Chroome с начальной страницей Google – 10 секунд. Загрузка главной страницы Yandex – 7 секунд.

Открытие электронной книги в FBReader – 2 секунды, запуск текстового редактора AbyWord – 4 секунды, электронной таблицы Gnumeric – 2 секунды, открытие папок с файлами в файловом менеджере PCManFM – мгновенно.

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

Введение

*nix-системы всегда были относительно устойчивы к некорректно написанным приложениям (в том случае, конечно, если они запускались не из-под суперпользователя). Однако иногда возникает желание поэкспериментировать с системой — порезвиться с конфигами, отдельные из которых могут быть жизненно важными, запустить подозрительный скрипт, поставить программу, полученную из недоверенного источника… А то и просто одолевает паранойя, и хочется возвести как можно больше барьеров для защиты от потенциальной малвари. В статье будут описаны некоторые средства, позволяющие избежать последствий невынужденных ошибок с помощью отката на заблаговременно созданную точку возврата (снапшоты Btrfs), запустить подозрительную программу в ограниченном окружении и потешить твою паранойю (Arkose и chroot).

Chroot

Chroot известен давным-давно. У него имеется огромное преимущество перед другими средствами — он работает везде, даже на очень старых дистрибутивах. Все эти новомодные песочницы представляют собой не что иное, как его дальнейшее развитие. Но есть и минусы. Например, нет возможности ограничить работу с сетью, root может при некотором усилии выйти из него, и самое главное — его достаточно сложно настраивать. Несмотря на это, для некоторых целей, к примеру установки пакетов из исходников, он подходит идеально.

Существует как минимум три способа создания chroot-окружения:

Все необходимые для работы запускаемой программы приложения и библиотеки ты определяешь сам. Это наиболее гибкий способ, но и наиболее замороченный.
Chroot-окружение формируется динамически. Одно время существовал проект Isolate, который это и делал, но нынче по неизвестным причинам он канул в Лету.
Развертывание базовой системы в указанном каталоге и чрутинг на него — его я и опишу.

Grub и Btrfs

Собственно, переменная recordfail необходима, чтобы предотвратить циклическую перезагрузку, для чего она при старте взводится, а затем, в случае успешной загрузки, устанавливается в 0. Хоть комментировать код, отвечающий за эту процедуру, и нежелательно, но думаю, что на настольной системе вполне можно обойтись и без него.

Огнелис в песочнице — об этом говорит заголовок

Другие статьи в выпуске:

Для начала установим пакет debootstrap, который используется как раз с этой целью.

Затем создадим каталог, в котором будет находиться chroot, и развернем базовую систему quantal в нем. В общем-то, его можно создать где угодно, но традиционное место его размещения — /var/chroot. Поскольку большинство следующих команд требуют права root, имеет смысл переключиться на аккаунт суперпользователя:

Разберем последнюю команду. Она разворачивает релиз убунты Quantal в отдельный каталог quantal-chr1 (мало ли, вдруг понадобится еще один chroot) с ближайшего зеркала. После завершения развертывания необходимо отобразить файловые системы procfs, sysfs и (если это необходимо) каталог /dev на данное поддерево. В случае если chroot будет использоваться для текстовых приложений только до перезагрузки, должно хватить следующих команд:

Если же требуется, чтобы данное поддерево работало и после перезагрузки, добавь соответствующие строки в /etc/fstab. Ну а для работы некоторых графических приложений также следует отобразить каталоги /tmp и /var/run/dbus. После этого уже можно вводить следующую команду, которая, собственно, и делает chroot:

И ты уже заперт в нем. Для того чтобы не спутать chroot с реальной системой, рекомендую изменить приглашение оболочки. Для примера давай установим и запустим в chroot Skype. Для этого потребуется установить на хостовой системе пакет schroot, который позволяет упростить запуск программ в chroot-окружении:

Развертывание в chroot базовой системы с помощью debootstrap

Затем добавим запись в файл /etc/schroot/schroot.conf. В моем случае я добавил следующую:

Пробрасываем /dev, /proc, /sys, /tmp и /var/run/dbus — как это сделать, смотри выше. Добавим в chroot пользователя и группу skype — при этом желательно, чтобы uid и gid совпадали с uid/gid основного пользователя реальной системы (в моем случае — rom), для чего набираем следующие команды:

После этого ставим свежескачанный Skype — опять же в chroot — и удовлетворяем его зависимости:

В основной системе разрешаем соединения с X-сервером с localhost и заходим в chroot как обычный пользователь:

Устанавливаем переменную DISPLAY (которую надо посмотреть в основной системе) и запускаем Skype:

Скайп успешно установлен и запущен в chroot-окружении.

Можно было бы написать скрипт для облегчения запуска, но это ты можешь сделать и сам.

Сравнение скорости компиляции на ext4 и на Btrfs

Использование Arkose

Arkose действует аналогично песочницам в Windows, таким, например, как Sandboxie. Практически это удобная обертка для контейнеров LXC. Но, как известно, удобство и гибкость порой несовместимы — тонкая настройка создаваемых контейнеров затруднительна. Из плюсов отмечу интуитивно понятный интерфейс (это если использовать GUI — впрочем, запуск из командной строки тоже очень прост), из минусов же — по умолчанию требует довольно много свободного места на жестком диске и имеются некоторые возможные пути обхода; но, если использовать Arkose как дополнительную обертку для потенциальных путей внедрения малвари (браузер) или даже просто для экспериментов с каким-нибудь интересным приложением, это никак не повредит.

Seccomp и seccomp-bpf

Очевидно, что это решение не очень гибкое. В связи с этим в ядре 3.5 появился seccomp-bpf, который позволяет с помощью правил BPF тонко настраивать, какие именно системные вызовы (и их аргументы) разрешены, а какие — нет. Seccomp-bpf применяется в Google Chrome, Chrome OS, а также бэкпортирован в Ubuntu 12.04.

Перед тем как использовать Arkose, его надо установить. Процедура стандартна:

Будет установлен как графический интерфейс (arkose-gui), так и утилита командной строки (arkose). Графический интерфейс настолько прост, что описывать его я смысла не вижу, лучше сразу перейдем к практике.

Ручное создание
read-only снапшо-
та в Btrfs

Опции командной строки рассмотрю:

-n — отображение сети на песочницу. Опции none и direct не требуют пояснения, filtered создает для каждой песочницы свой интерфейс. На практике же лучше использовать либо none, либо direct, поскольку filtered настраивать достаточно долго.
-d — доступ к шинам D-Bus из песочницы.
-s размер — устанавливает размер хранилища в мегабайтах. По умолчанию 2000 Мб для ext4 или половина памяти для tmpfs. После завершения работы запускаемой в песочнице программы хранилище уничтожается.
-t [ext4,tmpfs] — тип файловой системы хранилища. По дефолту используется ext4.
--root каталог — указывает каталог, который отображается на песочницу в качестве корня.
--root-type — как именно отображать корень. Если использовать cow, то любые изменения после закрытия песочницы пропадут, а если bind — сохранятся.
--base-path — указывает место хранения песочницы. По умолчанию это ~/.arkose.
--bind каталог и --cow каталог — отображает каталог либо в режиме cow, либо напрямую. Естественно, использование той или иной опции зависит от типа отображения корня — использовать опцию --cow на каталоге, который и так уже copy-on-write, не имеет смысла.
-h — использовать реальный домашний каталог. Действует аналогично --bind $HOME.
-p — разрешает использовать PulseAudio.

Для примера запустим Firefox:

Данная команда запустит Firefox с доступом к сети и к PulseAudio. Поскольку для каждого вновь создаваемого контейнера по умолчанию создается свой домашний каталог, то и профиль огнелиса будет новый, без установленных дополнений, если таковые у тебя имеются.

Добавление пользователя для запуска Skype в chroot

Кратко о BTRFS

Копирование при записи (Copy-on-Write). Эта технология служит для создания снапшотов — мгновенных снимков состояния системы. При создании снапшота драйвер ФС копирует в него метаданные и начинает мониторить фактическую запись. Если она обнаруживается, в снапшот помещаются оригинальные блоки данных, а на их место записываются новые.
Динамическое выделение инодfов. В отличие от ФС старого поколения, в Btrfs нет ограничения на количество файлов.
Сжатие файлов.
Возможность размещения ФС на нескольких физических носителях. Фактически это тот же самый RAID, только более высокоуровневый. На момент написания статьи поддерживались RAID 0, RAID 1 и RAID 10, поддержка же RAID 5 находилась на ранней стадии разработки.

Откат на снапшот Btrfs

Создание и удаление снапшотов

Для совершения операций над ФС нового поколения, таких, например, как создание снапшотов, дефрагментация тома и многих других, служит команда btrfs. Синтаксис у нее, в общем случае, следующий:

Какие же именно операции можно производить над Btrfs? Ниже будут приведены команды, которые мне показались интересными.

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

Снапшот создан. Опцию -r я рекомендую использовать для пущей безопасности — теперь файлы из него можно удалить, только удалив снапшот целиком:

Подтома Btrfs

Подтом Btrfs может выступать в двух ипостасях: как директория и как объект VFS — то, что может быть примонтировано. Например, при установке Ubuntu создается два подтома — @ и @home. Первый содержит системные файлы, второй — данные пользователя. Это похоже на разбиение диска на разделы, только если раньше один раздел мог содержать, как правило, лишь один объект VFS, то теперь на одном разделе могут быть сразу несколько объектов, при этом они могут быть вложенными.

Автоматизация

Создавать снапшоты ручками я не вижу большого смысла — можно банально забыть это сделать. Напрашиваются три сценария автоматизации:

написать скрипт и поместить его в rc.local;
написать скрипт и поместить его в cron;
использовать команду btrfs autosnap.

К сожалению, в Ubuntu 12.10 последний метод по каким-то причинам недоступен, так что выбора, как такового, практически нет. Лично я предпочел написать скрипт для крона, но сначала давай создадим подтом, в котором и будут храниться наши снапшоты. Для чего? Хотя бы для того, чтобы не засорять корневую папку.

Рассмотрим, что делают эти команды. Поскольку фактический корень ФС в данный момент недоступен (вместо него в убунте в качестве корня используется подтом @), мы вынуждены подмонтировать его ручками. В моем случае он находится на /dev/sda11. Третьей командой мы создаем подтом @snapshots — таким образом, если мы не подмонтируем его или реальный корень, его содержимое будет недоступно. А теперь собственно скрипт:

Скрипт этот можно разместить, где удобно (лично я предпочитаю подобные вещи размещать в /usr/local/bin, но это дело вкуса), и запускать его либо из крона, либо из rc.local. По умолчанию скрипт ротирует снапшоты старше одного дня, но ты можешь задать любое желаемое количество в формате команды date — главное, не забудь заключить в кавычки.

Использование ISO-образа

Для того чтобы при повреждении каких-либо жизненно важных файлов не дергать каждый раз болванку с записанной убунтой, есть возможность в меню Grub добавить пункт загрузки с ISO-образа, что я и предлагаю сделать. Для этого понадобится не-Btrfs-раздел (поскольку по неизвестным причинам стандартная initramfs убунтовской исошки не желает видеть образ, если он находится на разделе с описываемой ФС) и прямые руки. Добавляем в файл /etc/grub.d/40_custom следующие строчки:

и запускаем команду обновления основного конфига Grub:

Теперь даже в случае серьезного повреждения системы — если, конечно, не будет затронут загрузчик и его файлы — ты всегда сможешь загрузиться с ISO-образа и изменить поврежденные файлы или откатиться на предыдущее состояние системы.

Редактируем конфиг Grub'а

Если ты работаешь в chroot-окружении под root, то есть возможность оттуда вырваться. Один из способов — использование системного вызова mknod() с последующим монтированием реального корня. Установка патчсета grsecurity позволяет решить эту проблему.

Итак, предположим, ты уронил систему и тебе необходимо ее восстановить из снапшота Btrfs. Для этого загрузись с данного ISO-образа, примонтируй тот раздел, систему на котором ты уронил, — именно раздел, не подтом! — и введи следующие команды (естественно, с поправкой на твои снапшоты и разделы):

То же самое, при необходимости, делаем с @home и перезагружаемся. Если все прошло нормально, то можешь удалить @_badroot:

. — пример запуска демона в chroot-окружении. Несколько устарело, однако общие принципы остались те же.

Заключение

В *nix-системах есть множество способов обезопасить себя от неудачных экспериментов или смягчить их последствия. Я рассмотрел некоторые из них. Однако стоит заметить, что все эти способы предназначены в основном для экспериментаторов, любящих поковыряться в системе. Для отлова малвари они не подходят — их достаточно легко обнаружить, хотя некоторый уровень безопасности они, конечно же, обеспечивают.

Со snapper-ом вроде получилось… а вот btrfs subvolume snapshot… ни в какую. Может не правильно делаю…
напомню необходимо сделать снапшот корня (subvolume @)
делаю так:
btrfs subvolume snapshot @ ~/snapshots
ERROR: cannot access subvolume @: No such file or directory

/ в данном случае точка монтирования твоего @, /blablabla — путь к будущему снапшоту.

ATWA я и так и сяк пробовал… результат:

btrfs subvolume snapshot / ~/snapshots
ERROR: invalid snapshot name '/'

btrfs subvolume list /
ID 257 gen 1909 top level 5 path @
ID 259 gen 16 top level 257 path var/lib/machines
ID 268 gen 1896 top level 257 path .snapshots
ID 269 gen 1685 top level 268 path .snapshots/1/snapshot
ID 270 gen 1693 top level 268 path .snapshots/2/snapshot
ID 271 gen 1697 top level 257 path root/snapshots
ID 272 gen 1760 top level 268 path .snapshots/3/snapshot
ID 273 gen 1810 top level 268 path .snapshots/4/snapshot
ID 274 gen 1855 top level 268 path .snapshots/5/snapshot
ID 275 gen 1895 top level 268 path .snapshots/6/snapshot

mount -t btrfs
/dev/sdb6 on / type btrfs (rw,noatime,compress=lzo,ssd_spread,discard,
space_cache,autodefrag,subvolid=257,subvol=/@)
/dev/sdb7 on /home type btrfs (rw,noatime,compress=lzo,ssd_spread,discard,
space_cache,autodefrag,subvolid=5,subvol=/)

/ у тебя на sdb6, /home (а с ним и ~/) у тебя на другом разделе (!) — sdb7. В этом косяк.
Зачем тебе btrfs на двух разделах, если можно и нужно использовать subvolumes?

В статье в краткой форме описано как можно откатить операционную систему на базе Linux к рабочему состоянию. Например после неудачного обновления. Стоит заметить — файловая система у нас Btrfs. А для бекапа мы используем пакет apt-btrfs-snapshot, который создает снимок системы.

Установлена Ubuntu 12.10 на /dev/sda1 без отдельных разделов /boot.

Заходим под администратором:

Проверяем его работоспособность:

В ответ должны получить — Supported.

Давайте сделаем что нибудь с apt-get чтобы проверить откат:

В процессе вы увидите, что apt-btrfs-snapshot сделал автоматический снимок системы (called @apt-snapshot-yyyy-mm-dd_time). Однако можно проверить:

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

Монтируем файловую систему Btrfs в отдельную папку, например /mnt:

Теперь можно проверить:

@apt-snapshot это снимок рабочей корневой файловой системы (@). Для того чтобы сделать загрузку системы с снимка, а не из текущего корня, нужно переименовать @ на что-то другое, а затем @apt-snapshot переименовать на @:

Удаление неудачного корневого каталога:

Комментариум ( 16 )

По правде я не вижу смысла во всех этих снапшотах. Просто так система у меня ещё ни разу не падала, ну а для экспериментов можно на крайняк и слепок системы командой dd сделать. Ничего против BtrFS не имею, просто она все еще сырая и подающая немалые надежды. Имел ввиду, что ставить на неё систему в действующем состоянии разработки BtrFS нецелесообразно. Сам использую бтр на /home разделах и файлопомойках=) Хотя больше всего интересует zfs и када её портируют в линух.

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

А чем снимок через dd хуже? Ну про апгрейд я промолчу, на каждой машине по три оськи и перетусовываются они частенько. Апгрейд для меня нечто нецензурное=)) Стабильными завсегда остаются только хомяк и помойка=))

Читайте также: