How to Set Up Snapper and GRUB-Btrfs for Automatic Snapshots and Rollback on Arch Linux

How to Set Up Snapper and GRUB-Btrfs for Automatic Snapshots and Rollback on Arch Linux

arch linux btrfs linux linux filesystem snapper system snapshots

Abdullah Musa

June 12, 2026

Installing Arch Linux gives you a solid base, but setting up Snapper and Grub-Btrfs for automatic snapshots and instant rollback turns it into a truly resilient system.

This guide is part of the MusaBase Linux Series. For a complete overview, explore our Arch Linux Roadmap.

Welcome back to MusaBase! Today we’re picking up where we left off with Installing Arch Linux with Btrfs Filesystem to set up Snapper and Grub-Btrfs on that Arch Linux system. Now, as I said in my previous guide, because Arch Linux is a rolling‑release distro, the system can break sometimes. Or, in my recent case, since I experiment a lot on my Arch system, it tends to break even more often. Sure, I could fix the breakage by hunting down and removing every trace of what broke, but I’d rather save time than repeat the same manual fixes each time. The best automated solution I’ve found is installing Arch Linux on a Btrfs filesystem and setting up Snapper for automatic snapshots and rollbacks. And in today’s guide, I’m going to show you exactly how to do the same thing on your Arch Linux system.

In this guide, you will learn how to:

• Prepare your Arch Linux system for automatic snapshots and rollback
• Install essential tools like snapper and grub-btrfs
• Create a Snapper root configuration
• Create and fix the snapshots subvolume for top‑level @ integration
• Add a snapshots entry in /etc/fstab for automatic mounting
• Configure Snapper for automation
• Enable Snapper timers and GRUB snapshots integration
• Enable the overlayfs hook to make boot snapshots writable
• Finally, test that snapshots work by creating and rolling back to earlier points

By the end of this guide, you’ll have an Arch Linux system capable of rolling back to a point before anything went wrong. So without further ado, let’s get started!

---

Table of Contents

• Prerequisites
• Step 1: Install Packages
• Step 2: Initialize Snapper Root Config
• Step 3: Create and Configure Snapshots Subvolume
• Step 4: Configure Snapper
• Step 5: Configure Snapper and Grub-Btrfs Services
• Step 6: How to Create a Snapshot (Manually and Automatically)
• Step 7: How to Do a Rollback to Previous Point
• ❓ Frequently Asked Questions: Snapper and Grub‑Btrfs on Arch Linux
• What's Next

---

Prerequisites

This guide assumes you have already installed Arch Linux with Btrfs filesystem and have a basic CLI or terminal knowledge as we are going to perform every step on an Arch Linux TTY1 terminal session. But you can also follow the same steps on any desktop you're using on your Arch Linux system. If your Arch Linux system doesn't have a Btrfs filesystem, you can follow my Installing Arch Linux with Btrfs Filesystem guide after the installation, come back to this guide and continue. But for the automatic snapshots and rollback feature your system must have a Btrfs filesystem otherwise, the instructions in this guide won't work.

---

⚡ TL;DR: Snapper and Grub‑Btrfs for Auto Snapshots and Rollback on Arch Linux

A quick reference for the essential commands to set up Snapper automatic snapshots, integrate them into the GRUB menu, and perform a full system rollback on an existing Arch Linux Btrfs system.

1. Install packages:

   sudo pacman -Syu
   sudo pacman -S snapper snap-pac grub-btrfs inotify-tools

2. Create initial Snapper config:

   sudo snapper -c root create-config /

   This creates a nested /.snapshots we will fix next.
3. Fix nested snapshots subvolume:

   sudo btrfs subvolume delete /.snapshots
   sudo mkdir /btrfs-top
   sudo mount -o subvolid=5 /dev/sdXY /btrfs-top
   sudo btrfs subvolume create /btrfs-top/@snapshots
   sudo umount /btrfs-top
   sudo rmdir /btrfs-top

   (Replace /dev/sdXY with your Btrfs partition.)
