"Failsafe" system based on Ubuntu and btrfs

As a geek, I still have the habits, constantly experimenting with the system: rebuild, install non-stable RC cores, include experimental update branches. Often, I would even say I break the system too often (my personal best, 2 weeks without reinstalling).

What does it mean to break? When something is working extremely badly, for example, the often departing LibreOffice and Compiz who likes to hang, I either try to reconfigure the system, but this is rather long and dreary.

Actually, what I'm doing.
')
If someone, like me, likes to experiment with the system and is tired of restoring it every time, here is an option for you how I solved this problem for myself. I go under the cat.

how-to or another bike.

Point 1: LiveCD

Post fact, we assume that the disk is divided into 2 sections: / boot formatted in ext4 and / formatted in btrfs.
The disk in the MBR is recorded as grub 2.
Accordingly, the first paragraph:
From personal habits and considerations, it is much easier to restore the system from the graphical interface than to admire the black screen and sometimes without access to the Internet, to remember and prescribe commands. No, I do not think that the console is evil, I love the console, but anyway, but from the graphical interface is more pleasant.

First act

The idea is not new, I admit it somewhere figured on the habr, but I did not find the link, because I apologize at the source of the publication.
Copy the image of the desired Live Distra to the / boot folder
sudo cp /media/timofey/boot/grub/ISO/Linux/Ubuntu/ubuntu-12.10-desktop-amd64.iso /boot/ubuntu-12.10-desktop-amd64.iso
/ boot is placed on a separate partition, not because it's better, but because for reasons unknown to me, the LiveCDs written to btrfs from under grub 2 are not loaded.
Now we correct the default settings of grub 2 so that when updating grub'a, not to lose the image.
sudo nano /etc/grub.d/40_custom

and insert something similar there, after the comments:

 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 } 

Actually, it was configured in the image and likeness (the official wiki ubuntu):
/ Grub2 / ISOBoot
Now “almost” the most important, we re-generate the config:

sudo update-grub

Everything, now after rebooting by holding the shift key, we can launch a mini system with the Internet and a graphical interface, regardless of the state of the main system.

Item 2: Snapshots

I think that any person who has been familiar with Linux for a long time has at least heard about btrfs, it is even possible that he has already compiled his own opinion. When installing ubuntu on a partition with btrfs, the default is very wise, the sub-partition mechanism is used, and 2 sub-sections are created @ and home (which replace / and / home), respectively, when we reinstall the system, we will not lose the configs. But now is not about that. How to use this concern for end users? Very simple.

A little background:
It was originally planned to execute the script via rc.local, but it was not executed, then it was implemented via cron daily, later I defeated rc.local and to hell turned off snapshots in cron.

Script code:

 #!/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/" } 

It is located at / etc / btrfs_snapshot_onstartup
Add it to /etc/rc.local and grant permissions to execute both files, via sudo chmod + x 'path to file'
It may not earn execution logging in the ./snapshots/snapshots.log file, then you need to create it manually under root rights. After the reboot, he himself will get the necessary rights.

At any time we can view the status of the system snapshots by typing:
cat /var/log/snapshots.log

All images are added to the system section in the snapshots folder, where a folder for each successful launch of the system is created.
Some may say that it does not justify itself, creating snapshots during launch. Not at all, justifies, in a day I can make a bunch of changes to the system and restart it a hundred times and in alternative cases I can’t go back to the moment of successful launch (actual), but only one day ago.

Manual start option:

 #!/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 

Item 3: Recovery

So, for the sake of what they tried, they killed the system, what to do?
Boot from the LiveCD, mount the system partition in a convenient folder for us.
Then, by necessity, we hide or delete the standard @ and home sub-volvoes.
and replace, missing the necessary snapshot.
In most cases, it suffices to replace @.
nazarpc

Also snapshots allow not only to roll back to a certain state of the system, but also to pull out the necessary file or config from it, which also gives some freedom when deleting files of unknown origin.

Item 4: Cleaning

Snapshots do not take up much space, but over time a large amount of garbage can accumulate on the disk due to them. Here is a script for automatic cleaning of folders with snapshots. This removes all system snapshots.

 #!/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 

Total

We made a relatively fault-tolerant system in which we have the ability to quickly recover the system after a failure. At the same time spending a minimum of time and effort to build a protective system.

My own thoughts on this

I think that such a decision is unlikely to be useful in large IT structures, but it should be ideal for small-scale home use.

Also, it would be cool to finish the cleaning script so that it clears all the snapshots older, for example, weeks, and not all available ones, I honestly tried, but it never worked out for me. Then it could also be driven, for example, in cron by default, to run once a day, and then included in the official installation script on btrfs, I think with small modifications, this is a fairly universal solution, based on the standard btrfs capabilities.

Yes, I know lvm, but I do not need an extra layer of abstraction from iron and take pictures to a separate section, also not comme il faut.

UPD 1:
Thanks to the users of warsoul and kraleksandr , for help in correcting errors.
UPD 2:
Benefit user nuit , corrected scripts to avoid possible errors.