rsync или sftp?

Для таких больших файлов используйте rsync с --inplace или --partial-dir= параметры, так что если передача не удалась частично (например, из-за неожиданного разрыва соединения), вы могли легко возобновить ее, просто повторно запустив ту же команду.

Я обычно использую rsync для большинства общих передач, а не только для ситуаций, когда действительно необходимы его более полные возможности синхронизации, когда они доступны. Это не менее безопасно, чем sftp если наезд ssh (что обычно бывает) и не менее эффективным.

Я считаю главным преимуществом sftp (и связанные scp) является доступным везде, где ssh доступен, поэтому практически любой Linux / BSD / аналогичный клиент или сервер, тогда как rsync не устанавливается по умолчанию.

scp/sftp/rsync работают медленно, когда дело доходит до фактической передачи файлов, даже на Nehalems, поскольку шифрование является довольно тяжелым бременем. Вдобавок у меня сложилось впечатление, что scp/ssh установить свои собственные параметры волшебного сокета, такие как размер окна TCP, и всегда работают медленно (максимум 50-70 МБ / с на местный Пути 10 Гбит / с).

Меня это бесит, особенно для больших файлов и глобальных сетей, я не понимаю, почему кто-то думает, что он умнее, чем базовый стек TCP из ОС.

Я бы посмотрел на GridFTP Globus Toolkit (это FTP на стероидах), который использует параллельные / многопоточные сеансы TCP для массовых передач, а также отлично настроен на WAN. Вы можете поддержать GridFTP с помощью полноценной PKI или использовать ssh для учетных данных и инициирования сеанса. Имеет скорость передачи данных 10 Гбит / с и при необходимости может масштабироваться и балансироваться по нагрузке, но это действительно то, что необходимо для ТБ данных.

edit: Да, есть патчи SSH, которые исправляют параметры окна и вводят нулевой шифр для передачи и используют шифрование только для обмена ключами и учетными данными, но вам необходимо иметь оба терминатора соединения, чтобы эта сборка SSH в полной мере использовала Это.