Hi,
I use the official urbackup docker image. I migrated from another, custom build one. The custom build handles paths in a different way, so all symlinks are now “dead”. I read, that remove-unknown handles this (UrBackup - Server administration manual) but I cant manage to stop urbackupsrv without stopping the containerm since it is pid 1.
Any hints how I run urbackupsrv remove-unknown inside the official docker containerm without firing up the main entry urbackupsrv run?
Thanks 
Hmm, I tested to run the command with urbacksrv already running and this seem to work:
I detached the NIC, so urbackupsrv cant do anything. I then just typed the command and the server started to fix symlinks. Its still doing the deep link check but Iam optimistic. If that exist without error, I restart the main process and hope all is done
Okay, that worked. And a second run did not discover any erros anymore:
2022-08-11 06:46:00: Going to remove all unknown files and directories in the urbackup storage directory. Waiting 20 seconds...
2022-08-11 06:46:20: Shutting down all database instances...
2022-08-11 06:46:20: Opening urbackup server database...
2022-08-11 06:46:20: Testing if backup destination can handle subvolumes and snapshots...
Testing for btrfs...
ERROR: not a btrfs filesystem: /backups/testA54hj5luZtlorr494
TEST FAILED: Creating test btrfs subvolume failed
Testing for zfs...
TEST FAILED: Dataset is not set via /etc/urbackup/dataset
2022-08-11 06:46:20: Backup destination cannot handle subvolumes and snapshots. Snapshots disabled.
2022-08-11 06:46:20: Cleaning up 0 percent
2022-08-11 06:46:20: Cleaning up 0 bytes on backup storage
2022-08-11 06:46:20: Database cache size is 200 MB
2022-08-11 06:46:20: Starting cleanup...
2022-08-11 06:46:20: Freeing database connections...
2022-08-11 06:46:20: Enough free space now.
2022-08-11 06:46:20: Enough free space now.
2022-08-11 06:46:20: Client with id=1 has 7 full file backups max=52
2022-08-11 06:46:20: Client with id=1 has 168 incremental file backups max=168
2022-08-11 06:46:20: Client with id=3 has 4 full file backups max=52
2022-08-11 06:46:20: Client with id=3 has 30 incremental file backups max=168
2022-08-11 06:46:20: Client with id=4 has 7 full file backups max=52
2022-08-11 06:46:20: Client with id=4 has 168 incremental file backups max=168
2022-08-11 06:46:20: Client with id=5 has 4 full file backups max=52
2022-08-11 06:46:20: Client with id=5 has 31 incremental file backups max=168
2022-08-11 06:46:20: Client with id=6 has 2 full file backups max=52
2022-08-11 06:46:20: Client with id=6 has 1 incremental file backups max=168
2022-08-11 06:46:20: Client with id=2 has 1 full file backups max=1
2022-08-11 06:46:20: Client with id=2 has 0 incremental file backups max=0
2022-08-11 06:46:20: Deleting old logs...
2022-08-11 06:46:20: Done deleting old logs
2022-08-11 06:46:20: Cleaning history...
2022-08-11 06:46:20: Rewriting daily history...
2022-08-11 06:46:20: Reading history...
2022-08-11 06:46:20: 289 history items read
2022-08-11 06:46:20: Deleting history...
2022-08-11 06:46:20: Writing history...
2022-08-11 06:46:20: Rewriting monthly history...
2022-08-11 06:46:20: Reading history...
2022-08-11 06:46:20: 0 history items read
2022-08-11 06:46:20: Deleting history...
2022-08-11 06:46:20: Writing history...
2022-08-11 06:46:20: Rewriting yearly history...
2022-08-11 06:46:20: Reading history...
2022-08-11 06:46:20: 0 history items read
2022-08-11 06:46:20: Deleting history...
2022-08-11 06:46:20: Writing history...
2022-08-11 06:46:20: Done cleaning history
2022-08-11 06:46:20: Cleaning deleted backups history...
2022-08-11 06:46:20: Done cleaning deleted backups history.
2022-08-11 06:46:20: Cleaning up client lists...
2022-08-11 06:46:20: Done cleaning up client lists.
2022-08-11 06:46:20: Cleaning up old client access tokens...
2022-08-11 06:46:20: Done cleaning up old client access tokens.
2022-08-11 06:46:20: Updating statistics...
2022-08-11 06:46:20: Updating image stats...
2022-08-11 06:46:20: Updating file statistics...
2022-08-11 06:46:20: Done updating statistics.
2022-08-11 06:46:20: Enough free space now.
2022-08-11 06:46:20: Cleanup successfull.
2022-08-11 06:46:20: Removing unknown for client "Client1"
2022-08-11 06:47:50: Removing unknown for client "Client2"
2022-08-11 06:48:10: Removing dangling file entries...
2022-08-11 06:48:11: Deleted 0 file entries
2022-08-11 06:48:11: Successfully removed all unknown files in backup directory.
BUT I found out, that the symlinks under clients as well the current symlink under each client folder was NOT (yet?) updated. And I dont know if they should. @uroni ?
Another off topic question: urbackup uses two volumes: /backups and /var/urbackup - the first is obvious, the second should be the config?
I found out, that urbackup always store its config inside /backups too (inside urbackup)! Why is this? => Ahh, it seems that this is a regular database backup (backup_database)
Thanks
Too late but it might help fellows.
This is dangerous as remove-unkown is designed to be run with the server down.
stop your docker container for the server:
docker stop urbackup
start a docker container running urbackupsrv with the argument you want by using docker CMD:
version: '2'
services:
urbackup:
image: uroni/urbackup-server:latest
container_name: urbackup_remove-unknown
command: remove-unknown
environment:
- PUID=1002 # Enter the UID of the user who should own the files here
- PGID=100 # Enter the GID of the user who should own the files here
- TZ=Europe/Paris # Enter your timezone
volumes:
- /srv/dev-disk-by-label-secure/appdata/docker/urbackup/etc_default_urbackupsrv:/etc/default/urbackupsrv
- /srv/dev-disk-by-label-secure/appdata/docker/urbackup/var_urbackup:/var/urbackup
- /srv/dev-disk-by-label-secure/appdata/docker/urbackup/var_log:/var/log
- /srv/dev-disk-by-label-secure/backup/urbackup:/backups
cap_add:
- SYS_ADMIN # Activate the following two lines for BTRFS support
I added that snippet as a portainer stack but you should be able to run it with docker compose.
Once this remove-unknown container is created, you can start it with:
docker start urbackup_remove-unknown
I did not find a way to stop the server container when I ran the remove-unknown one. So you have to think about stopping the daemon container before running the remove-unknown one.