After deleting incremental backup, error when attempting a new backup

I’m running version 2.1.19 on Linux as a server backing up several Linux-based clients.

I had to delete the most recent incremental backup from one of the clients. However, after deleting the incremental backup through the Web interface (Clients > [client name] > Delete button under Actions column), two things have happened:

  1. In the server’s data directory, the “current” symbolic link no longer points to the correct, most recent backup. It still points to the one I deleted.

  2. Backups from this client now fail with the client error:
    Error while calculating tree diff. Not doing full backup because of internet connection."
    In the server log, I see the error:
    ERROR: Cannot read file tree from file "urbackup/clientlist_4.ub"

To try to solve this, I restarted the server. When UrBackup loads, I see a new set of errors in the log:

WARNING: Error: Unknown action [progress]
WARNING: File clientlist_b_138.ub is missing/cannot be accessed

I can find neither .ub file anywhere on the system.

Is this a bug in the server software? Or is there another way that I can fix it?

Thanks for any help.

Just to followup, I’ve been able to reproduce this error several times since my original post on several different clients. Does it really not happen to anyone else?

To attempt to fix it, I’ve run urbackupsrv remove-unknown, which sometimes makes changes but never resolves the problem. I’ve also run urbackupsrv verify-hashes, which so far hasn’t found any problems with the client backups.

In some cases, I’ve been able to get rid of the error with a new full backup. However, for multi-TB clients, that leaves me quite vulnerable if something goes wrong while the full backup is in process. It’s also extremely concerning that it’s so easy to break UrBackup.

Maybe if you correct that sym link? If you can, I’ve had the same thing, but with a local client and a full backup wasn’t a big deal, so I didn’t really dig into it.

Thanks for your reply.

Yes, I did try manually fixing the symlinks – that was before I found out that remove-unknown can do this as well. However, sadly, it doesn’t fix the problem. UrBackup is still looking for these phantom .ub files, and it refuses to process any incremental backup without them. Unfortunately I don’t know what happened to them, and when they existed.

It happened to me too right now!

The server held a full file backup and an incremental backup.
Had to delete the incremental backup.

Now further incremental backups refuse to run:

Server version 2.2.11.

Performing a full backup is very problematic, since it cannot be done over the internet due to its size.

Is there a way to rebase urbackup to use the full backup that exists on the server?

Sadly, I never found a real solution. My “fix” was to remove the client from UrBackup, manually delete any backup files remaining, run urbackupsrv remove-unknown, and then re-add the client. I know that’s not what you want to do, but without any helpful feedback from the developer or other users, I can’t think of another answer.

Since that time, I haven’t had a single issue. I can only guess that the problem was some kind of strange database corruption that was fixed by removing and re-adding the troublesome client. In my opinion, it’s a very serious problem, but not many other users have reported it, so I suppose it’s rare.

I should also mention that the server version under which I experienced the problem was a couple of versions older than the current release (2.2.11).

It doesn’t show a delete button for the last backup for this reason.

Often a full backup isn’t so bad if you have client side hashes enabled.

I can’t believe it actually worked!

Thank you

Did you try another incremental backup to make sure that runs without errors? In my case, running a full backup didn’t always solve the issue for every client. Though, like I wrote before, I think I had some database corruption, and hopefully you don’t.

Yes, a following incremental backup completed in 6 minutes without errors.