Mac client not correctly doing incremental backup


Hi! I’m a new user and have spent the past few weeks wrestling with Urbackup to see if it would be a good backup solution for my and my girlfriend’s private computers. I have a few issues and questions I’ve run into that I will be asking when/if they are relevant but right now I’m seeing some major problems with the OS X client on my girlfriend’s laptop.

  1. If a full backup is interrupted (for example by the computer idle sleeping or getting the lid closed) then the client will claim to “resume full backup” but it actually starts over and copies everything from scratch again - on a laptop this means that a full backup (600gb+ in this case) will only ever really complete if it’s left online and connected intentionally over a long period of time. It will “resume” a backup by deleting everything and starting over from scratch which seems a bit… misguided. Currently the backup server is on LAN but I intend to move it to a remote location soon so connectivity will be slower and this will be even more of a problem.

  2. When I did this however and I finally managed to get a full backup done, it seems that the incremental backup (which works fine on my windows PC) doesn’t work properly:

As you can see it’s uploading the majority of files again despite the fact that none of them have changed (this was the laptop left on overnight). This also takes up extra space on the backup server despite the fact that the documentation says the same unchanged file will only ever be stored once even in consecutive full backups?

(New users can only put two links in a post so I have to mangle them somewhat…)

Here’s a server log excerpt from the currently active “incremental” backup:

Anything else I can provide to help figure this out?

The software seems to be a bit rough around the edges, UI- and documentation-wise, but the speed is amazing (much faster than any other software I tried) so if it works and can be trusted then I will be a very happy user of this for a long time I think!



Resume wasn’t always supported, maybe it s not supported by the client/sever on your OS.

As i understand things :
The backup progress/speed is the backup speed, and not the transfer speed, i can backup at 1MB/sec over my 100kb link. The speed displayed account for the fact that the whole files aren’t always transferred.

There’s something odd with your storage backend, file in queue are (also to my understanding) files transferred, not yet written to disk or still considered as temps files. (large queue is low write speed)

For some reason your urbackup server can’t hard link files, that’s why you consume more space than you should, maybe your filesystem, os or server version doesn’t support this operation.

Agreeing that the software is a bit rough around the edges, but it has a single dev and is evolving and being fixed fast.

Which versions of urbackup are you using client and server ?
What’s the OS+ version for client and server, what’s the filesystem on which it’s stored?
If you can, try to setup the server on linux with storage filesystem as btrfs or zfs.


As you can see in the log file your server file system does not support hard links. That’s the reason.


I see! I thought from the “debug” and not error/warning level it was more of a notification and not something that serious - but yes I understand.

The problem turns out to be that Stablebit Drivepool that I use for pooling drives does not support hard-links so that’s of course beyond your control, now I have to find a drive pooling solution that works better. I moved it to Drivepool because Storage Spaces virtual disk on windows was aggravating me but perhaps I should go back to that then and try again.

Thanks for quick and very helpful answers, and good job and thanks for this software! <3


I’m facing the same obstacle in using drivepool for redundancy and urbackup for backup. Backup sizes grow huge very very quickly w/o hardlinking! Curious what you ended up doing.

I have been mulling over having a separate drive solely for urbackup that mirrors to another drive for redundancy, or even store urbackup data at the root level of a pooled drive (not in the pool itself), but I’m not very excited about either of those ideas.


Unfortunately I ended up not using urbackup anymore, not really related to this issue but it never really worked very well and support is too spotty to be a software you can trust. This is one field where it pays to pay for your stuff unfortunately.


@Johan3910 - Thanks for following up.

Still in the testing phase here, but I can see myself coming to a similar conclusion in the not too distant future. There’s just a lot to like with Urbackup so I’m gonna continue to test and tinker a bit more.

This is probably the 5th or 6th roadblock I’ve hit in getting what I’ve seen on paper to actually work in my environment. I have successfully gotten around the other issues, but this one is substantial. I decided I’m not going to buy any additional hardware just to support Urbackup so we’ll see how far I get.

Thanks again.