Возобновление частичной части rsync (-P/- partial) на прерванной передаче

Ответ 1

TL; DR: используйте --timeout=X (X в секундах), чтобы изменить тайм-аут сервера rsync по умолчанию, а не --inplace.

Проблема заключается в процессах сервера rsync (из которых два, см. вывод rsync --server ... in ps на приемнике) продолжают работать, чтобы ждать, пока клиент rsync отправит данные.

Если процессы сервера rsync не получают данные в течение достаточного времени, они действительно будут таймаутом, самозавершением и очисткой, переместив временный файл на его "правильное" имя (например, без временного суффикса). Затем вы сможете возобновить работу.

Если вы не хотите ждать длинного по умолчанию таймаута, чтобы заставить сервер rsync самостоятельно завершаться, тогда, когда ваше интернет-соединение вернется, войдите в сервер и вручную очистите сервер rsync. Однако вы должны вежливо прекратить rsync - в противном случае он не будет перемещать частичный файл на место; но, скорее, удалите его (и, следовательно, нет файла для возобновления). Чтобы вежливо спросить rsync о завершении, не SIGKILL (например, -9), но SIGTERM (например, pkill -TERM -x rsync - только пример, вы должны позаботиться о том, чтобы соответствовать только процессам rsync, связанным с вашим клиентом).

К счастью, есть более простой способ: используйте опцию --timeout=X (X в секундах); он также передается процессам сервера rsync.

Например, если вы укажете rsync ... --timeout=15 ..., процессы клиента и сервера rsync будут чисто выходить, если они не будут отправлять/получать данные за 15 секунд. На сервере это означает перемещение временного файла на место, готовое к возобновлению.

Я не уверен, что значение тайм-аута по умолчанию для различных процессов rsync будет пытаться отправлять/получать данные до их смерти (это может различаться в зависимости от операционной системы). В моем тестировании процессы rsync сервера продолжают работать дольше, чем локальный клиент. При "мертвом" сетевом соединении клиент прекращает работу со сломанным трубой (например, без сетевого сокета) примерно через 30 секунд; вы можете экспериментировать или просматривать исходный код. Смысл, вы могли бы попытаться "пропустить" плохое интернет-соединение в течение 15-20 секунд.

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

Интересно, если вы затем очистите все процессы сервера rsync (например, остановите свой клиент, который остановит новые серверы rsync, а затем SIGTERM старые серверы rsync, он, похоже, объединит (соберите) все частичные файлы в новый надлежащий именованный файл. Итак, представьте себе длинную частичную копию, которая умирает (и вы думаете, что "потеряли" все скопированные данные), и короткий запуск повторно запущенного rsync (oops!).. вы можете остановить второй клиент, SIGTERM первых серверов, он объединит данные, и вы сможете возобновить их.

Наконец, несколько коротких замечаний:

• Не используйте --inplace, чтобы обойти это. В результате у вас, несомненно, возникнут другие проблемы, man rsync для деталей.
• Это тривиально, но -t в ваших параметрах rsync избыточно, это подразумевается -a.
• Уже сжатое изображение диска, переданное через rsync без сжатия, может привести к сокращению времени передачи (избегая двойного сжатия). Тем не менее, я не уверен в методах сжатия в обоих случаях. Я бы протестировал его.
• Насколько я понимаю --checksum/-c, это не поможет вам в этом случае. Это влияет на то, как rsync решает, должен ли он передать файл. Хотя, после завершения первого rsync, вы можете запустить второй rsync с помощью -c, чтобы настаивать на контрольных суммах, чтобы предотвратить странный случай, что размер файла и время разговора одинаковы с обеих сторон, но были написаны плохие данные.

Ответ 2

Извините, но другие ответы здесь слишком сложны: -7. Более простой ответ для меня: (используя rsync over -e ssh)

# optionally move rsync temp file, then resume using rsync 
dst$ mv .<filename>.6FuChr <filename>
src$ rsync -avhzP --bwlimit=1000 -e ssh <fromfiles> <[email protected]>:<destdir>/

Работает также при возобновлении с scp, который был прерван.

Rsync создает временный файл... Временной файл быстро растет до размера частично перенесенного файла. Передача возобновляется.

Scp записывает в фактический конечный файл назначения. Если передача прерывается, это усеченный файл.

Объяснение аргументов:

-avhz.. h = humanoid, v = verbose, a = archive, z = сжатие .. архив инструктирует его поддерживать значения time_t, поэтому даже если часы отсутствуют rsync знает истинную дату каждого файла

-P не подходит для --partial --progress.  --partial сообщает rsync хранить частично переданные файлы (и после возобновления rsync будет использовать частично переданные файлы всегда после проверки безопасности)

Из справочных страниц: http://ss64.com/bash/rsync_options.html

--partial
By default, rsync will delete any partially transferred file if the transfer
is interrupted. In some circumstances it is more desirable to keep partially
transferred files. Using the --partial option tells rsync to keep the partial
file which should make a subsequent transfer of the rest of the file much faster.

--progress
This option tells rsync to print information showing the progress of the transfer.
This gives a bored user something to watch.
This option is normally combined with -v. Using this option without the -v option
will produce weird results on your display.

-P
The -P option is equivalent to --partial --progress.
I found myself typing that combination quite often so I created an option to make
it easier.

ПРИМЕЧАНИЕ: для соединения, которое прерывается несколько раз: Если вам нужно возобновить работу после rsync (после того, как соединение будет прервано), лучше переименовать временный файл по месту назначения. scp создает файл по назначению с тем же именем, что и конечный файл. Если scp прерван, этот файл является усеченной версией файла. Rsync (-avzhP) возобновится из этого файла, но начнет запись во временное имя файла, например..Yhg7al.

Порядок действий при запуске scp:

scp; *interrupt*; rsync; [REPEAT_as_needed: *interrupt*; mv .destfile.tmpzhX destfile; rsync;]. 

Процедура при запуске с помощью rsync:

rsync; [REPEAT_as_needed: *interrupt*; mv .destfile.tmpzhX destfile; rsync;].

Ответ 3

Я обнаружил, что добавление --inplace исправляет его. Не уверен, как - партнер должен работать без него, но он возобновил мои переводы. Мои файлы все еще довольно большие, и мне интересно, закончится ли я поврежденными файлами, если начнется передача, а через несколько часов начнется другая передача, но он увидит неполный файл и не знает, что он загружается в настоящее время, а затем начинает добавлять байты в Это. Кто-нибудь знает? Может быть, некоторые скрипты bash для регистрации текущего идентификатора процесса и не запускать другой перенос?

Ответ 4

Если вы боитесь коррумпированных файлов после возобновления, вы можете добавить --checksum, чтобы заставить его выполнять контрольные суммы всего файла каждый раз. На самом деле это обойдется вам в несколько циклов диск-IO и CPU, но будет лишь небольшая сетевая накладная.