Hi,

I recently switched to Kup for backing up my user files. I created a dedicated plan with an "Interval" schedule, set to 1 day. The backup disk is an SSD in the PC itself.

This seems to work fine after a fresh boot, but I often put the PC to sleep (suspend to RAM?) and noticed that Kup does not seem to do a backup after the system wakes up. Today, I saw the message in the tray telling me that Kup had last backed up 11 days ago. Oops. I was able to trigger the backup manually though.

Do you have any ideas how to remedy this? At least how/where to start investigating?

Cheers
Ben

Whichever component does the scheduling, does seem fragile. Probably kup-daemon?
Maybe see if this is running upon resume, or if you can restart it.
Does the systray widget show a red icon? Does the log file offer any information?

I don't suspend my PC, but I have had problems with various schedules in the past. I have three different plans, one to an external drive, and two to mounts on my NAS. I used to have some occasional issues with broken schedules.
But in an effort to be able to use the "prune old backups" feature, I started building Kup from git, as it has been a while since there has been a new version released for this software. I haven't seen any issues related to scheduling since then - almost two months, maybe more.

You may want to post a bug report on it, even if activity is slow.
https://bugs.kde.org/enter_bug.cgi?product=kup

Many thanks for your reply. I'm still a bit of a n00b when it comes to Linux, so apologies in advance if my questions are a bit naive.

claydoh wrote:Whichever component does the scheduling, does seem fragile. Probably kup-daemon?
Maybe see if this is running upon resume, or if you can restart it.

What is the best way of finding this out? I tried htop and filtered for "kup". That, as of now (after two suspends) gives me eight(!) lines of kup-daemon with a different PID each. Does that mean they are all running at the same time?

claydoh wrote:Does the systray widget show a red icon? Does the log file offer any information?

It normally shows red if more than a day has passed since the last backup. I had to reboot after running updates, and now the log only shows yesterdays backup - no error info yet. I'll probably have to check again in 2-3 days.

claydoh wrote:But in an effort to be able to use the "prune old backups" feature, I started building Kup from git, as it has been a while since there has been a new version released for this software. I haven't seen any issues related to scheduling since then - almost two months, maybe more.

I have installed kup 0.9.1-5 from the Manjaro Official Repositories. Do you think a version like kup-git could behave differently?

nurunet wrote:What is the best way of finding this out? I tried htop and filtered for "kup". That, as of now (after two suspends) gives me eight(!) lines of kup-daemon with a different PID each. Does that mean they are all running at the same time?

Sure, I have 12. But they are not using much in terms of resources.

It normally shows red if more than a day has passed since the last backup. I had to reboot after running updates, and now the log only shows yesterdays backup - no error info yet. I'll probably have to check again in 2-3 days.

Then you might click on the 'view log;' button and see what it is saying. If the log file doesn't open, it should be located in ~/.cache/kup/ , at least on my systems.

I have installed kup 0.9.1-5 from the Manjaro Official Repositories. Do you think a version like kup-git could behave differently?

it might, that is essentially what I have, I think. The version in my distro's repos is the same (9.1), and I pull from git directly and build it manually. Not as hard as it sounds, once things are set up, but having something more readily available will of course be much easier and less frustrating up front If you feel comfortable trying it out, and can roll back to the original if needed, it might be worth a go.

So... I reread the description of the schedule, and it says the backup "will be triggered when backup destination becomes available and [...]". I thus unmounted my backup drive (an SSD in the PC), mounted it again and... voilà. Kup started a new backup. Is this the intended behavior? Is Kup only supposed to backup to removable drives?

It seems to have something to do with suspending. On resume, some part of your system isn't informing another part of your system about drives being available, or messing up the schedule timers, or the kup-daemon simple needs to be restarted. Or, since kup used the program bup to do the actual backup things, at least for the incremental plans, it might be something there.

Is your secondary drive physically mounted via your fstab, or is being automounted, using Plasma's device auto-mounting features and options?

Logs might be helpful if the icon turns red, to see what it thinks is happening.

I back up to my NAS, which is mounted via my fstab, so it is just like an internal drive. But I don't use sleep, as it is a PC.
I don't have a laptop set up for backups at the moment, as there is no need. But when I have done so in the past, I don't recall any issues with sleep and resume -- but this also went to a physically mounted file system on my NAS.

claydoh wrote:Is your secondary drive physically mounted via your fstab, or is being automounted, using Plasma's device auto-mounting features and options?

The latter, I think. It is via Manjaro's Plasma settings, where you can choose mounting options for "detachable storage" (although that term is a stretch for an NVMe).

claydoh wrote:Logs might be helpful if the icon turns red, to see what it thinks is happening.

The log for the backup plan shows nothing new, despite the icon being red:

Code: Select all

Kup is starting bup backup job at Tuesday 31 January 2023 19:26:35 CET

bup "-d" "/run/media/nurunet/Linux Backup/Kup" "init"
bup "-d" "/run/media/nurunet/Linux Backup/Kup" "fsck" "--quick" "-j" "4"
Exit code: 0
bup "-d" "/run/media/nurunet/Linux Backup/Kup" "index" "-u" "--exclude" "/home/nurunet/.cache" "--exclude" "/home/nurunet/.local/share/Trash" "--exclude" "/home/nurunet/.local/share/baloo" "/home/nurunet"
Exit code: 0
bup "-d" "/run/media/nurunet/Linux Backup/Kup" "save" "-n" "kup" "-vv" "/home/nurunet"
Saving: 100.00% (11803716/11803716k, 33881/33881 files), done.   
Exit code: 0
Kup successfully completed the bup backup job at Tuesday 31 January 2023 19:28:09 CET


claydoh wrote:I back up to my NAS, which is mounted via my fstab, so it is just like an internal drive. But I don't use sleep, as it is a PC.

Maybe I'll try fstab then. Have to do some reading first.