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.
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.
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.
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.
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"
...