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?
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:
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!
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.
Just a suggestion: change the way the current symlink target is created, to be a relative path instead of an absolute pat, like ./251111-1156instead of /[whatever]/[client]/251111-1156
Hope this makes sense, bit of course, needs to be changed in the code AFAIU