4. Recreate mountpoint and add to fstab:

   sudo mkdir /.snapshots

   Get the partition UUID with

   sudo blkid /dev/sdXY

   . Then edit /etc/fstab:

   UUID=your-uuid  /.snapshots  btrfs  compress=zstd:1,noatime,subvol=@snapshots  0 0

5. Set permissions (optional but recommended):

   sudo chmod 750 /.snapshots
   sudo chown :wheel /.snapshots

6. Configure Snapper: Edit /etc/snapper/configs/root. Add your user and group to ALLOW_USERS="" and ALLOW_GROUPS="". Adjust timeline limits (TIMELINE_LIMIT_HOURLY="10", etc.) to your preference.
7. Enable services:

   sudo systemctl enable --now snapper-timeline.timer
   sudo systemctl enable --now snapper-cleanup.timer
   sudo systemctl enable --now snapper-boot.timer
   sudo systemctl enable --now grub-btrfsd.service

   Then update GRUB:

   sudo grub-mkconfig -o /boot/grub/grub.cfg

8. Add overlayfs hook: Edit /etc/mkinitcpio.conf, add grub-btrfs-overlayfs to the HOOKS array, then run:

   sudo mkinitcpio -P

9. Create snapshots: Manual:

   snapper -c root create -d "description"

   . Automatic snapshots are created on every pacman transaction.
10. Rollback: Reboot, choose *Arch Linux snapshots from GRUB. After booting into the snapshot:

    sudo mount -o subvolid=5 /dev/sdXY /mnt
    sudo btrfs subvolume delete /mnt/@  # or mv /mnt/@ /mnt/@.broken
    snapper -c root list
    sudo btrfs subvolume snapshot /mnt/@snapshots/NUMBER/snapshot /mnt/@
    sudo umount /mnt
    reboot

💡 After setup, verify with snapper -c root list and sudo btrfs subvolume list /. Your Arch system can now recover from a bad update with a simple reboot!

---

Step 1: Install Packages

In this step, we will install the core packages to make our Arch Linux system capable of rolling back to different snapshots we will make as we go.

• Run:

sudo pacman -Syu
sudo pacman -S snapper snap-pac grub-btrfs inotify-tools

• snapper: is responsible for creating, managing, and restoring Btrfs snapshots. Snapper can:
  • Create manual snapshots
  • Create automatic timeline snapshots
  • Restore the system to an earlier snapshot
  • If an update breaks the system, Snapper lets us roll back to a previous working snapshot.
• snap-pac: This package automates the creation of snapshots before and after running any pacman command. snap-pac automatically creates:
  • Pre and Post pacman execution snapshots.
  • So if an update or execution breaks the system, we have a recovery point without manually creating pre and post each time.
• grub-btrfs: Responsible for creating entries for Snapper snapshots and displaying them in the GRUB boot menu at boot time. grub-btrfs allows us to:
  • Boot directly into an older snapshot.
  • Recover from a broken point.
  • Let us boot into a working system even if the current installation won't boot.
• inotify-tools: This tool helps grub-btrfs detect when Snapper creates or deletes snapshots, because the purpose of this tool is to monitor file and directory changes.

So these tools work like this all together:

Snapper creates snapshot
        ↓
inotify detects change
        ↓
grub-btrfs updates GRUB snapshot entries

With the core packages installed and now that you know what each package does, let's head to creating and configuring the snapshots subvolume.

---

Step 2: Initialize Snapper Root Config

In this step, we will initialize snapper to create the /.snapshots subvolume and fix some @ or toplevel subvolume problems that are default in snapper.

2.1: Create Snapper Root Config

• Run:

sudo snapper -c root create-config /

The above command will create a Snapper configuration for the root (/) filesystem at /etc/snapper/configs/root and also creates the /.snapshots directory. Even though in the next few steps we are going to delete the /.snapshots directory, we run the snapper -c root create-config / command so Snapper can create its own default configurations such as:

• Which filesystem to snapshot
• Where snapshots will be stored
• Which retention policies to use

2.2: Create Toplevel @ Snapshot Subvolume

When we ran snapper -c root create-config / command, the Snapper created the /.snapshots subvolume along with other default configs on our system. Which is totally fine but with one exception. The /.snapshots that Snapper created was nested inside @ or toplevel. As if you run sudo btrfs subvolume list /, you will see the actual problem:

2.3: Why .snapshots inside @ is bad?

It's really bad in scenarios where we will actually perform a rollback on our system. Because when we perform a rollback, we replace @ entirely with an old snapshot. If our snapshots are stored inside @, they get wiped along with it, and we will lose all our snapshots at the exact moment we need them most. It's like travelling back in time and kicking our grandpa down the stairs kind of paradox. I hope I explained it well 🙃.

2.4: Fixing the Nested .snapshots Subvolume

• The fix is very simple, just run:

sudo btrfs subvolume delete /.snapshots

With the groundwork done for initializing Snapper config, let's head to creating the /.snapshots subvolume for Btrfs at the toplevel (@).

---

Step 3: Create Snapshots Subvolume @ Toplevel

In this step, we will manually create and mount the @snapshots subvolume for Btrfs at the toplevel. This step involves only a few commands, such as creating, mounting, umounting and deleting.

3.1: Create @snapshots at the Toplevel

• Run the following commands:

sudo mkdir /btrfs-top
sudo mount -o subvolid=5 /dev/sda3 /btrfs-top
sudo btrfs subvolume create /btrfs-top/@snapshots
sudo umount /btrfs-top
sudo rmdir /btrfs-top

Important: Replace the /dev/sda3 in the second command with your actual Btrfs root partition. For example, it may be /dev/nvme0n1p2, /dev/sda3, or another partition depending on your system.

• mkdir /btrfs-top: Make the btrfs-top directory, under the root filesystem, /. It's just a name, you can name it whatever you want.
• mount -o subvolid=5 /dev/sda3 /btrfs-top: Mounts the Btrfs partition (in my case /dev/sda3) at /btrfs-top. The subvolid=5 option mounts the top-level Btrfs filesystem, allowing us to access and manage all Btrfs subvolumes directly.
• btrfs subvolume create /btrfs-top/@snapshots: Creates a new Btrfs subvolume named @snapshots at the top level of the Btrfs filesystem.
• umount /btrfs-top: Unmounts the /btrfs-top directory from the filesystem.
• rmdir /btrfs-top: Deletes the /btrfs-top directory.

In a nutshell, we first create a temporary directory to use as a mountpoint. Next, we mount the top-level Btrfs filesystem (subvolid=5) to that mountpoint so we can access all Btrfs subvolumes directly. We then create the @snapshots subvolume, unmount the temporary mountpoint, and finally remove it because it is no longer needed.

3.2: Recreate the Mountpoint

• Now, we need to recreate the mountpoint for the snapshots so we can add it to /etc/fstab for auto mounting at everyboot for automation.
• Run:

sudo mkdir /.snapshots

3.3: Add @snapshots to /etc/fstab

• Next, we need to add the UUID of the btrfs partition to our /etc/fstab, so this subvolume auto-mounts at every boot.
• First get your UUID by running:

sudo blkid /dev/sda3

Important: Replace /dev/sda3 with your btrfs partition.

• Now, we can safely add our snapshots to /etc/fstab.
• Run:

sudo nano /etc/fstab

• In /etc/fstab, add the following line with your actual UUID:

UUID=cd3c8c4a-7406-4e15-baeb-88cb87a11f78  /.snapshots  btrfs  compress=zstd:1,noatime,subvol=@snapshots  0 0

• After adding the snapshots entry, press CTRL + O to save the changes then press ENTER to apply. To exit press CTRL + X.

3.4: Mount Snapshots Properly

• Next, let's mount and verify if it actually worked, run:

sudo mount -a
mount | grep snapshots

As you can see in the image above, the @snapshots is mounted at /.snapshots. This means it worked.

3.5: Set Permissions (Optional But Recommended)

• Run these commands consecutively:

sudo chmod 750 /.snapshots
sudo chown :wheel /.snapshots

• chmod 750 /.snapshots: This sets who can access /.snapshots directory:
  • 7: Means owner (root), can access, read, write and execute this directory.
  • 5: Means group (wheel), can only read.
  • 0: Means everyone else, no access at all.
• chown :wheel /.snapshots: This assigns the wheel group as the group owner of /.snapshots.

It's just a convenience plus security setting. Not strictly required for snapshots to work, but without it you'd need sudo for every single Snapper command.

• Now let's check if everything went well and accounted for, run:

sudo btrfs subvolume list /

And it's working.

With the toplevel snapshots subvolume mounted properly and set for automount at /etc/fstab, next let's configure snapper to use it without sudo.

---

Step 4: Configure Snapper

Now, we will edit /etc/snapper/configs/root remove the need for sudo for every Snapper command we will run and also edit Timeline settings for weekly, monthly, quarterly, etc.

• Run:

sudo nano /etc/snapper/configs/root

• In the opened file, scroll down with ⬇️ key and find these lines:

ALLOW_USERS=""
ALLOW_GROUPS=""

• ALLOW_USERS="": Lets us run snapper commands without sudo. Without this, every snapper command needs sudo.

• Add the name of your user and your user's group. As for me, my user is musabase and my group is wheel.
• Next, scroll down to these lines:

# limits for timeline cleanup
TIMELINE_MIN_AGE="3600"
TIMELINE_LIMIT_HOURLY="10"
TIMELINE_LIMIT_DAILY="10"
TIMELINE_LIMIT_WEEKLY="0"
TIMELINE_LIMIT_MONTHLY="10"
TIMELINE_LIMIT_QUARTERLY="0"
TIMELINE_LIMIT_YEARLY="10"

• The TIMELINE_LIMIT_* settings control how many snapshots to keep in each time category before old ones get deleted automatically.
• TIMELINE_LIMIT_HOURLY="10": Means keep the last 10 hourly snapshots.
• TIMELINE_LIMIT_DAILY="10": Means keep the last 10 daily snapshots.
• TIMELINE_LIMIT_WEEKLY="0": Means keep no weekly snapshots.

And so on. You can adjust these values as you need. However, I have set them according to my preference:

With configurations out of the way, next we are going to enable snapper and grub-btrfs services for automation.

---

Step 5: Configure Snapper and Grub-Btrfs Services

In this step, we are going to enable snapper timers and GRUB snapshot integration to automate timeline, pre, and post snapshots, and also enable overlayfs to make snapshots writable on boot.

5.1: Enable Snapper Timers

• Run these commands consecutively:

sudo systemctl enable --now snapper-timeline.timer
sudo systemctl enable --now snapper-cleanup.timer
sudo systemctl enable --now snapper-boot.timer

• systemctl enable --now: Enables and immediately starts the service.
• snapper-timeline.timer: Automatically creates snapshots at scheduled intervals (hourly, daily, weekly) as we set them in the configure snapper file step.
• snapper-cleanup.timer: Automatically cleans up snapshots, removing old ones according to the retention rules in the previous step.
• snapper-boot.timer: Automatically creates boot snapshots, making a snapshot each time the system boots so we can roll back to a previous boot state if needed.

5.2: Enable Grub Snapshot Integration

• Run:

sudo systemctl enable --now grub-btrfsd.service

• Next, run the grub-mkconfig command so GRUB can display our snapshot entries at boot:

sudo grub-mkconfig -o /boot/grub/grub.cfg

5.3: Enable Overlayfs Hook

• Open mkinitcpio.conf to add the grub-btrfs-overlayfs hook:

sudo nano /etc/mkinitcpio.conf

• In the mkinitcpio.conf file, look for the HOOKS=(base ....) line and add grub-btrfs-overlayfs.
• The complete line will look like this:

HOOKS=(base udev autodetect modconf kms keyboard keymap consolefont block filesystems fsck grub-btrfs-overlayfs)

• Next, regenerate initramfs with:

sudo mkinitcpio -P

With all the necessary steps done. Let get to creating first snapshot and verify it is working.

---

Step 6: How to Create a Snapshot (Manually and Automatically)

In this step, first we will manually create a snapshot and verify it from the Snapper list tool. If you have completed all the above steps properly, now with every pacman execution, or system changes, Snapper will automatically create snapshots, with pre and post executions.

6.1: Create Snapshots Manually

• Run:

snapper -c root create -d "First Snapshot"
snapper -c root list #shows existing snapshots

