Recover your files from Btrfs snapshots

Photo by Malcolm Lightbody on Unsplash

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:

mkdir $HOME/.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
Fedora Project community


  1. Joe D.

    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…

    • Stephen

      Hi Joe,
      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.

      • Joe D.

        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.

        • Stephen

          Hello Joe,
          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.

      • Roman Nádhera

        No. Deleting a file is use rm filename or use editor, delete the contens and save empty file.

    • Maybe Gnome takes different subvolume as different devices (they have different inode id).

      While you can maintain a bin by your self using

      cp --reflink=always

      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 😉

      • Joe D.

        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.


  2. eclipseo

    This look like a nice alternative to Git for binary files.

  3. 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.

  4. Donnie

    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.

  5. leslie Satenstein

    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.

    • Stephen

      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.

  6. What does send/receive provide over rsync? Maybe it preserves the copy on write structure? Does it do nested subvolumes?

    • Joe D.

      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.

    • Peter

      It is much much faster!

  7. dog

    is btrfs-convert safe/recommended to use to switch from EXT4 to BTRFS or is it advisable to reformat the OS?

    • Federico

      AFAIR btrfs-convert should be mostly safe to use, but there still are some corner cases.

  8. John

    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?

  9. leslie Satenstein

    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
    ll /.snapshots
    total 0
    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

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions

%d bloggers like this: