Hello!

today i noticed that my urbackup folder under appdata occupies a lot of space.

• urbackup.log was 6.5 gb (ERROR: Sending broadcast failed! (ipv6), hopefully i was able to fix this by setting BROADCAST_INTERFACES="eth0")!
• the other culprid is backup_server_files.db with 3.6 gb. seems excessive... or is this normal?

best regards

DB is normal, that's what keeps tracks of the millions of items that are backed up

 

urbackupsrv defrag-database -u root

might shrink it a bit

Edited April 14, 20251 yr by Kilrah

A noob is getting lost... but think I have worked it out now. I want to backup one Unraid box to an older Unraid box using urBackup.

I have a four year old urBackup server on Unraid. Nice. Runs great and saved my old server more than one. Thanks @binhex

I built a new, separate Unraid box, and now want to back that up to the same old urBackup server.

To install the client, I read the pinned post and ran the script from here: https://www.urbackup.org/download.html#linux_all_binary

TF=$(mktemp) && wget "https://hndl.urbackup.org/Client/2.5.25/UrBackup%20Client%20Linux%202.5.25.sh" -O $TF && sudo sh $TF; rm -f $TF

And that worked great. It backed up.

But how do I get it to survive a reboot? What do I copy to where on the USB stick?

I saw the post that followed and don't know how to do that :"as its installed to ram (keep in mind everything is in ram in unraid, other than cache, array disks and flash drive), so you will probably(i dont know yet), have to re-run the script i mentioned above, or perhaps just copy the urbackupclient that gets built and shove that on your flash drive and then copy that to /usr/local/bin/ and execute that as part of the go script - whateve the mechanism there is a bit of fiddling to be done but its def doable!."

Yeah... I got lost. Rebooted, and it has all gone. So what do I need to copy to where? I assume someone in this thread has done this? (And yes, I tried to read this thread and didn't quite get all the answers)

Edited: After 3 hours of reading, think I have found the answer on page 11 of this thread: https://forums.unraid.net/topic/82198-support-binhex-urbackup/page/11/#findComment-1201888

Thanks @Nepherim

Also there were a couple of questions during install I had to guess a reply to. Anyone any idea on these?

Please select the snapshot mechanism to be used for backups:

3) btrfs filesystem snapshots (dattobd and LVM will automatically use btrfs snapshots for btrfs filesystems)

4) Linux device mapper based snapshots (supports image backups and changed block tracking)

5) Use no snapshot mechanism. Files will be backed up without creating snapshots of them. Images backups will be not supported.

Enter choice (number 1-5, then enter): 4

I picked 4? Was that right? I only want file backups anyway of my four xfs disks.

Edit to add: Should have picked option 5 as four is leaving errors in my log files on every run. Now need to work out how to change that setting. Guess I need to re-run the script.

Also

Convert root device into device mapper device on boot (initramfs)? This is required for root device/filesystem backup. [Y/n]

I guessed a no as I only want file backup?

thanks

Edited June 25, 20251 yr by Batter Pudding
Updating with answers to myown questions

