Возобновление частичного (n-частичного) rsync на прерывистой передаче

19

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

Вот моя команда:

rsync -avztP -e "ssh -p 2222" /volume1/ [email protected]:/home/myaccount/backup/ --exclude "@spool" --exclude "@tmp"

Когда эта команда запущена, файл резервной копии с именем OldDisk.dmg с моего локального компьютера создается на удаленном компьютере как нечто вроде .OldDisk.dmg.SjDndj23 .

Теперь, когда интернет-соединение прерывается, и мне нужно возобновить передачу, я должен найти, где rsync остановился, найдя временный файл, например .OldDisk.dmg.SjDndj23 , и переименуйте его в < strong> OldDisk.dmg , чтобы он увидел, что уже существует файл, который он может возобновить.

Как я могу исправить это, поэтому мне не нужно вручную вмешиваться каждый раз?

    
задан Glitches 15.05.2013 в 20:06
источник

4 ответа

24

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

Проблема заключается в том, что процессы сервера rsync (из которых есть два, см. rsync --server ... в 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 вы можете запустить second rsync с -c , чтобы настаивать на контрольных суммах, чтобы предотвратить странный случай, что размер файла и время работы одинаковы с обеих сторон, но плохие данные было написано.
ответ дан Richard Michael 06.11.2013 в 05:26
  • Просто любопытно: не будет ли SIGINT (aka ^ C) «политиком», чем SIGTERM? –  JamesTheAwesomeDude 29.12.2013 в 17:50
  • Я не тестировал, как сервер rsync обрабатывает SIGINT, поэтому я не уверен, что он сохранит частичный файл - вы можете проверить. Обратите внимание, что это не имеет особого отношения к Ctrl-c; бывает так, что ваш терминал отправляет SIGINT в процесс переднего плана, когда вы нажимаете Ctrl-c, но сервер rsync не имеет управляющего терминала. Вы должны войти на сервер и использовать kill. Клиент rsync на стороне клиента не будет отправлять сообщение на сервер (например, после того, как клиент получит SIGINT через ваш терминал Ctrl-c), может быть интересно. Что касается антропоморфизации, не уверен, что такое «политик». :-) –  Richard Michael 29.12.2013 в 23:34
  • Я просто пробовал этот аргумент таймаута rsync -av --delete --progress --stats --human-readable --checksum --timeout = 60 --partial-dir / tmp / rsync / rsync: // $ remote : / / src /, но затем он истекает во время фазы «получения списка файлов» (который в этом случае занимает около 30 минут). Установка тайм-аута на полчаса, чтобы отменить цель. Любое обходное решение для этого? –  d-b 03.02.2015 в 09:48
  • @ user23122 --checksum считывает все данные при подготовке списка файлов, что отлично подходит для многих небольших файлов, которые часто меняются, но должны выполняться по требованию для больших файлов. –  Cees Timmerman 15.09.2015 в 19:10
5

Извините, но другие ответы здесь слишком сложны: -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 будет использовать частично переданные файлы всегда после проверки безопасности)

Из справочных страниц: Ссылка

--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;].
    
ответ дан gaoithe 19.08.2015 в 13:55
  • Но этот сайт говорит, что -progress подразумевает --verbose. –  Cees Timmerman 16.09.2015 в 10:33
  • --partial хранит частичные файлы, но для возобновления их следует использовать --append или --append-verify, а цель должна быть меньше источника, несмотря на то, что источник имеет более позднюю отметку времени. –  Cees Timmerman 19.10.2015 в 13:07
  • Если вам нужно снова возобновить (соединение rsync прервано), лучше всего переименовать временный файл в пункте назначения. Итак, процедура при запуске с scp: scp interrupt rsync [REPEAT_as_needed: interrupt mv_desttmp_destfile rsync]. Процедура при запуске с rsync: rsync [REPEAT_as_needed: interrupt mv_desttmp_destfile rsync]. –  gaoithe 18.01.2016 в 16:23
2

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

    
ответ дан Glitches 15.05.2013 в 20:29
  • Будьте осторожны с inplace, поскольку он также может принести больше вреда, чем пользы. Известно, что он вызывает дополнительные несоответствия, если к файлу в настоящее время обращаются другие. –  fyrye 13.10.2013 в 22:07
  • --append-verify подразумевает --inplace, но пропускает содержимое, которое не требует добавления. –  Cees Timmerman 16.09.2015 в 10:48
0

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

    
ответ дан mogul 15.05.2013 в 22:25
  • Мое понимание от человека rsync - это контроль контрольных сумм. Определение rsync о том, что передать, а не подтверждение после передачи, если это то, что вы предлагаете? Я не вижу, как размер файла и время работы в режиме modtime будут одинаковыми (для этого требуется контрольная сумма), если используется -inplace и соединение отключено. Для обеспечения корректности данных OP необходимо запустить второй rsync с -c. –  Richard Michael 06.11.2013 в 06:06