If you had a server with multiple network interfaces, is there a way to bind specific backup jobs to specific interfaces?
backup job 1 binds to NIC1
backup job 2 binds to NIC1
backup job 3 binds to NIC2
A job doesn’t “bind” to an interface… do you mean you want to be able to choose which interface the backup traffic is sent out? Duplicati provides no mechanism for that directly - it’s left up to your operating system and its routing table.
Is the backup destination local (LAN) or remote (Internet)? Is it the same for all 3 jobs?
there are a couple of ways this could be done.
The backup source is local disk and the destination would be remote internet (google drive).
What would help is if there was some way to specify in duplicati the source port of the backup.
For instance, if backup job 1 used port 123 to connect to the destination, but backup job 2 used port 456.
With this, any competent network engineer with halfway decent networking equipment could do traffic shaping / policy routing based on source port.
The source port will be random and selected by the OS, so that won’t work. Duplicati could potentially be changed to allow the usage of a fixed source port, but that would inherently be incompatible with concurrent (multi-connection) uploads.
I personally use QoS tagging in Windows so that all traffic generated by Duplicati is properly tagged, and then I use shaping on my gateway to deprioritize the traffic.
On my NAS I just deprioritize all traffic destined for the internet on port 443. It’s not perfect as it matches other traffic, but in my situation almost all significant output 443 traffic from the NAS is backup traffic, so it works well.
I don’t get trying to have Duplicati traffic be sent out different NICs on a machine inside your network, if ultimately it is destined for the internet anyway. Only one NIC should have a default gateway defined, so the OS will want to send Internet-bound traffic out that NIC. Shape the traffic at your gateway instead. Sounds like you are familiar with shaping.
Am I missing something?
yes. QoS tagging and vlans are all well and good when you have 1 internet connection.
But when you have multiple internet connections and you want certain traffic to go out internet 1, and other traffic to go out internet 2… it gets a little tricky.
As it stands, my router has no way of distinguishing backup job 1 from backup job 2 both going out to google drive since the destination port is 443.
If there were a way to have duplicati send traffic out different source ports based on backup job that would be ideal because now each backup job is unique traffic that is different from another backup job.
And the source port is random and chosen by the OS because duplicati does not specify the source port that it opens to initiate traffic. If it did, it wouldn’t be random chosen by the OS.
Ok so you want different backup jobs on the same machine to ultimately be sent out different ISP connections on your gateway. Yeah I see the challenge and don’t think there is any way to accomplish it with Duplicati today.
Fixed source port per backup job might work but it would still be incompatible with concurrent transfers, unless the source port designation supported a range or something.
Seems like a very unique use case you have here.
The main problem with fixing a source port, given fixed source IP and destination IP and port, is you’re limited to a single end-to-end TCP connection, which seems like a non-starter, and HTTP doesn’t do it intentionally that I can see, either by its standard or by implementation – feel free to cite any examples.
At the Microsoft .NET level, HttpClient which Duplicati uses doesn’t even seem to allow such a setting.
Socket.Bind does, but Duplicati uses a higher-level API. Note also the Remarks that show it’s optional:
You do not need to call Bind before using the Connect method unless you need to use a specific local endpoint.
Know your TCP system call sequences which comes from a Linux point of view says the same thing:
For a client process, it is not mandatory to issue a bind call.
All the above is a bit redundant because everyone here seems to know connect will bind, if need be.
I can’t find a Firefox source port in about:config. Exotic Linux tools such as curl and wget lack this.
Granted, nc has it, but it’s about as low-level a tool as exists on Linux as a command. Its purpose is:
The nc (or netcat) utility is used for just about anything under the sun involving TCP, UDP,
or UNIX-domain sockets. It can open TCP connections, send UDP packets, listen on arbitrary
TCP and UDP ports, do port scanning, and deal with both IPv4 and IPv6.
What can it distinguish? Does it know about anything QoS flavored, or is it only source/dest IP/port?
If it can distinguish source IP, I see claims that Windows can have multiple IPs on one adapter, then
How to Force an Application to Use a Specific Network Card
3 ForceBindIP GUI to Easily Bind Windows Application to Specific Network Adapter
might get you the rest of the way. Even though they say adapter, its interface appears to be address.
You could possibly get it to run per-job if you’re willing to be Using Duplicati from the Command Line.
I haven’t tried this, and can’t vouch for it, but there seem to be a limited number of things available to signal downstream networking equipment how you’d like things handled. IP TOS field and successor Differentiated Services DSCP come to mind (I’m not a QoS expert), but seem to have been ruled out.
So going back to the original question of can you “bind specific backup jobs to specific interfaces” the answer appears to be yes if jobs are processes starting each time, as opposed to a long-lived server.
Duplicati can run multiple long-lived servers if you prefer, each on its own port (8200, 8300, etc), so a job would just need to be put on the correct server for the desired interface, if jobs in GUI are wanted.
Duplicati.GUI.TrayIcon.exe will do the search for you. For Duplicati.Server.exe use --webservice-port. You might also need --server-datafolder so that multiple servers put their databases in different spots.
If you decide to try assigning jobs to interfaces, be careful about the Duplicati autoupdate design that starts a somewhat fixed initial install in Program Files, which launches the newest installed update…
Firewalls that look at application paths get confused. Confusion is avoided by using updates by .msi.
If duplicati runs on port 8200 by default, is that the standard source port used for sending backup data? Or is that just the port the web service runs on?
I guess I’m trying to understand, when duplicate initiates a backup job, what is the source port it uses to go connect to the internet (google drive) to begin the backup process?
I ask, because if duplicati uses a predictable source port I can at least do a throttle at the router for duplicati traffic and mark it as low priority from the rest of the upload traffic coming from the server.
Doesn’t quite get me the goal of using multiple interfaces … but I think if I can mark it as low priority that will be sufficient.
This, which is why a service that accepts incoming connections is often at a known port it hopes it can actually bind – that’s another problem that’s avoided by having the client just get an “ephemeral port”.
The use (or non-need, due to search some programs do) of --webservice-port was covered earlier.
--webservice-port
The port the webserver listens on. Multiple values may be supplied with a comma in between.
Client source port couldn’t be fixed at 8200 for the same reasons mentioned why it can’t be fixed at any value and still hope to support multiple connections using the same source IP to destination IP and port. The HTTP protocol and IP routing return server data to the proper client based on the client source port.
I thought everyone was in agreement that it’s up to the OS. Here’s Sysinternals Process Explorer data:
1e100 turns out to be a googol, and is Google, as is 142.250.31.153. It’s hard to tell what’s what, but there seems to be a sequentially allocated (as opposed to truly random) ephemeral source port used. You can see a similar effect with the Chrome browser client connections to the fixed server port 8200.
It doesn’t. As explained earlier, HttpClient doesn’t allow it, and I doubt Microsoft will ever do it because allowing this just invites trouble when things break when multiple connections to a destination are tried.
One possible approach was explained. Maybe it’s not wanted (risk?) or doesn’t work. I haven’t tested it.
This gets back to what @drwtsn32 was talking about, and I’m interested in how this was done, but not quite clear on why it doesn’t fit your situation. I possibly need to look over the whole network plan again.
I don’t do any such things but there’s documentation around on some ways of getting Windows to do it:
Quality of Service (QoS) Policy
QoS traffic management occurs below the application layer, which means that your existing applications do not need to be modified to benefit from the advantages that are provided by QoS policies.
In the second page of the QoS Policy wizard you can apply the policy to all applications, to a specific application as identified by its executable name, to a path and application name
If using a full path, the issues mentioned earlier about the unusual Duplicati autoupdater might apply.
It kind of looks like this is a way to QoS-tag (with DSCP) all the Duplicati upload traffic. This might get you what you want, if your networking equipment can handle it. But will it interfere with web UI traffic? Possibly some special handling of packets involving the known server port would have to be installed.
Yep, that is exactly how I’ve done it on Windows - Policy based QoS. I do not use a full path in the exe name, so it should be compatible with the Auto updater mechanism, but I’m not sure as I don’t use the auto updater.
I believe this is insufficient for the OP because he wants one backup job to go out one interface on the gateway, and a second backup job (on the same Duplicati machine) to go out a different interface. There’s no way to use Windows QoS Policy tagging to differentiate between backup jobs on the same Duplicati instance.
The multiple-Duplicati workarounds mentioned previously exist, but are kind of ugly because multiple Duplicati executable areas are a bit of a pain, and servers collide when run in the same web browser.
My current Duplicati are installed from .zip files into separate areas, and I have two running right now.
can you provide some steps, or a link to a guide you followed on setting up your policy based QoS on a windows machine.
If I can at least QoS tag the traffic and have it set to low priority then I will consider that a win. Even though it won’t go out multiple internet connections it will be good enough.
On a side note, I’d like to thank everyone who has replied and offered suggestions. I am impressed with the level technical level of the replies so far and appreciate everyone’s advice.
Here’s what I did… click Start then type “Edit Group Policy” and click the best match.
Navigate to Computer Configuration / Windows Settings / Policy-based QoS.
Right click on Policy-based QoS and click “Advanced QoS settings”. Click on the DSCP Marking Override tab and set these options:
Right click on Policy-based QoS again and this type click “Create new policy”.
Set a name for the policy and specify DSCP Value. I use “2” which corresponds to ToS 0x8 (this guide can help with translations). On my gateway (Debian Linux) I have set up rules using tc to deprioritize packets marked with ToS 0x8.
Click Next and click the “Only applications with this executable name” option and enter the exe name (no path) for Duplicati. I enter Duplicati.GUI.TrayIcon.exe because I use the regular Duplicati process on my main machine. If you use the Service version, you may need to use a different exe name.
Click Next and you can probably leave the source and destination at the default (any IP).
Click Next and you can probably leave the protocol and source/dest port options at default.
Click Finish and you’re done.
In my experience I also had to change this registry setting to get these policies to work. From what I recall they only normally work on domain networks, so setting this policy makes them also work on a non-domain (ie, public or private) network:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\QoS]
"Do not use NLA"="1"
Note you have to reboot after making that change in the Registry for it to go into effect. Also this setting seems to get wiped out during the major semi-annual Windows 10 upgrades.