«Отказоустойчивая» система на базе 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 ^[1]
Теперь «почти» самое важное, генерируем заново конфиг:

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 структурах, но для мелкого домашнего использовани должна подойти идеальна.

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

Автор: nefelim4ag

Источник ^[2]