Pull to refresh

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

Reading time5 min
Views41K
Я как гик, всё ещё имею привычки, постоянно эксперементировать с системой: пересобирать, ставить несталбильные 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, поправил скрипты, чтобы избежать возможных ошибок.
Tags:
Hubs:
+7
Comments31

Articles