Hi,
I was studying the current folder behavior and discovered that it cannot work when running the server as Container.
The symlink is pointing to the backup folder inside the container. This will never work when browsing the folder on the host, as this path does not exist. Well it exists on the host, but it’s different.
Example:
- Real path on the host
/srv/mergerfs/data/Backup/UrBackup/Joe
- Container path:
/backups/UrBackup
- ‘Current’ symlink Folder points to
/backups/UrBackup/Joe/230325-181, which is unreachable.
The problem is not solved by simply adjusting the path though. I manually created a symlink with the correct path, but all files inside the backup still point to /backups/UrBackup.
I don’t know what’s the fix for this behavior, maybe hardlinks?
kind bump, anyone please?
You need a “bind mount” (a feature of Docker) to map the “inside the container” path to a “host OS path”.
Here is the urbackup section of my docker-compose.yml file, look specifically at the “volumes” section - that is where I specified my three bind mounts:
urbackup:
image: uroni/urbackup-server:production
container_name: urbackup
restart: unless-stopped
network_mode: host
volumes:
- /backups/urbackup/database:/var/urbackup
- /backups/urbackup/backups:/backups
- ./app_data/urbackup/www:/usr/share/urbackup
environment:
- PUID=1009
- PGID=1008
- TZ=America/Denver
Looking at the second line in that volumes section, my “inside the container” path is /backups/urbackup/backups" and that is “bind mounted” to my host OS path of “/backups”.
Hi,
Sorry, but you have misunderstood what I wrote.
I know very well how docker works: I run 30-ish containers on my home server and I often build from scratch my Docker Compose files.
I am reporting a bug/issue regarding the current folder of UrBackup, which is a symlink to the latest backup. This is broken when you run UrBackup Server in docker, because the symlink it creates references the path inside the container that does not exist - and will never exist - on the host.
Therefore, UrBackup should account for this scenario; one possible solution is to allow the user to define the equivalent host path so it can be used in the current folder symlink and be usable on the host.
Since UrBackup has the feature to run a script after the backup, I will attempt to make one to fix the current folder. I will keep this discussion updated if I succeed!
Ahhh … I see what you are talking about now. The view from my host OS:
Linux-server-1 ASUS-Laptop # ls -lt | head
total 208
lrwxrwxrwx 1 urbackup urbackup 32 Apr 19 05:21 current → /backups/ASUS-Laptop/230419-0515
drwxr-x— 5 urbackup urbackup 4096 Apr 19 05:21 230419-0515
drwxr-x— 5 urbackup urbackup 4096 Apr 18 05:24 230418-0514
drwxr-x— 2 urbackup urbackup 4096 Apr 18 05:14 230418-0306_Image_C
drwxr-x— 2 urbackup urbackup 4096 Apr 18 03:06 230418-0305_Image_ESP
drwxr-x— 2 urbackup urbackup 4096 Apr 18 03:05 230418-0304_Image_SYSVOL
drwxr-x— 5 urbackup urbackup 4096 Apr 17 04:18 230417-0415
drwxr-x— 5 urbackup urbackup 4096 Apr 16 04:14 230416-0412
drwxr-x— 5 urbackup urbackup 4096 Apr 15 04:16 230415-0410
Linux-server-1 ASUS-Laptop # pwd
/backups/urbackup/backups/ASUS-Laptop
Linux-server-1 ASUS-Laptop # cd ./current
-su: cd: ./current: No such file or directory
Linux-server-1 ASUS-Laptop #
I have never tried to access “current” from the host OS (or even from inside the container for that matter). I just use the web GUI and everything works from there. So I had never noticed the issue that you are describing here.
I don’t know, but I would guess, that manually messing with “current” could be very bad for UrBackup. If you really need something pointing to that latest backup, I’d name it “my_current” or something like that in any scripts that you create. When UrBackup running inside the container needs to access a path, that path needs to be accessible from inside the container (of course you know this). If you were to manually change the symlink to point to the path outside the container, that’s going to throw UrBackup into fits if it ever tries to access it from inside the container.
Maybe things would work better for your needs if UrBackup did not create the symlink using a fully qualified pathname, but instead used a relative pathname like:
current → ./230419-0515
I’m kind of surprised that UrBackup doesn’t do something like this already. Because I can’t image anybody actually keeping their backups inside the container. Probably UrBackup was not written thinking that it might run inside something - a container or a VM or similar.
What’s exactly what I thought after digging into this issue.
By the way, the current folder is very important to me, because I can use it to see my files via Nextcloud, or index them from another computer.
I might have found a solution, which consists in disabling symlinks and using a script to adjust the current folder.
I’ll update in a couple of days to confirm works good and provide all the details.