I have been ruining arch for about a month now and I have been looking into setting up backups and such for my system and I heard that BTRFS works really well with timeshift. the only problem is that my fs is currently ext4. Is it worth swapping to BTRFS and losing all the data i have in this partition or should i just stay on ext4?
timeshift is not backups. If the disk fails, all the timeshifts are also lost.
A backup is copying the data onto one or more different devices.
If you want to also protect from fire burning down the building, you also send one copy to a different site/building, so if the first building burns down/floods, you have a backup elsewhere.
The snapshot features in btrfs do make some aspects of backups easier to do.
The snapshot feature also makes it easier to rollback on a failed system software update.
The timeshift helps if you accidentally delete something, you can then undo it by restoring the time shifted copy without having to search the backups.
2 Likes
How I’ve used BTRFS since 2015 is having two storage devices configured to use BTRFS RAID1 ( not native RAID1 from BIOS )
BTRFS on every write will checksum and clone the data and on every read it verifies the integrity of the data that just been read, if it succeeds, you get the data, if it fails, it reads the data from the other block device and verifies the data, if that succeeds, it will automatically repair the corrupted block while while sending you the correct data.
If both fail, I don’t know, that’s not happened with me yet. I’ve been in the situation numerous times over the years where my data has corrupted but BTRFS has fixed them all, including when FW16 BIOS 3.02 and later buggy firmware from Western Digital, BTRFS has saved my data
Yes, I would say BTRFS is worth it but for backing up data, do as @James3 said too
2 Likes
I used a read-only btrfs snapshot/subvolume (edit: for the root filesystem, not home - home is addressed in separate backups) when I upgraded my FW 13 from Fedora 39 to 40. If for some reason F40 caused problems (it didn’t), I could have gone back to 39 easily.
Having said that I did this manually, not using timeshift.
1 Like
And if it help you can convert ext4 to btrfs in place no lose of data in the partition…
https://btrfs.readthedocs.io/en/latest/Convert.html
https://amireslampanah.com/2021/09/complete-conversion-from-ext4-to-btrfs-on-arch-linux-and-other-linux-distros/
But as best is always to have a backup of important data before 
1 Like
As I understand it, the btrfs-convert program isn’t supported or recommended anymore. That may have been reversed since I last looked.
Always!
I have used btrfs-convert successfully twice, failed once. It’s a use at your own risk situation to be sure.
That being said, btrfs + btrbk + btrfs-maintenance has been nearly miraculous for the dozen or so different x86 and aarch64 devices on my network. Ability to duplicate data in place on a single device, have the disk check itself (“scrub”) periodically, easily mirror in RAID1, transmit compressed incremental backups without uncompressing / re-compressing, and to precisely segment what gets backed up via how you set up your subvolume structure are the key features for me.
Only thing I wish we had was per extent encryption, but that’s supposedly being worked on by an engineer at Farcebook.
After a year living with btrfs on my daily drivers, NAS, backups, everything, I shan’t be going back to ext2/3/4 after more than a decade using it, if that tells you anything.
I had low expectations but was pleasantly surprised there, that stuff came a long way. Turned the ext4 arch install on my fw into a btrfs one with very few issues.
Oh wow, I had not only had no idea such a tool existed, but I would’ve actively guessed such a tool couldn’t exist. That’s exciting, maybe I can easily switch afterall.
Do a backup first please, it works better than I’d expect but I did expect it to not work.
1 Like
I think ext4 to btrfs conversion results in a more limited set of btrfs features. You can search to find out what those limits are and if you need those features or not.
I think the most interesting bit of btrfs is the data integrity capability.
But, all that data integrity stuff has to follow a chain of events. Imagine the data being flipped in memory (because of faulty memory) and written down bad?
Hence the request from many to have ECC enabled systems.
As my laptop does not have ECC, I don’t bother about using btrfs. I do that on my server though! As that’s where my data is kept.
Does the FW 16 support ECC? I recall intel charges extra for that support, but my understanding was that amd chip’s didn’t have the extra cost add.
Reason it almost makes no sense in using btrfs or zfs on any laptop that does not support ECC.
No sense is a massive overstatement, even without ecc the window where errors can be added that won’t be detected later quite narrow.
That’s like not wearing a seat-belt cause you could also get run over before getting into the car.
Either you invest in a machine that takes care of that, or you don’t. My philosophy 
I agree that there are a lot of different ways to construct a risk/threat model. Each use case is going to have it’s own set of needs.
I started playing with btrfs a few months ago on external drives, and when I recently got my Framework 13 I decided to use it here, too. Declared “stable” over a decade ago, I guess I can finally trust it.
No, on my internal SSD I don’t have redundant copies, but even on a single device discovering bitrot is a good thing. (And I do do backups.)
(And even if you don’t have ECC RAM, detecting disk errors is still a good thing.)
There do seem to be two things to worry about:
-
Snapshots.
Too many of them are a problem, both because
btrfshas limitations and because they look like a good way to confuse me, with tons of snapshots everywhere, even snapshots of snapshots…I expect to use them very little, likely for just temporary things, such as before doing a backup, backup the snapshot and it will not have any version skew, as I continue to use my computer for other things. Once the backup is complete, delete the snapshot. If I want version control on a directory something like
githas better management tools.Snapshots and defragmenting also don’t get along, and CoW disks apparently like to fragment. I don’t know how big a problem that will be in practice.
-
Full disks.
A reliable way to hose a
btrfsvolume is to merely fill it:“Sorry, disk full.”
“Fine, I’ll delete some stuff.”
“Nope, it’s too late! That won’t fix things…”
Sounds like the thing to do is to have some unused space off the end of my partition. If it fills up resize it bigger, delete stuff, immediately resize back down to the previous size…and resolve not to fill my disk again.
Some people complain that btrfs doesn’t include encryption, but I’m happy with that, I run it on top of a dm-crypt device, and dm-crypt is well proven, that seems like a more safe and secure approach. Encryption is easy to get wrong, file systems are easy to get wrong, expecting to do both together—flawlessly—is a big ask. I’m happy to separate the two.
But in general, btrfs looks good. I even use it for my /boot partition.
-kb