urbackup-server-2.5.33, CentOS 7 linux, zfs file store
urbackupsrv started crashing on a SEGV - it looked like a sqlite problem. Ran defrag-database, then repair-database, which died with segmentation fault when (I think) working on backup_server_files.db. Ended up running sqlite3 PRAGMA integrity_check which passed, and then a dump/restore of backup_server_files.db.
And, on restart, urbackupsrv logged (and started doing)
WARNING: Creating file entry index. This might take a while…
With a 66GB backup_server_files.db and over 100 million records, this looks like it’s going to take days (at least) to complete. I ran the linux tuning hints from the update_server.html page.
Is there any way to speed this up, or just rebuild from scratch, or move older backups out of the way and ignore them? Any hints would be appreciated. Thanks!
Yes, it will take days.
I did that once and thought it had hung after 2 days. But, it hadn’t.
I would consider (I have been considering) Changing the server engine to mysql. Read something about doing that somewhere on here a while ago.
I wonder what might happen if I use SQL to remove old entries from backup_server_files.db ? Yes, I would likely lose history from the web interface, and I might have to manually clean up old backup directories later, but it might get backups running again? And we all know that most backed up files are never needed, and most restores only need recent backups. Hmmm.
That seems to have done the trick - so far so good. For anyone else who stumbles on this, I did:
cd urbackup/var
make a backup copy of *.db
echo 'DELETE from files;' | sqlite3 backup_server_files.db
mv fileindex fileindex.hide
and urbackup seems to be up and running again. I may keep an eye on disk usage going forward, just to make sure cleanups happen as expected.
Thanks very much for the help, and for urbackup!