Basically this is the fastest way against several days experimenting and puzzling bringing back your old situation which you will not bring back to work anymore.
TBH, I don’t like that approach
Me neither! Unfortunately this is a lesson learned after updating different versions with several customers. You could spend lot’s of time fixing the corrupt table, but after extensive research we found out that this is a much cleaner solution. At one time we thought having fixed the issue, but realized that randomly strange behaviors started to show up.
True, you would love to keep your build history, but in most cases you haven’t a disaster recovery situation. This is your disaster recovery solution, so make it available again as fast as you can.
The time consuming thing is backing up everting again (full back-up). After that you are in business again and yea, you miss your history.
We are also recieving
“WARNING: SQLite: database corruption at line 56972 of [3bfa9cc97d] errorcode: 11”
What are people doing to get around this?
Use: -u root
If no root user you will get this error code 14.
TEST IT: urbackupsrv remove-unknown -u root
After:
urbackupsrv reset-admin-pw -a admin -p PASSWORD
“Change admin root user password and after no more error 14”
So, is there no resolution for this error?
WARNING: SQLite: database corruption at line 56972 of [3bfa9cc97d] errorcode: 11
Running on Debian 12 (bookworm) but have seen in on earlier versions.
8GB of Non-ECC memory, and Urbackup V2.5.31
Same problem with urbackup 2.5.3.1 on a refurbished qnap TS1232XU-RP (QTS 5.1.0.2466 - ARM Cortex A57 - 4GB).
In my case it’s a fresh install, no updates from previous versions.
same problem windows server 2016 wath to do ?
version 2.5.31
A year has passed, still no solution 
After the last time I started clean, it happened again.
Maybe use some different kind of disk that doesn’t corrupt the data?
That said, I don’t understand why it would still be corrupt after the repair. That completely rebuilds the database…
Thanks for your reply.
The disks are fine as far as I can tell. They passed the long SMART test and badblocks.
Filesystem is ext4 which is considered safe (will now start from scratch on btrfs).
BTW: Backups and restore seem to be succeeding even with this error. This, in conjunction with the claim that repair completely rebuilds the database, maybe hint that it’s a software error?
Is your system using ECC RAM? Because to me this screams defect RAM.
1 Like
No.
If it is only in backup_server_files.db btw. all it breaks is the file dedup. So it is going to store some files multiple times perhaps – not a big deal.
Would be more worried about hardware issues (disk/RAM) though.
How To Corrupt An SQLite Database File lists the ways this can happen. As for software issues perhaps 5. applies, the best tool to find issues there is to compile with -fsanitize=address.
I think I found the root cause of “WARNING: SQLite: database corruption at line” in my setup. urbackup uses /var/urbackup for sqlite DB files storage. That folder was configured as a symlink to another one. After I replaced it with the bind mount, the issue has disappeared.
I’m using bindfs, you think it matters?
bindfs -u urbackup -g urbackup /storage/var/urbackup /var/urbackup
I’m not aware of bindfs, sorry. I just added this entry into /etc/fstab:
/zmir/urbackup /var/urbackup none defaults,bind 0 0
Yes… now you are adding two new things where there could be bugs, fuse and bindfs. And IMO bugs in fuse and bindfs are more likely than sqlite (e.g. there is an issue that bindfs doesn’t implement fsyncdir which sqlite needs…).
Please just use a bind mount and a standard/popular file system.
It was worth the try, but still…
# urbackupsrv repair-database
2023-10-30 22:23:24: SQLite: recovered 4491 frames from WAL file /var/urbackup/backup_server.db-wal code: 283
2023-10-30 22:23:24: SQLite: recovered 176043 frames from WAL file /var/urbackup/backup_server_files.db-wal code: 283
2023-10-30 22:23:24: SQLite: recovered 28 frames from WAL file /var/urbackup/backup_server_link_journal.db-wal code: 283
2023-10-30 22:23:24: SQLite: recovered 50 frames from WAL file /var/urbackup/backup_server_settings.db-wal code: 283
2023-10-30 22:23:24: SQLite: recovered 4491 frames from WAL file /var/urbackup/backup_server.db-wal code: 283
2023-10-30 22:23:24: Recovering contents of database with id 20...
2023-10-30 22:23:24: SQLite: recovered 50 frames from WAL file /var/urbackup/backup_server_settings.db-wal code: 283
2023-10-30 22:23:24: Recovering contents of database with id 30...
2023-10-30 22:23:25: SQLite: recovered 176043 frames from WAL file /var/urbackup/backup_server_files.db-wal code: 283
2023-10-30 22:23:25: Recovering contents of database with id 23...
2023-10-30 22:23:30: WARNING: SQLite: database corruption at line 56972 of [3bfa9cc97d] errorcode: 11
2023-10-30 22:23:31: WARNING: SQLite: database corruption at line 56972 of [3bfa9cc97d] errorcode: 11
2023-10-30 22:23:49: WARNING: SQLite: database corruption at line 56972 of [3bfa9cc97d] errorcode: 11
2023-10-30 22:24:09: WARNING: SQLite: database corruption at line 56972 of [3bfa9cc97d] errorcode: 11
2023-10-30 22:24:09: Recovering contents of database with id 24...
2023-10-30 22:24:09: SQLite: recovered 28 frames from WAL file /var/urbackup/backup_server_link_journal.db-wal code: 283
2023-10-30 22:24:09: Recovering contents of database with id 25...
2023-10-30 22:24:11: Importing database with id 20...
2023-10-30 22:24:13: Importing database with id 30...
2023-10-30 22:24:14: Importing database with id 23...
2023-10-30 22:24:38: Moving rows from lost+found...
2023-10-30 22:24:39: Importing database with id 24...
2023-10-30 22:24:39: Importing database with id 25...
Command used:
mount --bind /storage/var/urbackup /var/urbackup
Filesystem: ext4
Yeah, repair-database still prints the database corruption warning. I’m sorry for misinforming you.