btrfs(sometimes pronounced butter fs) is a new free file system being developed with support from Oracle. Distributed under the GPL license. Despite the fact that its development is still far from complete, on January 9, 2009, the file system was integrated into Linux kernel, and is available in Debian Squueze.
Although Btrfs was included in the 2.6.29 kernel, the developers state that "starting from the 2.6.31 kernel, we only plan to make the disk change format compatible henceforth." The developers still want to improve the user/management tools to make them more user friendly. For getting additional information about Btrfs, at the link in section.
Ext2/3/4 can be turned into Btrfs (but not vice versa).
Debian Squeeze and newer versions support Btrfs.
btrfs-tools (in DebianSqueeze and above)
See also: Btrfs wiki FAQ
Creation file system:
mkfs.btrfsManage volumes, subvolumes, snapshots; checking the integrity of the file system:
btrfsctlScanning for btrfs filesystems:
btrfsctl -a btrfsctl -A /dev/sda2Creating snapshots and subvolumes:
mount -t btrfs -o subvol=. /dev/sda2 /mnt btrfsctl -s new_subvol_name /mnt btrfsctl -s snapshot_of_default /mnt/default btrfsctl -s snapshot_of_new_subvol /mnt/new_subvol_name btrfsctl -s snapshot_of_a_snapshot /mnt/snapshot_of_new_subvol ls /mntChecking the extent trees of the file system:
btrfsckOutput metadata in text form:
debug-tree debug-tree /dev/sda2 >& big_output_fileShow btrfs filesystems on hard drive:
btrfs-show /dev/sda*Defrag (not required by default):
# btrfs filesystem defragment /mnt or # btrfs filesystem defragment /mnt/file.isoThe ext3 file system can be turned into btrfs, and further work with it as a new file system. Moreover, the state of the original ext3 file system will be available later.
# Always run fsck first %# fsck.ext3 -f /dev/xxx # Convert from Ext3->Btrfs %# btrfs-convert /dev/xxx # Mount the resulting Btrfs filesystem %# mount -t btrfs /dev/xxx /btrfs # Mount the ext3 snapshot %# mount -t btrfs -o subvol=ext2_saved /dev/xxx /ext2_saved # Loopback mount the image file %# mount -t ext3 -o loop,ro /ext2_saved/image /ext3The /ext3 directory now shows the state of the original file system.
Unmounting takes place in reverse order:
%# umount /ext3 %# umount /ext2_saved %# umount /btrfsYou can revert to an ext3 file system and lose your changes:
%# btrfs-convert -r /dev/xxxOr you can stay on btrfs and delete the saved ext3 filesystem image:
%# rm /ext2_saved/imageNote: the new file system after conversion sometimes has a very large metadata size.
View metadata size:
# btrfs filesystem df /mnt/data1tb/Normalize their size:
btrfs fi balance /mnt/btrfsRead more: Conversion from ext3 (English) and Converting ext3fs to btrfs (Russian)
For btrfs, online (on the fly) resizing of the file system is available. First you need to mount desired section:
# mount -t btrfs /dev/xxx /mntAdding 2GB:
# btrfs filesystem resize +2G /mnt or # btrfsctl -r +2g /mntDownsizing by 4GB:
# btrfs filesystem resize -4g /mnt or # btrfsctl -r -4g /mntSet size to 20GB file system:
# btrfsctl -r 20g /mnt or # btrfs filesystem resize 20g /mntUsing all free space:
# btrfs filesystem resize max /mnt or # btrfsctl -r max /mntThe above commands are valid only for the file system. To resize a partition, you need to use other utilities such as fdisk. Consider an example to reduce a partition by 4GB. Mount and reduce the partition:
# mount -t btrfs /dev/xxx /mnt # btrfsctl -r -4g /mntNow unmount the partition and use fdisk:
# umount /mnt fdisk /dev/xxx # where dev/xxx is HDD with the section we needMoving to a new file system is always a difficult task. We already trust the old, proven file system. It may even have some limitations in functionality and performance, but it has never let us down. The new file systems offer very a large number of functions, but the question arises, can they be trusted?
One such file system is Btrfs. This is a relatively new file system that appeared in 2007 and was developed by Oracle. It offers a very wide range of new features and is therefore of great interest to users, but there are still rumors on the net that this file system is not yet suitable for permanent use. In this article, we will try to figure out what opportunities Btrfs gives us, and also whether it can already be used.
As I said, Btrfs was developed by Oracle in 2007. There is no single decoding of the name, some say that it means B-tree FS, others Better Fs. Just like in other file systems, all data is stored on disk at specific addresses. These addresses are stored in metadata. And this is where the differences begin. All metadata is organized as b-trees. This gives greater performance when working with the file system, and also allows you to add an unlimited number of files.
But even that is not all. When you overwrite a file, the data is not overwritten, but only the modified part is copied to the new location. Then the metadata is simply updated. This allows you to create snapshots of the file system that do not take up disk space until many changes have been made. If the old block is no longer needed because it is not part of any snapshot, then it is automatically deleted.
Due to its structure, Btrfs has a lot of possibilities, for example, it can handle today's very large storage media. The maximum file system size is 16 exabytes. This is all possible thanks to the proper use of disk space. Other file systems use the entire hard drive, end to end, to record their structure.
Btrfs does things differently. Each disk, regardless of its size, is divided into blocks of 1 GB for data and 256 MB for metadata. These blocks are then assembled into groups, each of which can be stored on different devices, the number of such blocks in a group may depend on RAID level for the group. The volume manager is already integrated into the file system, so no additional software needs to be used.
Data protection and compression is also supported at the file system level, so here you also do not need additional programs. The btrfs file system also supports data mirroring across multiple media. Here are other features of btrfs that can be mentioned:
All this is very good, but is it possible to use this file system already? Let's try to deal with this.
There are still many misconceptions around Btrfs. Many of them stem from real problems that were at the beginning of the development of the file system. But people looking at this information do not look at its date. Yes Btrfs was indeed unstable and unstable. There were a lot of data loss issues and a lot of users writing about it, but that was back in 2010.
The most important part of a file system is its storage format on disk. But the format of the Btrfs file system is already fixed, it happened back in 2012 and it no longer changes unless absolutely necessary. This alone is sufficient to recognize the stability of btrfs.
But why is Btrfs considered unstable by many? There are several reasons for this. First, it is the fear of users to new technologies. This was not only in Linux, but also in Microsoft, with their transition to NTFS, and in Apple. But there is some paradox here, the XFS file system has gone through 20 years of stable development, but the most stable file system is ext4, which was developed from a fork of ext3 in 2006. In fact, it is a year older than Btrfs.
The second reason is in active development, although the data storage format is frozen, the main codebase is still actively developed and there is still a lot of room for performance improvements and new features.
But there are already many confirmations that the file system is ready. This file system is used on Facebook's servers, where the company stores its sensitive data. And that in itself is an important factor. Companies such as Facebook, SuSE, RedHat, Oracle, Intel and others are working on improving the file system. This file system has been used by default in SUSE Linux Enterprise since release 12. All these factors together prove that the file system is quite ready to use. And given the functionality and features of btrfs, it can already be used.
Why it is worth using Btrfs and whether it is worth it at all, figured it out. Now I would like to show some practice so that you can evaluate this file system in action. I will give examples based on Ubuntu. First, install the file system management tools:
sudo apt install btrfs-tools
First you need to create a file system. Let's say we have two hard drives /dev/sdb and /dev/sdc, we want to create a single file system on them with data mirroring. To do this, just do:
sudo mkfs.btrfs /dev/sdb /dev/sdc
The default will be RAID0 for data (no redundancy, and RAID1 for metadata (duplicate to a single disk). When using a single disk, the metadata is also duplicated, if you want to disable this behavior, you can use the -m single option:
sudo mkfs.btrfs -m single /dev/sdb
But by doing this, you increase the risk of data loss, because if the metadata is lost, so is the data.
You can view information about the newly created file system with the command:
sudo btrfs filesystem show /dev/sdb
Or about all mounted filesystems:
sudo btrfs filesystem show
To mount, use the usual command:
sudo mount /dev/sdb /mnt
You can mount any of the drives, it will have the same effect. The line in /etc/fstab will look like this:
/dev/sdb /mnt btrfs defaults 0 1
Now we look at information about the disk space occupied:
sudo btrfs filesystem df /mnt
To enable compression, just add the compress option when mounting. You can pass the lzo or zlib algorithm to it:
sudo mount -o compress=lzo /dev/sdb /mnt
$ sudo mount -o compress=zlib /dev/sdb /mnt
To recover a corrupted Btrfs, use the recovery mount option:
sudo mount -o recovery /dev/sdb /mnt
You can resize a volume in real time using the resize command:
sudo btrfs filesystem resize -2g /mnt
Reduce the size by 2 gigabytes. Then increase by 1 gigabyte:
sudo btrfs filesystem resize +1g /mnt
You can create logical partitions, subvolumes inside the main partition using Btrfs. They can be mounted inside the main partition:
sudo btrfs subvolume create /mnt/sv1
$ sudo btrfs subvolume create /mnt/sv2
$ sudo btrfs subvolume list /mnt
You can mount the subvolume with the id you got with the last command:
sudo umount /dev/sdb
sudo mount -o subvolid=258 /dev/sdb /mnt
Or you can use the name:
sudo mount -o subvol=sv1 /dev/sdb /mnt
First, mount the btrfs root instead of the subvolume:
sudo umount /mnt
sudo mount /dev/sdb /mnt/
To remove a subvolume, you can use the mount path, for example:
sudo btrfs subvolume delete /mnt/sv1/
The Btrfs file system allows you to create snapshots of changes. The snapshot command is used for this. For example, let's create a file, then take a snapshot:
touch /mnt/sv1/test1 /mnt/sv1/test2
Create a snapshot:
sudo btrfs subvolume snapshot /mnt/sv1 /mnt/sv1_snapshot
None of us are immune from mistakes. Sometimes the syndrome of crooked hands leads to very sad consequences. Sometimes it is very difficult to resist and not to conduct "anti-scientific" experiments with the system or run a script / application downloaded from an unverified source. And here various tools for running applications in an isolated environment and extended file system capabilities come to the rescue.
*nix systems have always been relatively resistant to ill-written applications (provided, of course, that they were not run as root). However, sometimes there is a desire to experiment with the system - to frolic with configs, some of which can be vital, run a suspicious script, install a program obtained from an untrusted source ... Otherwise, paranoia simply overcomes, and I want to build as many barriers as possible to protect against potential malware. The article will describe some means to avoid the consequences of unforced errors by rolling back to a previously created return point (Btrfs snapshots), running a suspicious program in a limited environment and amusing your paranoia (Arkose and chroot).
Chroot has been known for a long time. It has a huge advantage over other tools - it works everywhere, even on very old distributions. All these newfangled sandboxes are nothing more than its further development. But there are also disadvantages. For example, there is no way to restrict networking, root can get out of it with some effort, and most importantly, it is quite difficult to configure it. Despite this, for some purposes, such as installing packages from source, it is ideal.
There are at least three ways to create a chroot environment:
Most likely, when booting from the Btrfs partition, Grub will swear that sparse files are not allowed and ask you to press any key. To prevent this message from popping up, open it in your favorite text editor file /etc/grub.d/00.header and comment out the following line there:
If [ -n "\$(have_grubenv)" ]; then if [ -z "\$(boot_once)" ]; then save_env recordfail; fi; fi
Actually, the recordfail variable is necessary to prevent a cyclic reboot, for which it is cocked at startup, and then, in case of successful loading, it is set to 0. Although it is undesirable to comment on the code responsible for this procedure, I think that on a desktop system it is quite you can do without it.
Ognelis in the sandbox - this is what the title says
First, let's install the debootstrap package, which is used just for this purpose.
$ sudo apt-get install debootstrap
Then we will create a directory in which the chroot will be located, and deploy the quantal base system in it. In general, it can be created anywhere, but its traditional location is /var/chroot. Since most of the following commands require root permissions, it makes sense to switch to the superuser account:
$ sudo su - # mkdir /var/chroot && cd /var/chroot # debootstrap quantal ./quantal-chr1 http://mirror.yandex.ru/ubuntu
Let's take a look at the last command. It deploys the Quantal Ubuntu release into a separate quantal-chr1 directory (you never know, you suddenly need another chroot) from the nearest mirror. After deployment is complete, you must map the procfs, sysfs filesystems, and (if applicable) the /dev directory to this subtree. In case the chroot will only be used for text applications until a reboot, the following commands should suffice:
# mount --bind /proc /var/chroot/quantal-chr1/proc # mount --bind /sys /var/chroot/quantal-chr1/sys # mount --bind /dev /var/chroot/quantal-chr1/ dev
If you want this subtree to work after a reboot, add the appropriate lines to /etc/fstab. Well, for the work of some graphic applications the /tmp and /var/run/dbus directories should also be displayed. After that, you can already enter the following command, which, in fact, makes the chroot:
# chroot /var/chroot/quantal-chr1/
And you're already locked in it. In order not to confuse chroot with a real system, I recommend changing the shell prompt. For example, let's install and run Skype in the chroot. To do this, you need to install the schroot package on the host system, which makes it easier to run programs in a chroot environment:
Deploying to the base system chroot using debootstrap # apt-get install schroot Then we add an entry to the /etc/schroot/schroot.conf file. In my case, I added the following:
/etc/schroot/schroot.conf description=Quantal Skype directory=/var/chroot/quantal-chr1 priority=3 users=rom groups=rom root-groups=root,rom
We forward /dev, /proc, /sys, /tmp and /var/run/dbus - see above for how to do this. Add a skype user and group to the chroot - it is desirable that the uid and gid match the uid / gid of the main user of the real system (in my case, rom), for which we type the following commands:
# schroot -c quantal-skype -u root # addgroup --gid 1000 skype # adduser --disabled-password --force --uid 1000 --gid 1000 skype
After that, we put the freshly downloaded Skype - again in the chroot - and satisfy its dependencies:
# dpkg --force-all -i skype-ubuntu-precise_4.1.0.20-1_i386.deb # apt-get -f install # exit
On the main system, we allow connections to the X server from localhost and enter the chroot as a normal user:
$ xhost +localhost $ cd / && schroot -c quantal-skype -u rom /bin/bash
Set the DISPLAY variable (which you need to look at in the main system) and start Skype:
$ export DISPLAY=":0.0" $ skype --dbpath=/home/skype/.Skype &
Skype was successfully installed and launched in a chroot environment.
It would be possible to write a script to facilitate launch, but you can do it yourself.
Arkose works in a similar way to Windows sandboxes, such as Sandboxie. In practice, this is a convenient wrapper for LXC containers. But, as you know, convenience and flexibility are sometimes incompatible - fine tuning created containers is difficult. Of the pluses, I note an intuitive interface (this is if you use the GUI - however, launching from command line is also very simple), but from the minuses - by default it requires quite a lot of free space on the hard disk and there are some possible ways bypass; but, if you use Arkose as an additional wrapper for potential ways to introduce malware (browser) or even just to experiment with some interesting application, it won't hurt.
Seccomp is a little-known mechanism introduced in the 2.6.12 kernel that allows a process to make a one-way transition to a "safe" state, where only four system calls are available to it - exit(), sigreturn(), read() and write(), and the last two are available only for already open files. If the process tries to call any other syscall, it will be killed immediately.
Obviously this solution is not very flexible. In this regard, seccomp-bpf appeared in the 3.5 kernel, which allows you to fine-tune, using BPF rules, which system calls (and their arguments) are allowed and which are not. Seccomp-bpf is used in Google Chrome, Chrome OS, and backported to Ubuntu 12.04.
Before using Arkose, it must be installed. The procedure is standard:
$ sudo apt-get install arkose-gui
Both the GUI (arkose-gui) and the command line utility (arkose) will be installed. The graphical interface is so simple that I don’t see the point in describing it, it’s better to immediately move on to practice.
Manual creation Let's start Firefox as an example:
$ sudo arkose -n direct -p firefox
This command will launch Firefox with web access and PulseAudio. Since each newly created container has its own home directory by default, the firelis profile will also be new, without installed add-ons, if you have any.
“But wait! Why sudo? - a reasonable question may arise. The fact is that some preparatory operations are available only from under root. However, I hasten to reassure you - the launched program will work with the rights of the current user.
Adding a user to run Skype in chroot It happens that after installing updates, the system collapses. Tools similar to the Windows System Restore component would be useful here. I am proud to say that we have them! And one of those tools is Btrfs. Of the advantages of the new file system from Oracle, it is worth noting the following:
To perform operations on a new generation file system, such as creating snapshots, defragmenting a volume, and many others, the btrfs command is used. Its syntax, in general, is as follows:
btrfs<команда> <аргументы>
What kind of operations can be performed on Btrfs? Below are the commands that I found interesting.
The remaining commands, although interesting, are related to the topic of the article only in so far as, and we will not consider them. So, to create a snapshot of a subvolume with the current date, for example, the root directory, we type the following command:
$ sudo btrfs subvol snap -r / /snapshot-2013-01-16
$ sudo btrfs subvol del /snapshot-2013-01-16
A Btrfs subvolume can act in two ways: as a directory and as a VFS object - something that can be mounted. For example, when installing Ubuntu, two subvolumes are created - @ and @home. The first contains system files, the second is user data. This is similar to partitioning a disk, only if earlier one partition could contain, as a rule, only one VFS object, now there can be several objects on one partition at once, and they can be nested.
I don’t see much point in creating snapshots manually - you can simply forget to do this. Three automation scenarios come to mind:
Unfortunately, in Ubuntu 12.10 the last method is not available for some reason, so there is practically no choice as such. Personally, I preferred to write a cron script, but first, let's create a subvolume in which our snapshots will be stored. For what? At least in order not to litter the root folder.
# mkdir /mnt/sda11 # mount /dev/sda11 /mnt/sda11 # btrfs subvol create /mnt/sda11/@snapshots # umount /mnt/sda11
Let's see what these commands do. Since the actual root of the FS in this moment inaccessible (in ubuntu, subvolume @ is used as the root instead), we have to mount it manually. In my case it is on /dev/sda11. With the third command, we create the @snapshots subvolume - so if we don't mount it or the real root, its contents will be inaccessible. And now the actual script:
Autosnap.sh #!/bin/bash set -e VOLUME=/dev/sda11 TMP_PATH=/tmp/snapshots MOUNT_OPTS=" [email protected]" # Current date and time - needed to name snapshot folders NOW="$(date +%Y%m%d%H%M)" NOW_SEC="$(date +%s)" if [ $# -ne 1 ]; then # If the script is run without arguments, set the default to one day ago OLDER_SEC="$(date --date "1 day ago" +%s)" else # If we have an argument, we assume that this is a date in any format that the date command understands, with all the consequences OLDER_SEC="$(date --date "$1" +%s)" fi # Subtract the desired date from the current date and convert it to minutes OLDER=$(($NOW_SEC-$ OLDER_SEC)) OLDER_MIN=$(($OLDER/60)) [ ! -d "$(TMP_PATH)/" ] && mkdir "$(TMP_PATH)/" [ -z "`grep "$(TMP_PATH)" /proc/ mounts`" ] && mount "$(VOLUME)" "$(TMP_PATH)/" -o "$(MOUNT_OPTS)" && ( # Mount mkdir "$(TMP_PATH)/$(NOW)/" # Create snapshots btrfs subvol snap / "$(TMP_PATH)/$(NOW)/rootsnap" > /dev/null 2>&1 btrfs subvol snap /home "$(TMP_PATH)/$(NOW)/homesnap" > /dev/null 2>&1 ) && ( # Look for folders with snapshots older than the specified date for f in `find "$(TMP_PATH)" -mindepth 1 -maxdepth 1 -type d -cmin +"$OLDER_MIN" -print0 |xargs -0`; do btrfs subvol del "$(f)/rootsnap" > /dev/null 2>&1 && btrfs subvol del "$(f)/homesnap" > /dev/null 2>&1 && # and delete snapshots and folders containing them rmdir "$f" done ) umount -l "$(TMP_PATH)" && rmdir "$(TMP_PATH)"
This script can be placed where it is convenient (I personally prefer to place such things in /usr/local/bin, but this is a matter of taste), and run it either from cron or from rc.local. By default, the script rotates snapshots older than one day, but you can specify any desired number in the format of the date command - most importantly, do not forget to enclose in quotes.
In order not to pull the disc with the recorded ubunt every time when any vital files are damaged, it is possible to add the boot item from the ISO image in the Grub menu, which I propose to do. To do this, you will need a non-Btrfs partition (because for unknown reasons, the standard initramfs of the Ubuntu ISO does not want to see the image if it is located on the partition with the described FS) and direct hands. Add the following lines to the /etc/grub.d/40_custom file:
Menuentry "Ubuntu 12.10 i386 iso" ( insmod part_msdos insmod fat # Install the root from where we get the ISO set root="hd0,msdos7" # Path to the image relative to the above root set isofile=/ubuntu-12.10-desktop-i386.iso # Mount as a loopback device directly into Grub loopback loop $isofile linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noeject noprompt -- initrd (loop)/casper/initrd.lz )
and run the command to update the main Grub config:
$ sudo update grub
Now, even in case of serious damage to the system - unless, of course, the bootloader and its files are affected - you can always boot from an ISO image and change damaged files or roll back to a previous system state.
If you work in a chroot environment as root, then there is an opportunity to escape from there. One way is to use the mknod() system call and then mount the real root. Installing the grsecurity patchset solves this problem.
Btrfs commands have standard and abbreviated forms. For example, the command "btrfs subvolume snapshot" can be written as "btrfs su sn".
So, let's say you dropped the system and you need to restore it from a Btrfs snapshot. To do this, boot from this ISO image, mount the partition on which you dropped the system - exactly the partition, not the subvolume! - and enter the following commands (of course, adjusted for your snapshots and partitions):
# cd /mnt/sda11 # mv @ @_badroot # mv @snapshots/201302011434/rootsnap @
The same, if necessary, we do with @home and reboot. If everything went well, then you can remove @_badroot:
$ sudo btrfs subvol del @_badroot
On *nix systems, there are many ways to protect yourself from or mitigate bad experiments. I have reviewed some of them. However, it is worth noting that all these methods are intended mainly for experimenters who like to dig deeper into the system. They are not suitable for catching malware - they are easy enough to detect, although they certainly provide some level of security.
Original: How to create and use BTRFS snapshots - Tutorial
Author: Igor Ljubuncic
Publication date: February 25, 2012
Translation: A. Krivoshey
Date of transfer: April 2012
BTRFS is a relatively new file system based on Sun's ZFS, which brought the most innovation to Unix in the last 25 years before it was taken over by Oracle. BTRFS is still considered unstable and therefore not suitable for production applications. However, this file system has many useful features that are worth exploring. One of them is the creation of snapshots of the system.
Let me clarify. Snapshots are instant snapshots of the state of a system. In a sense, if you copy a file and make a backup, you are taking a snapshot of it at the time of the copy. This can be done anywhere and anytime. Think of a file system that can actually manage multiple copies of your files within its structure, and let you use them however you please. Sounds interesting, let's investigate.
Before we start digging deeper, I would like to briefly outline the capabilities of this file system. BTRFS should handle all system operations related to disks and file management, which usually require additional utilities. BTRFS provides defragmentation, load balancing, shrinking, growing, hot swapping, RAID, snapshots, compression, cloning, and more, all built into the file system driver. With other file systems, you will likely need a variety of other drivers and user utilities to manage all these kinds of operations, such as a file system defragmenter, RAID and LVM drivers, and so on.
Built-in functionality means performance and ease of use. However, at the moment BTRFS is not yet fully usable due to instability as well as performance degradation compared to other file systems such as Ext4. But it has enormous potential, so it cannot be ignored, but must be studied.
In this guide, I will show you how to manage snapshots. This is a super relevant feature that will allow you to create backups important files before making any changes to them and then restore them if necessary. In a way, it's like Windows System Restore plus a filesystem-level rollback driver. By the way, in addition to snapshots, in this article you can also find a few useful information about everyday work with the BTRFS file system. Testing was done on a Fedora 16 Verne system with a KDE desktop.
You can use BTRFS for the root file system, with the exception of /boot, which must be formatted with a traditional journaling file system. For simplicity, in this guide, we will work with a separate device /dev/sdb1 formatted in BTRFS and used when necessary. In practice, this could be /home or /data, or whatever.
We will take /dev/sdb1 and mount it. Then we will create some subsections. Think of subsections as virtual rooted trees, since each of them is a separate, independent tree data structure, even if the data is the same.
Below is the sequence of commands required for this. Don't be scared, we'll explain how they work.
$ btrfs subvolume create /mnt/data $ btrfs subvolume create /mnt/data/orig $ echo "Dedoimedo is l33t" > /mnt/data/orig/file $ btrfs subvolume snapshot /mnt/data/orig /mnt/data/backup
/dev/sdb1 is mounted on /mnt. We create a subkey called data. Inside it, we create another subsection called orig. And already inside it our files will be created. From the user's point of view, subsections look like regular directories. In other words, data and data/orig are directories.
Next, we create text file to origin called file containing some text. Finally, we create a snapshot of the orig subkey and call it backup. We now have an identical copy of the orig subsection. Here is the proof:
In addition, to check, we use the command btrfs subvolume list to see all subsections:
$ btrfs subvolume list
Note that each subsection has its own ID number. As we will soon see, this is important.
Currently, /mnt shows both orig and backup by default (all in data). We can change it. Remember earlier I mentioned virtual root tree structures? BTRFS allows you to change the virtual root directory to any of the subkeys.
Thus, using subsections and snapshots simply means switching between different data hierarchies. No need to delete, overwrite files, or do anything else. You just switch to another subsection. We will now see how this is done.
Team btrfs subvolume set-default ID is all we need. We will set the default view to a different partition, then unmount the device, and mount it again. It is important!
Now, if you are working on a file system that cannot be unmounted because it is in use, such as /usr or /etc, you must restart the computer for the changes to take effect. Now another subsection will be displayed in the given directory tree. The user will not notice the difference, but the data in the directories will change.
To really see how this works, we'll edit the file file in backup. Replace the text Dedoimedo is l33t with Dedoimedo is NOT l33t.
$ echo "Dedoimedo is NOT l33t" > /mnt/data/backup/file
Okay, we know the ID for all subsections. Therefore, we will mount the ID as the default view. This means that as soon as you remount /mnt, we will see a file with this content here.
$ btrfs subvolume set-default 257 /mnt $ umount /mnt $ mount /dev/sdb1 /mnt
Now let's put everything back:
This can be done as many times as needed:
.png)
Above, we changed the view between 257 and 260, that is, between orig and backup, as a result, we could view the contents of the modified file. We simply showed the user different subsections.
As a result, if we want to see both orig and backup in the data directory, we need to restore the default view of the top-level subsection, that is, data. Note that all data is displayed in the /mnt directory, since we chose it as the mount point. However, you can use any other directory instead.
The snapshot function in BTRFS is implemented quite neatly, and its use is not difficult. Of course, you need to be careful to use the correct data tree and not mix things up. But now you already know the basic BTRFS commands and can act more confidently. In the future, we will test Snapper, a BTRFS frontend available from openSUSE that allows the same functionality to be implemented via a graphical user interface for those who don't like the command line.
As a geek, I still have the habit of constantly experimenting with the system: rebuilding, installing non-stable RC kernels, including experimental update branches. Often, I would even say I break the system too often (my personal best, 2 weeks without reinstalling).
What does break mean? When something works extremely badly, for example, LibreOffice and Compiz that often crashes and likes to freeze, I either try to reconfigure the system, but this is quite long and dreary.
Exactly what I'm getting at.
If someone, like me, likes to experiment with the system and is tired of restoring it every time, then here's an option for you how I solved this problem for myself. I will pass under the cat.
How-to or regular bike.
And paste something like this 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 (official ubuntu wiki):
/Grub2/ISOBoot
Now "almost" the most important thing, we re-generate the config:
sudo update-grub
That's it, now after rebooting, holding down the shift key, we can start a mini system with the Internet and a graphical interface, regardless of the state of the main system.
A little background:
It was originally planned to execute the script through rc.local, but it was not executed, then it was implemented through daily cron, later I defeated rc.local and turned off snapshots to hell 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 execution permissions to both files via sudo chmod +x "file path"
The execution logging to the ./snapshots/snapshots.log file may not work, 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 system snapshots by typing:
cat /var/log/snapshots.log
All snapshots are added to the partition with the system in the snapshots folder, where a folder is created for each successful system startup.
Some might say that it doesn't pay off to take snapshots at startup. Not at all, 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 will not be able to return to the moment of a successful launch (actual), 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
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.
#!/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 would also be cool to finish the cleaning script so that it cleans up 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 for btrfs, I think with minor modifications, this is a fairly universal solution based on standard btrfs features.
Yes, I know lvm, but I don’t need an additional layer of abstraction from hardware and putting pictures on a separate section is also not comme il faut.
UPD 1:
Thanks to users
