The command in my first email works fine when run on the Windows
machine, either directly or from within a batch file, locally in a
command prompt or in an ssh terminal from another machine. It only fails
when a shell script on another machine connects by ssh and run the batch
file from the ssh command.
The equivalent from your command would be putting your rdiff-backup
command in a batch file (with %%s in the remote-schema) and than from
the Linux server running:
ssh username@windowsmachine rdiff-backup.bat
If you just ssh to the machine and run the batch file it works. If you
put the batch file in the ssh command it fails.
On 11/1/21 1:11 PM, Dominic Raferd wrote:
On 01/11/2021 15: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.
It may not help much, but we run from Windows machines to a Linux
server using (a more complicated version of) the command below, which
works fine for rdiff-backup 2.0.5 and Windows 21H1:
rdiff-backup.exe --remote-schema "\path\to\plink.exe -batch -P 22 -ssh
-i \path\to\privatekey.ppk %s rdiff-backup --server" -v 5
"C:/Users/ThisUser" thisuser@192.168.50.135::archive
