Why EndeavourOS Should Make Btrfs + Snapper a First-Class Default
An Open Letter to the EndeavourOS Developers and Community
EndeavourOS has built its reputation around something that is increasingly rare in the Linux world: freedom without unnecessary complexity.
It gives users a relatively clean Arch Linux experience while providing enough tooling and configuration to make installation and day-to-day use approachable. It does not try to hide Linux from the user. It does not bury everything underneath layers of proprietary abstractions. It gives people a system that they can understand, modify, break, rebuild, and make their own.
That philosophy is one of the biggest reasons people choose EndeavourOS.
But there is one area where I believe EndeavourOS is unnecessarily asking users to fend for themselves:
System snapshots and rollback protection.
More specifically:
EndeavourOS should seriously consider making Btrfs + Snapper an officially supported and easily selectable default filesystem/snapshot configuration during installation.
Not necessarily by forcing every user onto Btrfs.
Not necessarily by removing ext4.
And certainly not by turning EndeavourOS into a completely automated, opaque system.
Instead, EndeavourOS should recognize that Btrfs + Snapper has matured into one of the most valuable safety nets available to desktop Linux users, particularly on an Arch-based rolling-release distribution.
Other Arch-based distributions, including CachyOS and Garuda Linux, have demonstrated the value of providing this type of functionality as part of the out-of-the-box experience.
EndeavourOS should learn from that—not by becoming Garuda or CachyOS, but by taking the best idea and implementing it in an EndeavourOS way.
The Core Problem
EndeavourOS is based on Arch Linux.
That is both its greatest strength and one of its greatest responsibilities.
Arch gives users access to an enormous software ecosystem and extremely current packages. But rolling releases inherently mean that users are regularly changing important components of their operating system.
A normal system update can potentially change:
-
the Linux kernel
-
graphics drivers
-
Mesa
-
systemd
-
boot components
-
desktop environments
-
display managers
-
libraries
-
networking components
-
audio components
-
Python and other runtimes
-
firmware
-
applications
-
package dependencies
-
configuration files
-
Wayland/X11 components
-
GPU-related packages
Most updates work perfectly.
But sometimes they don’t.
And when something goes wrong, the difference between:
“My system is broken and I have to troubleshoot it”
and
“I’ll simply roll back to the state it was in 20 minutes ago”
is enormous.
That difference is Snapper + Btrfs.
Linux Users Shouldn’t Have to Learn Disaster Recovery Before They Get Disaster Recovery
This is perhaps the biggest argument for making it an installation option.
Today, a knowledgeable EndeavourOS user can absolutely configure:
-
Btrfs
-
Snapper
-
snap-pac
-
grub-btrfs
-
appropriate subvolumes
-
snapshot schedules
-
cleanup policies
-
bootable snapshots
-
rollback procedures
And that’s great.
The problem is that the users who benefit most from snapshots are often the users least likely to configure them correctly before something goes wrong.
This creates a strange situation.
The people who already know how to protect their systems are perfectly capable of installing and configuring Snapper themselves.
The people who don’t know how to protect their systems are the people most likely to discover Snapper after they need it.
That’s backwards.
A backup or recovery mechanism is most useful when it exists before the disaster.
Nobody says:
“You should install a fire extinguisher after the fire starts.”
Yet that’s effectively what we’re doing when we expect users to discover snapshot tooling after a bad update.
“But EndeavourOS Is About Keeping Things Simple”
That’s a legitimate argument.
But I would argue that not providing recovery infrastructure actually makes the user experience more complicated, not less.
Consider two users.
User A
They install EndeavourOS.
They update the system.
A graphics stack update causes their desktop environment to stop loading.
Now they have to:
-
Determine what broke.
-
Boot into a TTY or recovery environment.
-
Investigate logs.
-
Determine which packages changed.
-
Identify the problematic package.
-
Understand Arch package management.
-
Potentially downgrade packages.
-
Deal with dependency conflicts.
-
Fix configuration files.
-
Potentially use an Arch installation medium.
-
Chroot into the system.
-
Repair the installation.
-
Hope they didn’t make things worse.
User B
They install EndeavourOS with Btrfs + Snapper.
The same update causes a problem.
They restore the previous known-good snapshot.
Done.
That is not more complicated.
It is dramatically simpler.
The complexity has merely been moved from emergency troubleshooting into a sensible automated safety mechanism.
Snapshots Are Not a Replacement for Backups
This distinction is important.
Nobody should argue that Snapper makes traditional backups unnecessary.
It doesn’t.
A Btrfs snapshot is generally stored on the same physical storage device as the operating system.
If the SSD dies, the snapshots can disappear with it.
If the computer is stolen, the snapshots are gone.
If the filesystem suffers catastrophic damage, the snapshots may not save you.
Personal files can also require completely different backup strategies.
So the argument isn’t:
“Btrfs + Snapper replaces backups.”
The argument is:
“Btrfs + Snapper provides an extremely convenient first line of defense against software and configuration failures.”
That’s a completely different proposition.
Users should ideally have both:
Snapshots for fast system recovery.
Backups for actual data protection.
Rolling Release + Snapshots Is an Extremely Logical Combination
This is where the case becomes especially compelling for EndeavourOS.
EndeavourOS isn’t a traditional fixed-release distribution.
It follows the Arch rolling-release model.
That means users are continually moving forward.
That’s one of the reasons people love it.
You get newer:
-
kernels
-
drivers
-
desktops
-
applications
-
libraries
-
development tools
without reinstalling the operating system every six months or two years.
But rolling forward also means that rollback capability becomes particularly valuable.
Think about the relationship:
Rolling release
↓
Frequent system changes
↓
Occasional possibility of regression
↓
Need for easy recovery
↓
Snapshots
That’s an extremely logical progression.
Snapshots don’t undermine the rolling-release model.
They make the rolling-release model safer to use.
Btrfs Is Particularly Well Suited to This
Btrfs brings several features that are extremely attractive for desktop Linux systems.
Among them:
-
Copy-on-write
-
Subvolumes
-
Snapshots
-
Compression
-
Checksumming
-
Flexible filesystem management
-
Efficient snapshot creation
-
Space-efficient incremental changes
The snapshot functionality is particularly important.
A snapshot can capture the state of a filesystem at a particular point in time without requiring users to duplicate the entire filesystem in the traditional sense.
That makes it possible to create frequent system restore points without the enormous storage overhead people might associate with full disk images.
Snapper Makes the Idea Usable
Btrfs alone isn’t the complete solution.
That’s why the combination matters.
Btrfs provides the filesystem capabilities.
Snapper provides a management layer for snapshots.
And with appropriate integration into the package-management workflow, the experience can become even better.
Imagine:
Before a major system update, automatically create a snapshot.
Then:
Update the system.
If everything works:
Continue normally.
If the update causes a problem:
Roll back.
That is an incredibly powerful safety mechanism for a rolling-release desktop.
This Is Especially Valuable for Kernel and Graphics Updates
Anyone who has spent enough time maintaining Linux desktops knows that some of the most frustrating failures can involve graphics.
A system can go from:
“Everything works perfectly.”
to:
“Why am I staring at a black screen?”
after an update involving:
-
NVIDIA
-
AMD graphics
-
Intel graphics
-
Mesa
-
Wayland
-
Xorg
-
kernel packages
-
display managers
-
desktop environments
When troubleshooting a problem like this, knowing that you can return the system to its previous state changes the entire experience.
Instead of:
“Oh no, what did I break?”
you have:
“Okay. I’ll roll back, then investigate the update.”
That’s a fundamentally better relationship between the user and their operating system.
It Would Make Experimentation Safer
This is another major advantage.
EndeavourOS attracts users who like experimenting.
They might install:
-
KDE
-
GNOME
-
Hyprland
-
XFCE
-
different kernels
-
NVIDIA drivers
-
development environments
-
custom system services
-
alternative boot configurations
-
virtualization software
-
custom themes
-
system tweaks
-
packages from the AUR
That experimentation is part of the fun.
But experimentation without an easy rollback mechanism can become frustrating.
Imagine being able to tell a new EndeavourOS user:
“Try it. If you don’t like what happens, you can roll the system back.”
That encourages experimentation.
It doesn’t discourage it.
The AUR Makes This Even More Relevant
EndeavourOS users have access to the Arch User Repository.
That’s one of the most powerful aspects of the Arch ecosystem.
But it also means users frequently install software that isn’t part of the official repositories.
AUR packages can be extremely useful.
They can also introduce additional variables into a system.
A snapshot gives users a safety net before experimenting.
This doesn’t mean:
“Install anything you want because snapshots make it impossible to break your computer.”
That’s obviously false.
It means:
“You have a convenient escape hatch when an experiment doesn’t go according to plan.”
That’s valuable.
Snapshots Also Improve User Confidence
This is an underrated benefit.
A technically sophisticated user might happily troubleshoot a broken system for three hours.
A less experienced user might simply reinstall Linux.
That’s a problem.
Every time a user encounters an unrecoverable system failure, there’s a possibility they conclude:
“Linux is too difficult.”
But if they can recover their system in minutes, the lesson becomes:
“Linux is resilient.”
That’s a much better experience.
A good operating system isn’t merely one that works when everything goes right.
A good operating system also gives users reasonable ways to recover when something goes wrong.
“Power Users Can Set It Up Themselves”
Yes.
That’s true.
And this is one of the weakest arguments against making it easier.
Power users can also:
-
partition manually
-
configure swap
-
install bootloaders manually
-
configure networking
-
create users manually
-
configure kernels manually
We don’t therefore conclude:
“The installer shouldn’t provide these things.”
The purpose of a distribution installer is to provide sensible defaults and sensible choices.
A feature being configurable manually doesn’t mean the distribution shouldn’t provide it.
EndeavourOS Doesn’t Have to Force Btrfs
This is an important distinction.
The proposal doesn’t have to be:
“Remove ext4 and force everyone onto Btrfs.”
That’s unnecessary.
Instead, the installer could present something like:
Filesystem
ext4
-
Simple
-
Traditional
-
Excellent general-purpose filesystem
Btrfs + Snapper
-
Snapshots
-
Easy rollback
-
Compression
-
Subvolumes
-
Enhanced recovery workflow
And perhaps:
Advanced/manual partitioning
for experienced users.
That preserves the EndeavourOS philosophy.
Users retain control.
But new users finally have an obvious, supported path toward system snapshots.
Make Btrfs + Snapper an “Easy Mode” for Recovery
This is where EndeavourOS could distinguish itself.
Rather than simply installing Btrfs, EndeavourOS could provide an opinionated but transparent configuration.
For example:
Root subvolume
@
Home subvolume
@home
Snapshot location
/.snapshots
Compression
Reasonable zstd compression enabled.
Snapper
Configured automatically.
Package integration
Create snapshots before major package transactions.
Cleanup
Automatically remove old snapshots according to a sensible retention policy.
Boot integration
Provide a supported mechanism for booting or restoring snapshots when appropriate.
Documentation
Explain exactly what is happening.
The user doesn’t need to become a Btrfs administrator.
But the system remains understandable.
The Goal Should Not Be “Hide Linux”
The goal should be:
“Protect users while still showing them how Linux works.”
That’s an important distinction.
EndeavourOS shouldn’t become a black box.
When a snapshot is created, users should be able to see it.
When Snapper creates snapshots, users should understand why.
When snapshots are cleaned up, users should know the policy.
When a rollback occurs, the documentation should explain what changed.
This can actually become an educational feature.
CachyOS and Garuda Have Already Demonstrated the Demand
This is perhaps the most practical part of the argument.
Users already have Arch-based alternatives that provide significantly more hand-holding around system recovery.
Garuda Linux has long emphasized snapshot-based recovery as part of its desktop experience.
CachyOS has likewise embraced Btrfs/snapshot-oriented configurations for users who want that safety net.
That creates an interesting competitive situation.
Someone can look at several Arch-based distributions and ask:
“Which one gives me the best balance of Arch simplicity and recovery capability?”
If another distribution says:
“We automatically give you snapshots.”
while EndeavourOS effectively says:
“You can configure that yourself.”
some users will simply choose the former.
That’s not necessarily because they want a bloated distribution.
They simply want sensible defaults.
EndeavourOS Could Do This Without Becoming Garuda
This point deserves emphasis.
The solution isn’t to copy Garuda.
And it isn’t to copy CachyOS.
EndeavourOS has its own identity.
Its strength is its relatively clean relationship with Arch.
So the philosophy should be:
Take the recovery technology, not the entire distribution philosophy
) 
tomorrow
