Вопрос: Любимые советы и трюки rsync


Чем больше я использую rsync тем больше я понимаю, что это швейцарский армейский нож передачи файлов. Есть так много вариантов. Недавно я узнал, что вы можете пойти --remove-source-files и он будет удалять файл из источника, когда он был скопирован, что делает его скорее скорее перемещением, чем копированием программы. :)

Какие у вас любимые советы и трюки rsync?


54
2017-07-24 11:21


Источник




Ответы:


Попробуйте использовать версию rsync 3, если вам нужно синхронизировать много файлов! V3 строит свой список файлов постепенно и намного быстрее и использует меньше памяти, чем версия 2.

В зависимости от вашей платформы это может иметь большое значение. В OSX версии 2.6.3 потребуется более одного часа или сбоя, пытаясь создать индекс в 5 миллионов файлов, а скомпилированная версия 3.0.2 начала копирование сразу.


17
2017-07-24 16:29



Следует отметить, что если вы используете некоторые параметры (например, --delete-before например) используется старое поведение «списка сборки», поскольку для правильной работы этих параметров необходимо, чтобы эти параметры работали правильно, поэтому, если вы не видите этого поведения, проверьте, могут ли другие параметры, которые вы используете, остановить его. Это может быть полезно, если вы используете rsync в интерактивном режиме на большом дереве и хотите принудительно выполнить начальное сканирование, чтобы выход --progress (т. е. счетчик «объекты для сравнения» никогда не будет повышаться, поскольку после первоначального сканирования не будет найдено никаких новых объектов). - David Spillett


С помощью --link-dest для создания резервных копий на основе снимков на основе пространства, в результате чего у вас появляется несколько полных копий данных резервного копирования (по одному для каждого резервного копирования), но файлы, которые не меняются между прогонами, жестко связаны, а не создают новые копии, экономя пространство.

(на самом деле, я все еще использую rysnc-с последующим-cp -al метод, который достигает того же, см. http://www.mikerubel.org/computers/rsync_snapshots/ для старости, но все еще очень-очень хорошо справляются с обоими методами и связанными с ними проблемами)

Одним из основных недостатков этого метода является то, что если файл поврежден из-за ошибки диска, он так же поврежден во всех моментальных снимках, которые ссылаются на этот файл, но у меня есть автономные резервные копии, которые будут защищать от этого в приличной степени. Другое, на что нужно обратить внимание, заключается в том, что ваша файловая система имеет достаточное количество дескрипторов или вы исчерпаете их, прежде чем на самом деле закончите дисковое пространство (хотя у меня никогда не было проблем с настройками ext2 / 3 по умолчанию).

Кроме того, никогда не забывайте о очень полезной --dry-run для небольшой здоровой паранойи, особенно когда вы используете --delete* опции.


17
2017-07-24 12:26



+1 для --dry-run - David Z
Обратите внимание: -n - ярлык для -dry-run - ctennis
Я предпочитаю придерживаться длинных имен, особенно в сценариях, которые другие могут поддерживать. Это дает более четкое представление о том, что предназначено без ссылки на документы. - David Spillett
+1 Я реализовал резервное решение многих TB на многих машинах с методом -link-dest для жестко привязанных снимков, как описано выше, - он отлично работал. - matja
Если вам нравится резервное копирование -link-dest, проверьте Dirvish который использует rsync под капотом - hfs


Если вам нужно обновить сайт с помощью огромных файлов по медленной ссылке, вы можете перенести небольшие файлы таким образом:

rsync -a -max-size = 100K / var / www / there: / var / www /

то сделайте это для больших файлов:

rsync -a -min-size = 100K --bwlimit = 100 / var / www / there: / var / www /

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


12
2017-08-26 13:05





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


10
2017-07-24 11:32



Благодаря! Это просто спасло меня от какой-то неприятной записи правил фильтра. - benzado


--rsh это мое.

Я использовал его для изменения шифрования на ssh на что-то быстрее (--rsh="ssh -c arcfour") также установить цепочку sshs (рекомендуется использовать его с ssh-agent) для синхронизации файлов между хостами, которые не могут напрямую разговаривать. (rsync -av --rsh="ssh -TA userA@hostA ssh -TA -l userB" /tmp/foobar/ hostB:/tmp/foobar/).


8
2017-07-24 17:26





--time-limit

Когда эта опция используется, rsync остановится после T минут и выйти. Я думаю, этот вариант полезен, когда rsyncing большое количество данных в ночное время (не занятые часы), а затем останавливается, когда это время для людей, чтобы начать использовать сеть, в течение дня (часы работы).

--stop-at=y-m-dTh:m

Этот параметр позволяет указать, в какое время остановить rsync.

Batch Mode

Пакетный режим может использоваться для применения одного и того же набора обновлений для многих идентичных систем.


7
2018-06-04 23:51



Полезно! Раньше я использовал команду «at», чтобы убить процесс - Lionel
Исходные патчи: rsync.samba.org/ftp/rsync/rsync-patches-3.1.0.tar.gz ; Win32 с патчем: itefix.no/i2/cwrsync - jftuga
К сожалению, эти параметры недоступны в rsync, распространяемом с дистрибутивами Redhat / Centos или Ubuntu. - IanB
@Lionel: Как вы используете at убить процесс? - IMTheNachoMan


Если вам интересно, как далеко продвинулся медленный rsync, и не использовал -v для перечисления файлов по мере их переноса, вы можете узнать, какие файлы он открыл:

 ls -l /proc/$(pidof rsync)/fd/*

на системе, которая имеет / proc

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

Он также рассказал мне немного интересную информацию - другой конец, по-видимому, сдался, поскольку также была сломанная сокетная ссылка:

/proc/22954/fd/4: broken symbolic link to `socket:[2387837]'

6
2018-01-09 19:08