«Отказоустойчивая» система на базе 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/sh #This script for autocreating snapshot DATA=$(date +%g%m%d%k%M%S) ################################## if [ ! -d /tmp/system/ ]   then   mkdir /tmp/system/  else if [ ! -d /tmp/system/snapshots/ ]         then          mkdir /tmp/system/snapshots/        fi fi  mount /dev/sda2 /tmp/system/  #################################################################### mkdir /tmp/system/snapshots/$DATA/ cd /tmp/system/  btrfs subvolume snapshot ./@       ./snapshots/$DATA/@_${DATA}/ btrfs subvolume snapshot ./@home   ./snapshots/$DATA/@home_${DATA}/ #################################################################### chmod 777 ./snapshots/snapshots.log echo successful_launch_$(date +%X_%x) >> ./snapshots/snapshots.log cp ./snapshots/snapshots.log /var/log/snapshots.log   sleep 2 umount /tmp/system/ && sudo rmdir /tmp/system/ #################################################################### exit 0 

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

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

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

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

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

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

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

#!/bin/bash #This is script to autocreate backups to external HDD #откуда if [ ! -d /tmp/system ]  then sudo mkdir /tmp/system fi sudo mount /dev/sda2 /tmp/system  cd /tmp/system/snapshots/   for i in */*   do    sudo btrfs subvolume delete $i   done   for i in *   do    sudo rmdir -v $i   done   echo cleanup $(date +%s=%X_%x) > '/tmp/system/snapshots/snapshots.log'  sudo cp '/tmp/system/snapshots/snapshots.log' '/var/log/snapshots.log'  sleep 1  sudo umount -l /tmp/system && sudo rmdir /tmp/system  read exit 0 

Итог

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

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

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

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

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