Hi Michael,
it's difficult to tell without a more concrete error message. Running
the command in debug mode (-v 9) might help to understand where the
script hangs.
What happens if you call `ssh ${BACKUP_USER}@${TARGETHOST}
rdiff-backup.bat ${BACKUPTO}` like the cron job? Or even something like
`ssh ${BACKUP_USER}@${TARGETHOST} C:\Windows\System32\OpenSSH\ssh.exe
r...@datasrv2.intra.hoec rdiff-backup --server`
But as you said that the issue appeared after an update of Windows, I
can currently only imagine that something changed with SSH. I would look
if perhaps something changed in the SSHD _and_ SSH configuration files
between 1909 and 21H1, something which makes a difference between
connecting interactively or not.
What you could also try is to call the
KR, Eric
On 01/11/2021 16:21, Michael Crider - HOEC wrote:
> We have used rdiff-backup for well over 10 years for our Linux servers
> and workstations, and until recently to back up Windows servers and
> workstations we mounted their drives locally on the backup server and
> ran rdiff-backup against the mount. When our first Windows 10
> workstations arrived with v1909, we started having trouble reliably
> mounting the drives, so we recently put the Windows executable of 2.0.5
> on our Windows workstations and tried the same method we use for Linux -
> a cron job on the backup server would ssh to the Windows workstation
> (running the built-in OpenSSH server) and call a batch file that would
> run rdiff-backup, sending the backup back to the server. Keys were in
> place to allow passwordless connections. This way we could schedule
> several workstations to run in sequence without having multiples overlap
> in time (as might happen if we did the scheduling at the workstation).
> That was very stable on workstations running Windows 10 1909 and below.
> Then we upgraded all of our workstations to 21H1. Now we can manually
> ssh to the Windows workstation and run the batch file and it runs just
> fine. But if we run the cron job script that does the ssh and runs the
> batch file, everything works (setting environment variables and updating
> specific local files from network masters using scp) until the
> rdiff-backup command. We don't have "echo off" on the batch file so we
> can see the command issued. It makes the connection to the backup server
> and starts rdiff-backup on it, but then it hangs and doesn't progress
> any further, and no files are updated in the backup destination. We
> started with rdiff-backup 2.05 using SysNative in the remote-schema,
> then moved to 2.1.0a1-64 to see if that helped (changing the
> remote-schema to System32 but leaving everything else the same). but
> nothing changed except for an added warning about the server not
> understanding the API. If we are running the cron script in a terminal
> we can press Ctrl-C and exit. If it runs from a cron schedule we have to
> kill rdiff-backup on either the workstation or the server. Has anyone
> else seen something similar?
>
> The command in the cron job is: ssh ${BACKUP_USER}@${TARGETHOST}
> rdiff-backup.bat ${BACKUPTO}; RDIFF_RESULT=$?
>
> The command in the batch file is:
> C:\rdiff-backup-2.1.0a1-64\rdiff-backup.exe -v 6
> --exclude-symbolic-links --remote-schema
> "C:\Windows\System32\OpenSSH\ssh.exe %%s rdiff-backup --server"
> --include "C:/FuturaData" --include "C:/Program Files (x86)/Futura
> Systems/FuturaGIS/Staking Client" --exclude
> "C:/Users/%BACKUP_USER%/AppData/Local/Temp" --exclude
> "C:/Users/%BACKUP_USER%/AppData/Local/ESRI/Local Caches" --include
> "C:/Users/%BACKUP_USER%" --exclude "C:/**" C:/
> r...@datasrv2.intra.hoec::%BACKUPTO%
>
> Both use environment variables set on the command line of the script or
> earlier in the script.
