Open Taomyn opened 5 years ago
Ah, okay I see the issue.
It seems like this would only affect the system user, so it may be best to hardcode the translation
C:\\Windows\\system32\\config\\systemprofile\\AppData\\Local\\DuplicatiClient -> C:\\ProgramData\\DuplicatiClient
Using "ProgramData" for the local system account I'm hoping is what they are considering for Duplicati itself, and I've actually replaced the Local\Duplicati folder with a symbolic link to C:\ProgramData\Duplicati so as not to lose the data on major Windows updates. It works but when I tried it for DUC it still didn't work.
I still don't understand what's going on, my script has this at the end of it:
"C:\Program Files\Duplicati 2\duplicati_client.exe" login https://_________:8200 --insecure>>c:\duplicati_after.log
"C:\Program Files\Duplicati 2\duplicati_client.exe" run 3>>c:\duplicati_after.log
"C:\Program Files\Duplicati 2\duplicati_client.exe" logout>>c:\duplicati_after.log
Yet in task manager I see this with both processes just sitting there:
I have to kill them manually.
Is anything appearing in the duplicati_after.log?
Each command should only take a second or so, and if it's a timeout it should die after 30 seconds (so 90 seconds total)
To capture errors in your log files, you will probably need to change:
... >> c:\duplicati_after.log
to:
... >> c:\duplicati_after.log 2>&1
(assuming duplicati_client sends errors to STDERR.) A regular >
or >>
will not capture STDERR.
Anything triggering an exception will end up in stderr.
I try my best to capture and handle exceptions with reasonable explanations which end up in stdout and are only indicated as errors through the return code, though.
Run-script-after not work theorizes a deadlock where duc in --run-script-after is unable to complete its backup, because the original backup isn't complete until its --run-script-after is complete, so deadlock. Solution is to let --run-script-after finish by having duc backup run independently off a start command. Maybe there is a better way, but my bat scripting isn't wonderful, and my PowerShell scripting is worse.
I do not experience any deadlock at all. I have been using duc on 3 machines to trigger another backup job after a first backup job completes - no problems and I've been using this approach for over 6 months now.
Still not sure why duplicati running as a service is affecting how duc operates....
It's a plausible explanation that the --run-script-after blocks the backup until duc finishes running, so it can get it's return code.
I'm guessing the script wrapper works because it makes Windows fork a new process, so --run-script-after immediately stops because the script doesn't have to do anything and duc is still launching.
I managed to get it working with the following batch script:
@echo off
setlocal
if /i "%DUPLICATI__OPERATIONNAME%" neq "Backup" goto end
if /i "%DUPLICATI__PARSED_RESULT%" neq "Success" goto end
if "%~1" neq "restart" (
start "" cmd /c "%~dpnx0" restart
exit /b
)
set "d=%~dp0duplicati-client\duplicati_client.exe"
"%d%" login
"%d%" run 3
"%d%" logout
:end
This portion of code:
if "%~1" neq "restart" (
start "" cmd /c "%~dpnx0" restart
exit /b
)
basically restarts the script in a new process to run duplicati_client
, and then let the old one exits. You can also write 2 separate scripts (one that uses start
to call the actual batch script that run duplicati_client
) to achieve the same thing.
I'm trying to get duc to perform a specific backup at the end of my main backups (Windows) - basically it's a job to separately back up the Duplicati databases whenever a backup completes.
Currently I have simply exported the backup job and added it to the batch script that gets run at the end of the main jobs. This works well but has 2 draw backs, it's insecure as the credentials are all there and it doesn't update the job last run info in the GUI. Hence trying to use duc.
When it runs the batch script the process gets stuck, in fact there seems to be two processes spawned with the same command line parameters. Duplicati runs as a service using the local system account and if I use a tool like "psexec" to spawn a local systsem account cmd prompt, I can run my commands so I know the syntax is good.
I'm not sure if this is related but I did notice that like Duplicati, duc stores the config in the profile folder but for the local system account this is in a bad location under "system32" - it's better practice to use the "ProgramData" folder. I did however see that even with my test the folder in system32 never got created and I have no idea why.