So "all of the sudden" (I know, but I really think it's true!), my URBackup stopped working because it's not connecting to the internet. I tried installing a new client (on same Windows VM) but no luck. I do a full image backup every day and this is what I'm seeing:

13 hours ago, betaman said:

So "all of the sudden" (I know, but I really think it's true!), my URBackup stopped working because it's not connecting to the internet

is there a specific reason you need your urbackup clients to connect to the server over the internet?, mine all connect within the LAN:

12 hours ago, binhex said:

is there a specific reason you need your urbackup clients to connect to the server over the internet?, mine all connect within the LAN:

No not really since they're on the same LAN. However, I was addressing this message as root cause:

Edited August 4, 2025Aug 4 by betaman

4 minutes ago, betaman said:

No not really since they're on the same LAN. However, I was addressing this message as root cause:

You seem to have your clients set to connect over the internet (from your screenshot), untick that option if all clients are on the same LAN.

1 hour ago, betaman said:

was addressing this message as root cause:

It just means that somehow it's not seeing the server on the LAN, so check your networking and test reachability. Or restart the server, maybe it crashed and stopped sending broadcasts.

Edited August 4, 2025Aug 4 by Kilrah

1 hour ago, binhex said:

You seem to have your clients set to connect over the internet (from your screenshot), untick that option if all clients are on the same LAN.

That's what I did and received again the original error of No Internet Server configured.

45 minutes ago, Kilrah said:

It just means that somehow it's not seeing the server on the LAN, so check your networking. Or restart the server, maybe it crashed and stopped sending broadcasts.

Ok, I will reboot the server once a parity check completes.

Restarting the server container is what I meant.

18 minutes ago, Kilrah said:

Restarting the server container is what I meant.

I’ve already tried that as well as restarting the client machine to no avail.

10 hours ago, betaman said:

That's what I did and received again the original error of No Internet Server configured.

ok this is what i think has happened:

1. your urbackup clients were happily connecting to urbackup server locally over the lan - happy days

2. something/someone ticked the option to set the urbackup clients to connect over the internet, the default 'server url clients connect to' was left as a blank url 'urbackup://' (invalid url).

3. your urbackup clients get pushed the change from the server to connect over the internet instead of the lan and the client accepts the change, including the badly defined url.

4. voila! your urbackup clients now have broken connectivity, they are attempting to connect over the internet to a urbackup server url of 'urbackup://' and failing to connect, and changing the option back on the server now does nothing, because the clients are not listening for the server over the lan (incorrectly configured).

So how do you get out of this?, easiest way is to right click the systray icon for the urbackup client, select settings/internet tab and untick the option enable backup via internet:

note: ensure you do NOT have the option set on your urbackup server 'clients try to connect via internet/active client' otherwise you will be going in circles as the server will auto reconfigure the client again and break connection.

4 hours ago, binhex said:

ok this is what i think has happened:

1. your urbackup clients were happily connecting to urbackup server locally over the lan - happy days

2. something/someone ticked the option to set the urbackup clients to connect over the internet, the default 'server url clients connect to' was left as a blank url 'urbackup://' (invalid url).

3. your urbackup clients get pushed the change from the server to connect over the internet instead of the lan and the client accepts the change, including the badly defined url.

4. voila! your urbackup clients now have broken connectivity, they are attempting to connect over the internet to a urbackup server url of 'urbackup://' and failing to connect, and changing the option back on the server now does nothing, because the clients are not listening for the server over the lan (incorrectly configured).

So how do you get out of this?, easiest way is to right click the systray icon for the urbackup client, select settings/internet tab and untick the option enable backup via internet:

note: ensure you do NOT have the option set on your urbackup server 'clients try to connect via internet/active client' otherwise you will be going in circles as the server will auto reconfigure the client again and break connection.

So I agree this endless loop seems to be the issue. I checked the server settings and the internet option was checked so I unchecked it. Went back to client settings and did same thing. A little later I check both server and client settings and client is back to internet checked even though server isn’t checked. I say F it and uninstall and reinstall client.

Now I get this (server still showing internet unchecked) after an initial message saying URBackup was waiting for local server.

EDIT: So now I see this message. I also just had to enable permissions on the client because the client name was the same as the prior one.

Edited August 5, 2025Aug 5 by betaman

After getting the server and client side settings in sync again (i.e. local connection vs internet) and rebooting the server, it's working again. Thanks!

I tried to open a backed up image today, but getting an error. And I think I know what is going on on but don't want to break things 'cos I am noob in docker apps.

Clearly the image BACKUPs are working as the large files are there, but the retrieval of the images is not possible. The paths are confused somewhere and the server is looking in the wrong place when attempting to mount the image.

Note there is no problem with file backups.

I am editing this post as I work through a process of elimination which also includes a crash course in how docker actually sees things...😁

First, my settings:

Settings page:

The GUI shows me:

All BACKUPS are happening fine. And I can access FILE backups no problem. It is only mounting images is trouble.

I attempt to open an Image file via the GUI. It fails to mount. It can't find it as it is looking in the wrong place 😕.

The only thing I change in the pictures below is my PC name that is being backed up. Nothing else... no other part of the path

I can go to /media/urbackup/MY-COMPUTER/250902-0030.... and find that backup is there. The backup exists, but not where it is looking. It has forgotten to add the /urbackup/ part

Also in the log are cleanup messages, but that gets things correct and looks in the full path:

Here the path is the full /media/urbackup/ in front of it. This one is trying to delete from the correct place (just can't find it as something else already deleted it).

Question

How do I fix where it opens the image from? Clearly the BACKUP is working fine. And I can access and recover files from the file side, just something is going wrong mounting the Image backups. It feels to me like some confusion of paths have crept in here.

This is a REALLY old install of urbackup on an old v6.12.15 server. Has a path changed somewhere else? How do I fix this without disrupting the file backups? ONLY image backups seem to have an issue.

Note - these images are from a Windows PC. Sure they used to work last I looked, but that could be years ago.

Is there a simple tweak I can do to get it to look at the right place?

My guessed answer

I am a noob to this, but I am trying to make an educate guess at the answer. To me it is in those first two images. Are my initial settings wrong? Surely /media/ should point to /mnt/user/urbackup/ and the GUI should therefore just point to /media/ as to where it puts its backups?

Updated: okay... so I am new to this stuff... and crash learning docker as I go along. I just learnt how to "open a terminal in the docker" so have re-written my previous dumb initial post. But that backup is in /media/urbackup/MY-COMPUTER/ and not just in /media/MY-COMPUTER/ like the log is showing when it tries to mount the image. Why is the image being loaded from the wrong place?😕

Edited September 14, 2025Sep 14 by Batter Pudding
Learning and adjusting facts

On 9/14/2025 at 2:31 PM, Batter Pudding said:

You should usually never pass the whole of /mnt/user to a container, you'd have created a share for it first (say "urbackup") and passed /mnt/user/urbackup to the container, then set /media as backup location.

But it's unrelated, AFAIK that feature isn't possible to use in a/this container anyway because it needs to do a fuse mount and what's required to do that isn't available.

Edited September 16, 2025Sep 16 by Kilrah

2 hours ago, Kilrah said:

You should usually never pass the whole of /mnt/user to a container

Thanks for confirming. This is what I started to learn, and realised was looking wrong. But can I fix that now without messing up the backups? If I changed the /media to point to /mnt/user/urbackup and updated the backup storage path to point to /media as your screenshot would the backups be happy and continue as they are now, with continued update to the current backups? Isn't there file links I need to be concerned about?

To be fair, the only thing that has ever lived on that UNRAID box is urBackup. So no harm it being "wrong", but would be useful to correct.

2 hours ago, Kilrah said:

But it's unrelated, AFAIK that feature isn't possible to use in a/this container anyway because it needs to do a fuse mount and what's required to do that isn't available.

Managed to re-read part of this thread (for approx 10th time) and could see my problems. And now understand this is not a feature of our Docker version. Guess the time I was thinking of is when I have done this on a server running on Windows.

But all was not lost. Even though the GUI would not let me unpack. The backups are there, just had to do some faffing around. I ended up manually dragging the last "full" backup back to my PC. And then raided files from the Windows Server edition so I could run "uncompress_image.bat"

I need to dig in and experiment a bit more. But importantly yesterday I got back the 20KB of files I needed, after transferring 367GB across the network and unpacking that to a 500GB file!! LOL. Good job I had plenty of disc space 🤣

Now, next time this happens, I assume I could attempt to uncompress directly across the network? Looking at how that script ran it was trying to index back through the incrementals.

Edited September 16, 2025Sep 16 by Batter Pudding

I want to fix my paths (see above)

In a standard install where the /media/ points to /mnt/user/urbackup and the Backup Storage Path is /media what is in your /mnt/user/urbackup folder?

I assume you have

BackupName

BackupName2

urbackup (with the database files in it)

urbackup_temp_files

As long as "urbackup" is a folder in there with the database files in it, I can't see why I can't just fix this. Stop server, fix paths, restart server.

I do notice that at the moment I have two "urbackup_temp_files" folders. On in /mnt/user/ and one in /mnt/user/urbackup/. I guess one of those is not normally sitting there.

On 9/16/2025 at 12:59 PM, Batter Pudding said:

Now, next time this happens, I assume I could attempt to uncompress directly across the network? Looking at how that script ran it was trying to index back through the incrementals.

Why not use the file backup function in urbackup, i use this myself and can restore accidently deleted files from my windows machine in minutes, that way you dont have to deal with a honking massive disk image and all the decompress/mount issues.

On 9/16/2025 at 12:59 PM, Batter Pudding said:

To be fair, the only thing that has ever lived on that UNRAID box is urBackup. So no harm it being "wrong", but would be useful to correct.

If that is true you might want to consider making a note not to do it in the future and leave it at that, if there are no other shares then the risk is zero.

If you do want to be brave (this may cause issues) then the trick here is to NOT change the container path and instead change the host path ONLY, so i assume you told urbackup to store files in /media/urbackup (or similar, right?), so what you want to do is change /media for the container to point at /mnt/user/urbackup and then copy all files and folders in /mnt/user/urbackup/ (share created by urbckup) to /mnt/user/urbackup/urbackup/, yes its a bit ugly but it gets you around the issue.

Good luck!, if there is important data in your backups then tread carefully here!.

1 hour ago, Batter Pudding said:

In a standard install where the /media/ points to /mnt/user/urbackup and the Backup Storage Path is /media what is in your /mnt/user/urbackup folder?

I assume you have

BackupName

BackupName2

urbackup (with the database files in it)

urbackup_temp_files

Yup

On 9/16/2025 at 1:59 PM, Batter Pudding said:

If I changed the /media to point to /mnt/user/urbackup and updated the backup storage path to point to /media as your screenshot would the backups be happy and continue as they are now, with continued update to the current backups?

I believe so, but not sure if the DB stores relative/absolute paths etc...

On 9/16/2025 at 1:59 PM, Batter Pudding said:

I need to dig in and experiment a bit more. But importantly yesterday I got back the 20KB of files I needed, after transferring 367GB across the network and unpacking that to a 500GB file!! LOL. Good job I had plenty of disc space 🤣

Yeah that's why IMO file backups are more suitable, I never do images in urbackup unless it's a situation where I know I might need to restore that straight away e.g. if a full OS upgrade fails.

With file backups you can just browse to the file in the webui and click restore, or if the file is still there but you just need to restore an older version you just right-click on it and restore.

On 9/16/2025 at 1:59 PM, Batter Pudding said:

Now, next time this happens, I assume I could attempt to uncompress directly across the network?

Sure

Edited September 18, 2025Sep 18 by Kilrah

3 hours ago, binhex said:

Why not use the file backup function in urbackup

This was a fresh install of a new PC, and I thought I'd go for the Image backups on the boot drive like I used with a friend on a Windows Server running urBackup. I have a weird PC with multiple drives so most stuff was already split out onto other drives and file backups. Just really the OS drive had a Image Backup, and of course Sod's Law said I needed 40KB of files I had deleted a little earlier...

At least I know now how to manually reassemble things from a VHDZ. 😁Grab a few files from the Windows Server to uncompress, and have a ton of disk space to hand. Out of a disaster one always learns something new.

3 hours ago, binhex said:

If that is true you might want to consider making a note not to do it in the future and leave it at that, if there are no other shares then the risk is zero.

This is likely what I'll do. If it ain't broke, don't fix it. Though in the near future I know I'll upgrade that ancient box to get a faster disk controller in there. So the OCD says to try and tidy up a bit with the paths. Your comments on needing to move urbackup into a urbackup subfolder makes me realise it is not as simple as I hoped. I was hoping the backup database also used that same /media/urbackup path as noted in the GUI.

2 hours ago, Kilrah said:

Yeah that's why IMO file backups are more suitable

All my other backups are file backups. That Image backup was a bit of a new experiment really. Already adjusting the plan there.

That PC really only has OS on the C drive. D drive is data. E drive is apps, etc. This split setup makes backup easier.

Part of it was to avoid a full reinstall of my main PC if a disaster occurred. So I think I am going to just readjust my disaster recovery plan

Thanks all 😁

Edited September 18, 2025Sep 18 by Batter Pudding

Had an update for the app and once it applied its failing to start.

Created by...
___.   .__       .__
\_ |__ |__| ____ |  |__   ____ ___  ___
 | __ \|  |/    \|  |  \_/ __ \\  \/  /
 | \_\ \  |   |  \   Y  \  ___/ >    <
 |___  /__|___|  /___|  /\___  >__/\_ \
     \/        \/     \/     \/      \/
   https://hub.docker.com/u/binhex/
2025-11-10 09:10:53.455264 [info] Host is running unRAID
2025-11-10 09:10:53.490462 [info] System information: Linux LahomaMediaCenter 6.12.54-Unraid #1 SMP PREEMPT_DYNAMIC Tue Oct 21 15:58:46 PDT 2025 x86_64 GNU/Linux
2025-11-10 09:10:53.526141 [info] Image architecture: 'amd64'
2025-11-10 09:10:53.560683 [info] Application name: 'urbackup'
2025-11-10 09:10:53.596440 [info] Base image release tag: '2025110901'
2025-11-10 09:10:53.634150 [info] Application image release tag: '2.5.34-1-01'
2025-11-10 09:10:53.676988 [info] PUID defined as '99'
2025-11-10 09:10:53.721146 [info] PGID defined as '100'
2025-11-10 09:10:53.997519 [info] UMASK defined as '000'
2025-11-10 09:10:54.035374 [info] Permissions file '/config/perms.txt' exists, skipping setting ownership and permissions on '/config' and '/data'
2025-11-10 09:10:54.075479 [info] Deleting files in /tmp (non recursive)...
2025-11-10 09:10:54.119648 [info] Starting Supervisor...
2025-11-10 09:10:54,268 INFO Included extra file "/etc/supervisor/conf.d/urbackup.conf" during parsing
2025-11-10 09:10:54,269 INFO Set uid to user 0 succeeded
2025-11-10 09:10:54,273 INFO RPC interface 'supervisor' initialized
2025-11-10 09:10:54,273 INFO supervisord started with pid 7
2025-11-10 09:10:55,276 INFO spawned: 'urbackup' with pid 57
2025-11-10 09:10:55,277 INFO reaped unknown pid 8 (exit status 0)
2025-11-10 09:10:55,295 DEBG 'urbackup' stderr output:
/home/nobody/start.sh: line 20:    63 Illegal instruction        /usr/bin/urbackupsrv run --config '/config/urbackup/config/urbackupsrv' --no-consoletime
2025-11-10 09:10:55,295 DEBG fd 9 closed, stopped monitoring <POutputDispatcher at 22375946821920 for <Subprocess at 22375946813856 with name urbackup in state STARTING> (stdout)>
2025-11-10 09:10:55,295 DEBG fd 11 closed, stopped monitoring <POutputDispatcher at 22375946478736 for <Subprocess at 22375946813856 with name urbackup in state STARTING> (stderr)>
2025-11-10 09:10:55,295 WARN exited: urbackup (exit status 132; not expected)
2025-11-10 09:10:55,296 DEBG received SIGCHLD indicating a child quit
2025-11-10 09:10:56,298 INFO spawned: 'urbackup' with pid 64
2025-11-10 09:10:56,317 DEBG 'urbackup' stderr output:
/home/nobody/start.sh: line 20:    70 Illegal instruction        /usr/bin/urbackupsrv run --config '/config/urbackup/config/urbackupsrv' --no-consoletime
2025-11-10 09:10:56,317 DEBG fd 9 closed, stopped monitoring <POutputDispatcher at 22375946478736 for <Subprocess at 22375946813856 with name urbackup in state STARTING> (stdout)>
2025-11-10 09:10:56,317 DEBG fd 11 closed, stopped monitoring <POutputDispatcher at 22375946317472 for <Subprocess at 22375946813856 with name urbackup in state STARTING> (stderr)>
2025-11-10 09:10:56,318 WARN exited: urbackup (exit status 132; not expected)
2025-11-10 09:10:56,318 DEBG received SIGCHLD indicating a child quit
2025-11-10 09:10:58,321 INFO spawned: 'urbackup' with pid 71
2025-11-10 09:10:58,340 DEBG 'urbackup' stderr output:
/home/nobody/start.sh: line 20:    77 Illegal instruction        /usr/bin/urbackupsrv run --config '/config/urbackup/config/urbackupsrv' --no-consoletime
2025-11-10 09:10:58,340 DEBG fd 9 closed, stopped monitoring <POutputDispatcher at 22375946317472 for <Subprocess at 22375946813856 with name urbackup in state STARTING> (stdout)>
2025-11-10 09:10:58,340 DEBG fd 11 closed, stopped monitoring <POutputDispatcher at 22375946738224 for <Subprocess at 22375946813856 with name urbackup in state STARTING> (stderr)>
2025-11-10 09:10:58,340 WARN exited: urbackup (exit status 132; not expected)
2025-11-10 09:10:58,340 DEBG received SIGCHLD indicating a child quit
2025-11-10 09:11:01,345 INFO spawned: 'urbackup' with pid 93
2025-11-10 09:11:01,363 DEBG 'urbackup' stderr output:
/home/nobody/start.sh: line 20:   101 Illegal instruction        /usr/bin/urbackupsrv run --config '/config/urbackup/config/urbackupsrv' --no-consoletime
2025-11-10 09:11:01,363 DEBG fd 9 closed, stopped monitoring <POutputDispatcher at 22375946944864 for <Subprocess at 22375946813856 with name urbackup in state STARTING> (stdout)>
2025-11-10 09:11:01,363 DEBG fd 11 closed, stopped monitoring <POutputDispatcher at 22375946947312 for <Subprocess at 22375946813856 with name urbackup in state STARTING> (stderr)>
2025-11-10 09:11:01,364 WARN exited: urbackup (exit status 132; not expected)
2025-11-10 09:11:01,364 DEBG received SIGCHLD indicating a child quit
2025-11-10 09:11:01,364 INFO gave up: urbackup entered FATAL state, too many start retries too quickly
2025-11-10 09:15:23,655 WARN received SIGTERM indicating exit request

I have stopped the container for now

1 hour ago, ijuarez said:

Had an update for the app and once it applied its failing to start.

I have stopped the container for now

I'm having the same issue

Sadly, me too...

Container "runs", but in the log you see that it had too many retry's ("gave up: urbackup entered FATAL state, too many start retries too quickly"), website is also not working.