feroxy

I'm afraid it makes no difference. I tested with one job running and get the same result. In fact I have noted that each backup job tends to max out at approximately the same transfer rate (ie if I start one job and let it settle at whatever low speed, and then start a second, the first job doesn't suddenly half it's throughput, rather the second tends to match the first), which doesn't come close to causing the drives to thrash. In fact drive activity is barely registering during these backup jobs (sort of pulsing activity rather than any sort of continuous read/writes). I hate to keep referring back to a different piece of software, but the Kopia backup jobs I set up were able to complete their runs inside of an hour, maxing out the transfer link even while running at the same time as the urbackup jobs... And those are file level backups which as Binhex mentioned should tend to be slower based on windows file system reads.

Interesting. I might be misremembering, but I had thought it was faster in the past. At the moment, the numbers i quote are for image backups, so in theory are those not more along the lines of large chunks of data being transferred? Also given that Kopia is able to max out the network link doing a file level backup, does seem to indicate that maybe urbackup has some bottlenecks somewhere... Kopia doesn't do image backups though so its not a drop in replacement.

I'm experiencing extremely slow network transfers when using urbackup, maxing out at about 25-30Mbps (often less) over a gigabit lan connection. I've posted about this on the urbackup community too - no answers as yet but it's really limiting the usefulness of this as a backup solution. I don't think it is an issue with my network, as in an attempt to narrow it down, I've tested a couple of other backup dockers (Kopia for one) and those max out the network just fine while writing to the same disk/share,. Plus things used to work fine so not sure what has changed... Curious if anyone else is finding this to be the case?

Hi all It has come to my attention that my parity drive will not spin down, while the other array drives do this no problem. I have read previous support queries that resolved to an errant cache folder existing on one of the array drives, but in my case, the array data drives all all spun down with no problems (and no shares where they shouldn't be) so I'm at a loss to explain what is keeping the parity drive active (If I understand it correctly it has little reason to stay active if the data drives are inactive?) any help appreciated.

Thank you, I have removed that plugin now. I will keep an eye on it and see if it resolves the issue.