Я как гик, всё ещё имею привычки, постоянно эксперементировать с системой: пересобирать, ставить несталбильные 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, но мне не нужен дополнительный слой абстракции от железа и выносить снимки на отдельный раздел, тоже не комильфо.
Автор: nefelim4ag