6.2: Auto Snapshots

• For automatic snapshots, we don't manually do anything. We simply just run the pacman or yay command and Snapper will automatically create a pre and post snapshot before and after the command completes its cycle.
• Let's say we install wget, and Snapper will automatically create pre and post snapshot.

In the images, you can see the before and after states of the snapper root list. In the left image, there's only one manually created snapshot and the other two are system generated. In the right image, after we ran the sudo pacman -S wget command and checked the snapshot list, we can see there are pre and post snapshot entries available.

With Snapshots being created (manually and automatically), let's perform a rollback to a previous snapshot in the next step. Otherwise what's the point of going through all this trouble.

---

Step 7: How to Do a Rollback to Previous Point

Let's say, I've installed KDE Plasma and SDDM. But I want to ditch the whole desktop environment and install Hyprland with pre-configured dotfiles. One way is to just run the sudo pacman -R command. The other way is performing a rollback. Let's see how this goes.

7.1: Boot into Older Snapshot

• Reboot the system.
• From the Grub menu, navigate to *Arch Linux snapshots and press Enter.
• Next, pick the snapshot from where the catastrophe happened, for me it's pre | sudo pacman -S sddm plasma.
• Next, select * vmlinuz-linux & initramfs-linux.img and press ENTER, and you will boot into your snapshot.

7.2: Perform Rollback to Good Snapshot

After booting into the older snapshot, we need to mount the top-level Btrfs subvolume, detect the broken snapshot and delete it. And then restore the older snapshot (good one) as the new @/top-level and that's it.

• Mount the top-level subvolume by running:

sudo mount -o subvolid=5 /dev/sda3 /mnt

Important: Replace /dev/sda3 with your top-level subvolume name.

• Delete or create the backup of the bad @ or top-level subvolume by running:

sudo btrfs subvolume delete /mnt/@ #deletes the subvolume
#OR
sudo mv /mnt/@ /mnt/@.broken #creates the backup

What is @?

@ is our entire operating system, every file in /usr, /etc, /bin, everything that makes Arch Linux run. It's just one big folder at the Btrfs top level. When we boot normally, we are running FROM @.

What are snapshots?

Every snapshot is just a frozen copy of @ at a point in time. We are just deleting the current bad @ and next we are restoring an old good @ from one of the snapshots.

• Run the snapper root list command and note the number of snapshot you want to roll back to, in my case it's 6:

snapper -c root list
sudo btrfs subvolume snapshot /mnt/@snapshots/6/snapshot /mnt/@

Important: Replace the number 6 with your actual snapshot number and run the command.

• Next, just unmount the mounted subvolume and reboot, and select the normal Arch Linux entry from the GRUB and you are all set.

sudo umount /mnt
reboot

As we can see here, after performing a rollback, my system no longer has sddm and plasma packages. Meaning we have done it!

---

❓ Frequently Asked Questions: Snapper and Grub‑Btrfs on Arch Linux

What is Snapper and how does it make Arch Linux more reliable?

Snapper is a tool for creating, managing, and restoring Btrfs snapshots. On a rolling‑release like Arch Linux, Snapper automatically takes a snapshot before and after every pacman transaction. If an update breaks your system, you can instantly roll back to the previous working state, saving hours of troubleshooting.

What does grub‑btrfs do and why do I need it?

grub‑btrfs watches the /.snapshots directory and automatically adds every Snapper snapshot to the GRUB boot menu. This means you can boot directly into any snapshot right from the GRUB screen, even if your main system refuses to start. It's the bridge between Snapper's snapshots and your bootloader.

Why must I delete the nested .snapshots subvolume and recreate it at the top level?

By default Snapper creates /.snapshots inside the @ subvolume. If you ever roll back, the old @ gets replaced and all snapshots stored inside it are wiped out right when you need them most. Moving the snapshots to a separate top‑level subvolume (@snapshots) keeps them safe during rollbacks.

How does snap‑pac automate snapshots with pacman?

snap‑pac hooks into pacman and triggers Snapper automatically. Every time you run sudo pacman -S ..., -R, or -U, snap‑pac creates a pre snapshot right before the transaction and a post snapshot right after it. This gives you a guaranteed recovery point without any manual work.

