Learn AlmaLinux 10 Btrfs snapshot rollback to restore a previous system state, verify the rollback, and boot safely from the snapshot.

Introduction

This tutorial shows how to perform an AlmaLinux 10 Btrfs snapshot rollback on a dedicated server so you can return the system to a known-good state after an unsuccessful change or update. The process focuses on identifying the correct snapshot, switching the active default subvolume, and confirming that the server boots from the restored state.

You will work directly with the Btrfs filesystem layout on AlmaLinux 10, then validate the rollback by checking the default subvolume and confirming that key filesystem contents or service state match the snapshot you selected.

Prerequisites

• An AlmaLinux 10 dedicated server with the root filesystem on Btrfs
• Root access or a normal administrative user with sudo privileges
• Access to a recovery environment or maintenance window with the filesystem safely unmounted, if needed
• Local console or remote console access in case bootloader verification is required
• Basic familiarity with dedicated server administration

Tutorial steps

Start by identifying the current Btrfs layout and the snapshots that are actually available. This ensures you roll back to the intended subvolume instead of restoring the wrong state.

lsblk

findmnt

btrfs subvolume list /

If the root filesystem is already mounted read-write on the live system, stop here and decide whether you can safely proceed from the current environment. For a rollback on a production dedicated server, the safer approach is to use a recovery environment or otherwise ensure the target filesystem is not actively in use before changing the default subvolume.

When you are operating from a recovery environment or another safe maintenance context, mount the Btrfs filesystem and inspect the snapshot tree again from the mounted root so you can confirm the target path and subvolume ID.

mount /dev/DEVICE /mnt

btrfs subvolume list /mnt

Review the output and confirm that the snapshot or subvolume you want to restore exists and matches the expected state. If you need to check the current default subvolume before changing it, use the following command against the mounted filesystem.

btrfs subvolume get-default /mnt

Perform the rollback by setting the desired snapshot as the default subvolume. Use the subvolume ID from the listing output, and make sure you are targeting the mounted filesystem, not the active running root unless that is the maintenance method you intentionally chose.

btrfs subvolume set-default SUBVOL_ID /mnt

After the default subvolume has been changed, unmount the filesystem cleanly.

umount /mnt

If the rollback changed the bootable layout or you need to refresh GRUB metadata after the subvolume switch, regenerate the boot configuration before rebooting the server.

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

Then confirm which kernel entry GRUB treats as the default so you know the system is aligned with the expected boot path.

grubby --default-kernel

At this point, reboot the dedicated server so it comes up using the rolled-back snapshot.

reboot

Verification

After the system restarts, verify that it booted successfully and that the rollback actually took effect. Start by checking the mounted root and current Btrfs default subvolume on the live system.

findmnt

btrfs subvolume get-default /

Next, confirm the restored state by checking a few filesystem contents or service-related files that should match the snapshot you selected. Use only items that are meaningful for the server you rolled back, such as configuration files or application data that changed before the snapshot was taken.

If the machine is a production dedicated server, also confirm the relevant service or workload state matches the restored filesystem contents before resuming normal operations.

You can compare your result with the backup-validation approach described in Backup Verification on Ubuntu 26.04 and AlmaLinux 10 or use the rollback-testing perspective from Backup Restore Testing on Linux Dedicated Servers when you need a broader recovery workflow.

Troubleshooting

If the expected snapshot does not appear in btrfs subvolume list, verify that you mounted the correct Btrfs filesystem and that you are inspecting the intended root, not a different mount point or device.

If btrfs subvolume set-default succeeds but the server still boots into the previous state, check the bootloader configuration and confirm the correct filesystem was mounted when you updated the default subvolume. Regenerate GRUB configuration again only when the boot layout requires it.

If the system fails to boot after rollback, return to the recovery environment, mount the filesystem again, and use btrfs subvolume get-default to confirm which subvolume is currently selected before making another change.

Rollback

If you need to undo the rollback, repeat the same procedure and set the previous default subvolume back with btrfs subvolume set-default, then regenerate the boot configuration if required and reboot again. This restores the earlier boot target without introducing any new filesystem changes.

Conclusion

You have completed an AlmaLinux 10 Btrfs snapshot rollback on a dedicated server by selecting the correct snapshot, switching the default subvolume, and rebooting into the restored system state. After the reboot, you can verify the result by checking the default subvolume and confirming that key filesystem contents or service state match the snapshot you intended to recover.