Is there a way to force UrBackup server to immediately remove client? I am experimenting with UrBackup so I often need to remove the client completely and start again. I have tried to set clean-up time window to 1-7/0-24 but the clients do not get removed anyway. Now it’s already 30 hours and the clients I wanted removed are still there.
###11.3 Cleanup for servers with file backups with lots of files
UrBackup’s database is in a mode which enables high concurrency. Since the cleanup procedure can sometimes be bottlenecked by the database it may be advisable to switch the database into a mode which allows less concurrency but is fast for some operations for the cleanup procedure. This is not possible while UrBackup is running, so you should tweak the backup window such that you can be sure there are no backups running at some point. Then you can stop the server run the cleanup separately by calling urbackupsrv cleanup --amount x
on GNU/Linux or on Windows: cleanup.bat x
Where x is the percent of space to free on the backup storage or the number of Bytes/ Megabytes/ Gigabytes e.g. “20G” or “10%”. If it should only delete old backups use “0%”.
Just curious if you have any idea if there’s a big difference between:
urbackupsrv cleanup -a 0%
and
urbackupsrv remove-unknown
I occasionally use the second command to do exactly what the original poster asked: to remove backups for clients that no longer exist. Is the “cleanup” version faster or better?
I imagine you are correct, but it’s not a small matter of just opening up some scripts in vi and having a look. urbackupsrv is an executable, not a perl or bash script. I suppose I could check the source, but was interested if there was any real world experience with these commands.
Remove unknown is a bit dangerous. For example if for some reason your backup storage folder is currently empty it’ll remove all backups from the database.
Is there another behaviour on dockerized instances?
sh-5.1# /usr/bin/urbackupsrv cleanup -a 0%
2022-06-17 08:35:35: Shutting down all database instances...
2022-06-17 08:35:35: Opening urbackup server database...
2022-06-17 08:35:35: SQLite: recovered 1890 frames from WAL file /var/urbackup/backup_server.db-wal code: 283
2022-06-17 08:35:35: WARNING: SQLite: cannot open file at line 38147 of [fb90e7189a] errorcode: 14
2022-06-17 08:35:35: WARNING: SQLite: os_unix.c:38147: (13) open(/var/urbackup/backup_server_files.db) - errorcode: 14
2022-06-17 08:35:35: Could not open db [urbackup/backup_server_files.db]
2022-06-17 08:35:35: ERROR: Database "urbackup/backup_server_files.db" couldn't be opened
2022-06-17 08:35:35: ERROR: Couldn't open backup server database. Exiting. Expecting database at "/var/urbackup/backup_server_files.db"
sh-5.1# ls -la /var/urbackup/backup_server_files.db
-rwxrwx--- 1 nobody users 157286400 Jun 17 07:38 /var/urbackup/backup_server_files.db
sh-5.1# whoami
root
urbackup is not running:
sh-5.1# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 2368 84 ? Ss Jun16 0:01 /usr/bin/tini -g -- /bin/bash /usr/local/bin/init.sh
root 7 0.0 0.1 33568 20144 ? S Jun16 0:14 /usr/bin/python /usr/bin/supervisord -c /etc/supervisor.conf -n
root 60 0.0 0.0 5360 88 ? S Jun16 0:00 sleep infinity
root 106 0.0 0.0 7612 968 pts/0 Ss+ Jun16 0:00 sh
root 133 0.0 0.0 7612 4360 pts/1 Ss 08:27 0:00 sh
root 161 0.0 0.0 10272 3724 pts/1 R+ 08:36 0:00 ps aux
This warning should be included in the manual. Also it should be reminded that you should run this with the urbackup user (at least for ZFS) or all backups may be removed from the database.