Rsync в Windows XP отлично работает по требованию, но зависает при запуске в качестве запланированной задачи

Question

Я хочу использовать Rsync для резервного копирования веб-сайта в систему Windows XP, которая каждую ночь копируется на ленту. Я посмотрел на cwRsync и Grsync, и они оба работают нормально, пока я запускаю их, когда вход в Windows. Я могу настроить запланированное задание в Windows и запускать задание по требованию, и даже это прекрасно работает.

Но когда я пытаюсь запустить запланированное задание, когда я вышел из системы, он зависает. При следующем входе в систему задание отображается как работающее, и я вижу запущенные процессы RSYNC.EXE и SSH.EXE. Я должен остановить задачу, а затем убить два процесса. Между тем файлы не были переданы. Это делает это каждый раз.

Я добавил столько журналов, сколько смог, но журнал останавливается командой Rsync:

opening connection using: ssh -l user domain.com rsync --server --sender -vvnlogDtpre.iLs . /home/user/backups/site-backup.tar 

Чтобы исключить проблемы с планировщиком задач, я создал простое пакетное задание, запланировал его и вышел из системы. Когда я вернулся через некоторое время, задание было выполнено, как и предполагалось, и результат был таким, как ожидалось.

Хост-система - это сервер общего хостинга Linux. У меня настроено задание CRON, которое сначала создает дамп всех баз данных, используя mysqldump, а затем создает файл TAR с этим, а также все папки, которые мне нужно сохранить с хоста. Эта часть работает как шарм.

И, как я уже сказал, запуск Rsync в Windows для захвата файла TAR также работает нормально, и мне особенно нравится то, как он использует дельта-копирование для перемещения только тех битов, которые отличаются. Это экономит тонну трафика, что является одной из основных причин, по которой я хотел использовать Rsync.

Answer 1

У меня была эта проблема, и обновление моего Cygwin не сработало.

Я наконец изолировал проблему со скриптом, который запустил rsync; скрипт имел следующие строки:

REM Set HOME variable to your windows home directory. That makes sure 
REM that ssh command creates known_hosts in a directory you have access.
SET HOME=%HOMEDRIVE%%HOMEPATH%

Похоже, что в Windows Scheduler HOMEDRIVE и HOMEPATH не инициализируются, поэтому HOME не был установлен и ssh.exe завис при попытке принять удаленный ключ.

После инициализации HOME в известном каталоге он начал работать нормально.

Answer 2

У меня такая же проблема... Сначала я обновил свою версию Rsync для Windows из rsync.net, но это не помогло.

Тогда я посмотрел на их файл с примером летучей мыши. Я заметил пути, где не подходит для Windows 2008.

Я просто открыл переменные окружения для системы и добавил следующее ...

CWRSYNCHOME = C:\Program Files (x86)\cwRsync

CYGWIN = нонсек

CWOLDPATH ----- <просто REM в примере, пакет не добавил к переменным среды

* PATH = C:\Program Files (x86)\cwRsync\bin

* добавьте к своей уже длинной PATH после a;

затем я просто удаляю все установленные пути в пакетном файле. EXCEPT SET HOME = C:\RSYNC <--- Я переместил свой паб и закрытые ключи для папок и файлов SSH в этот каталог и удостоверился, что безопасность была установлена для всех для этой папки в окне, где выполняется это, потому что задача запускается как учетная запись службы, а не как администратор. и в то время я пытался устранить причины неудачи.

• пример bat, о котором я говорю, поставляется с установкой из Rsync.net для rsync - это более старая версия, но она работала для меня (3.1) (у меня была версия 2.6, и я пытался изменить как можно меньше)

Rsync теперь запускается как запланированная задача в Windows Server 2008 R2 без проблем. каждые 30 минут

Продолжительная версия Rsync из источника (не то, что я использовал, но, вероятно, не повредит)

http://sourceforge.net/projects/sereds/files/cwRsync

Я надеюсь, что это помогает кому-то застрять в этой проблеме, это было очень сложно !!!

Answer 3

Задача решена. Я начал заново со свежей установки Cygwin, чтобы получить последние версии SSH и RSYNC, и теперь он работает нормально.

Answer 4

Просто столкнувшись с этой же проблемой в 2018 году в Windows 10, я обнаружил, что корень проблемы в моем случае заключается в том, что учетная запись SYSTEM (под которой запускается задача) не доверяет целевому серверу SSH, и SSH будет поэтому бесконечно запрашивайте доверие, одобрение или отмену соединения в сеансе безголового терминала.

Чтобы решить эту проблему, я добавил сервер в файл ~/.ssh/known_hosts учетной записи SYSTEM, скопировав его от своего собственного пользователя.