This article will explore what Btrfs snapshots are, how they work, and how you can benefit from taking snapshots in every-day situations. This is part of a series that takes a closer look at Btrfs, the default filesystem for Fedora Workstation and Fedora Silverblue since Fedora Linux 33. <\/p>\n
In case you missed it, here’s the previous article from this series: https:\/\/fedoramagazine.org\/working-with-btrfs-subvolumes\/<\/a><\/p>\n <\/span> <\/p>\n Imagine you work on a file over extended periods of time, repeatedly adding changes and undoing them. Then, at some point you realize: Parts of the changes you undid two hours ago would be very helpful now. And yesterday you had already changed this particular bit, too, before you trashed that design. But of course, because you regularly save your files, old changes are lost. Many people have probably experienced a situation like this before. Wouldn’t it be great if you could recover old file versions without having to manually copy them at regular intervals?<\/p>\n This is just one typical situation where Btrfs snapshots can help you out. When used correctly, snapshots also give you a great backup solution for your PC. <\/p>\n Below you will find a lot of examples related to snapshots. If you want to follow along, you must have access to a Btrfs filesystem and root access. You can check the file system of a directory using the following command:<\/p>\n Here the findmnt <\/em> command shows the type of filesystem for your \/home\/<\/em> directory. If it says btrfs<\/em>, you’re all set. Let’s create a new directory in which to perform some experiments:<\/p>\n In the text below, you will find lots of command responses in boxes such as shown above. Please keep in mind while reading\/comparing command output that the box contents may be wrapped at the end of the line<\/strong>. This may make it difficult to recognize long lines that are broken across multiple lines for readability. When in doubt, try to resize your browser window and see how the text behaves!<\/p>\n Let’s start with an elementary question: What is a Btrfs snapshot? If you look in the Docs [1]<\/a> and Wiki [2]<\/a>, you won’t immediately find an answer to this question. In fact, it is nowhere to be found in the “Features” section. If you search a little, you will find snapshots mentioned extensively along with Btrfs subvolumes [3]<\/a>. So now what?<\/p>\n Remember that snapshots were both mentioned in the previous articles of this series? There it said: <\/p>\n What is the advantage of CoW? In simple terms: a history of the modified and edited files can be kept. Btrfs will keep the references to the old file versions (inodes) somewhere they can be easily accessed. This reference is a snapshot<\/em>: An image of the filesystem state at some point in time.<\/p>\n Working with Btrfs: General Concepts<\/a><\/cite><\/p><\/blockquote>\n and also:<\/p>\n Another advantage of separating \/<\/em> and \/home<\/em> is that you can take snapshots<\/em> separately. A subvolume is a boundary for snapshots, and snapshots will never contain the contents of other subvolumes below the subvolume that the snapshot is taken of.<\/p>\n Working with Btrfs: Subvolumes<\/a><\/cite><\/p><\/blockquote>\n It seems snapshots have something to do with Btrfs subvolumes. You may have heard about snapshots in other contexts before, for example with LVM, the Logical Volume Manager. While technically they serve the same purpose, they are different in terms of how they reach their goal.<\/p>\n Every Btrfs snapshot is a subvolume. However, not every subvolume is a snapshot. The difference is in what the subvolume contains. A snapshot is a subvolume with added content: it holds references to current and\/or past versions of files (inodes). Let’s see where snapshots come from!<\/p>\n To use snapshots, you need a Btrfs subvolume to take snapshots of. Let’s create one inside our test folder (~\/btrfs-snapshot-test):<\/p>\n Since by default Btrfs subvolumes are owned by root, you must call chown<\/em> to modify the files in the subvolume to be owned by a regular user. Now add a few files inside it:<\/p>\n Your directory now looks something like this:<\/p>\n Let’s create the very first snapshot from that:<\/p>\n And that’s it. Let’s see what was achieved:<\/p>\n It seems it made a copy! To verify, let’s read the contents of foo<\/em> from the snapshot:<\/p>\n The real effect becomes apparent when we modify the original file:<\/p>\n This shows that the snapshot still holds the “old” version of the data: The content of foo<\/em> hasn’t changed. So far, you could have achieved the exact same thing with a simple file copy. You can now go ahead and continue working on the old file, too:<\/p>\n Under the hood, however, our snapshot is in fact a new Btrfs subvolume. You can verify this with the following command:<\/p>\n So what’s the point of all this? Up until now snapshots seem to be a complicated way to copy files around. In fact, there is more to snapshots than meets the eye. Let’s create a bigger file:<\/p>\n There is now a new file demo\/bigfile<\/em> that is 512 MiB in size. Let’s make another snapshot so you don’t lose it when you modify the data:<\/p>\n Now let’s simulate some changes by appending a small string to the file:<\/p>\n Here’s the resulting file structure:<\/p>\n But the real magic happens somewhere else. Had you copied demo\/bigfile<\/em>, you would now have two files of about 512 MiB in size with mostly the same content. However, since they are distinct copies, they would occupy about 1 GiB of storage total. Keep in mind that the difference between both files is hardly more than 10 Bytes – that’s almost nothing compared to the original file size.<\/p>\n Btrfs snapshots work different than file copies: They keep references to current and past inodes instead. When you appended the change to the file, under the hood Btrfs allocated some more space to store the changes in and added a reference to this new data to the original inode. The previous contents remain untouched. If it helps your mental model, you can think of this as “storing” merely the difference between the original file and the modified version.<\/p>\n Let’s have a look at the effect of this:<\/p>\n The interesting figure here is seen in line “TOTAL”:<\/p>\n While you have a total of 1 GiB files, it takes merely 512 MiB to store them.<\/p>\n So far, in this article, you have seen how to create Btrfs snapshots and what makes them so special. One may be tempted to think: If I take a series of Btrfs snapshots locally on my PC, I have a solid backup strategy. This is not the case<\/strong>. If the underlying data, which is shared by Btrfs subvolumes, is accidentally damaged (by something outside of Btrfs’ influence, e.g. cosmic rays), all the subvolumes pointing to this data contain the same error.<\/p>\n To turn the snapshots into real backups you should store them on a different Btrfs filesystem, such as on an external drive. For the purposes of this article let’s create a new Btrfs filesystem contained inside a file and mount it to simulate an external drive. If you have an external drive formatted with Btrfs lying around, feel free to substitute all the paths mentioned in the following commands to try it out! Let’s create a new Btrfs filesystem:<\/p>\n Note<\/strong>: The commands below will create a new file of 8 GB size on your filesystem. If you want to follow the steps below, please ensure you have at least 8 GB of disk space available. Do not allocate less than 8 GB to the file, as Btrfs may otherwise encounter issues during mounting.<\/p>\n These commands created a new file of 8 GB in size named btrfs_filesystem.img<\/em> and formatted a Btrfs filesystem inside it. Now you can mount it as if it were an external drive:<\/p>\n Great, now there is an independent Btrfs filesystem mounted under backup-drive<\/em>! Let’s try to take another snapshot and place it there:<\/p>\n What happened? Well, you tried to take a snapshot of demo<\/em> and store it in a different Btrfs filesystem (a different device from Btrfs’ point of view). Remember that a Btrfs subvolume only holds references to files and their contents (inodes)? This is exactly the problem: The files and contents exist in our home filesystem, but not in the newly-created backup-drive<\/em>. You have to find a way to transfer the subvolume along with its contents to the new filesystem.<\/p>\n The Btrfs utilities include two special commands for this purpose. Let’s see how they work first:<\/p>\n Another error! This time it tells you that the subvolume we’re trying to transfer is not read-only. This is true: You can write new contents to all of the snapshots\/subvolumes created so far. You can create read-only snapshots like this:<\/p>\n Unlike previously, here the -r<\/em> option is added to the snapshot<\/em> subcommand. This creates a read-only snapshot, which is easily verified:<\/p>\n Now you can retry transferring the subvolumes:<\/p>\n It worked! You have successfully transferred a read-only snapshot of our original subvolume demo<\/em> to an external Btrfs filesystem.<\/p>\n Above you have seen how you can store Btrfs subvolumes\/snapshots on another Btrfs filesystem. But what can you do if you do not have another Btrfs filesystem and cannot create one, for example because the external drives need a filesystem that allows compatibility with Windows or MacOS hosts? In such cases you can store subvolumes in files:<\/p>\n The file demo-3-ro-subvolume.btrfs<\/em> now contains everything that is needed to recreate the demo-3-ro<\/em> subvolume at a later point in time.<\/p>\n If you perform this action repeatedly for different subvolumes, you will notice at some point that the different subvolumes do not share their file contents any more. This is because when sending a subvolume such as above, all the data needed to recreate this standalone subvolume is transferred to the target. You can, however, instruct Btrfs to only send the difference between two subvolumes to the target! This so-called incremental send will ensure that shared references remain shared between the subvolumes. To demonstrate this, add a few more changes to our original subvolume:<\/p>\n Next create another read-only snapshot:<\/p>\n And now send it:<\/p>\n In the command above, the -p<\/em> option specifies a parent subvolume, against which the differences are calculated. It is important to keep in mind that both the source and target Btrfs filesystem must contain the same, unmodified parent subvolume! Ensure that the new subvolume is really there:<\/p>\n But how do you know whether the incremental send only transferred the difference between both subvolumes? Let’s transfer the data stream to a file and see how big it is:<\/p>\n According to ls, the file is merely 315 bytes in size! This means that the incremental send only transferred the changes between the two subvolumes, along with additional Btrfs-specific metadata.<\/p>\n Before continuing, let’s do some cleaning up of the things you don’t need at the moment:<\/p>\n So far you have managed to create read\/write and read-only snapshots of Btrfs subvolumes and send them to an external location. In order to turn this into a backup strategy, however, there has to be a way to send the subvolumes back to the original filesystem and make them writable again. For this purpose, let’s move the demo subvolume somewhere else and try to recreate it from the most recent snapshot. First: Rename the “broken” subvolume. It will be deleted once the restore was successful:<\/p>\n Second: Transfer the most recent snapshot back to this filesystem:<\/p>\n Third: Create a read-write subvolume from the snapshot:<\/p>\n The last step is important: You cannot just rename demo-4-ro<\/em> to demo<\/em>, because it would still be a read-only subvolume! Finally you can check whether everything you need is there:<\/p>\n The last command above tells you that the last 19 characters in bigfile<\/em> are in fact the change last performed. At this point, you may want to copy recent changes from demo-broken<\/em> to the new demo<\/em> subvolume. Since you didn’t perform any other changes, you can now delete the obsolete subvolumes:<\/p>\n And that’s it! You have successfully restored the demo<\/em> subvolume from a snapshot that was previously stored on a different Btrfs filesystem (external media).<\/p>\n In the second article of this series I mentioned that subvolumes are boundaries for snapshots, but what exactly does that mean? In simple terms, a snapshot of a subvolume will only contain the content of this particular subvolume, and none of the nested subvolumes below. Let’s have a look at this:<\/p>\n Let’s take a snapshot as before:<\/p>\n And check out the contents:<\/p>\n Notice that another_file<\/em> is missing, even though the folder nested<\/em> is present. This happens because nested<\/em> is a subvolume: The snapshot of demo<\/em> contains the folder (mountpoint) for the nested subvolume, but its contents aren’t present. Currently there is no way to perform snapshots recursively to include nested subvolumes. However, we can take advantage of this to exclude folders from snapshots! This is typically useful for data that you can reproduce easily, or that will rarely change. Examples include virtual machine or container images, movies, game files and more.<\/p>\n Before we wrap up the article, let’s remove everything we created while testing:<\/p>\n If you decide you want to use Btrfs to perform regular backups of your data, you may want to use a tool that automates this task for you. The Btrfs wiki has a list of backup tools specialized on Btrfs [4]<\/a>. On this page you will also find another summary of the steps to perform Btrfs backups by hand. Personally, I have had a lot of good experiences with btrbk<\/em> [5]<\/a> and I am using it to perform my own backups. In addition to backups, btrbk<\/em> can also keep a list of Btrfs snapshots locally on your PC. I use this to safeguard against accidental data deletion.<\/p>\n If you want to know more about performing backups using Btrfs, leave a comment below and I’ll consider writing a follow-up article that deals exclusively with this topic.<\/p>\n This article investigated Btrfs snapshots, which are Btrfs subvolumes under the hood. You learned how to create read\/write and read-only snapshots, and how this mechanism can help safeguard against data loss.<\/p>\n The next articles in this series will deal with:<\/p>\n If there are other topics related to Btrfs that you want to know more about, have a look at the Btrfs Wiki [2]<\/a> and Docs [1]<\/a>. Don\u2019t forget to check out the first two articles of this series, if you haven\u2019t already! If you feel that there is something missing from this article series, let me know in the comments below. See you in the next article!<\/p>\n [1]: https:\/\/btrfs.readthedocs.io\/en\/latest\/Introduction.html<\/a> This article will explore what Btrfs snapshots are, how they work, and how you can benefit from taking snapshots in every-day situations. This is part of a series that takes a closer look at Btrfs, the default filesystem for Fedora Workstation and Fedora Silverblue since Fedora Linux 33. In case you missed it, here’s the […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[48],"tags":[45,61,46,47],"class_list":["post-130878","post","type-post","status-publish","format-standard","hentry","category-fedora-os","tag-fedora","tag-fedora-project-community","tag-magazine","tag-news"],"_links":{"self":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts\/130878","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/comments?post=130878"}],"version-history":[{"count":0,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts\/130878\/revisions"}],"wp:attachment":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/media?parent=130878"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/categories?post=130878"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/tags?post=130878"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Introduction<\/h2>\n
$ findmnt -no FSTYPE \/home\nbtrfs<\/pre>\n
$ mkdir ~\/btrfs-snapshot-test\n$ cd ~\/btrfs-snapshot-test<\/pre>\n
Snapshots in Btrfs<\/h2>\n
\n
\n
Creating Btrfs snapshots<\/h2>\n
$ cd ~\/btrfs-snapshot-test\n$ sudo btrfs subvolume create demo\nCreate subvolume '.\/demo'\n$ sudo chown -R $(id -u):$(id -g) demo\/\n$ cd demo<\/pre>\n
$ touch foo bar baz\n$ echo \"Lorem ipsum dolor sit amet, \" > foo<\/pre>\n
$ ls -l\ntotal 4\n-rw-r--r--. 1 hartan hartan 0 Dec 20 08:11 bar\n-rw-r--r--. 1 hartan hartan 0 Dec 20 08:11 baz\n-rw-r--r--. 1 hartan hartan 29 Dec 20 08:11 foo<\/pre>\n
$ cd ..\n$ sudo btrfs subvolume snapshot demo demo-1\nCreate a snapshot of 'demo' in '.\/demo-1'<\/pre>\n
$ ls -l\ntotal 0\ndrwxr-xr-x. 1 hartan hartan 18 Dec 20 08:11 demo\ndrwxr-xr-x. 1 hartan hartan 18 Dec 20 08:11 demo-1\n$ tree\n.\n\u251c\u2500\u2500 demo\n\u2502 \u251c\u2500\u2500 bar\n\u2502 \u251c\u2500\u2500 baz\n\u2502 \u2514\u2500\u2500 foo\n\u2514\u2500\u2500 demo-1 \u251c\u2500\u2500 bar \u251c\u2500\u2500 baz \u2514\u2500\u2500 foo 2 directories, 6 files<\/pre>\n
$ cat demo\/foo\nLorem ipsum dolor sit amet,\n$ cat demo-1\/foo\nLorem ipsum dolor sit amet,<\/pre>\n
$ echo \"consectetur adipiscing elit, \" >> demo\/foo\n$ cat demo\/foo\nLorem ipsum dolor sit amet, consectetur adipiscing elit,\n$ cat demo-1\/foo\nLorem ipsum dolor sit amet,<\/pre>\n
$ echo \"sed do eiusmod tempor incididunt\" >> demo-1\/foo\n$ cat demo-1\/foo\nLorem ipsum dolor sit amet, sed do eiusmod tempor incididunt<\/pre>\n
$ sudo btrfs subvolume list -o .\nID 259 gen 265 top level 256 path home\/hartan\/btrfs-snapshot-test\/demo\nID 260 gen 264 top level 256 path home\/hartan\/btrfs-snapshot-test\/demo-1<\/pre>\n
Btrfs snapshots vs. file copies<\/h2>\n
$ dd if=\/dev\/urandom of=demo\/bigfile bs=1M count=512\n512+0 records in\n512+0 records out\n536870912 bytes (537 MB, 512 MiB) copied, 1.3454 s, 399 MB\/s<\/pre>\n
$ sudo btrfs subvolume snapshot demo demo-2\nCreate a snapshot of 'demo' in '.\/demo-2'<\/pre>\n
$ echo \"small changes\" >> demo\/bigfile<\/pre>\n
$ tree\n.\n\u251c\u2500\u2500 demo\n\u2502 \u251c\u2500\u2500 bar\n\u2502 \u251c\u2500\u2500 baz\n\u2502 \u251c\u2500\u2500 bigfile\n\u2502 \u2514\u2500\u2500 foo\n\u251c\u2500\u2500 demo-1\n\u2502 \u251c\u2500\u2500 bar\n\u2502 \u251c\u2500\u2500 baz\n\u2502 \u2514\u2500\u2500 foo\n\u2514\u2500\u2500 demo-2 \u251c\u2500\u2500 bar \u251c\u2500\u2500 baz \u251c\u2500\u2500 bigfile \u2514\u2500\u2500 foo 3 directories, 11 files<\/pre>\n
$ sudo compsize .\nProcessed 11 files, 5 regular extents (9 refs), 3 inline.\nType Perc Disk Usage Uncompressed Referenced TOTAL 100% 512M 512M 1.0G none 100% 512M 512M 1.0G<\/pre>\n
\n
Btrfs snapshots and backups<\/h2>\n
$ truncate -s 8G btrfs_filesystem.img\n$ sudo mkfs.btrfs -L \"backup-drive\" btrfs_filesystem.img\nbtrfs-progs v5.18\nSee http:\/\/btrfs.wiki.kernel.org for more information. [ ... ] Devices: ID SIZE PATH 1 8.00GiB btrfs_filesystem.img<\/pre>\n
$ mkdir backup-drive\n$ sudo mount btrfs_filesystem.img backup-drive\n$ sudo chown -R $(id -u):$(id -g) backup-drive\n$ ls -lh\ntotal 4.7M\ndrwxr-xr-x. 1 hartan hartan 0 Dec 20 08:35 backup-drive\n-rw-r--r--. 1 hartan hartan 8.0G Dec 20 08:37 btrfs_filesystem.img\ndrwxr-xr-x. 1 hartan hartan 32 Dec 20 08:14 demo\ndrwxr-xr-x. 1 hartan hartan 18 Dec 20 08:11 demo-1\ndrwxr-xr-x. 1 hartan hartan 32 Dec 20 08:14 demo-2<\/pre>\n
$ sudo btrfs subvolume snapshot demo backup-drive\/demo-3\nCreate a snapshot of 'demo' in 'backup-drive\/demo-3'\nERROR: cannot snapshot 'demo': Invalid cross-device link<\/pre>\n
Storing snapshots on a different Btrfs filesystem<\/h3>\n
$ sudo btrfs send demo | sudo btrfs receive backup-drive\/\nERROR: subvolume \/home\/hartan\/btrfs-snapshot-test\/demo is not read-only\nERROR: empty stream is not considered valid<\/pre>\n
$ sudo btrfs subvolume snapshot -r demo demo-3-ro\nCreate a readonly snapshot of 'demo' in '.\/demo-3-ro'<\/pre>\n
$ touch demo-3-ro\/another-file\ntouch: cannot touch 'demo-3-ro\/another-file': Read-only file system<\/pre>\n
$ sudo btrfs send demo-3-ro | sudo btrfs receive backup-drive\/\nAt subvol demo-3-ro\nAt subvol demo-3-ro\n$ tree \u251c\u2500\u2500 backup-drive\n\u2502 \u2514\u2500\u2500 demo-3-ro\n\u2502 \u251c\u2500\u2500 bar\n\u2502 \u251c\u2500\u2500 baz\n\u2502 \u251c\u2500\u2500 bigfile\n\u2502 \u2514\u2500\u2500 foo\n\u251c\u2500\u2500 btrfs_filesystem.img\n\u251c\u2500\u2500 demo\n[ ... ]\n\u2514\u2500\u2500 demo-3-ro \u251c\u2500\u2500 bar \u251c\u2500\u2500 baz \u251c\u2500\u2500 bigfile \u2514\u2500\u2500 foo 6 directories, 20 files<\/pre>\n
Storing snapshots on non-Btrfs filesystems<\/h3>\n
$ sudo btrfs send -f demo-3-ro-subvolume.btrfs demo-3-ro\nAt subvol demo-3-ro\n$ ls -lh demo-3-ro-subvolume.btrfs -rw-------. 1 root root 513M Dec 21 10:39 demo-3-ro-subvolume.btrfs<\/pre>\n
Incrementally sending subvolumes<\/h3>\n
$ echo \"a few more changes\" >> demo\/bigfile<\/pre>\n
$ sudo btrfs subvolume snapshot -r demo demo-4-ro\nCreate a readonly snapshot of 'demo' in '.\/demo-4-ro'<\/pre>\n
$ sudo btrfs send -p demo-3-ro demo-4-ro | sudo btrfs receive backup-drive\nAt subvol demo-4-ro\nAt snapshot demo-4-ro<\/pre>\n
$ ls backup-drive\/\ndemo-3-ro demo-4-ro\n$ ls -lR backup-drive\/demo-4-ro\/\nbackup-drive\/demo-4-ro\/:\ntotal 524296\n-rw-r--r--. 1 hartan hartan 0 Dec 20 08:11 bar\n-rw-r--r--. 1 hartan hartan 0 Dec 20 08:11 baz\n-rw-r--r--. 1 hartan hartan 536870945 Dec 21 10:49 bigfile\n-rw-r--r--. 1 hartan hartan 59 Dec 20 08:13 foo<\/pre>\n
$ sudo btrfs send -f demo-4-ro-diff.btrfs -p demo-3-ro demo-4-ro\nAt subvol demo-4-ro\n$ ls -l demo-4-ro-diff.btrfs -rw-------. 1 root root 315 Dec 21 10:55 demo-4-ro-diff.btrfs<\/pre>\n
Restoring subvolumes from snapshots<\/h3>\n
$ sudo rm -rf demo-4-ro-diff.btrfs demo-3-ro-subvolume.btrfs\n$ sudo btrfs subvolume delete demo-1 demo-2 demo-3-ro demo-4-ro\n$ ls -l\ntotal 531516\ndrwxr-xr-x. 1 hartan hartan 36 Dec 21 10:50 backup-drive\n-rw-r--r--. 1 hartan hartan 8589934592 Dec 21 10:51 btrfs_filesystem.img\ndrwxr-xr-x. 1 hartan hartan 32 Dec 20 08:14 demo<\/pre>\n
$ mv demo demo-broken<\/pre>\n
$ sudo btrfs send backup-drive\/demo-4-ro | sudo btrfs receive .\nAt subvol backup-drive\/demo-4-ro\nAt subvol demo-4-ro\n[hartan@fedora btrfs-snapshot-test]$ ls\nbackup-drive btrfs_filesystem.img demo-4-ro demo-broken<\/pre>\n
$ sudo btrfs subvolume snapshot demo-4-ro demo\nCreate a snapshot of 'demo-4-ro' in '.\/demo'\n$ ls\nbackup-drive btrfs_filesystem.img demo demo-4-ro demo-broken<\/pre>\n
$ tree demo\ndemo\n\u251c\u2500\u2500 bar\n\u251c\u2500\u2500 baz\n\u251c\u2500\u2500 bigfile\n\u2514\u2500\u2500 foo 0 directories, 4 files\n$ tail -c -19 demo\/bigfile a few more changes<\/pre>\n
$ sudo btrfs subvolume delete demo-4-ro demo-broken\nDelete subvolume (no-commit): '\/home\/hartan\/btrfs-snapshot-test\/demo-4-ro'\nDelete subvolume (no-commit): '\/home\/hartan\/btrfs-snapshot-test\/demo-broken'<\/pre>\n
Subvolumes as boundary for snapshots<\/h2>\n
$ sudo btrfs subvolume create demo\/nested\nCreate subvolume 'demo\/nested'\n$ sudo chown -R $(id -u):$(id -g) demo\/nested\n$ touch demo\/nested\/another_file<\/pre>\n
$ sudo btrfs subvolume snapshot demo demo-nested\nCreate a snapshot of 'demo' in '.\/demo-nested'<\/pre>\n
$ tree demo-nested\ndemo-nested\n\u251c\u2500\u2500 bar\n\u251c\u2500\u2500 baz\n\u251c\u2500\u2500 bigfile\n\u251c\u2500\u2500 foo\n\u2514\u2500\u2500 nested 1 directory, 4 files $ tree demo\ndemo\n\u251c\u2500\u2500 bar\n\u251c\u2500\u2500 baz\n\u251c\u2500\u2500 bigfile\n\u251c\u2500\u2500 foo\n\u2514\u2500\u2500 nested \u2514\u2500\u2500 another_file 1 directory, 5 files<\/pre>\n
$ sudo btrfs subvolume delete demo\/nested demo demo-nested\nDelete subvolume (no-commit): '\/home\/hartan\/btrfs-snapshot-test\/demo\/nested'\nDelete subvolume (no-commit): '\/home\/hartan\/btrfs-snapshot-test\/demo'\nDelete subvolume (no-commit): '\/home\/hartan\/btrfs-snapshot-test\/demo-nested'\n$ sudo umount backup-drive\n$ cd ..\n$ rm -rf btrfs-snapshot-test\/<\/pre>\n
Final thoughts on Btrfs-based backups<\/h2>\n
Conclusion<\/h2>\n
\n
Sources<\/h2>\n
[2]: https:\/\/btrfs.wiki.kernel.org\/index.php\/Main_Page<\/a>
[3]: https:\/\/btrfs.readthedocs.io\/en\/latest\/Subvolumes.html<\/a>
[4]: https:\/\/btrfs.wiki.kernel.org\/index.php\/Incremental_Backup#Available_Backup_Tools<\/a>
[5]: https:\/\/github.com\/digint\/btrbk<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"