«Отказоустойчивая» система на базе Ubuntu и btrfs

Я как гик, всё ещё имею привычки, постоянно эксперементировать с системой: пересобирать, ставить несталбильные RC ядра, включать experimental ветки обновлений. Часто, я бы даже сказал слишком часто ломаю систему (мой личный рекорд, 2 недели без переустановки).

Что значит ломаю? Когда что-то работает крайне нехорошо, например часто вылетающий LibreOffice и Compiz который любит подвисать, я или пытаюсь реконфигурировать систему, но это достаточно долго и муторно.

Собственно, к чему я веду.

Если кто-то так же как я, любит эксперементировать с системой и её надоело каждый раз восстанавливать, то вот вам вариант как я решил эту проблему для себя. Проошу под кат.


how-to или очередной велосипед.

Пункт 1: LiveCD


Пост фактум, мы исходим из того что диск разбит на 2 раздела: /boot отформатированный в ext4 и / отформатированный в btrfs.
На диске в MBR записан grub 2.
Соответственно, первый пункт:
Из личных привычек и соображений, намного проще восстановить систему из графического интерфейса, чем любоваться чёрным экраном и порой без доступа к интернету, вспоминать и прописывать команды. Нет, я не считаю что консоль зло, я люблю консоль, но так или иначе, а из графического интерфейса приятнее.

Действие первое

Идея не нова, признаюсь она где-то фигурировала на хабре, но ссылку я не нашёл, потому прошу прощения у источника публикации.
Копируем образ нужного Live дистра в папку /boot
sudo cp /media/timofey/boot/grub/ISO/Linux/Ubuntu/ubuntu-12.10-desktop-amd64.iso /boot/ubuntu-12.10-desktop-amd64.iso
/boot вынесен на отдельный раздел, не потому что так лучше, а потому что по неизвестным мне причинам, LiveCD записанные на btrfs из под grub 2 не загружаются.
Теперь поправляем настройки grub 2 по умолчанию, чтобы при обновлении grub'a, не терять образ.
sudo nano /etc/grub.d/40_custom

и вставляем туда нечто подобное, после комментариев:
menuentry "Ubuntu 12.10 amd64" {
 set isofile=/ubuntu-12.10-desktop-amd64.iso
 loopback loop $isofile
 linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noeject noprompt --
 initrd (loop)/casper/initrd.lz
}


Собственно по образу и подобию настраивалось (официальная wiki ubuntu):
/Grub2/ISOBoot
Теперь «почти» самое важное, генерируем заново конфиг:

sudo update-grub

Всё, теперь после перезагрузки зажав клавишу shift, мы сможем запустить мини систему с интернетом и графическим интерфейсом, не зависимо от состояния основной системы.

Пункт 2: Снимки


Я думаю, любой достаточно давно знакомый с Linux человек как минимум слышал о btrfs, возможно даже, что уже составил своё собтвенное мнение. При установке ubuntu на раздел с btrfs по умолчанию делается очень мудро, используется механизм сабразделов, и создаются 2 саб раздела это @ и home (которые заменяю / и /home), соответственно при граматной переустановке системы, конфиги мы не потеряем. Но сейчас не об этом. Как же использовать эту заботу о конечных пользователях? Очень просто.

Немного предыстории:
Изначально планировалось выполнять скрипт через rc.local, но он не выполнялся, потом было реализовано через cron ежедневное, позже я победил rc.local и к чертям отключил снапшоты в cron.


Код скрипта:

#!/bin/bash
#This script for autocreating snapshot on startup
#Version 1.2.9
set -e
DATA="$(date +%g%m%d%k%M%S)"
VOLUME=/dev/sda1
[ ! -d "/tmp/$DATA/" ] && sudo mkdir "/tmp/$DATA/"
mount $VOLUME "/tmp/$DATA/" && {
[ ! -d "/tmp/$DATA/snapshots/" ] && sudo mkdir "/tmp/$DATA/snapshots/"
mkdir "/tmp/$DATA/snapshots/$DATA/" && cd "/tmp/$DATA/"
btrfs subvolume snapshot ./@       ."/snapshots/$DATA/@_${DATA}/"
btrfs subvolume snapshot ./@home   ."/snapshots/$DATA/@home_${DATA}/"
[ ! -f ./snapshots/snapshots.log ] && touch ./snapshots/snapshots.log
chmod 777 ./snapshots/snapshots.log
echo on_startup_$(date +%X_%x) >> ./snapshots/snapshots.log
umount -l "/tmp/$DATA/" && sudo rmdir "/tmp/$DATA/"
}


Расположен он по адресу /etc/btrfs_snapshot_onstartup
Добавляем его в /etc/rc.local и даём права на исполнение обоим файлам, через sudo chmod +x 'путь к файлу'
Может не заработать логирование выполнения в файл ./snapshots/snapshots.log, тогда нужно создать его вручную под правами рут. После перезагрузки он сам получит нужные права.

В любой момент мы можем просмотреть состояние снимков системы набрав:
cat /var/log/snapshots.log

Все снимки складываются в раздел с системой в папку snapshots, где создаётся папка каждого успешного запуска системы.
Некоторые могут сказать, что не оправдывает себя, создание снапшотов во время запуска. Отнюдь, оправдывает, за сутки я могу внести кучу изменений в систему и сотню раз её перезапустить и в альтернативных случаях я не смогу вернуться к моменту успешного запуска (актуального), а только однодневной давности.

Вариант, запуска вручную:
#!/bin/bash
#This script for autocreating snapshot
#Version 1.2.8
set -e
DATA=$(date +%g%m%d%k%M%S)
##################################
[ ! -d /tmp/$DATA/ ] && sudo mkdir /tmp/$DATA/ 
sudo mount /dev/sda2 /tmp/$DATA/ && {
####################################################################
[ ! -d /tmp/$DATA/snapshots/ ] && mkdir /tmp/$DATA/snapshots/ 
mkdir /tmp/$DATA/snapshots/$DATA/
cd /tmp/$DATA/

sudo btrfs subvolume snapshot ./@       ./snapshots/$DATA/@_${DATA}/
sudo btrfs subvolume snapshot ./@home   ./snapshots/$DATA/@home_${DATA}/
####################################################################
sudo chmod 777 ./snapshots/snapshots.log
sudo echo this.hands_$(date +%X_%x) >> ./snapshots/snapshots.log
sudo cat ./snapshots/snapshots.log
sleep 1
sudo umount -l /tmp/$DATA/ && sudo rmdir /tmp/$DATA/
####################################################################

sudo btrfs filesystem df / #information about fs
}
read
exit 0


Пункт 3: Восстановление


Вот, ради чего и старались, убили систему, что делать?
Загружаемся с LiveCD, подмонтируем системный раздел, в удобную для нас папку.
Затем по необходимости прячем или удаляем стандартные сабволумы @ и home.
и заменяем, недостающей нужным снапшотом.
В большинстве случаев, достаточно заменить @.
nazarpc
Так же снапшоты позволяют не только откатиться на определённое состояние системы, но и вытащить из него нужный файл или конфиг, что так же даёт некоторую свободу при удалении файлов непонятного происхождения.


Пункт 4: Чистка


Снапшоты занимают не много места, но со временем на диске может скопиться из-за них большой объём мусора. Вот скрипт для автоматической очистки папок с снапшотами. Это удаляет все снимки системы

