But…that “trick” is exactly how we rollback btrfs snapshots. Move the old one out of the way and copy the snapshot to restore into it’s place.
1 Like
Trying to uderstand that. Are they separate physical drives? I found this on data storage
They are saying they use Btrfs on their PC since they interact with it the most to utilize all its features. They use Ext4 for their storage, aka their backups because when it comes to backing up your stuff, you really just want something reliable and solid that just works, which Ext4 is proven to do.
My current setup probably similar: 256GB SSD on my laptop with Btrfs, but I also have an external 2TB SSD I use for my backups, which is Ext4
1 Like
Move the current snapshot out of the way then there are 3 different ways to rollback selected snapshot:
- Copy the selected snapshot to restore as you wrote.
OR
- Create a new snapshot from the read-only snapshot in place to boot.
Example:
btrfs subvolume snapshot /mnt/@snapshots/home/4/snapshot /mnt/@home # then reboot
OR
- Boot directly into the selected non-read-only snapshot, then set it as the default for booting (That is how Timeshift work).
The point 2 is efficient. You do not need to copy the selected snapshot to restore.
Yes, it is.
1 Like
This is correct behavior from my point of view. If you rollback to a snapshot from last year it makes all newer snapshots of that dataset obsolete.
And zfs automatically deletes the newer snapshots during rollback with the ‘-r’ option.
zfs rollback -r mypool/dataset@last-year
Not sure what this “awkward trick” is that you are referring too.
1 Like
How do you know which snapshots are good and useful? but they would accidentally deleted if you do not know they are good.
The “trick” helps that ZFS file system is cloned and keeps the snapshots safe, then you can check them if they are healthy, when snapshots are bad, then you can rollback a last good snapshot to delete all bad snapshots.
But you could not get good/useful data back after rollback if it is a part in newly deleted snapshot without cloning file system.
I want to test and run 2 different snapshots, both get different tasks. But that is hard for ZFS to keep both snapshots for testing or I have little experience about ZFS.
ZFS is very suitable for live system with database in server.
BTRFS is good for desktop and testing.
That’s in my opinion. 
Both are CoW filesystems not like other non-CoW filesystems e.g. ext4 that is not safe.
I would assume you start the rollback with the youngest available snapshot. If that does not work you go to the second youngest, etc., until you end up rolling back the oldest snapshot. In that scenario you are not deleting any useful younger snapshot.
1 Like
If you have a desktop PC with a RAID (like I do) you only have two options. Either you use mdadm+lvm+ext4/xfs or you use zfs. And in that comparison zfs is the clear winner in all aspects.
btrfs is not suitable for raid. Not for raid5/6 and not even for raid10 because they do not have a “true” mirror concept like mdadm or zfs.
1 Like
I am not sure see the difference here other than semantics.
In btrfs, everything is a subvolume, including snapshots.
Taking a snapshot is making a copy of the subvolume.
1 Like
Yeah, I already knew BTRFS is not for RAID levels but Raid 1 would be ok. I don’t use RAID in Desktop.
But I don’t see that size of snapshot is big in disk after copy of the subvolume?
Example: 100 snapshots of the same subvolume 100 GB, but I do not see 100 x 100 GB in the disk, not like cloning 1:1 size.
A zfs clone is the same. It takes no additional space.
1 Like
This is the beauty of a copy-on-write filesystem. Even xfs can do things like this with “cp --reflink”:
When --reflink[=always] is specified, perform a lightweight copy, where the data blocks are copied only when modified.
With cp --reflink you can create snapshots on xfs too.
3 Likes
Certainly not for Linus Torvalds 
It’s great that we have several options.
2 Likes
A few things. First, a rollback is not the same thing as replacing subvolume with a snapshot. A rollback rolls the dataset back to a prior point in time. Doing that, necessitates removing the snapshots as otherwise it wouldn’t be the same as it was at the point you are rolling back to.
The purpose of snapshots is not really to be able to do system level restores. That is only one use of them. When we rollback a dataset, we aren’t trying to rollback the state of the system, we are trying to rollback the state of the dataset itself. For example, if you have dataset called mypool/home mount at /home and you perform a rollback on it, the dataset should now be identical to how it was at the point the snapshot was taken.
There is a fundamental difference in the way zfs and btrfs treat snapshots. In zfs, snapshots are part of the dataset that you take the snapshots of. In btrfs, snapshots are independent subvolumes. The only real difference is that the snapshot has data in it that shows which subvolume it was a snapshot of.
However, this creates an interesting problem. As soon as you restore a snapshot, there is now no relation between the snapshots and the main subvolume. In fact, once you have done this, there is no longer a way to differentiate what is a snapshot and what isn’t because, technically speaking, they are all snapshots now.
In zfs, this is not the case. You can always differentiate between them and easily get a list which includes or excludes the snapshots. When you have a lot of subvolumes/datasets, this is beneficial.
In general, zfs has much more functionality and flexibility than btrfs. As is usually the case, more functionality comes at the expense of increased complexity.
That being said, as much as I prefer zfs for my personal use, it is only better if you are willing to invest the time to learn how to properly configure and use it. If you don’t want to make that investment, btrfs is definitely the better choice.
Also, I don’t want to people to think I am anti-btrfs. As many of you know I spend quite a bit of time working with btrfs and run btrfs on some of my systems.
9 Likes
If I understand correctly,
-
ZFS snapshots are real snapshots in the sequence list of dataset.
-
BTRFS snapshots are not real snapshots, but they are like nodes in tree, you can choose any node what you want to change data to create a new node as change state.
Agreed!
I first used Btrfs with snapper and grub-btrfs a few months back and it was good, but it is all terminal-based. When saw Dalto’s Btrfs Assistant, I was hooked immediately.
I would like to see it as a Calamares option once you check btrfs-progs (as it’s in the AUR, Calamares can’t install it) But if you decide on btrfs in Calamares, then take a look at Dalto’s link above.
1 Like
I wouldn’t say they aren’t “real”. I might say they are “independent”(They still share data).
Calamares can’t install AUR packages.
1 Like
Are they both self-healing?
That’s why I prefer btrfs. Also you can never have too much ram with zfs.
1 Like