Dear community, i have a little understanding question. So here it goes:
I use btrfs and snapper to do some snaphots. I’m using systemd-boot with esp mounted at /efi.
Because of systemd-boot, the kernel lives in /efi as well. As that is formatted with fat, it won’t be snapshotted. That’s why i use this little pacman hook, to rsync /efi over to the btrfs partition (-> /.efibackup): https://wiki.archlinux.org/title/System_backup#Snapshots_and_/boot_partition
i just modified the paths to fit my setup. Now to my question. Shouldn’t the hook run PreTransaction?
I mean, i like to do my backup beforehand, not afterwards!? But in the hook from the wiki its When = PostTransaction
It should run post transaction. However, if you are using snap-pac, make sure it runs before the post-transaction snapshot.
Basically, what you are doing is putting a copy of the /efi partition into the btrfs partition. Then future snapshots will contain it. That way, when you restore, you will have a copy of /efi that matches the system.
Thanks for your reply @dalto. I dont use snap-pac. I only make use of Pre/Post Snapshots when updating, like: sudo snapper create --command "sudo pacman -Syu" --description="Sysupgrade"
I understand the concept that you describe in your second paragraph. I just can’t wrap my head around that PostTransaction point in time. Btrfs-snapshots aside, let’s say i use ext4 and want to backup my /efi partition prior to a kernel update… Well if i would do a full backup of my system, i usually would do it before i’m doing the update, not after because thats pretty stupid
The goal in this case, is to make sure that you have a copy of your efi partition that matches whatever snapshot you are restoring.
The way to achieve that, is to backup your efi partition after installing kernel updates. The key is that it needs be done after the kernel is updated but before the snapshot is taken.
Don’t think about the backup of the efi partition as a “backup”. The timing of that can happen any time before your “backup”. Since it can happen any time, the best time to do it is right away after a kernel is updated.
IIUC the confusion comes from the assumption that you are creating one backup, while you are creating two (Pre/Post).
The rsync command in the Archwiki Hook is just an example and is not connected to snapper Pre/Post snapshot command. It is a suggestion for a general backup strategy, which you set it and forget it. So you would probably want the currently running system’s contents, in case of FS failure.
The rsync target folder would be on/by the latest (most current) snapshot.
Since the snapshots are created (and the /efi is rsynced) after the (snapper) command, the old /efi will be kept with the previous snapshot. You just have one more snapshot (without /efi) per transaction.
As long as the snapshots are not bootable, there is no major/stressing thing to think about.
I don’t think the OP is taking pre/post snapshots. According to the above they are taking manual snapshots.
Just to be clear, once the hook runs the first time, all snapshots will contain the efi copy. They can be taken before the transaction, after the transaction or anywhere in-between. They will all contain a version matched to the snapshot.
I don’t use btrfs, so my perception only comes from RTFM, which suggests that the specific command is the simple way to create two (pre and post) snapshots, when you want to contain consequences of only one command (sysupgrade with pacman).
Just to avoid the usual xyproblem, and add to understanding, IMHO, snapshots implementation would vary, depending on the reason and intended usage of the snapshots.
As snapper snapshots are not convenient to create bootable rescue alternative (like grub-btrfs, or timeshift), they can be used for a classic backup. If the system fails, the user would use standard rescue methods (boot to Live USB, chroot in the system, etc.) and recover full or partial content from a previous snapshot. In this case, only one (Pre) snapshot is required to contain a pacman SysUpgrade. Also, the /efi partition need not be in a bootable form (mountable partition with relevant name), so rsyncing to a folder inside the relevant snapshot would be available for copying files to a recovery scheme (paired to the relevant snapshot).
In case snapper snap-shooting is specially configured to create bootable snapshots (ro, or other), rsynced /efi partition should be able to be mounted properly, paired to a specific snapshot. AFAIK, this is a demanding task in regard to configuration.
Does any of the above make sense, or where is the mistake?
Thanks for your replies, guys. Yes, i make use of pre/post snapshots “the manual way” as posted above ( sudo snapper create --command "sudo pacman -Syu" --description="Sysupgrade")
Besides that, im doing regular timeline snapshots via snapper (and for convenience i use that little gui frontend called btrfs assistant, @dalto may have heard of - thank you for that nice tool by the way!).
Anyway:
Thtat’s the point i guess.
So i think it is just problematic at the beginning. Say you just created that hook. Then you create a snapshot (manual, or maybe as a pre-snapshot from the command that i use - doesn’t matter), then pacman -Syu → kernel gets updated. Afterwards(!), the hook creates the copy of your efi partition. Maybe another snapshot afterwards (manual / post-snapshot from the command that i use).
Alright, now you encounter some problem. Maybe and want to revert to the snapshot you created before the pacman -Syu command. Now what’s the situation according the efi partition? The kernel got updated, so your current efi partition would not match your snapshot you took beforehand. So you need to revert your efi partion as well. Your first (pre) snapshot does not contain a copy of your efi partition, because the hook did not run yet. Your second (post) snapshot does contain a copy of your efi partition, hooray! But wait, it contains the same, updated version of your efi partition (->kernel) as your actual efi partition. Shoot, i’m trapped!
That’s what i mean.
From now on, it gets irrelevant, as @dalto said. All upcoming snapshots (manual or timeline or whatever) contain your esp-copy now. The next pacman -Syu containing a kernel update comes. You do your pre-snapshot → the same copy of your esp will be included as in your snapshot one hour ago, or yesterday.
You do your update - kernel gets updated - esp gets copied by the hook - post snapshot: contains the updated esp/kernel. Now, when you want to revert to a previous snapshot, your pre-update-snapshot contains the “old” esp/kernel that you can copy back and your esp will match your snapshot/reverted system
Yeah, that is my bad. I misread it the first time.
Yes, but the same thing would happen even if it was pre-transaction. snapper is taking the snapshot and then running the command. That means the snapshot happens before the copy occurs so the snapshot would not contain the ESP data you need.
You could do the snapshots with hooks instead to guarantee the correct order but if you do that, only your pre-transaction snapshots would be viable. All the other ones(post/manual/timeline) would have the wrong data.
xyproblem, and add to understanding, IMHO, snapshots implementation would vary, depending on the reason and intended usage of the snapshots.
- thank you for that nice tool by the way!).
. So in that scenario it really does make no difference. Thank you.