Make installation of timeshift-autosnap-manjaro the default but optional?

Timeshift is fine for most desktop uses but it not perfect for all situations. And while uninstalling timeshift is an option, if it is not done before a snapshot is taken, it is a little messy to remove and it enables quotas which you probably do not want enabled, if not using timeshift. So it takes a reasonable amount of knowledge to properly remove it. Could it be made an optional install in Calamares?


Timeshift does not automatically start making backups on its own, even if only because it doesn’t have the faintest idea where you would want to store them.

Of course, when used in conjunction with btrfs it becomes a different matter, and it is possible that Calamares enables that by default ─ this I do not know ─ but even then, those snapshots aren’t taking up a lot of space, because btrfs is a copy-on-write filesystem, and so it only stores the modified extents ─ or disk blocks, if you will ─ while the rest of the snapshot simply links back to the original file extents from before the modification. I also don’t see how getting rid of a snapshot would be messy.

However, if Timeshift does automatically create snapshots if you opt for btrfs during installation, then I will agree that Timeshift’s configuration should be left at the discretion of the system administrator. What I will not agree with is the removal of Timeshift, and especially not given that its periodic snapshotting can easily be disabled in its settings.

1 Like

I think not, because the backup type (rsync or btrfs) is among the first-time settings asked to the user.


That was my impression as well.

I do not know how timeshift it is configured, I do not use it. Maybe it is through installing and enabling cronie? If one is like me, not knowing how it works, it is not exactly trivial to remove it, if it does make a snapshot, until you know a few things.

Not knowing much about timeshift, I uninstalled it and the auto snapshot package, or whatever it is called. I do not recall exactly how, but probably in an attempt to remove the timeshift directory, I discovered the snapshot. I then removed that subvolume snapshot and thought I was done with it.

I then installed snapper and things seemed fine. However, when I would run snapper list, it would take 10-15 seconds before listing the snapshots… odd. I then installed strace in an attempt to determine the cause but I could not.

The answer was eventually found in dmesg, when a message about qgroup would appear at the time of running snapper list. Seems Timeshift had enabled quotas. I then removed the quota on / and now snapper list returns the results immediately.

I did not start timeshift and I did not enable it, at least not intentionally. I have never used it, snapper and snap-pac are better suited to my needs.

Just tested in a VM. There is actually a snapshot made on Btrfs by default on update. :hushed:

Creating Timeshift snapshot before upgrade…
First run mode (config file not found)
Selected default snapshot type: BTRFS
Using system disk as snapshot device for creating snapshots in BTRFS mode
Mounted ‘/dev/sda1’ at ‘/run/timeshift/backup’
Creating new backup…(BTRFS)
Saving to device: /dev/sda1, mounted at path: /run/timeshift/backup
Created directory: /run/timeshift/backup/timeshift-btrfs/snapshots/2021-10-22_23-19-07
Created subvolume snapshot: /run/timeshift/backup/timeshift-btrfs/snapshots/2021-10-22_23-19-07/@
Created control file: /run/timeshift/backup/timeshift-btrfs/snapshots/2021-10-22_23-19-07/info.json
BTRFS Snapshot saved successfully (0s)

If you configure Timeshift to make btrfs snapshots, yes. Not if you configure it to use rsync. :wink:

1 Like

I didn’t configure it in that VM, as shown in the output i quoted.

You don’t know, what you don’t know. First I tried to delete what I thought was just a timeshift directory, per this post. And then I had no idea timeshift had set quotas, which I do not use, or that it would have an adverse effect on a snapper command.

Hopefully I have found all of the ways timeshift has altered the system, so on subsequent installations I will be aware and know how to revert it.

You hit the nail on the head. The only reason I see you created this post to begin with is your ignorance of how Timeshift works. That’s okay, do some more reading or ask more questions in a #support thread.

FYI, snapshots are not designed to be manually deleted. Remove them from Timeshift itself.

1 Like

Is this true of a Plasma Minimal install? I do not recall seeing anything backup related.

When you open the timeshift app first time after installation of Manjaro, you are asked to select where (the drive or partition) and which type of backup (rsync or btrfs) you want, number of scheduled backups etc.
Probably that’s what @maycne.sonahoz said.
[If timeshift is installed in Plasma minimal, it should have the same behaviour.]

Quotas are known to make problems together with snapshots:

  • Bugs in accounting code might cause false out of space situations.
  • Combining quota with (too many) snapshots of subvolumes can cause performance problems, for example when deleting snapshots.

My personal experience ist that this did proceed until (maybe after a year or so) my server (with 3 harddisks and RAID 1) took hours to remove snapshots after midnight. Since i don´t use quotas any more this has not happened again.
The performance-problems may be not visible any more when you use a ssd. The impact may be smaller or later, when you use RAID 0 and only 1 disk :wink:

I have more experience with Manjaro ARM than I do with x86_64, where timeshift is not (yet?) a basic element of the OS. I am simply trying to suggest that with a minimal install, the changes timeshift makes, are to me, unexpected behavior and requires specific knowledge to remove.

I still think it would be nice to make it optional on minimal, but it appears from what @maycne.sonahoz has shown, my issue may be avoided by making sure timeshift is uninstalled before running the first system update. I will install into a VM to further investigate.

Edit: Confirmed.

Having learned a little more about how timeshift is implemented, I have amended the OP subject line. The unexpected behavior is not from timeshift itself, but rather the autosnap hook that triggers on the first system update.

Errors do occur when the hook triggers, but it is a pre-hook and is easily missed in a large first update, if not paying proper attention. And by then, the system changes have been made.