Im scratching my head, I have searched and read a few posts but i think they are all out of date or something.
Im looking at btrfs for the first time.
Timeshift is working on btrfs properly but when i check grub for auto entries it only had 1 entry created by timeshift although i created several manually? Maybe it just creates the grub entries after pacman updates, i don’t know how it created one entry but it wont create any more. It will if i manually use update-grub though?
I did some searching and it seems that i should have a service grub-btrfs.path but i dont? timeshift-autosnap-manjaro is already installed.
The list of snapshot is not updated in boot menu automatically, you need to manually update it by launching the sudo update-grub. Make sure your grub-btrfs package has been installed
UPD:Also make sure that you do not have a restriction on the number of snapshots.
grub-btrfs is installed. Yea it does update the grub list if i manually update-grub but it had already created a menu and a single entry by itself already? i didn’t do it, i didn’t even know grub would have this option at the time but i spotted the timeshift menu and the single entry after a reboot.
Anyhow, so your saying it cant do it automatically? (even though it did once) , i have to run update-grub? why cant it do that, it has root access its only a single command? scratch head
If you have a Timeshift-Autosnap-Manjaro package, then an automatic snapshot of the system will be created before each update of the system and GRUB update will be executed. You can also create a Systemd service so that it would happen automatically.
Yes, at least it was conceived. You can check if this happens. Look, whether the lines in the console log appear during the update process (if the update through Pacman) or go to the log when updated through the Pamac (button in the form of an arrow in the lower right corner during the update):
Detecting snapshots ...
Found snapshot: 2024-06-05 22:06:53 | timeshift-btrfs/snapshots/2024-06-05_22-06-53/@ | ondemand hourly | {timeshift-autosnap} {created before upgrade}|
Found 1 snapshot(s)
Unmount /tmp/grub-btrfs.hmVuRJTdNt .. Success
yay, but no problem i shall keep a look out during the next update.
Thx.
P.S.
I know i shouldnt ask another question but meh.
I am just looking at btrfs-assistant and although it does list all the timeshift snapshots, the restore button is grayed out for all of them? Dont suppose youd know why?
I’m not sure, but it is possible that btrfs-assIstant uses Snapper for snapshots, not Timeshift. You can try to use the built-in functionality to create/restore, although I prefer Timeshift
No problem. Regarding the differences in the btrfs-assistant graphic interface, you probably have not installed snapper and btrfsmaintenance packages. As a result, the corresponding sections are hidden.
I would think twice before i go BTRFS, its a advanced Filesystem and if you have issues, you run into more problems as with a EXT4 Filesystem.
If you still want to go the BTRFS path, i recommend at least to use Timeshift Rsync instead Timeshift BTRFS, because Timeshift rsync is easier to restore.
I was also interested to check out BTRFS in the past, i mean it has interesting features for sure.
But there was 2 Topics which showed how difficulty it is to restore Timeshift btrfs and why the most people decided to go btrfs-assistant instead.
The Pain Topic:
Timeshift Rsync also just gives additional backup safety, while btrfs (if i understand it right) only let me restore the files as long as the HDD/SDD exists.
@Molski
Of course i don’t have first hands experience with BTRFS, if my information’s are wrong. Please correct me then. I’m always interested to learn more.
well thx for the feedback, im not on my main os or even the same drive, i have iso system images plus i use borg to my nas every couple of hours which is z3 + z3. Im just tinkering atm.
However, are you saying that if one was to tinker with btrfs that timeshift may not be a good idea, should i look at snapper ?
Or are you saying to give btrfs a miss all together?
When using RSYNC, the whole meaning of BTRFS snapshot is lost, then it is better to use Borg, for it there is Gui Pika-Bacup. He has good compression and increasing snapshot. In fact, it is possible to create BTRFS snapshot on other discs (in addition to the root), it just is not configured by default and you need to spend time to make out all the nuances. RSYNC just like Borg will not allow you to boot into a snapshot of the system
In fact, it doesn’t matter which file system you use, each has many supporters and those who dissuade it to use. This is one of those permanent holy wars on the Internet. It doesn’t matter that these are ZFS, BTRFS .EXT 4, bcachefs. If someone had a negative experience, he will dissuade you and it does not matter that many work well.
You know, i wondered why Linux tends to favor Btrfs over ZFS for snapshots and backup-type file systems? I was quite happy after getting used to ZFS on Truenas, pity i have to learn all this jargon again. I think ZFS is actually more reliable as well even if its not directly integrated with the kernel.
They did not agree on the use of a license. Linus said that it was not good to mix the license and that was all over. Some distributions allow you to install the system on ZFS, such as Cachyos or some versions of Ubuntu. I tried to use ZFS on one of my disks and honestly did not see the big advantages over BTRFS. Speed would be better, but I did not want to sacrifice the use of RAM.
This is a cool system for a NAS or a large server where you can give dozens of gigabytes RAM for cache, but it is doubtful on the home computer.
Which really hits the nail on the head when it comes to open source. If groups or individuals don’t agree on a progression then no problem just fork it into 2, 3 or however many or even build something completely different. just think if all that extraneous energy and brain power were put into a more single minded progression.
Then Bcachefs appeared and everyone began to say that it would be faster and better than BTRFS, but I did not find this confirmation, the only comparison that did not show strong advantages, it may change over time.
In fact, many people around the planet spend more time on compliance with the rules than to create something, these are people, at least at the moment.
I know I’m in a part of those other troublesome threads. I’m sure there was a bug, not even that long ago, in Timeshift when you used the restore button/command (at least for me). It would point your root volume to the wrong place, and appear to work, and does! But it would kind of create a mess the way it did it improperly, especially if you used it multiple times. It does work properly now, I’ve done it quite a few times since then.
For me, with knowing almost nothing about btrfs, there was one thing I needed to know, and everything was easier.
The moment it clicked for me, is when I just mounted the drive without any subvol option, you can mount it in as many places as you want at the same time. This is how you can see all of Timeshift’s snapshots actual files, and read or write? to them. (The RW option on these snapshots, I am not a fan of either.) But to start, just mount it like ext4, but with subvol=@ for the root volume. The @ symbol is just a convention to name volumes with, starting with the at symbol, like @home, @var, etc. But the starting @ is just a convention. From there it’s all downhilll, at least it was for me.
There are also very easy to use btrfs <command> <option> commands, all in one place. And I would just man btrfs-command, very well documented, which was quicker for me over web searching. Start with subvolume and filesystem, which can be shortened to btrfs su sh / for subvolume show for example. With ext4 you need to install dozens of apps, to gain a fraction of what btrfs-tools does. So that also makes many things easier.
I guess you are right when you are just comparing it for backup, and only using TImeshift with its limited options. But snapshots are usually just rollback points. I think the confusion with backup and snapshots, is snapshots are great to backup (live) filesystems, but are not a backup themselves.
Rsync has to read both the source and destination, and write the changes. Compared to a practically instant btrfs snapshot. So there are two copies with Rsync, and technically this is more like a backup, with having two copies. Linux is great, and rsync and just the cp command can backup things like this. But btrfs gives you those options, plus soooo much more. Rsync isn’t an exact copy, and there are circumstances where it actually fails outright.
With btrfs if you change 4 kB of a 4 TB file, the snapshot will only take up 4k, plus insignificant metadata. (Compared to reading hundreds, or thousands? of gigs. Then sending a 4 TB file.) This is every block modified to the filesystem, even if you’re doing advanced things rsync doesn’t do. So it’s already more reliable, and way more efficient.
When mounting the btrfs root drive (with no subvol option), you just see the snapshots in /mnt/timeshift-btrfs/snapshots/*/[@|@home]
From there you can deal with the snapshots as you see fit. Even tar, cp -a, or rsync them, but I’m always trying to get away from that. (I started out using btrfs send to send snapshots to other drives, or even other hosts). The advantages of btrfs over something like ext is pretty substantial, except for raw performance, but the flexibility and data integrity outweighs that IMHO. I think the incremental sending, and/or Snapper is the greater learning curve. Btrfs itself I found really easy.
i shall keep a look out during the next update.
