Snapshotting is a key feature of Btrfs.
These snapshots can be easily sent to a destination (i.e. to an external USB disk or to another host via ssh) using the built in btrfs commands send and receive.
You know, I’m not an expert, I’m a simple user, so I’m unable to go deep in the topics, to explain the backgrounds and so on.
Btw I would like to write a very simple article. The goal is to show such functionality in order to perform incremental backups to an external USB disk. I will not explain deeply what a snapshot is. I will not show any script nor backup software based on btrfs snapshots (like snapper?).
I have a new system with snapper. I let snapper do its thing, but I still make my own btrfs read-only snapshots and send them incrementally to an off-system drive. A snapper snapshot on the filesystem is of no use if the filesystem or the drive it’s on go belly up.
@alciregi I think this sounds like a reasonable idea for an article. It’s great when users come in to share knowledge with other readers! I would encourage you to collaborate with, at least get review from, @cmurf or someone who has a bit of expertise with btrfs so we pass on the best possible information. I think we would want that kind of review before publishing. Does that sound okay?
mount /dev/a /mnt/fedora #this can be called 'mounting the top-level of the file system'
mount /dev/b /mnt/backup
cd /mnt
btrfs subvolume snapshot -r home home.20200901
btrfs send home.20200901 | btrfs receive /mnt/backup #called 'bootstrap' or 'setup' with the first full backup
btrfs subvolume snapshot -r home home.20200904
btrfs subvolume snapshot -r home home.20200905
btrfs send -p home.20200901 home.20200904 | btrfs receive /mnt/backup #incremental
btrfs send -p home.20200904 home.20200905 | btrfs receive /mnt/backup #incremental
The thing that ensnares us all in Btrfsland is that it’s so flexible, and is not on rails, that it permits many different kinds of workflows and snapshot naming conventions. All valid.
It’s a good idea to just explain the simple case, and expect there will be many “but why?” questions. Folks will still love it and encourage them to experiment and answer their own questions.
A tiny “food for thought” at the end that doesn’t need to be deeply explained, two ways to restore: you can just copy individual files out of any of the snapshots on the backup. Or for disaster recovery you can do a full send/receive of the newest “home” snapshot to the new drive; the details of which could be a part 2 article.
Indeed, the goal of such article wouldn’t be to deeply explain snapshots, but to describe a simple use case.
I think that for more information, docs.f.o. is a better place.
I’ve more experiences with ZFS. But I think that the answer is no. Receive takes a stream of instructions, creates a new subvolume, and uses the instructions to modify that subvolume until it looks like the one being sent.
You can use btrfs send with the -f option, to send the snapshot to a file (that can reside on a different kind of filesystem) instead of pipe it to btrfs receive, but I don’t think you can incrementally send streams to a file Correct?
+1 From me. BTRFS snapshots saved me a lot of hassle recovering from a self induced pit of despair recently. The beauty of the filesystem was evident when I needed to take the snapshots from booting the installation media on USB, as I wanted to rearrange the layout a bit and reinstall. Original layout was two subvolumes at / and /var. This proved not so great for snapshots for obvious reasons. So this time I made a subvolume /home as well as /var and /. As I am running Silverblue, this makes /var/home a reflink to /home I believe. I mounted my backup subvolumes and copied in my home data. Very much the easiest way I have recovered from fragging my setup I think, well ever.
@alciregi You can combine -p and -f options. The catch is, that incremental file requires a specific full (no -p option) send file to restore them with the receive command. The incremental send file must always be relative to a full send file; OR you have to keep all intermediate incremetal send files and ‘receive’ them in order to do a restore.
Whereas when received on btrfs, the resulting snapshot is a completely whole snapshot. Therefore the retention requirements are much less. I only need to keep one snapshot in common on the send and the receive btrfs file systems.
@pfrields, @jakfrost can I proceed with the workflow? It is a long time that I don’t write an article on the Fedora Magazine.
I created a new user story on teams.f.o.
Correct?