Incremental backup time slot format is incorrect

Hi all,

I’ve been using urbackup for several years. Today, i’m getting a strange error: i can’t save the general server configuration. No matter what I do, it crashes with the following error message:
Incremental backup time slot format is incorrect.

The error message is actually displayed in French, but I’ll present it in English for everyone’s understanding.

What happened? I don’t know… I was playing with the API when I ran the test script and I found myself in this very uncomfortable situation.

Just as mysteriously, the field values have been replaced as follows. For example, instead of having this,

Default directories to back up: /etc; /root; /home

I find this:

Default directories to back up: {'value': '/etc;/home;/root'}

Same for the save interval, the data is contained in an array {value: …}.

image

How can i get out of this delicate situation?
Thank you in advance for your help and suggestions.

Ernest.

Here’s a pastebin link where you’ll find a trace of the API test script execution this morning. :roll_eyes:

Thanks for your help

Ernest.

No answer… I’m not desperate, but almost! This situation is really blocking me, I can’t change any of the UrbackupSRV settings.

Would you advise me to report the problem on the uroni/urbackup-server-python-web-api-wrapper ?

thanks in advance

Ernest.

Did you try changing the values back?
The json notation ({'value': ...}) is obviously not a valid value.

Of course I tried to replace the invalid value with a valid one… but the interface blocks the recording of this correction! :angry:

On reflection, i wonder if the database isn’t corrupted. For example, this morning i observed the following record :

the computer name pve12400 has been replaced by a very dodgy json table : {'value'_ ''}

So I try a database correction operation. Here’s the output:

root@pbs14200:~ # urbackupsrv repair-database
2024-01-08 11:46:12: Recovering contents of database with id 20...
2024-01-08 11:46:17: WARNING: SQLite: database corruption at line 56972 of [3bfa9cc97d] errorcode: 11
2024-01-08 11:49:09: WARNING: SQLite: database corruption at line 56972 of [3bfa9cc97d] errorcode: 11
2024-01-08 11:51:59: Recovering contents of database with id 30...
2024-01-08 11:51:59: Recovering contents of database with id 23...
2024-01-08 11:52:17: WARNING: SQLite: database corruption at line 56972 of [3bfa9cc97d] errorcode: 11
2024-01-08 12:21:52: WARNING: SQLite: database corruption at line 56972 of [3bfa9cc97d] errorcode: 11
2024-01-08 12:22:24: WARNING: SQLite: database corruption at line 56972 of [3bfa9cc97d] errorcode: 11
2024-01-08 12:48:08: WARNING: SQLite: database corruption at line 56972 of [3bfa9cc97d] errorcode: 11
2024-01-08 12:48:16: Recovering contents of database with id 24...
2024-01-08 12:48:20: WARNING: SQLite: database corruption at line 56972 of [3bfa9cc97d] errorcode: 11
2024-01-08 12:48:43: WARNING: SQLite: database corruption at line 56972 of [3bfa9cc97d] errorcode: 11
2024-01-08 12:49:13: WARNING: SQLite: database corruption at line 56972 of [3bfa9cc97d] errorcode: 11
2024-01-08 12:49:37: WARNING: SQLite: database corruption at line 56972 of [3bfa9cc97d] errorcode: 11
2024-01-08 12:49:37: Recovering contents of database with id 25...
2024-01-08 12:49:37: Importing database with id 20...
2024-01-08 12:50:41: Importing database with id 30...
2024-01-08 12:50:41: Importing database with id 23...
2024-01-08 13:47:54: Moving rows from lost+found...
2024-01-08 13:47:55: Importing database with id 24...
2024-01-08 13:48:22: Importing database with id 25...

Restart the server and try again to correct: another failure.

line 56972 in the database doesn’t correct itself…

what can I do?

thank you in advance for your advice and suggestions.

Ernest.

Honestly, at this point I would start from scratch. :confused:
You could try to use sqlite and repair some invalid values directly from the database, but who knows what else is corrupted…

That’s what I resigned myself to doing: reinstalling the application with an empty backup folder.

The error on line 59672 had nothing to do with my problem, as I understood from reading an interesting discussion on the subject.

On the other hand, the presence of json arrays like this one {'value': '/etc;/home;/root'} in place of the valid information /etc; /root; /home contaminated all Urbackup clients outside the local network! :disappointed_relieved:

For example, on a client not in the local network, the authentication key is corrupted:

root@Nextcloud:~ # grep auth /usr/local/var/urbackup/data/settings.cfg
internet_authkey.group={'value': 'Fg5YCmMtyV'}
internet_authkey=FEMk9To90l

but on a local network client, the authentication key is valid:

root@checkmk:~ # grep auth /usr/local/var/urbackup/data/settings.cfg
internet_authkey.group=AVtiGCynzU
internet_authkey=EU4ccjaAeH

I think the urbackup_api_test.py script has definitely corrupted the settings table data in the backup_server_settings.db database… Unfortunately, I didn’t have a backup of the Urbackup application databases.

Ernest.