Is there any big disadvantages of using time shift over snapper for btrfs system? I find time shift to be much more user friendly and easier to configure.
It depends what you want. Timeshift is easier to use but it basically only serves one purpose. It takes snapshots of @ and optionally @home for system recovery. It does nothing else.
snapper is more flexible in several ways:
- It can take snapshots of any btrfs subvolume
- It creates read-only snapshots so they can be easily replicated to other drives or remote devices
- Snapper allows you to name your subvolumes however you like
- Snapper supports both flat and nested subvolume layouts
- Snapper doesn’t require the root of the BTRFS partition to be mounted
If you don’t care about any of those things, than you can stick with timeshift as it is easier to use and configure.
3 Likes
No expert on this, but my impression that Timeshift does very well what it does, but has no flexibility for other choices of things to back up. In particular, it cannot ‘send out’ snaps for external backup - and cannot cover off directories outside its main remit.
I’m sure others can explain more comprehensively, but this is an overview of the limitations TImeshift has that snapper doesn’t share. Of course, with more ‘power’ comes the need for more configuration and setup for snapper…
1 Like
As to configuration ease. I find the AUR application btrfs-assistant fixes this for snapper. When I build a EOS system with btrfs, I install snapper and then btrfs-assistant. I immediately use btrfs-assistant to configure and setup snapper. No cli commands to use and no wiki to read.
2 Likes
snapper with btrfs-assistant all the way 
4 Likes