Force to remove client immediately

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.

Thanks very much,
Martin

Manually running the cleanup should remove it: https://www.urbackup.org/administration_manual.html#x1-9900011.3

###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%”.

I see, thanks very much.

Because this is a high positioned Google result - I’ll put the idiot’s guide here:

/etc/init.d/urbackupsrv stop
urbackupsrv cleanup -a 0%
/etc/init.d/urbackupsrv start

Will run the cleanup process with a target of cleaning up 0% of backups… So effectively only the removed clients get processed.

4 Likes

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?

Thanks for any tips.

1 Like

Well, the obvious answer would be to read the two scripts and note the differences for yourself.

If I remember correctly (which I may not), cleanup is a subset of what remove-unknown does.

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.

Here is an explanation: 11.4 Cleaning the storage folder of files not known by UrBackup https://www.urbackup.org/administration_manual.html#x1-10000011.4

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.

2 Likes

Excellent, thanks for the info!

note that the operation can take a long time… so it is important to use the screen command to start the process in the background.

1 Like

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

If it matters: I use the binhex image: https://github.com/binhex/arch-urbackup

Solved: The right command for this container is /usr/bin/urbackupsrv cleanup -a 0% -u nobody as urbackup runs as nobody:

[nobody@NAS /]$ /usr/bin/urbackupsrv cleanup -a 0% -u nobody
2022-06-17 09:47:01: Shutting down all database instances...
2022-06-17 09:47:01: Opening urbackup server database...
2022-06-17 09:47:01: SQLite: recovered 1901 frames from WAL file /var/urbackup/backup_server.db-wal code: 283
2022-06-17 09:47:02: SQLite: recovered 147408 frames from WAL file /var/urbackup/backup_server_files.db-wal code: 283
2022-06-17 09:47:02: SQLite: recovered 1136 frames from WAL file /var/urbackup/backup_server_link_journal.db-wal code: 283
2022-06-17 09:47:03: SQLite: recovered 7966 frames from WAL file /var/urbackup/backup_server_links.db-wal code: 283
2022-06-17 09:47:03: SQLite: recovered 189 frames from WAL file /var/urbackup/backup_server_settings.db-wal code: 283
2022-06-17 09:47:03: SQLite: recovered 1901 frames from WAL file /var/urbackup/backup_server.db-wal code: 283
2022-06-17 09:47:03: SQLite: recovered 189 frames from WAL file /var/urbackup/backup_server_settings.db-wal code: 283
2022-06-17 09:47:04: SQLite: recovered 147408 frames from WAL file /var/urbackup/backup_server_files.db-wal code: 283
2022-06-17 09:47:04: Testing if backup destination can handle subvolumes and snapshots...
Backupfolder not set
2022-06-17 09:47:04: Backup destination cannot handle subvolumes and snapshots. Snapshots disabled.
2022-06-17 09:47:04: Cleaning up 0 percent
2022-06-17 09:47:04: Cleaning up 0 bytes on backup storage
2022-06-17 09:47:04: Database cache size is 200 MB
2022-06-17 09:47:04: Starting cleanup...
2022-06-17 09:47:04: Freeing database connections...
2022-06-17 09:47:04: SQLite: recovered 1901 frames from WAL file /var/urbackup/backup_server.db-wal code: 283
2022-06-17 09:47:04: SQLite: recovered 189 frames from WAL file /var/urbackup/backup_server_settings.db-wal code: 283
2022-06-17 09:47:05: SQLite: recovered 147408 frames from WAL file /var/urbackup/backup_server_files.db-wal code: 283
2022-06-17 09:47:05: Deleting client with id "1" name "Test-NB"
2022-06-17 09:47:05: Removing file backup with id "6"
2022-06-17 09:47:05: SQLite: recovered 7966 frames from WAL file /var/urbackup/backup_server_links.db-wal code: 283
2022-06-17 09:47:05: Removing file backup with id "6" successful.
2022-06-17 09:47:05: Removing file backup with id "8"
...