System has been running for a few months without issue; today I noticed the urbackupsrv.service was exiting
Ubuntu Ubuntu 20.04.4 LTS
installed via ppa:uroni/urbackup
status urbackupsrv.service Active: active (exited) since Fri 2022-08-12 14:15:03 ADT; 2min 2s ago
debug log:
2022-08-12 14:15:04: WARNING: SQLite: no such table: directory_link_journal in "SELECT linkname, linktarget FROM directory_link_journal" errorcode: 1
2022-08-12 14:15:04: ERROR: Error preparing Query [SELECT linkname, linktarget FROM directory_link_journal]: no such table: directory_link_journal. Retrying in 1s...
repair-database runs without error
cleanup segfaults:
2022-08-12 14:22:03: WARNING: SQLite: no such table: files in "SELECT MIN(id) AS tmin, MAX(id) AS tmax FROM files WHERE backupid=?" errorcode: 1
2022-08-12 14:22:03: ERROR: Error preparing Query [SELECT MIN(id) AS tmin, MAX(id) AS tmax FROM files WHERE backupid=?]: no such table: files
Segmentation fault
I installed urbackup-server-dbgsym_2.4.15.0-1_amd64.ddeb via opensuse but I still recieve “(No debugging symbols found in /usr/bin/urbackupsrv)”
Is there other info I can provide? Next step I should take?
Sounds like the database is broken now.
Did you enabled the database backup option? If yes, you should see a urbackup folder inside ypur configured backups folder which could be copied back to the config folder (as last option - maybe we want to wait for further replies).
Thanks very much for the reply and info. I do seem to have backups in the default directory with .db .ub and key files all dated 5 days ago -thank goodness for database backups being selected by default!
Should I, then, copy all the files from the backup location and overwrite the files in /var/urbackup/ ?
I see there are files/dirs in /var/urbackup that would not and I assume should not be overwritten.
Can I also ask: is there some kind of maintenance I should be doing to keep these dbs from becoming corrupted? The drive is a fairly new high quality ssd -it’s still possible that the drive is the issue, I know, but if the drive is healthy is there anything I could/should be doing to avoid future corruption?
Delete the whole config dir (the few addiotional files/folders will be re-created)
Copy ALL files from the urbackup folder inside backup dir to the config dir
Fire up urbackup
See, what happens
If I diff my two folders:
root@NAS:~# diff /mnt/cache/appdata/urbackup/ /mnt/user/BackupsV2/urbackup
Only in /mnt/cache/appdata/urbackup/: UrBackupUpdate.exe
Only in /mnt/cache/appdata/urbackup/: UrBackupUpdate.sig
Only in /mnt/cache/appdata/urbackup/: UrBackupUpdate.sig2
Only in /mnt/cache/appdata/urbackup/: UrBackupUpdateLinux.sh
Only in /mnt/cache/appdata/urbackup/: UrBackupUpdateLinux.sig2
Only in /mnt/cache/appdata/urbackup/: backup_server.db-shm
Binary files /mnt/cache/appdata/urbackup/backup_server.db-wal and /mnt/user/BackupsV2/urbackup/backup_server.db-wal differ
Binary files /mnt/cache/appdata/urbackup/backup_server_files.db and /mnt/user/BackupsV2/urbackup/backup_server_files.db differ
Only in /mnt/cache/appdata/urbackup/: backup_server_files.db-shm
Binary files /mnt/cache/appdata/urbackup/backup_server_files.db-wal and /mnt/user/BackupsV2/urbackup/backup_server_files.db-wal differ
Only in /mnt/cache/appdata/urbackup/: backup_server_link_journal.db-shm
Binary files /mnt/cache/appdata/urbackup/backup_server_link_journal.db-wal and /mnt/user/BackupsV2/urbackup/backup_server_link_journal.db-wal differ
Only in /mnt/cache/appdata/urbackup/: backup_server_links.db-shm
Binary files /mnt/cache/appdata/urbackup/backup_server_links.db-wal and /mnt/user/BackupsV2/urbackup/backup_server_links.db-wal differ
Only in /mnt/cache/appdata/urbackup/: backup_server_settings.db-shm
Binary files /mnt/cache/appdata/urbackup/backup_server_settings.db-wal and /mnt/user/BackupsV2/urbackup/backup_server_settings.db-wal differ
Only in /mnt/cache/appdata/urbackup/: backupfolder
Only in /mnt/user/BackupsV2/urbackup: clientlist_b_769.ub
Only in /mnt/cache/appdata/urbackup/: clientlist_b_774.ub
Only in /mnt/cache/appdata/urbackup/: clientlist_b_776.ub
Only in /mnt/cache/appdata/urbackup/: clientlist_b_777.ub
Only in /mnt/cache/appdata/urbackup/: dataplan_db.txt
Only in /mnt/cache/appdata/urbackup/: fileindex
Only in /mnt/cache/appdata/urbackup/: server_token.key
Only in /mnt/cache/appdata/urbackup/: server_version_info.properties
Only in /mnt/cache/appdata/urbackup/: version.txt
Only in /mnt/cache/appdata/urbackup/: version_linux.txt
You can see, that between the client files (which are getting downloaded afaik) there only database changes.
So, Stop urbackup, save CURRENT config dir, do the steps from above and try out
The manual states just how to backup, but not how to restore the internal database
I did as suggested and the service now starts. The index took a few minutes to rebuild then it returned to normal operation
In case someone else can learn from a silly mistake of mine:
I messed up the owner when copying the files back over (just wasn’t thinking). I discovered this by checking /var/log/urbackup.log and seeing ‘error opening file for writing: urbackup/server_ident(…)’. So I changed owner back to user ‘urbackup’, restarted the service and all appears well.
Thank you again, KluthR -really appreciate the help.
Sounds great
Maybe its also worth doing a urbackupsrv remove-unknown?
=> Remove unknown files and directories from backup storage and fix symbolic links in backup storage but not sure. There should be more files than known in backup storage after restoring urbackup database, this command should fix this.
