some of my clients seem unable to complete incremental or full file backups (but images backups are working fine)
Assuming that the issue above was related to a corrupt DB, I have tried to run repair_database but it cause the process to core dump.
Running latest version of urbackupsrv on ubuntu. Clients are running latest version of urbackupclient on windows 11 pro. client with the issue is backing up over Lan.
Here the output of running repair-database:
root@hal:/usr/bin# ./urbackupsrv repair-database -u urbackup
2024-05-11 08:23:27: SQLite: recovered 8720 frames from WAL file /var/urbackup/backup_server.db-wal code: 283
2024-05-11 08:23:27: SQLite: recovered 69408 frames from WAL file /var/urbackup/backup_server_files.db-wal code: 283
2024-05-11 08:23:27: SQLite: recovered 8 frames from WAL file /var/urbackup/backup_server_link_journal.db-wal code: 283
2024-05-11 08:23:27: SQLite: recovered 7 frames from WAL file /var/urbackup/backup_server_settings.db-wal code: 283
2024-05-11 08:23:27: SQLite: recovered 8720 frames from WAL file /var/urbackup/backup_server.db-wal code: 283
2024-05-11 08:23:27: Recovering contents of database with id 20...
Segmentation fault (core dumped)
Here is the output of dmesg matchingt he core dumps:
It is best to think of the recovery API as a salvage undertaking. Recovery will extract as much usable data as it can from the wreck of the old database, but some parts may be damaged beyond repair and some rework and testing should be performed prior to returning the recovered database to service.
ouch I see…
in that case, is there a simple way to simply wipe out the db completely and let clients start over? in this case I don’t need to get back older files, I am using urbackup in case of hd/ssd failures only.
Ideally preserving the settings though…
Edit: Except for repair-database, my issue probably wasn’t similar to OP’s. About that: It didn’t work on a brand new database either. But, judging by uroni’s answer, he’s already well aware of it.
Just wanted to share my nearly identical experience on a fresh Ubuntu 22.04 LTS with latest updates and latest UrBackup server. My older Ubuntu 20.04 LTS server has failing hardware and so I’m building a new one. Just got UrBackup running yesterday backing up a couple of computers. Just added another handful today and it was humming along without any issues until suddenly for no apparent reason urbackupsrv crashed and refused to restart. Testing showed nearly identical error messages to OP’s.
urbackupsrv repair-database, remove-unknown, and cleanup all fail. I restored the backed up database and discovered that while remove-unknown and cleanup both work, repair-database still failed with the same error messages. So I took it a step further and nuked the database entirely to start fresh. I was surprised to find that repair-database still failed.
Below is the output from my restored database, but the fresh is the same, just fewer frames in the WAL files.
$ sudo urbackupsrv repair-database -u urbackup
2024-06-15 09:12:06: SQLite: recovered 4943 frames from WAL file /var/urbackup/backup_server.db-wal code: 283
2024-06-15 09:12:06: SQLite: recovered 16 frames from WAL file /var/urbackup/backup_server_link_journal.db-wal code: 283
2024-06-15 09:12:06: SQLite: recovered 241 frames from WAL file /var/urbackup/backup_server_settings.db-wal code: 283
2024-06-15 09:12:06: SQLite: recovered 4943 frames from WAL file /var/urbackup/backup_server.db-wal code: 283
2024-06-15 09:12:06: Recovering contents of database with id 20...
Segmentation fault
To be fair, I’m not exactly running on bare metal with this new server, so probably have several potential problem points. I just found it odd that I’m seeing the exact same errors as the OP did around 30 days ago when nobody else that I’ve found seems to have experienced this same error and posted about it. But if someone could at least confirm for me that repair-database should work on a fresh and updated Ubuntu 22.04 LTS with UrBackup installed via the documentation for the Ubuntu install via the PPA, I’d appreciate it!
FYI, in my case I ended removing everything and restarting backups from scratch (I did reuse the ident keys). so far so good. so I assume it was a on-off glitch db corruption, but it looks like repair-database is not an option.
Hello,
My test configuration: Ubuntu Server 24.04 with Urbackup Server 2.5.33. (Installed from OpenSuSE build service download page)
Only one client with file backups, aprox 60MB of files.
“urbackupsrv repair-database” - the same error: Segmentation fault (core dumped)
All of a sudden all backups of some clients vanished in the web UI. The files on the disk are still there however. I tried repair-database but this also crashes with a segmentation fault. I compiled the debug version of urbackup 2.5.33 and here is the output:
(gdb) run
Starting program: /root/urbackupsrv-debug/urbackup-server-2.5.33/urbackupsrv repair-database -u root
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff64006c0 (LWP 2796635)]
2024-08-18 20:24:37: Recovering contents of database with id 20...
Thread 1 "urbackupsrv" received signal SIGSEGV, Segmentation fault.
open_db (p=p@entry=0x7fffffffb3f0, openFlags=openFlags@entry=0) at sqlite/shell.c:21207
21207 const char *zDbFilename = p->pAuxDb->zDbFilename;
(gdb) bt
#0 open_db (p=p@entry=0x7fffffffb3f0, openFlags=openFlags@entry=0) at sqlite/shell.c:21207
#1 0x00005555556796b6 in do_meta_command (zLine=<optimized out>, p=0x7fffffffb3f0) at sqlite/shell.c:24192
#2 0x0000555555607871 in CDatabase::Recover (this=<optimized out>, pFile="urbackup/server_database_export_20.sql") at /usr/include/c++/12/bits/basic_string.h:233
#3 0x00005555559471db in repair_cmd () at urbackupserver/apps/repair_cmd.cpp:43
#4 0x000055555580e9f7 in LoadActions_urbackupserver (pServer=<optimized out>) at urbackupserver/dllmain.cpp:484
#5 0x0000555555619f3e in CServer::LoadStaticPlugins (this=this@entry=0x555555ccb950) at Server.cpp:2257
#6 0x0000555555637dc0 in main_fkt (argc=<optimized out>, argv=<optimized out>) at main.cpp:571
#7 0x000055555563b40f in main_fkt_catch (argc=<optimized out>, argv=<optimized out>) at main.cpp:130
#8 0x000055555563b442 in real_main (argc=<optimized out>, argv=<optimized out>) at main.cpp:164
#9 0x0000555555a32248 in run_real_main (args=std::vector of length 10, capacity 10 = {...}) at urbackupserver/cmdline_preprocessor.cpp:98
#10 0x0000555555a38b77 in action_repair_database (args=std::vector of length 2, capacity 3 = {...}) at urbackupserver/cmdline_preprocessor.cpp:772
#11 0x000055555560282d in main (argc=<optimized out>, argv=0x7fffffffe998) at urbackupserver/cmdline_preprocessor.cpp:1384