Hi,
that's really a tricky one without any error message, so poking in the dark:
1. do you.see rdiff-backup in the list of processes?
2. if the rdiffbackup.bat content is simpler, what happens?
a. just `rdiff-backup.exe -v`
b. C:\rdiff-backup-2.1.0a1-64\rdiff-backup.exe -v 9 --remote-schema
>>> "C:\Windows\System32\OpenSSH\ssh.exe %%s rdiff-backup --server"
>>> r...@datasrv2.intra.hoec::%BACKUPTO%
c. C:\rdiff-backup-2.1.0a1-64\rdiff-backup.exe -v 9
r...@datasrv2.intra.hoec::%BACKUPTO%
3. On Linux, I would call strace on the rdiff-backup process, and guess where
it's stuck. Anything similar under Windows?
KR, Eric
On 5 November 2021 15:10:57 UTC, Michael Crider - HOEC <mcri...@hoecoop.org>
wrote:
>I sent this privately to Eric by mistake, now replying on list.
>
>Hi Eric,
>
>Answers inline below.
>
>On 11/1/21 1:22 PM, Eric L. Zolf wrote:
>> 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.
>Running the command with -v 9 didn't change anything. The program still
>crashes after making an ssh connection to the backup server with no
>visual output, but doesn't return to the command prompt.
>> What happens if you call `ssh ${BACKUP_USER}@${TARGETHOST}
>> rdiff-backup.bat ${BACKUPTO}` like the cron job?
>Same effect.
>> Or even something like
>> `ssh ${BACKUP_USER}@${TARGETHOST} C:\Windows\System32\OpenSSH\ssh.exe
>> r...@datasrv2.intra.hoec rdiff-backup --server`
>This runs successfully, starting "rdiff-backup --server" on the backup
>server and closing when I kill the process on the 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.
>Unfortunately we have already upgraded all our Windows computers to
>21H1, so I don't have configuration files from 1909 to compare. For now
>I have worked around the problem by writing an expect script, run from
>the cron job on the backup server, that spawns an ssh connection and
>executes the batch file. This completes and exits successfully.
>> 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.
>
