November 29, 2012 at 12:46 "Fault-tolerant" system based on Ubuntu and btrfs
As a geek, I still have the habit of constantly experimenting with the system: rebuild, install unstable RC kernels, enable experimental update branches. Often, I would say breaking the system too often (my personal record, 2 weeks without reinstalling).
What do you mean breaking? When something works extremely badly, for example, often LibreOffice and Compiz crashes, which likes to hang, I try to reconfigure the system, but it's long and boring.
Actually, what am I leading to.
If someone like me likes to experiment with the system and is tired of restoring it every time, then here is an option for me as I solved this problem for myself. I walk under the cat.
how-to or another bike.
Post factum, we assume that the disk is divided into 2 partitions: / boot formatted in ext4 and / formatted in btrfs.
Grub 2 is written on the MBR disk.
Accordingly, the first point:
From personal habits and considerations, it is much easier to restore the system from the graphical interface than to admire a black screen and sometimes without access to the Internet, remember and write down commands. No, I don’t think that the console is evil, I love the console, but anyway, it’s more pleasant from the GUI.
The idea is not new, I admit it somewhere figured on the hub, but I did not find the link, therefore I apologize to the source of the publication.
We copy the image of the desired Live distro to the / boot
/ boot folder on a separate partition, not because it’s better, but because for reasons unknown to me, LiveCDs written to btrfs from under grub 2 are not loaded.
Now we correct the default grub 2 settings so that when updating grub'a, do not lose the image.
and insert something similar there, after the comments:
Actually, in the image and likeness, I set up (the official wiki ubuntu):
/ Grub2 / ISOBoot
Now the "almost" most important thing is to generate the config again:
Everything, now after restarting holding the shift key, we can start the mini-system with the Internet and a graphical interface, regardless state of the main system.
I think that any person who has been familiar with Linux for a long time has at least heard of btrfs, perhaps even having already formed their own opinion. When installing ubuntu on a partition with btrfs, it is very wise by default, the sub-partition mechanism is used, and 2 sub-partitions are created, these are @ and home (which replace / and / home), respectively, when we reinstall the system, we won’t lose the configs. But now is not about that. How to use this care for end users? Very simple.
A little background:
Initially, it was planned to execute the script through rc.local, but it was not executed, then it was implemented through cron daily, later I defeated rc.local and to hell disabled snapshots in cron.
Script code:
It is located at / etc / btrfs_snapshot_onstartup
Add it to /etc/rc.local and give execute rights to both files, via sudo chmod + x 'path to file'
May not log execution execution to the file ./snapshots/snapshots.log, Then you need to create it manually under root rights. After the reboot, he himself will receive the necessary rights.
At any time, we can view the status of snapshots of the system by typing:
cat /var/log/snapshots.log
All snapshots are added to the system section in the snapshots folder, where a folder is created for each successful system startup.
Some may say that it does not pay off, creating snapshots during startup. Far from it, it 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 return to the moment of a successful (actual) launch, but only one day ago.
Option to start manually:
So, for the sake of what they tried, they killed the system, what should I do?
We boot from the LiveCD, mount the system partition into a folder convenient for us.
Then, if necessary, hide or delete the standard subwolves @ and home .
and replace with the missing snapshot.
In most cases, replacing @ is enough.
nazarpc
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 automatically cleaning folders with snapshots. This deletes all system snapshots.
We have made a relatively fault-tolerant system in which we are able to quickly restore the system after a failure. At the same time spending a minimum of time and effort to build a protective system.
I think that such a solution is unlikely to be useful in large IT structures, but it should be ideal for small home use.
It would also be cool to finish the cleanup script so that it clears all snapshots older than, for example, weeks, and not all available ones, I honestly tried, but it didn’t work out for me. Then it could also be driven, for example, into 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 capabilities of btrfs.
Yes, I know lvm, but I don’t need an additional layer of abstraction from iron and taking pictures to a separate section is also not comme il faut.
UPD 1:
Thanks to users of warsoul and kraleksandr, for help in fixing errors.
UPD 2: The
benefit of the user nuit , corrected scripts to avoid possible errors.
What do you mean breaking? When something works extremely badly, for example, often LibreOffice and Compiz crashes, which likes to hang, I try to reconfigure the system, but it's long and boring.
Actually, what am I leading to.
If someone like me likes to experiment with the system and is tired of restoring it every time, then here is an option for me as I solved this problem for myself. I walk under the cat.
Item 1: LiveCD
Post factum, we assume that the disk is divided into 2 partitions: / boot formatted in ext4 and / formatted in btrfs.
Grub 2 is written on the MBR disk.
Accordingly, the first point:
From personal habits and considerations, it is much easier to restore the system from the graphical interface than to admire a black screen and sometimes without access to the Internet, remember and write down commands. No, I don’t think that the console is evil, I love the console, but anyway, it’s more pleasant from the GUI.
Action one
The idea is not new, I admit it somewhere figured on the hub, but I did not find the link, therefore I apologize to the source of the publication.
We copy the image of the desired Live distro to the / boot
sudo cp /media/timofey/boot/grub/ISO/Linux/Ubuntu/ubuntu-12.10-desktop-amd64.iso /boot/ubuntu-12.10-desktop-amd64.iso/ boot folder on a separate partition, not because it’s better, but because for reasons unknown to me, LiveCDs written to btrfs from under grub 2 are not loaded.
Now we correct the default grub 2 settings so that when updating grub'a, do not lose the image.
sudo nano /etc/grub.d/40_customand 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, in the image and likeness, I set up (the official wiki ubuntu):
/ Grub2 / ISOBoot
Now the "almost" most important thing is to generate the config again:
sudo update-grubEverything, now after restarting holding the shift key, we can start the mini-system with the Internet and a graphical interface, regardless state of the main system.
Item 2: Pictures
I think that any person who has been familiar with Linux for a long time has at least heard of btrfs, perhaps even having already formed their own opinion. When installing ubuntu on a partition with btrfs, it is very wise by default, the sub-partition mechanism is used, and 2 sub-partitions are created, these are @ and home (which replace / and / home), respectively, when we reinstall the system, we won’t lose the configs. But now is not about that. How to use this care for end users? Very simple.
A little background:
Initially, it was planned to execute the script through rc.local, but it was not executed, then it was implemented through cron daily, later I defeated rc.local and to hell disabled 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 give execute rights to both files, via sudo chmod + x 'path to file'
May not log execution execution to the file ./snapshots/snapshots.log, Then you need to create it manually under root rights. After the reboot, he himself will receive the necessary rights.
At any time, we can view the status of snapshots of the system by typing:
cat /var/log/snapshots.log
All snapshots are added to the system section in the snapshots folder, where a folder is created for each successful system startup.
Some may say that it does not pay off, creating snapshots during startup. Far from it, it 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 return to the moment of a successful (actual) launch, but only one day ago.
Option to start manually:
#!/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 should I do?
We boot from the LiveCD, mount the system partition into a folder convenient for us.
Then, if necessary, hide or delete the standard subwolves @ and home .
and replace with the missing snapshot.
In most cases, replacing @ is enough.
nazarpc
Also snapshots allow not only to roll back to a certain state of the system, but also to extract 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 automatically cleaning folders with snapshots. This deletes 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 have made a relatively fault-tolerant system in which we are able to quickly restore the system after a failure. At the same time spending a minimum of time and effort to build a protective system.
My own thoughts about this
I think that such a solution is unlikely to be useful in large IT structures, but it should be ideal for small home use.
It would also be cool to finish the cleanup script so that it clears all snapshots older than, for example, weeks, and not all available ones, I honestly tried, but it didn’t work out for me. Then it could also be driven, for example, into 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 capabilities of btrfs.
Yes, I know lvm, but I don’t need an additional layer of abstraction from iron and taking pictures to a separate section is also not comme il faut.
UPD 1:
Thanks to users of warsoul and kraleksandr, for help in fixing errors.
UPD 2: The
benefit of the user nuit , corrected scripts to avoid possible errors.