No recent backup, but there is

Hello there. I’ve seen similar problems to this, but haven’t seen any solution. So the problem: one of subclients shows that there is no recent backup, but actually there is. No errors in log.

How to reproduce:
Create new client
Create new sub client
Separate settings for sub client
No differential backups, only full backups every day
Make full backup - and see the result.

I tried to enable differential backup and make it and it worked, no more “No recent backup” in this sub client, but I don’t need differential backups.

1 Like

@littledpurple What do you mean by ‘diferential’ backups? Are you referring to ‘incremental’ backups?
We also see this issue but enabling incremental backups doesn’t seem to help in our case.

Also, what do you mean by subclients? Are you referring to groups?

I’m sorry if this is just a translation issue, i’m just trying to make sure I’m thinking about the same thing.

Yes, I meant incremential backups. If I turn on Full backups only, web GUI shows there is no backup.

By subclients I mean virtual sub clients UrBackup - Server administration manual

1 Like

Yes, we have the same issue. We are using only full backups and it always says “No recent backups”. Even when I do a incremental backup, the status does not change.

Are there any errors that are generated during the backup process?

Nope!

Client 1:

Client 2:

Settings:

Overview:

What are your settings for full vs incremental backups?

Hmmm… It seems as though the status is connected to both the Full and Incremental backups.

Does that status ever change, even briefly, right after a full backup?

I wonder what would happen if you set Incrementals to be every 24 hours, with retention of 1?

LOL That might solve the visual issue, but I think the underlying logic needs to be able to handle the fact that you might not want to do incremental backups.

urbackupsrv repair-database
urbackupsrv remove-unknown 

My case: Backup status is wrong (or not ?)

Even if I do an incremental backup, the status does not change.

No, it does not change, even not right after a full backup.

I changed the settings to the default settings and when I create a full backup, the status says now “OK”

When I change the settings to the ones I want to use (only 1 full backup) and create an other one, the status is again “no recent backup”.

@Alexander_Zaitsev: Thanks for the tip - does not work in my case.

What are all of those errors you are experiencing? Are they related to this problem?

Also, since you are blocking the incremental backups anyway, why not leave whatever numbers it has in its other settings? (Or, at least, leave them as 1 and not 0)

Hi,

no those backups were canceled by myself manually.

I changed the settings to:

But still “no recent backup”:

Has data actually changed since the last backup?

What does your “Activities” tab look like?

I have the same issue.

Linux client. No incs enabled, only full backup. Table says “No recent backup” but there is.

The JS data provided for that host:

grafik

which maybe gets generated by status.cpp: stat.set("file_ok", res[i]["file_ok"] == "1" && lastbackup!=0);

but I did not digged further. Maybe @uroni could explain how JS image_ok gets determined in that case?

Okay, digged a bit deeper.

These statuses are generated by the alarm script, right?

So, I found out, that the “diasbled” key next to the interval fields just set the values to a fixed signed value (-3600 for incr as example).

The default alarm script starts with:

--find largest (maximum of incr and full interval) interval for file and image backups
local file_interval = params.incr_file_interval
local full_file_interval = params.full_file_interval
if full_file_interval>0 and full_file_interval<file_interval
then
	file_interval = full_file_interval
end

So: file_interval = -3600, full_file_interval = 86400 . At this point, file interval works with the inc file interval.

Then it checks if full_file_interval is bigger than 0 - it is - and if the full_fle_interval is lower than the inc file interval - it is not. If both are yes, the full file interval is used.

Is that right? It should also use full_file_interval if file_interval is lower than 0 (aka disabled), like:

--find largest (maximum of incr and full interval) interval for file and image backups
local file_interval = params.incr_file_interval
local full_file_interval = params.full_file_interval
if file_interval <= 0 or (full_file_interval>0 and full_file_interval<file_interval)
then
	file_interval = full_file_interval
end

Correct me, if Iam wrong.

1 Like

Yeah, that is the cirtical hint. You can change the alert script (by creating a copy and switching) and adjust the if condition like for image backups:

if full_image_interval>0 and (full_image_interval<image_interval or image_interval<0)

and check if it works then.

That worked.

I would also patch <0 to <=0 because 0 should be treated as disabled (putting 0 into these input fields also does not trigger the Disabled-Checkbox to be active. No big thing, but the alarm should catch that.

So, final version:

--find largest (maximum of incr and full interval) interval for file and image backups
local file_interval = params.incr_file_interval
local full_file_interval = params.full_file_interval
if full_file_interval>0 and (full_file_interval<file_interval or file_interval<=0)
then
	file_interval = full_file_interval
end

local image_interval = params.incr_image_interval
local full_image_interval = params.full_image_interval
if full_image_interval>0 and (full_image_interval<image_interval or image_interval<=0)
then
	image_interval = full_image_interval
end

If ok, I would create an PR.

1 Like

That would require other changes and would not be backwards compatible.

So - no <=0? Leave as <0?

1 Like