Timeshift makes snapshot before each AUR application to upgrade

Am I the only one to find this weird? Doing a yay -Syyuv to upgrade AUR packages, I would expect Timeshift to create one snapshot then Yay to continue upgrading all of them, but Timeshift wants to snapshot after each app, and it’s taking forevaarr (it’s lenghtily calculating disk space for the tenth time now).

Checking if target drive has enough free space for a snapshot (RSYNC)
Target device: /dev/sda1, mount path: /run/timeshift/160911/backup
Linking from snapshot: 2021-09-10_15-00-01
Calculating required disk space...

Not to mention they are all failing becauseof this rsync error that it’s not telling me what it is - and yet, at the next AUR app, it needs to check again if there’s enough disk space.

Space required for snapshot: 85200010 (85.2 MB). Space available: 4535922688 (4.5 GB)
------------------------------------------------------------------------------
Creating new snapshot...(RSYNC)
Saving to device: /dev/sda1, mounted at path: /run/timeshift/160911/backup
Linking from snapshot: 2021-09-10_15-00-01
Syncing files with rsync...
  0.95% complete (01:31:50 remaining)
E: rsync returned an error                                                      
E: Failed to create new snapshot
Failed to create snapshot
------------------------------------------------------------------------------
Removing snapshots (incomplete):
------------------------------------------------------------------------------
Removing '2022-07-14_19-23-28'...
Removed '2022-07-14_19-23-28'                                                   
------------------------------------------------------------------------------

Found stale mount for device '/dev/sda1' at path '/run/timeshift/160911/backup'
Unmounted successfully
GRUB-Konfigurationsdatei wird erstellt …
Thema gefunden: /usr/share/grub/themes/manjaro/theme.txt
Linux-Abbild gefunden: /boot/vmlinuz-5.14-x86_64
initrd-Abbild gefunden: /boot/intel-ucode.img /boot/initramfs-5.14-x86_64.img
Found initrd fallback image: /boot/initramfs-5.14-x86_64-fallback.img
Linux-Abbild gefunden: /boot/vmlinuz-5.10-x86_64
initrd-Abbild gefunden: /boot/intel-ucode.img /boot/initramfs-5.10-x86_64.img
Found initrd fallback image: /boot/initramfs-5.10-x86_64-fallback.img
Warnung: Zur Erkennung anderer bootfähiger Partitionen wird os-prober ausgeführt.
Dessen Ausgabe wird zur Erkennung bootfähiger Programmdateien und Erzeugen neuer Boot-Einträge verwendet.
Ubuntu 20.04.3 LTS (20.04) auf /dev/nvme0n1p5 gefunden
Bootmenü-Eintrag für UEFI-Firmware-Einstellungen wird hinzugefügt …
Found memtest86+ image: /boot/memtest86+/memtest.bin

And after failing to create a snapshot, it always updates the grub menu for some reason…

Is this just how it is, or can I make it behave normally somehow?

You could try enabling batchinstall:

yay -Syu --batchinstall
      --batchinstall
              When building and installing AUR packages instead of installing
              each package after building, queue each package for install.
              Then once either all packages are built or a package in the
              build queue is needed as a dependency to build another package,
              install all the packages in the install queue.
2 Likes

So you mean this is expected behavior from Timeshift?

Yes, because yay is installing each AUR package individually and sequentially.
If you have a pacman hook that makes a snapshot before each install, that’s what you get.

--batchinstall installs it in one go.

I remember that we had a lengthy discussion not that long ago about disabling snapshot for AUR packages. The search function should find the thread.

2 Likes

i assume you have timeshift-autosnap or timeshift -autosnap-manjaro installed and rsync snapshots enabled .
Why bother with autosnap at all, when using ext4 ?
I only use timshift shedule with 3 boot- and 1 weeky-snapshot (notebook) that’s more than enough and running in the background.
For desktop PC I would change 3 boot- to 3 daily snapshots.
cheers

1 Like

Just to be clear, this behavior is not coming from timeshift itself; rather it comes from the timeshift-autosnap-manjaro package. However, you would have had to manually turn the auto-backup option on as it’s only enabled by default if a BTRFS partition is detected.

1 Like

I’ll keep it short, not a good idea.

Cause you can still roll back your system from a tty or the live environment.

1 Like

I have a pacman hook for borg, in which I have set a time limit to prevent backups being taken if the last backup was before that limit has expired (currently set to 4 hours which is fine for me). I have never used Timeshift so don’t know if something similar is possible?

2 Likes

You still haven’t checked it ?

   autosnap

is just an annoying extra (especially for ext4) and is not

   timeshift

I can always roll back from tty with timeshift --restore command. No autosnap needed.
…stll tired ?

Apparently, some different opinions here about how best to use Timeshift?
My drive is ext4 because I have no experience with BTRFS and setting up the disk properly seemed to be a whole new learning curve that I’m afraid of.

Yes, I did turn it on manually.

I guess that makes sense if you turn on your pc every day like I do with my desktop. The machine in question here is my laptop sometimes lying around a couple weeks unused. I thought it made the most sense before updates, which is a typical point where things sometimes tend to break…

So does anyone do this normally? Seems like a super convenient way to get your AUR packages updated, why is it not the default/how everyone does it?

I don’t do AUR batch install there is no need in my case (but that can be in yours with auto snap). I make manual snapshot in Timeshift when I feel like it, this is plenty enough restoration points in time if needed. I only keep a couple of them.

The reason is that those AUR packages that are compiled, will be build and compiled with the currently installed version of their dependencies.
If one of the dependencies is also an AUR package, it will only be updated during the installation and will leave you with a non-working package because the runtime dependency changed.

…and after a couple of weeks you boot it up ( - and it booted - miracle), but you missed a major update or two and then you get in trouble. Two major updates including keys and AUR stuff. With autosnap on ext4 you will now have 4 or even more snapshots from only this event which is a waste of time and space. All you need is a snapshot from the last working boot, so why all this hassle. BTRFS is different and here autosnap makes sense, snapshots happens instantly and take less space in comparison to ext4. And if you want full madness, use BTRFS and snapper (joke).
In all the years running manjaro I only used (not needed but tested) timeshift twice. It is nice to have, but don’t let it drive you crazy.

Edit:
Even more important is backing up your private stuff on external storage. A system can be repaired/replaced, your private stuff not.

1 Like

I add Topgrade and update EVERYTHING all at one time. Launch Konsole, ender topgrade, password, and answer yes where needed. Now one thing use Yay and not Paru if you use Topgrade. Rather I’m running Topgrade or not Paru if installed always goes. I prefer how Yay handles things.

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.