I’ll also throw my hat into the ring on this as I’m also seeing this error.
# urbackupsrv repair-database -u root
2024-01-10 22:19:55: Recovering contents of database with id 20...
2024-01-10 22:19:55: Recovering contents of database with id 30...
2024-01-10 22:19:55: Recovering contents of database with id 23...
2024-01-10 22:19:57: WARNING: SQLite: database corruption at line 56972 of [3bfa9cc97d] errorcode: 11
2024-01-10 22:20:15: WARNING: SQLite: database corruption at line 56972 of [3bfa9cc97d] errorcode: 11
2024-01-10 22:20:23: WARNING: SQLite: database corruption at line 56972 of [3bfa9cc97d] errorcode: 11
2024-01-10 22:21:39: WARNING: SQLite: database corruption at line 56972 of [3bfa9cc97d] errorcode: 11
2024-01-10 22:21:39: Recovering contents of database with id 24...
2024-01-10 22:21:47: Recovering contents of database with id 25...
2024-01-10 22:21:47: Importing database with id 20...
2024-01-10 22:21:47: Importing database with id 30...
2024-01-10 22:21:47: Importing database with id 23...
2024-01-10 22:23:21: Moving rows from lost+found...
2024-01-10 22:23:21: Importing database with id 24...
2024-01-10 22:23:32: Importing database with id 25...
I’m currently using UrBackup Server 2.5.32 on a Rocky Linux 8.9 LXC container on Proxmox 8.1.3. The datastore for this server is on ZFS and the server has ECC memory, so I have a hard time believing that it’s a corruption issue.
The only reason I ran into this issue is related to troubleshooting a different issue about a client using too much space.
Given the diverse hardware/systems in this thread, and the fact we are all receiving the exact same error, it seems like it shouldn’t be due to corruption, however I’m not exactly sure what that warning message means, so I could be misunderstanding it.
Looking at the code, the function that actually generates the error message in the logs appears to be errorLogCallback, which is registered with sqlite3_config here. It appears that database corruption at line 56972 of [3bfa9cc97d] is coming from SQLite itself.
A cursory Google for “database corruption at line” came up with very little. Perhaps there’s a nugget buried somewhere that can be revealed with better search terms or a direct dive into SQLite’s code.
EDIT: I found (I think) the relevant functions in SQLite’s code. sqlite3CorruptError makes the call to sqlite3ReportError, which is the function that actually prints the output. I’m unable to deduce what lineno is actually referring to, or how I’d go about pulling that data out of the UrBackup SQLite db in order to investigate further.