Thanks! I ended up asking OpenAI and got the same answer (I was unaware that urbackup was heavily dependent on hardlinks) Here’s it’s answer:
VERIFY HARDLINK CAPABILITY:
test commands:
touch /mnt/merged/testfile
ln /mnt/merged/testfile /mnt/merged/testlink
ls -li /mnt/merged/testfile /mnt/merged/testlink
(If this fails you can’t use it. ed.)
UrBackup doesn’t care how the mount point is presented — it just needs:
A filesystem it understands (ext4, btrfs, zfs, etc.).
Correct free space reporting.
Working hardlink support for deduplication.
The reason you hit trouble with MergerFS + Btrfs is that MergerFS is a FUSE layer, and UrBackup’s space/hardlink checks sometimes misbehave with FUSE mounts — even if the underlying FS is fine.
( OpenAI then proceeded to recommend instead of merging the disks I setup a mirrored RAID. Of course, doing this means halving the storage capability plus the fact that the redundancy is supplied by the fact the disks are -physically_removed_ periodically, that’s why they are in docks! Sigh. AI’s - highly useful with zero common sense - can’t live with 'em and you can’t live without 'em. ed.)
With RAID, there’s no FUSE layer — the kernel presents it as a “real” block device — so UrBackup sees it as a normal disk.
( Yah, I knew that already. Of course, I could also -stripe- the disks together but then if one disk in the backup pool dies - everything on all disks is trash. With FUSE, you still can get some data out of working disks. ed.)
Keep MergerFS → You get flexibility, but UrBackup may only reliably work with ext4 pools.
Go RAID → You lose flexibility, but UrBackup will treat it like a single native disk and Btrfs will work fine.
Go single large disk → Simplest, but single point of failure unless you manually duplicate.
If you want maximum reliability with UrBackup → RAID1 with Btrfs is the safest bet.
If you want maximum flexibility → stick with MergerFS but use ext4 for now until UrBackup’s FUSE handling improves.
If you want maximum simplicity → single large disk, but keep an offline copy.
So that was OpenAIs response. It was a very good, very useful, response. NONE of which was in the manual, the forums, or anywhere on the website. I guess I have to ask - is there an attempt to make the docs hard for a newbie? My guess is the OpenAI response was gathered from dozens of reddit posts scattered over the last decade.
The single large disk is another solution - I could buy a new USB 3.2 dock that supports a monster $900 20TB disk and bypass FUSE - of course then when the disk crashes I lose 20TB of data not just 8TB. Maybe some day in the future when hard drive prices drop for large disks.
I was sort of surprised the OpenAI answers were as generally sane as they were. The OpenAI Foundation must have scraped out a lot of good material when training the current LLM.
I do think the manual needs some reworking. A lot has changed since 2022 when it was written. The one thing that really needs to be emphasized I think in the manual is putting some thought into preparation of the target media. urbackup has zero knowledge of things like disk pools and such whereas commercial backup software often has extensive knowledge of such things. So switching from a commercial package (Backup Exec in this case) is a shock. But so far - it’s working well even with EXT4. In fact, our largest fileserver has around 3TB of data and about a million and a half files on it - and I imaged that to a vhdx file in about 5 hours. It was - and I kid you not - taking ALMOST TWO DAYS for B.E. to do the same backup - going to the same USB disk pool - on the same server
And the other super scary frightening thing about BE is for fun I stuck one of the BE written 8TB disks in a dock in a brand new Win 2022 server - and it couldn’t even see it as a disk. At all. Event Log showed a disk had been inserted but nada, nothing, in disk manager.
As it turned out what I THINK was going on is BE was addressing every large disk above 2TB in our pool as some crazy 512e LBA assist or some baloney, because the GPT partition table that BE was writing to these disks was misaligned. So Windows server was taking one look at this 8TB disk with native 4k blocks and a GPT table in some crazy-ass spot on the disk and going “that ain’t no disk” Which means every single large BE disk we have is garbage - it’s unreadable if I try taking it to any other server. So if my backup server hardware were to die - which is kind of the point of disaster recovery - I’d have been completely hosed if I bought a new one.
I have to say - learning about THAT little trap door is worth all of the time I’ve spent messing with urbackup and learning about it this weekend.
Anyway, what I have found through all of this is the following:
-
The filesystem backups in urbackup are probably useful for some people but for me they are pointless for windows servers. I just disabled them and am doing image backups only. If I need a file I can mount the vhd or vhdx file on some convenient server and get it.
-
On the other hand - image backups for Linux filesystems are nonexistent - so - it’s excellent that UrBackup supports filesystem backups. Yes - if I rebuilt all my Linux bare metal servers as Btrfs servers - I could do Copy on Write snapshotting. But - everything I’ve run across says the urbackup Linux client cannot deal with COW much less the UrBackup server.
What I have been doing for my critical Linux servers is crude but effective - virtualize them. if they are on HyperV then I can snapshot them if they are on KVM then the -cleanest- way to do it is shut them down late at night during a maintenance cycle and make a copy of the VM file.
-
the urbackup Windows client uses vss like it’s supposed to and that there is the most valuable bit of all of this. Half of my servers are hyperv VMs and the rule I instituted in the department is if it can be put into a VM then put it into a VM. Because the UrBackup client is properly written, I can do an image backup of my hyperv hypervisor servers and get a nice 2-3TB vhdx file and be done with it. And that vhdx file contains all the other smaller VMs of the other servers. All I really need to do is script a weekly snapshot of those which is trivial and a UrBackup of them will contain consistent VM files inside of it. Absolutely sweet.
-
Speed is critical (which is another reason I’m not bothering with file backups) and I’m getting around 550 Mb/sec on image backups but about 10% of that speed on file backups. The OpenAI seems to think this is normal due to the overhead of all the filesystem calls. I’m not complaining!
-
Attempting to mount an image from the web GUI just causes UrBackup to hang to the point I have to reboot the backup server. But mounting it from the command line using urbackup - zero problems. Not sure what’s going on with that one.
My network is quite a mix - I have Windows Server hypervisor servers running a mix of Linux and Windows Server VMs, and I have Linux KVM+QEMU hypervisors running a mix of Linux and Windows Server VMs. I think one of my people even has a Docker image somewhere. So having a solid Linux backup server is really important - and we haven’t had one. The commercial backup people all seem to have drunk the kool aid that the Linux world is Red Hat only. NONE of our Linux stuff is Red Hat, it’s all Debian based, either Debian server or Canonical’s hacked up version of Debian.
So I was looking forward to setting up the Linux client. But I’m not that thrilled, honestly.
The first impression on the Linux client is probably a couple hundred warnings about auto_prt being deprecated. Really? Are we serious? That’s like a 10 year old error. They were arguing about this SIXTEEN years ago:
c++ - Is auto_ptr deprecated? - Stack Overflow
For the record the current advice is:
// Old (deprecated)
auto_ptr p(new MyClass());
// New (recommended)
unique_ptr p = std::make_unique();
cpp:
auto_ptr p1 = p2;
replace with
unique_ptr p1 = std::move(p2);
Am I going to do it? No, it’s not my code, I don’t understand it. But with Ubuntu as a recommended target in the manual and on the website for the client - I’d be very worried.
Canonical is known for being pricks and removing stuff “just because” in new Ubuntu versions. People are screaming bloody murder for them pulling support of Vnc client in the latest Ubuntu 26 Desktop. They are blaming it on Wayland but I don’t buy that since they have a building full of developers and one of them could have taken an afternoon and written a bridge layer to keep the anti-Microsoft religious types happy who are now hating they have to use RDP Client. I can EASILY see them mucking about with the compiler.
Next, the build instructions on
UrBackup - Install client on Debian or Ubuntu from sources are antiques and very broken. O-M-G. That was at least 8 hours of time sorting this out. Here’s what I had to do to build it on Jammy:
apt install -y libssl-dev libsqlite3-dev
apt install --no-install-recommends build-essential
apt install zliblg-dev
apt install libz-dev
apt install libcrypto+±dev (this is unnecessary unless you want to experiment)
apt install libdevmapper-dev
apt install libzstd-dev
wget https://hndl.urbackup.org/Client/2.5.31/urbackup-client-2.5.31.tar.gz
tar xzf urbackup-client-2.5.31.tar.gz
cd urbackup-client-2.5.31.0
./configure --enable-headless --enable-embedded-cryptopp
make
make install
Note the configure option to force use of the internal crypto code. The crypto library under Ubuntu Jammy - and probably later Ubuntu versions - is NOT compatible. It has many more types of encryption in it - and UrBackup server is compiled with it’s own crypto library. I first attempted to build the client with the external library per directions - this FAILED. What I discovered is you MUST use the internal library or the client WILL NOT connect to the server.
Note the headless option there. Nobody builds Ubuntu servers with a CPU-sucking GUI on them at least nobody who should be given responsibility for doing this. And who puts files on a desktop anymore? Networks & NASes, people. You can literally build a NAS out of that 10 year old PC you are e-wasting so DO IT and then you can trash your desktop and you won’t lose your files.
I get that URBackup originated “back in the day” when networks were Thinnet and people actually did store actual data locally on their MFM and RLL drives with “stiction” issues that you had to bounce the PC on the desk to fire up - but honestly WHO DOES THIS anymore? Why do you think every corporate PC out there has a weenie little 256GB SSD in it? It’s because the days of 200 desktop PC’s streaming backup files to a UrBackup server have been slid into the history books. Now we have desktops saving to servers and servers streaming GIANT volumes to UrBackup and the documentation needs to reflect this.
Anyway, getting back to the Linux client.
Now, the #1 first basic test on this blew up with a core dump:
urbackupclientbackend
terminate called after throwing an instance of ‘std::logic_error’
what(): basic_string::_M_construct null not valid
Aborted (core dumped)
You never do this in code. If options are required then test for a null passed on the command line and gracefully exit with an error message that tells the user what to do.
moving on:
urbackupclientbackend -v info
2026-10-11 21:48:28: SQLite: recovered 24 frames from WAL file /usr/local/var/urbackup/backup_client.db-wal code: 283
2026-10-11 21:48:28: FileSrv: Servername: -redcap-
2026-10-11 21:48:28: urbackupserver: Server started up successfully!
2026-10-11 21:48:28: sambaredir: Server started up successfully!
2026-10-11 21:48:28: Started UrBackupClient Backend…
so far so good.
Now the next problem is, /etc/rc.local disappeared after Ubuntu 15 when they switched to systemd So please stop talking about it on the website.
Here, ripped off from Start client backend through systemd · Issue #7 · funilrys/aur-urbackup2-client
and modified is:
cat /etc/systemd/system/urbackupclientbackend.service
[Unit]
Description=UrBackup Client Backend
After=syslog.target network.target
[Service]
ExecStart=/usr/local/sbin/urbackupclientbackend --no-consoletime
User=root
#Optional: set working directory if needed
#WorkingDirectory=/usr/local/var/urbackup
[Install]
WantedBy=multi-user.target
Note that the config line used in the other example is removed - because the most current Linux UrBackup client ignores everything in the traditional default file. Instead it’s new config file is /usr/local/var/urbackup/data/settings.cfg and there is no use putting anything in here since this file is completely blown away and overwritten by configs pulled from the server.
The manual needs to mention this. The manual needs to say “once upon a time the Linux client used /etc/default/urbackupclient as a default config file and actually paid attention to stuff in it but that ship has sailed” This is because there’s dozens of antique website posts out there that talk about urbackup but the posters haven’t picked up the clue phone.
Now, with the correct file,
systemctl daemon-reload (run once)
systemctl enable urbackupclientbackend (run once)
then the commands:
systemctl start urbackupclientbackend
systemctl stop urbackupclientbackend
work normally as God - or Canonical in this case - intended. LOL
start the server
systemctl start urbackupclientbackend
wait a while and do a
urbackupclientctl status
Then load in the directories to backup - either from the client or the server
urbackupclientctl add-backupdir -d /home -n home
etc
etc.
and it’s off to the races.
That install web page REALLY needs to be updated.