One of my backup job saves to a portable device which doesn’t always have the same IP in my lan (It is complicated for me to write a proper explanation for this).
Say sometime it has ip 192.168.0.100 and sometimes 192.168.0.200.
So, I ask: is there any way to set up a job with destination 192.168.0.100 and in case this IP is not reachable to change it with 192.168.0.200?
At first I thought to write a run-script-before-required script altering the hosts file, but this task is intricate and it requires adminstrator privileges and so I stopped myself in the hope that a simpler solution is possible…
One way you could do this is with --run-script-before and have the script issue a new --remoteurl based on some test (ping, file present, etc). To change that you’d use the echo command like this:
echo --remoteurl=new-url
So you’d construct some sort of test and echo that only if the backup destination is in the alternate location. Otherwise don’t echo anything and Duplicati will use the remote url as defined in the backup job.
If the destination is using regular SMB, you might be able to use the --alternate-destination-marker and --alternate-target-paths instead. The options were designed for local paths but they might work for UNC/SMB.
Wouldn’t it just be a whole lot easier to assign a static IP to the device. Currently it’s configured for DHCP which is why it’s getting an IP between .100 and .200 (the range of you DHCP scope, likely defined in your router, not that this is a router issue).
When you assign a static IP it should be outside of the DHCP scope or strange conflicts can occur. In your case you should be using an IP between 192.168.0.2 - 192.168.0.99 or 192.168.0.201 - 192.168.0.254. 192.168.0.1 is excluded above as by default that will be the routers IP address.
Before setting a static IP verify that no other devices on the network are using that IP by pinging the candidate address and verifying that you DO NOT get a reply back, which 99% of the time confirms that address is not already in use.
If you have other questions ask away.
1 Like
My guess was that he is connecting a portable device to different host machines that have different IPs.
Not exactly, but you’re right thinking that I cannot solve the issue setting a static IP.
My situation resembles the one described at page --REMOTEURL ignored in --run-script-before script · Issue #3651 · duplicati/duplicati · GitHub
which I have discovered after your replies searching google for “remoteurl” (poorly documented imho).
Anyway, thank you for your hints. they address me in the right direction.
1 Like
Does this method work when the destination is of the type: ftp://x.x.x.x?
What does new-url parameter need to contain? The ip? The string ftp://x.x.x.x? Something else?
My attempts so far have failed.
Yes, it should work fine with FTP URLs. I believe you need to include the full URL which includes authentication information. You can see what the URL should look like if you export the job as command line.
Thank you for your reply.
I did as you said but without success. This is the content of my bat script. Is there something wrong?
@ping 192.168.0.93 -n 1 -w 100>nul || goto :pingerror
@goto :eof
:pingerror
@echo --remoteurl=ftp://192.168.1.93:2121/\duplicati\documenti?auth-username=xxx^&auth-password=xxx
@goto eof
:eof
@exit /b
I encountered a very very strange thing (for me).
I tried to run the backup job from the command line. It worked.
But when I tried to run it from the Duplicati gui (http://localhost:8200/ngax/index.html#/) it continues to give the error:
Failed: Impossibile effettuare la connessione al server remoto.
Unfortunately the ping test on Windows doesn’t produce consistent error result. It will return “success” with “destination host unreachable” for instance.
You might be able to use something besides ping. Or if you want to use ping you might be able to adjust the approach per this post: Feature-Request: Start backup only if some host is available - #6 by ts678
I think that the source of the issue lies elsewhere because even if I reduce the script to the following line:
@echo --remoteurl=ftp://192.168.1.93:2121/\duplicati\documenti?auth-username=xxx^&auth-password=xxx
the backup job continues to give the previous error.
When I run it from the command line, it run successfully.
Ok maybe…
Do you have any special characters in your username or password, like % ?
No. They contain only letters and numbers.
The only special character in the echo command line is ^ that I was forced to use before & otherwise it considers it as a space.
Ok, are you sure the ping test is doing as you expect? If the ping test didn’t work, then your destination is never really changed and your backup would fail because it still tries to go to 192.168.0.93.
It might help to add a debug line in your script. Something as simple as:
:pingerror
echo pingerror occurred > c:\path\test.log
@echo --remoteurl= ......
....
might help confirm that the test is working.
I’m confused. Can’t you just lock your portable device to use one ssid and / or be statically assigned by the router?
The same thing happens eg with backing up to Android and having the device use multiple ssid’s as each ssid may provide a different ip. The fix is to make it static and only have one ssid in use so its always the same no matter what.
It might be very interesting to make one backup task in Duplicati go to multiple ips. I’d probably use that. Wouldn’t go out of my way to do that though.
The current version of my batch script has only the echo line, no ping at all.
Oh, gotcha.
This is kind of a stab in the dark, but what happens if you only use forward slashes? I don’t think backslashes should be in the URL:
@echo --remoteurl=ftp://192.168.1.93:2121/duplicati/documenti?auth-username=xxx^&auth-password=xxx
I’ve found the cause of the issue. The batch script was never executed (when the backup job was launched from the Duplicati GUI; from the command line, all worked regularly, and this is a mystery yet).
I firstly set c:%HOMEPATH%\Documents\checkftp.bat for --run-script-before.
Then I tried c:\users\myname\Documents\checkftp.bat; and the issue has disappeared.
Evidently using an environment variable is not properly interpreted.
Anyway, thanks for your help and your patience.
1 Like
Glad you figured it out - thanks for the follow-up!