How can I manually create a snapshot?

Run snapper -c root create -d "description". The snapshot will appear immediately in the list shown by snapper -c root list. Manual snapshots are handy before big experiments or configuration changes.

What is the grub‑btrfs‑overlayfs hook and why must I add it to mkinitcpio?

The grub‑btrfs‑overlayfs hook makes snapshots writable when you boot into them from GRUB. Without it, a snapshot boots in read‑only mode and you cannot permanently fix anything. The hook uses OverlayFS to layer a temporary writable layer on top, letting you make changes and then restore that snapshot as the new working system.

How do I roll back to an older snapshot?

Reboot and select *Arch Linux snapshots from the GRUB menu. Choose the desired snapshot (for example, a pre snapshot before a bad update), then select the kernel to boot. Once booted into the snapshot, mount the top‑level Btrfs subvolume, delete or backup the broken @ subvolume, and restore the good snapshot as the new @ with btrfs subvolume snapshot. Finally unmount and reboot.

What does inotify‑tools do in this setup?

inotify‑tools provides the inotifywait command, which grub‑btrfs uses to monitor the /.snapshots directory for changes. As soon as Snapper creates or deletes a snapshot, inotify detects it and grub‑btrfs instantly updates the GRUB menu without needing to run grub‑mkconfig manually each time.

Can I boot directly into a snapshot from GRUB without any extra steps?

Yes. Once grub‑btrfs is enabled and you have generated the GRUB configuration, every snapshot appears under the Arch Linux snapshots submenu. You can boot any snapshot immediately, exactly like booting your normal system.

How do I adjust how many automatic snapshots are kept?

Edit /etc/snapper/configs/root and modify the TIMELINE_LIMIT_* values. For example, setting TIMELINE_LIMIT_HOURLY="10" keeps the last 10 hourly snapshots. Higher numbers keep more history but use more disk space. After saving the file, the changes apply automatically on the next cleanup cycle.

What if I forget to add the snapshots subvolume to /etc/fstab?

The @snapshots subvolume will not be mounted automatically at boot. Snapper will fail to create new snapshots or see existing ones because the /.snapshots mountpoint will be empty. Adding the UUID line to /etc/fstab and running sudo mount -a fixes this immediately.

Is this setup safe for a production Arch Linux machine?

Absolutely. Snapshots are created instantly (Btrfs copy‑on‑write) and consume very little extra space until files diverge. With timeline snapshots, pre/post pacman snapshots, and GRUB integration, you have multiple layers of recovery. Many users rely on this exact combination for daily‑driven Arch systems.

💡 Pro Tip: Run snapper -c root list any time to see all existing snapshots, and use sudo btrfs subvolume list / to verify that @snapshots lives at the top level. If you ever need to clean up old snapshots manually, sudo snapper -c root cleanup number can delete a specific snapshot by its number.

---

Congratulations, your Arch Linux system now has automatic snapshots and rollback capability!

At this point, you have a bulletproof Btrfs setup with Snapper taking automatic pre‑ and post‑pacman snapshots, grub‑btrfs listing them right in your boot menu, and overlayfs making rollbacks writable. Your system can recover from almost any breakage with a simple reboot. From here, you can move forward depending on how you want to use your Arch install.

What's Next?

Desktop Environments and Post Install Guide

KDE, GNOME, XFCE and more: Set up a full desktop environment on your fresh Arch install and enhance your experience, explore the Arch Linux Roadmap.

---

Try Hyprland Dotfiles

ML4W, HyDE, JaKooLit, Caelestia, End 4 and more: Find the perfect Hyprland setup for your workflow, explore the Hyprland Dotfiles Hub.

---

Gaming on Linux

Steam, Proton, Bottles and more: Run Windows games on your Arch Linux system, explore the Linux Gaming Hub.

That's it for this guide. Now that your system can roll back on demand, you can experiment without fear. In future guides, we'll cover system hardening, kernel tweaks, and other power‑user topics. If you run into any issues, feel free to leave a comment — I'll be happy to help.
101 out, I'll see you in the next one! 🚀

Abdullah Musa June 12, 2026