Talk:Snapper

From ArchWiki

New article structure

Thinking about adding two new subsections (modify and delete configurations), I observed the structure of the article was not grouped. Could be better to change article structure to (e.g.):

1       Installation
2       Configuration
2.1       Create a new configuration
2.2       List configurations
2.3       Modify a configuration (new subsection -> snapper -c config set-config option=value)
2.4       Delete a configuration (new subsection -> snapper -c config delete-config)
3       Snapshots
3.1       Take snapshots
3.1.1       Automatic timeline snapshots
3.1.1.1       Enable/disable
3.1.1.2       Set snapshot limits
3.1.1.3       Change snapshot and cleanup frequencies
3.1.2       Manual snapshots
3.1.2.1       Simple snapshots
3.1.2.2       Pre/post snapshots
3.1.3       Snapshots on boot
3.2       List snapshots
3.3       Delete a snapshot
4       Access for non-root users
5       Tips and tricks
[... same as original ...]

This would group important topics, such as configurations and snapshots. I think it would be a better way to structure the article. --AlonsoLP (talk) 10:45, 22 January 2019 (UTC)Reply[reply]

New page suggestion: Btrfs Snapshots

The main article about Btrfs is already very long but does not cover the tools for working with snapshots, even though some of these tools are already in the repositories, and are popular. There is this article about Snapper, that covers some of these tools, but the article about snapper should focus on Snapper itself, and maybe tools based on snapper, but not independent tools. It is also important to show which tools are based on snapper and which tools only require btrfs itself. The Snapper article mixes both tools. -- Teateawhy (talk) 03:09, 11 January 2020 (UTC)Reply[reply]

A new layout

Hi Archlinux wiki contributors,

I've wrote a guide for LUKS+Btrfs installation, completed with a new layout. What about adding the new layout to Snapper page?

Cheers -- S0x9v (talk) 13:24, 4 December 2020 (UTC)Reply[reply]

I would say even the revision you proposed in Suggested Filesystem Layout section is a bit bloated. I totally agree with Lahwaacz's reversion. In my understanding, the suggested layout you proposed in your earlier edits serves multiple purposes that are easily separable:
  • A better alternative to the ugly file structure caused by snapper rollback as described here. Here I would actually agree that mounting 0/snapshot is a good idea because it preserves the functionality of snapper rollback.
  • Making separate subvolumes for Snapper#Preventing_slowdowns.
  • Making separate subvolumes for preserving information during rollbacks as in Snapper#Preserving_log_files. Maybe even the subvolume for /home should be put into that section and that section renamed to "Preserving Information".
So for simplicity's sake, they should be put in separate places so that readers of the wiki can choose what to adopt. A personal blog might be a better place for the edits you are proposing.
Fanzhuyifan (talk) 15:26, 4 December 2020 (UTC)Reply[reply]
Actually 0/snapshot does not preserve the functionality of snapper rollback:
snapper internally reserves 0 for current system, as you can see here. Also 0/snapshot lacks info.xml. Therefore installing system into 0/snapshot is purely for aesthetic reasons (last ASCII art). We still need to force snapper rollback --ambit classic when rolling back for the first time since snapper does not recognize 0/snapshot.
As for "bloated", the layout I proposed is taken directly from various root on ZFS installations. As in here and here. They are not bloated, just necessary for different use cases. It's essential to have a separate /var/lib/libvirt and apply chattr +C /var/lib/libvirt on it if you use qcow for QEMU disk image, for example.
I agree the separation is not needed for all use cases and therefore should be put into Snapper#Preventing_slowdowns and Snapper#Preserving_log_files, as you've proposed. But this info must be on the wiki page to inform potential users, not on some unindexed blog page. It can actually be a quite frustrating experience when you experienced terrible performance with your system, only to find out much later that there's some gotchas laying around.
User homes can be automatically created as subvolumes with useradd -m --btrfs-subvolume-home $username.
Cheers, -- S0x9v (talk) 08:34, 5 December 2020 (UTC)Reply[reply]
My bad. I thought "In this scenario, after the initial setup, snapper needs no changes, and will work as expected" meant that snapper rollback would work as expected.
I don't use the "qcow for QEMU" you mentioned and I don't know what it is. But if the configurations you are proposing are only relevant for those users, I would suggest putting the relevant materials in the wiki page for QEMU.
As for the Ubuntu and Debian default layouts you mentioned, Arch Linux is not Ubuntu or Debian. We start with no partition and lets the user take full reign from then on. In line with the principles of Arch_Linux#Simplicity, I would say let's just keep the most essential configurations and guides for snapper on this page, and move the advice and cautions to their respective places.
Fanzhuyifan (talk) 08:59, 5 December 2020 (UTC)Reply[reply]
snapper rollback will work as expected, only rolling back for the first time needs snapper rollback --ambit classic.
Cheers, -- S0x9v (talk) 10:16, 5 December 2020 (UTC)Reply[reply]
I didn't know that! I think if you are going to mention this, you should mention the whole thing -- say that only the first roll back needs special treatment and maybe provide a brief explanation of the reasons, if possible.
Fanzhuyifan (talk) 11:54, 5 December 2020 (UTC)Reply[reply]
.qcow is the default virtual disk format for QEMU, which stands for QEMU Copy-on-Write. The underlying filesystem already has this attribute and another layer on it will induce significant performance penalty.
I think this piece of information is more relevant here than in QEMU:
Considering the layout is determined during installation, and everyone installing Archlinux on Btrfs will be referencing to Snapper#Suggested_filesystem_layout. We need to tell them right here, in a note, that if you are going to run virtual machines you must create this additional subvol and disable CoW or the performance will suffer. Also /etc/fstab will be generated in the next step with genfstab, which includes this subvol.
Cheers, -- S0x9v (talk) 10:16, 5 December 2020 (UTC)Reply[reply]
In that case, I would say a new section titled "Virtual Machine Recommendations" would be a quite reasonable place to put your tips that apply for virtual machine users.
Fanzhuyifan (talk) 11:54, 5 December 2020 (UTC)Reply[reply]
Yes, Arch Linux is not Ubuntu or Debian, as Lahwaacz have already pointed out, but more detailed. I've incorporated Archlinux specific changes to my layout.
Cheers, -- S0x9v (talk) 10:16, 5 December 2020 (UTC)Reply[reply]
There is some very interesting stuff here, and in User_talk:Lahwaacz#Btrfs_layout. It's difficult to find for the average user though, shouldn't the suggested layout be updated to reflect those tips ? ie {@,@home,@var_cache,@var_log,@var_tmp} ? -- Cvlc (talk) 03:35, 25 November 2021 (UTC)Reply[reply]
I added a tip that suggests to create more subvolumes. Is there anything else in this old discussion? — Lahwaacz (talk) 17:53, 14 August 2023 (UTC)Reply[reply]

Deleting Orphaned snapshots (and snapshots in general)

Snapper marks snapshots as read only, so rm fails with a cascade of "Read-only filesystem" errors. The solution is to either remove the subvolume with btrfs subvolume delete or set it as read-write before removing it. Should this be mentioned somewhere?

It also might be helpful to mention that the subvolume itself is not the numbered directory, it's a subdirectory named "snapshot"; attempting to use btrfs subvolume commands on the numbered snapshot directories will also fail.

Rbuchberger (talk) 13:39, 5 May 2021 (UTC)Reply[reply]

Deleting a subvolume is not specific to Snapper. -- Lahwaacz (talk) 16:29, 5 May 2021 (UTC)Reply[reply]

Preserving log files

See this longer systemd issue: "/var stays busy at shutdown due to journald". —This unsigned comment is by SamirNassar (talk) 22:49, 26 November 2021 (UTC). Please sign your posts with ~~~~!Reply[reply]

Adding a mention about booting into read-only snapshots

I use snap-pac-grubAUR on my system to have snapper (via grub-btrfs) generate snapshots and add them to the GRUB boot menu.

The developer of grub-btrfs has mentioned the difficulty booting into read-only snapshots (namely, some services that depend on a writable /var directory won't start, and you won't get a GUI) and has posted a fix in the README for the package.

I think it'd be appropriate to mention this somewhere, as I think a user would assume that simply installing snap-pac-grub would be sufficient, and a lack of GUI/other services isn't what a normal user would expect.

The fix for this is adding grub-btrfs-overlayfs to the HOOKS section in /etc/mkinitcpio.conf

The developer's suggestion to first copy the files located at /usr/lib/initcpio/hooks/grub-btrfs-overlayfs and /usr/lib/initcpio/install/grub-btrfs-overlayfs to /etc/initcpio/hooks/ and /etc/initcpio/install/ seems superfluous, as mkinitcpio reads the files at their default location just fine, but it may be wise to include that step, as well.

Would it be appropriate to create a new grub-btrfs page just for this one tip? Or does it make sense to include this in the section Snapper#Wrapping_pacman_transactions_in_snapshots?

Mbc (talk) 18:37, 5 March 2023 (UTC)Reply[reply]

My take on it is that some users may still want volatile ro (?), but it is certainly useful to add info for it, yes. I suggest to add a tips& tricks subsection 5.1.2 for it and change the pacman hooks crosslink for snap-pac-grub to point to it. The extra subsection can link to the dedicated readme for it, linking the original issue it resulted from may be useful too. Regarding the copy of files I agree with you, but it can be mentioned in verbose that it is superfluous to copy. Probably the dev has not yet updated the readme accordingly (or forgot), but we cannot tell. Copying to /etc saves you headache in case the packaged hooks change functionality (I'm not using the package, cannot judge how likely). Also cool that the readme includes instructions for dracut users, which can be pointed to as well. --Indigo (talk) 11:27, 8 March 2023 (UTC)Reply[reply]
Added the subsection Snapper#Booting into read-only snapshots - open to any improvements or revisions. Mbc (talk) 18:56, 8 March 2023 (UTC)Reply[reply]

Native --command for wrapping shell commands in pre-post snapshots

Section 5.1 of the article suggests to use snp to wrap any shell command in pre-post btrfs snapshots. I believe the wiki should also mention that using the native --command option of Snapper is possible, and refer to the comment in the snp script for the choice of snp vs native --command. I'm happy to write that if you agree. PingCrimson (talk) 09:05, 6 March 2024 (UTC)Reply[reply]

Good idea. Since the tools in section 5.1 are pacman-specific and snp is more universal, you could alternatively add a Template:Tip with a couple of sentences mentioning snpAUR's general feature under the closing sentence of Snapper#Pre/post snapshots, which links down to 5.1.
As a sidenote: the wiki does not use Help:Style#HTML tags, you can get an overview of markup in Help:Style/Formatting and punctuation#Cases by formatting/punctuation and when you click "edit-source" for a section. --Indigo (talk) 20:36, 6 March 2024 (UTC)Reply[reply]
Done, and thanks for the tip. Feel free to send any feedback. PingCrimson (talk) 10:16, 9 March 2024 (UTC)Reply[reply]
Ok, very good. See edit summary of Special:diff/802877. The italics of Special:diff/802793 were done for consistency with the subsection name. I later removed the link down in the tip, because the section already ends with one. --Indigo (talk) 20:32, 10 March 2024 (UTC)Reply[reply]
That's great, many thanks! PingCrimson (talk) 16:14, 11 March 2024 (UTC)Reply[reply]