#!/bin/bash
#Version 0.0.9
set -e
DATA=$(date +%g%m%d%k%M%S)
[ ! -d "/tmp/$DATA" ] && sudo mkdir "/tmp/$DATA"
sudo mount /dev/sda1 "/tmp/$DATA" && 
{
cd "/tmp/$DATA/snapshots/"
 for i in */*
  do
   sudo btrfs subvolume delete "$i"
  done
 for i in *
  do
   sudo rmdir -v "$i"
  done
echo cleanup_$(date +%g%m%d%k%M%S) > "./snapshots.log"
sudo cp "./snapshots.log" '/var/log/snapshots.log'
sudo umount -l "/tmp/$DATA" && sudo rmdir "/tmp/$DATA"
}
read
exit 0


Итог


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

Мои собственные мысли по этому поводу

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

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

Да я знаю lvm, но мне не нужен дополнительный слой абстракции от железа и выносить снимки на отдельный раздел, тоже не комильфо.


UPD 1:
Спасибо пользователям warsoul и kraleksandr, за помощь в исправлении ошибок.
UPD 2:
Благо пользователю nuit, поправил скрипты, чтобы избежать возможных ошибок.

Похожие публикации

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 31

    +11
    btrfs

    Отказоустойчивая


    Смешно.
      0
      А что не так? То что она альфа, ещё не означает что она неюзабельна.
      Если на то пошло, можно пальцем ткнуть в недавнюю ошибку в коде ядра и ext4 из-за которой, она в определённых ситуациях сжирала данные.
        0
        А можно пальцем ткнуть в давнишнее письмо Эдика Шишкина в lkml, где он на пальцах расписывает, почему btrfs — defective by design и не взлетит.
          0
          И там же Крис расписал вариант решения проблемы и говорит о фиксе. А как там у Эдика Шишкина дела с reiser4? Что-то после многих текстов о превосходстве reiser4 и обещаний интеграции в mainline давно ничего не слышно.
            +1
            Спасибо, я отлично помню это сообщение. Но в данный момент, я не вижу под linux ни одной замены поставляемой нативно.
            Да есть Reiser4. Она умеет упаковывать мелкие данные данные в большой блок, это огромный плюс. Так же её не обделили модульностью и возможностью включения прозрачного сжатия.
            Но её некому поддерживать и насколько я понимаю, для её использования мне нужно прикручивать старое ядро и накладывать патчи.
            ZFS, о ней я знаю намного меньше, но насколько я помню, там механизмы снапшотов реализованы совершенно иначе. Насколько я помню, она разрабатывалась под Solaris, т.е. её тоже надо прикручивать. Хотя почитав wiki, выяснил что делается это установкой её из репозитория.

            Я с удовольствием сменю btrfs, на другую файловую систему, если в ней будут:
            1. Сжатие данных.
            2. CoW
            3. Выравнивание износа ячеек ssd, как на btrfs, например с ключём монтирования ssd_spread.
            4. Упаковка мелких файлов в tails, хотя насколько я помню, она ещё не реализована.
            5. Снапшоты и сабволумы, т.к. с ними намного удобней оперировать, чем с разделами на диске.

            Я хочу сказать, что я не против других файловых систем, просто пока я не вижу альтернативы и буду очень признателен если мне её покажут.
              0
              С таким списком требований, а особенно
              Снапшоты и сабволумы
              … только zfs (вроде есть нативный модуль ядра для неё). Хотя чёрт её знает, как zfs на ssd будет себя вести.
                0
                Кхм. ZFS подходит, только по одному пункту, остальные же:
                прозрачное сжатие к ней можно прикрутить.
                CoW только подобие, при постоянном создании снапшотов, т.к. старые данные, не будут перезаписываться.
                Выравнивания износа нету, упаковки мелких файлов нету.

                У ZFS нету квот как в btrfs и ntfs (мне не принципиально, но факт), которые или в 3.6 или в 3.7 реализуют в btrfs.
                Переменный размер блоков это добро, его очень часто не хватает, но учитывая экценты в btrfs, размер блоков не имеет большого значения.

                Из письма шишкина, кстати, ясно только то, что ему не нравиться дизайн, файловой системы. Точнее то что в ней под всё есть «Дерево», даже под логи, метаданные и кеш суммы (отдельное под данные). (Да на практике какой-то куст).
                Как я понял, то по каким то причинам, дерево ещё у btrfs любит перестраиваться, это похоже и есть её дырка в отказоустойчивости. Но если включёны снапшоты, то повреждённое дерево оно восстанавливает из них.
                Проблема при работе с большим количеством мелких файлов. Да, есть такая проблема, btrfs искажает данные о свободной памяти и не эффективно использует место при большом количестве мелких файлов.
                НО, господин Шишкин, я не видел другой FS с tail packing, кроме reizer, не одна не умеет потенциально удачно с ними работать, кроме Raiser4.

                Вообще надо понимать, что btrfs с Reiser4, сравнивать не корректно, в виду того, что единственное что их объединяет это B-trees. Остальное у них различно. Raiser, работает с диском. Btrfs работает с размеченными чанками. Как следствие даже не пытается использовать размеченные под её террабайты, пока чанк не заполняться информацией и не будет создан новый чанк и так до забивания раздела под завязку.

                Извините, если получилось агрессивно и сумбурно. Я просто сам путаюсь уже во всех этих тонкостях.
                  0
                  Из письма шишкина, кстати, ясно только то, что ему не нравиться дизайн, файловой системы.
                  Он, как я понял, упирает на то, что B-trees работают так, как задумывалось, с приемлемыми аналитически посчитанными вычислительными сложностями операций, если у них листы постоянного размера, а разработчики btrfs ничтоже сумняшеся запихали туда информацию переменного размера (те самые inline extents), и поэтому оно работает совсем не так, как должно.

                  я не видел другой FS с tail packing, кроме reizer, не одна не умеет потенциально удачно с ними работать, кроме Raiser4.
                  Reiser3 вроде как умеет. На своём опыте: gentoo'вский portage с portage tree, размещённым на reiser3, шевелится в разы быстрее, чем на ext.

                  Извините, если получилось агрессивно и сумбурно. Я просто сам путаюсь уже во всех этих тонкостях.
                  Да нормально. Мне тоже хочется, чтобы всё и сразу, но так не бывает, вот и сижу на дефолтной ext4.
                    0
                    Ext4 является чем то средним, в этом её большой жирный плюс.
                  0
                  Я очень хочу узнать, почему вы хотите выравнивать износ на ssd-дисках вместо прошивки ssd диска. Вы думаете, btrfs с этим справится лучше?
                    0
                    Да я думаю btrfs справиться с этим лучше, я примерно представляю как она работает, пусть и не уверен что правильно.
                    Прошивка стоит официальная и последняя, но как работает она я смутно предполагаю. Если она работает хорошо, то btrfs, со своей принудительной фрагментацией и принудительной записью только в не использованные ранее блоки ничем ей не помешает.
                      0
                      Помешать не помешает, а производительность уронит. Практически все ssd, кроме совсем топовых (типа 900ой серии интела) очень не любят произвольную запись мелкими блоками.
                        0
                        А как же принудительный write cache?
                          0
                          Мы про производительность записи на SSD в зависимости от того, линейно или рандомно на неё пишет файловая система, или про производительность фс?
                            0
                            ssd учитывая почти нулевую задержку и write cache с редко сбрасываемыми, но объёмными «грязными» данными, получается не будет работать с постоянными мелкими запросами, разве не так?
                            Насколько я помню, у них производительность при совсем случайной записи в больших объёмах падает раза в 2, но разница между 500 и 300 Мб/с на десктопе или ноуте не должна быть заметна.
                0
                Я как-то в режиме broad search поднял btrfs для cephs. Оно прожило примерно 10 минут, после чего снесло нафиг ядро из-за ошибки где-то в недрах btrfs. Ничего особенного, просто random io.
              +1
              find /tmp/system/snapshots/ -mtime +7 -delete
              

              Удалит файлы, которым больше 7 дней.
                0
                Спасибо, но не выйдет. Я же удаляю не бекапы, а так называемые subvolume.
                0
                  0
                  При чём тут /var/tmp?
                  Если вы по поводу логов, то не вижу смысла, он заново копируется из раздела, перед отмонтированием, если про автоматическое монтирование, отмонтирование, то в любом случае, папка создаётся и удаляется в процессе загрузки.
                  Что вы предлагаете хранить между перезагрузками?
                    0
                    Да, тут уже неважно где и что создаётся :) Обо всём говорит качество самого скрипта.

                    if [ ! -d /tmp/system/ ] 
                     then
                      mkdir /tmp/system/
                     else if [ ! -d /tmp/system/snapshots/ ] 
                           then 
                            mkdir /tmp/system/snapshots/ 
                          fi
                    fi
                    

                    а если /tmp/system — это файл или сокет или что-то ещё, то мы всё равно будем пытаться создать какую-то директорию? И после того как не получится создать, попытаемся примонтировать туда девайс. И даже когда монтирование отвалится, то мы всё равно будем пытаться туда заснэпшотиться.
                    Ну и создание директории для снэпшотав тоже интересное :) На системе, где в /tmp никогда не будет выживать директория system, мы никогда не создадим директорию для снэпшотов.

                    mount /dev/sda2 /tmp/system/
                    

                    Предположим дошли до монтирования, но монтирование отвалилось, а мы всё равно настойчиво пытаемся сделать снэпшот. А на многих дистрах /tmp сейчас в tmpfs ;)

                    Вобщем какой-то неотказоустойчивый скрипт для отказоустойчивой системы :)
                      0
                      Да признаюсь, есть доля идиотизма. Но я лично не сталкивался с дистрами с /tmp, в tmpfs, хотя сам тоже монтирую tmp в оперативную память.
                      Фокус в том, что скрипт иногда не верно отрабатывал и если tmp, подмонтирована не в оперативку, то в результате, даже после перезагрузки папки system, могли оставаться.
                      Я сильно сомневаюсь что в /tmp будет сокет или файл, с таким именем. Но да, замечание справедливо, сейчас подумаю как исправить.
                        0
                        set -e
                        
                        [ ! -d /tmp/system ] && mkdir /tmp/system
                        mount /dev/sda /mnt/system
                        [ ! -d /tmp/system/snapshots ] && mkdir /tmp/system/snapshots
                        ...
                        
                  0
                  Вот только хотел сообразить статью на эту тему, тоже как-то посмотрел в сторону btrfs. Ещё была мысль сделать raid1 c разделом другого диска, btrfs позволяет это делать очень просто, тогда мы получаем и избыточность, и возможность делать откат системы. Беспроигрышный вариант.

                  К стати, неплохо было бы добавить в статью, что subvolume можно не только заменить, но и подмонтировать в любую папку, и достать несколько файлов из любого бекапа, не трогая текущее состояние ФС. По структуре хранения всё это напоминает мне git, но можно удалить коммиты.
                    0
                    По поводу RAID, тоже размышлял. Но в ноутбуке, такое достаточно трудно осуществимо.
                    Да, действительно можно было бы добавить, но учитывая энтропию имён снапшотов и папок к ним, это неудобно (открывать лог и вбивать в консоли длинный параметр монтирования) осуществимо без подмонтирования и просмотра раздела в целом.
                    А вот, по по поводу «и достать несколько файлов из любого бекапа, не трогая текущее состояние ФС.», упомяну. Так как это действительно легко осуществимо и я просто не сообразил, о таком раскладе событий.
                    0
                    UPD 2: ...

                    Ну не совсем и поправил :)
                    Воткни вначале set -e, чтобы при падении любой из команд всё останавливалось, а если вдруг нужно будет пропустить падение какой-либо из команд, то достаточно будет сделать command || /bin/true
                    Директорию со снэпшотами нужно создавать после монтирования.
                    И если делаешь скрипты для запуска вручную, то желатально ещё использовать Bash Traps и снимать монтирование итп в их обработчиках, тк Ctrl-C достаточно часто жмут.
                      0
                      Наверное, лучше всё-таки /home выделять на отдельный раздел, чем думать о нём при откатах
                        0
                        Когда у тебя ssd, при условии что я не параноик, хочется равномерного износа. Потому даже вынос boot, на отдельный раздел, это уже не равномерный износ. Представь что если вынести home?
                        Учитывая, то что все папки с постоянно изменяющимися и не важными файлами у меня в tmpfs, то система почти не пишет на ssd, но я то пишу, я же пользуюсь home, гугл хром, пишет почти ежесекундно, со скоростью 160 кб/с.

                        Вот такая вот противная «шляпа», а так да, home достаточно удобно выносить на отдельный раздел.
                        0
                        Все время ставлю btrfs и все время оно валит мне ядро. Сыровато.
                          0
                          Очень интересно, а чуть более развёрнуто?
                          Ни разу не возникало проблем, даже при установке /boot на btrfs.
                          (Да, груб 2 и он выдавал ошибку, но это он виноват, а не фс и это легко исправляется комментом 1 строки)
                            0
                            Мы экспериментируем с ceph на debian squeeze c ядром Linux 2.6.32-16-pve #1 SMP Fri Nov 9 11:42:51 CET 2012 x86_64 GNU/Linux. Это последний proxmox из коробки.

                            Там можно под ceph osd отдать raw device, заформаченый в btrfs. Когда мы так делаем, система в итоге колтрейсится и паникует.

                            Причем если выдать партицию на диске, то вроде все нормально. Проблема проявляется, когда /dev/sda, например, целиком делается btrfs и маунтится. Там что-то с btrfs check связано, который not taunted.

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое