As you have seen in a previous article, Btrfs snapshots are a convenient and fast way to make backups. Please note that these articles do not suggest that you avoid backup software or well-tested backup plans. Their goals are to show a great feature of this file system, snapshots, and to inspire curiosity and invite you to explore, experiment and deepen the subject. Read on for more about how to recover your files from Btrfs snapshots.
A subvolume for your project
Let’s assume that you want to save the documents related to a project inside the directory $HOME/Documents/myproject.
As you have seen, a Btrfs subvolume, as well as a snapshot, looks like a normal directory. Why not use a Btrfs subvolume for your project, in order to take advantage of snapshots? To create the subvolume, use this command:
btrfs subvolume create $HOME/Documents/myproject
You can create a hidden directory where to arrange your snapshots:
As you can see, in this case there’s no need to use sudo. However, sudo is still needed to list the subvolumes, and to use the send and receive commands.
Now you can start writing your documents. Each day (or each hour, or even minute) you can take a snapshot just before you start to work:
btrfs subvolume snapshot -r $HOME/Documents/myproject $HOME/.snapshots/myproject-day1
For better security and consistency, and if you need to send the snapshot to an external drive as shown in the previous article, remember that the snapshot must be read only, using the -r flag.
Note that in this case, a snapshot of the /home subvolume will not snapshot the $HOME/Documents/myproject subvolume.
How to recover a file or a directory
In this example let’s assume a classic error: you deleted a file by mistake. You can recover it from the most recent snapshot, or recover an older version of the file from an older snapshot. Do you remember that a snapshot appears like a regular directory? You can simply use the cp command to restore the deleted file:
cp $HOME/.snapshots/myproject-day1/filename.odt $HOME/Documents/myproject
Or restore an entire directory:
cp -r $HOME/.snapshots/myproject-day1/directory $HOME/Documents/myproject
What if you delete the entire $HOME/Documents/myproject directory (actually, the subvolume)? You can recreate the subvolume as seen before, and again, you can simply use the cp command to restore the entire content from the snapshot:
btrfs subvolume create $HOME/Documents/myproject
cp -rT $HOME/.snapshots/myproject-day1 $HOME/Documents/myproject
Or you could restore the subvolume by using the btrfs snapshot command (yes, a snapshot of a snapshot):
btrfs subvolume snapshot $HOME/.snapshots/myproject-day1 $HOME/Documents/myproject
How to recover btrfs snapshots from an external drive
You can use the cp command even if the snapshot resides on an external drive. For instance:
cp /run/media/user/mydisk/bk/myproject-day1/filename.odt $HOME/Documents/myproject
You can restore an entire snapshot as well. In this case, since you will use the send and receive commands, you must use sudo. In addition, consider that the restored subvolume will be created as read only. Therefore you need to also set the read only property to false:
sudo btrfs send /run/media/user/mydisk/bk/myproject-day1 | sudo btrfs receive $HOME/Documents/
mv Documents/myproject-day1 Documents/myproject
btrfs property set Documents/myproject ro false
Here’s an extra explanation. The command btrfs subvolume snapshot will create an exact copy of a subvolume in the same device. The destination has to reside in the same btrfs device. You can’t use another device as the destination of the snapshot. In that case you need to take a snapshot and use the send and receive commands.
For more information, refer to some of the online documentation:
man btrfs-subvolume man btrfs-send man btrfs-receive
Hi, thanks for the tips !
Has Fedora 33 found a way around the fact that the files in a subvolumes in home cannot be put into the trash bin (under Gnome at least), but instead can only be deleted ?
That is nice to snapshot but the bin is useful too…
Deleting a file is putting it into the trash bin. I guess you’re referring to the inability to drag and drop a file into the trash bin.
Nope, I did try both to drag into the bin or to press delete, it really only provides Delete permanently. This even creating writable .Trash-$UID at the root of the filesystem and in each subvolume.
I found several places where folks looked at the matter and apparently it is because of the inability to list subvolumes by a normal user (even wheel).
So not an obvious trick to solve.
I have F33SB Beta installed with btrfs as the filesystem. If I delete a file using Gnome Files, I can undelete it from my trash bin, or move it to wherever from there. What I found I cannot do is drag and drop into the trash bin, it just doesn’t work. I use right click then select delete, or just use the delete key.
No. Deleting a file is use rm filename or use editor, delete the contens and save empty file.
Ugh, this seems like a serious issue. Is it reported as a F33 Final blocker?
…. Do not have to delete content.
Maybe Gnome takes different subvolume as different devices (they have different inode id).
While you can maintain a bin by your self using
across different subvolume and delete the original file. (moving files between subvolume will cause a copy while reflink can avoid this, yes even moving files between subvolumes can be tricky)
But until those software can handle subvolume gracefully, we have to do tricky things 😉
Yes, that’s the pity: it considers these as different devices but does not use the .Trash-$UID at the root of each subvolume as it does for external drives.
A pity because else would be very handy to have a subvolume for files and not have to snapshot and send the entire home to reduce traffic and unnecessary files. Btrbk is a breeze.
This look like a nice alternative to Git for binary files.
Oh my, this is a real game changer re: backups. Now just to figure out how to wrap it in something to look like Time Machine on a Mac.
This is very interesting. I have been using snapshots with my vms in Qemu for a few years now. Its nice to see Fedora switching to BTRFS as more users will be testing it.
Hi Fedora and RedHat fans.
Is there going to be a consolidated document or Youtube describing the installation of Fedora 33 with btrfs, including creating subvolumes and including a second btrfs data partition? Then it would be great to show btrfs encryption and the inclusion of the ssd parameter when the target is a SSD or M.2 drive.
Using the Fedora beta 33, I am preparing myself for the go live date. My learning has been by trial and error and reading many man pages and watching many Youtubes about btrfs.
I would think this would be placed in the F33 installation section of the user guide with more detailed instructions in the F33 System Administrators guide, which is the norm. The install currently has
as subvolumes with a default layout scheme of a fresh install. I run Silverblue and so I wanted
as a subvolume, plus I have two SSD’s that I wanted setup as RAID1 and created the
subvolume on them. With the spinning disk having the
subovlumes which I believe get the most thrashing. I had to do this using the advanced blivet GUI of the installer. AFAIK, currently BTRFS on fedora recognizes SSD’s and correctly handles them, also newer SSD’s are not prone to the same errors earlier types were plagued with it seems.
What does send/receive provide over rsync? Maybe it preserves the copy on write structure? Does it do nested subvolumes?
As far as I know, it just sends subvolume per subvolume.
To me the main advantage for backing up is that rsync has no knowledge of renaming or moving. So if you change a letter in a large folder name, rsync will want to resend all the data. While the filesystem knows about the fact it is just renamed and sends a tiny amount of instructions just to rename the folder or file.
It is much much faster!
is btrfs-convert safe/recommended to use to switch from EXT4 to BTRFS or is it advisable to reformat the OS?
AFAIR btrfs-convert should be mostly safe to use, but there still are some corner cases.
I actually switched to Fedora from Ubuntu because of the issues I kept running into with the version of btrfs Ubuntu used. The problem was the accumulation of snapshots, which would lead to a “disk full” report, even though the “full” consisted of nothing but old snapshots that should have been discarded sequentially oldest to youngest, but were not.
BTRFS at the time did a really horrible job and had to be overseen closely or it would flood the disk with “snapshots.” The first time I encountered this, I had to boot the system from a thumb drive and use the BTRFS utilities to purge the snapshots. Since it was a 640 Gb disk, and the normal utilities reported well over half that space as “free” the experience was disconcerting. That first time, while the system would boot, even the BTRFS utilities couldn’t run because BTRFS perceived the disk as “full” even though nearly half the space should have been free. So, I had work around the hard disk restrictions with a thumb drive.
So, is BTRFS any better than it was?
GlobalReserve – should allow Btrfs tools to work even on a full filesystem.
I will be usuing snapshots byt the following is my “Aide Mémoire”:
To remember the syntax:
sudo btrfs subvolume snapshot -r ThisSubvolume ToSnapshot/repository/snapshotID
in my setup, for example:
sudo btrfs subvolume snapshot -r /home /.snapshots/homeyyyymmdd
drwxr-xr-x. 1 root root 32 Oct 23 22:20 home-2020-1023
drwxr-xr-x. 1 root root 0 Oct 23 16:20 opt-2020-1023
dr-xr-xr-x. 1 root root 276 Oct 23 22:22 root-20201023
mkdir -p “$HOME”/.backups
echo “Backing up $HOME to ~/.backups/$LOGNAME.$NOW folder, please wait…”
sudo btrfs subvolume snapshot -r /home $HOME/.backups/$LOGNAME.$NOW
credits to leslie Satenstein at