Большинство *устойчивый* удаленная копия файла?
Оболочка входа в систему будет всегда читать /etc/profile, который позволяет системному администратору устанавливать переменные среды и пути для всех пользователей.
Если Вы - единственный пользователь, и это - Ваша система, Вы свободны отредактировать или удалить/etc/profile, если Вы желаете.
OK, в моем случае я нашел решение. Я действительно использую предложенную в цикле . Теперь все выглядит так:
while ! \
rsync -aiizP --append --stats . -e ssh user@host.com:./path/rfiles ; \
do now=$(date +"%T") ; echo · Error at $now · ; sleep 5 ; done
- без циклов мне пришлось бы снова запускать rsync вручную. Теперь все работает как шарм.
Интересно, что я получаю ошибку ровно через 10 минут после потери соединения и примерно через 9 минут после того, как соединение снова включилось и запустилось! В то же время в окне терминала ничего не происходит. Интересно, откуда взялся этот 10-минутный тайм-аут.
Большое спасибо за помощь.
Гэри
К твоему сведению: Вот ошибка тайм-аута, которую я получаю (через 10 минут после факта):
...
thedirectory/afile.ext
Read from remote host myhost.com: Operation timed out
rsync: writefd_unbuffered failed to write 16385 bytes [sender]: Broken pipe (32)
rsync: connection unexpectedly closed (394 bytes received so far) [sender]
rsync error: unexplained error (code 255) at /SourceCache/rsync/rsync-40/rsync/io.c(452) [sender=2.6.9]
Основная проблема с rsync в том, что он не может продолжать индуктивные файлы. Если вы копируете сложную структуру каталогов, то это нормально, но если вы хотите скопировать, например, один образ dvd, то он не будет надежным.
Для таких случаев я использую wget. Точнее,
wget -c -t 0 -T 10 http://....
Особенно интересен таймаут 20 сек, который решает общую проблему, что наши инструменты эффективно зависают/замораживают из-за одного потерянного пакета.
Конечно, ему нужен http-сервер на стороне источника. Если это непрактично, есть инструмент с именем
split
, который может разбивать большие файлы на более мелкие, а затем использовать для них rsync. Разделенные файлы могут быть позже воссоединены с простой кошкой.
Конечно, вы можете запускать rsync даже в цикле до тех пор, пока не получится:
while ! rsync ...; do echo next try; done
Расширение после комментария
rsync может продолжить файлы, с флагом -partial. Спасибо @GregHewgill! :-)
Если попытаться решить эту проблему на уровне утилиты копирования файлов, то rsync не хуже. Обязательно используйте опции -au, чтобы rsync не пыталась синхронизировать один и тот же файл несколько раз. Rsync будет прогрессировать до тех пор, пока она сможет, по крайней мере, обменяться списком файлов и полностью передать один файл, прежде чем будет прервана; если вы не можете этого гарантировать, у вас возникнут проблемы без инструмента на сетевом уровне.
Я думаю, что проще (и естественнее) решить эту проблему на сетевом уровне: построить надежный туннель сети поверх ненадежного сетевого соединения. Много лет назад я использовал Rocks для этой самой цели; он не поддерживается, и в последнее время я не пытался его компилировать или использовать, но нет фундаментальных причин, почему бы он не работал. Смотрите на это пространство в поисках альтернатив.
Я бы определенно предложил rsync . Я использую rsync для копирования файлов в любой момент, когда мне кажется, что соединение может быть прервано. Если копирование не удастся, я знаю, что могу просто запустить его снова.
Легко включить его в цикл во время , если вам нужно, чтобы он автоматически перезапускался до тех пор, пока он не завершится успешно.