scp завис при попытке скопировать файлы из Linux в Windows

Какая другая хорошая альтернатива для scp? , (считайте, что мне нужна 100% стабильности)

Подумайте о том, чтобы перевернуть его и использовать WinSCP с компьютера Windows для подключения и получения файлов на сервере Linux.

Это может быть признаком проблем с сетью - ping не обнаруживает всех проблем. Наиболее вероятная причина - брандмауэр или устройство NAT, которое разрывает соединение.

Добавление -v для подробного вывода в scp даст вам более подробную информацию о том, что он делает, и может дать лучшее представление о том, что происходит. Если вы хотите опубликовать результат неудачной передачи с параметром -v, возможно, я смогу дать более точный ответ.

Сброс соединения одноранговым узлом означает именно это - целевой сервер сбросил / закрыл соединение. Устройства NAT сделают это, если какое-то время не отправлялись какие-либо данные или если они работают некорректно.

Некоторые интернет-провайдеры делают это как форму формирования трафика, чтобы ограничить одноранговый трафик - к сожалению, некоторые применяют это и к соединениям SSH. Скорее всего, это не будет проблемой для бизнес-подключений, но если на одном конце есть домашнее подключение к Интернету, это может произойти.

Сервер SSH в Windows также может быть нестабильным. Вы не указываете, какой из них используете, но не все из них работают надежно.

В одном из реальных примеров странностей у меня был друг, у которого были похожие проблемы - это оказалась ошибка в прошивке его кабельного модема, которая повредила один из каждых двух миллионов пакетов. Достаточно редко, чтобы небольшие переводы работали идеально, но большие каждый раз умирали.

Или это могут быть обычные проблемы с интернетом. Интернет не на 100% надежен и никогда не будет. Иногда происходит сбой подключения, иногда пакеты теряются по пути. Иногда крохотные человечки внутри кабеля Ethernet устраивают забастовку и не хотят нести ваши пакеты. Итак, вам нужен инструмент, который может справиться с этим, и продолжайте попытки, пока не добьетесь успеха.

rsync был бы здесь лучшим выбором просто потому, что он позволяет возобновить работу. Это сообщение в блоге объясняет, как настроить rsync с возобновлением вместо scp. При необходимости вы можете написать простой сценарий оболочки, чтобы проверить код выхода rsync и продолжать попытки, если это не удается. Это другое сообщение в блоге есть пример такого сценария.

Эйтан, вы не упомянули, можете ли вы установить другие инструменты на компьютере с Windows, и если вам нужно зашифрованное соединение, вот мои комментарии и предложения:

• Сегодня у меня проблема с rsync для копирования больших древовидных структур с большим количеством файлов ... где он просто падает, но хорошо, что когда вы снова запустите его, они будут "продолжать" с того места, где они остановились раньше ....
• rsync нужны утилиты ssh или rsh ... предположим, что проблема в вашем ssh-сервере с rsync, вы создадите новую точку отказа. Но лично я бы протестировал, прежде чем отказаться от этого решения, поскольку оно универсально.

Мое предложение

• У меня большой опыт использования Cygwin для решений, подобных вашим.
  Итак, установите базовые пакеты + откройте ssh + cygrunsrv (для создания службы Windows).
• Затем, чтобы не переписывать свое решение, попробуйте использовать ssh-сервер cygwin вместо Windows или любого другого ssh-сервера, который вы используете.
• В качестве альтернативы вы можете установить rsh-сервер и попробовать его с помощью rsync.
• Другой вариант - это FTP-сервер (proftpd или pureftpd) и использовать ncftp/ ncftpput в Linux, чтобы подключиться к вам Windows.
  В ncftp возможность идентифицировать уже существующие / старые файлы и решать, перезаписывать их или нет, и рекурсивные каталоги. Вы, вероятно, сможете найти RPM ncftp на своем DVD Red Hat.
  Что касается производительности, FTP будет лучшим ....

Как видите, мне нравится cygwin, он мне часто помогает в Windows ... и является обязательным инструментом на моем рабочем столе Windows.

Удачи.