улучшение производительности резервного копирования rsync


8

Каковы лучшие методы для улучшения rsync по сравнению с ssh-зеркалированием между коробками Unix, при условии, что одна система всегда будет иметь главную копию, а другая система всегда будет иметь недавнюю копию (менее 48 часов назад)

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

Ответы:


6

Если :

  • Время модификации ваших файлов правильное
  • Файлы не очень большие
  • Невозможно пропустить push (или есть какая-то обработка невыполненных заданий)

Вы можете использовать find -ctimeили, file -cnewerчтобы составить список измененных файлов с момента последнего выполнения, и копировать только измененные файлы (просто прославленное дифференциальное нажатие).

Это довольно неплохо получилось для нескольких хостов: просто сделайте разностную tar на источнике и распакуйте его на всех хостах.

Это дает вам что-то вроде этого:

find -type f -cnewer /tmp/files_to_send.tar.gz > /tmp/files_to_send.txt
tar zcf /tmp/files_to_send.tar.gz --files-from /tmp/files_to_send.txt 
for HOST in host1 host2 host3 ...
do
    cat /tmp/files_to_send.tar.gz | ssh $HOST "tar xpf -"
done

Сценарий должен быть доработан, но вы поняли идею.


Упс: еще одно бесполезное использование кошки :-)
Стив Шнепп

На самом деле, это можно сделать почти так же, как это; если допустить, что с этими возможностями можно будет запускать сразу после сценариев, поддерживающих файлы данных
sal

4

Предполагая, что данные, которые вы запрашиваете, еще не сжаты, включение сжатия (-z), вероятно, поможет повысить скорость передачи, за счет некоторого ЦП на любом конце.


сжатие уже было включено через ssh
sal

3
Сжатие через rsync обычно более эффективно, чем сжатие в туннеле SSH. Причина в том, что rsync обладает большими знаниями и может ими воспользоваться. Например, его сжатие может ссылаться на части файлов, которые не были переданы.
Дероберт

5
@derobert перенес сжатие с ssh на rsync улучшил производительность почти на 20%
sal

2

Если вы передаете очень большие файлы с большим количеством изменений, используйте опции --inplace и --whole-file, я использую их для своих образов виртуальной машины 2 Гб, и это очень помогло (главным образом, из-за того, что протокол rsync мало что сделал с передачей дополнительных данных с этими файлами). Я не рекомендую эти варианты для большинства случаев, хотя.

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


2

Другая стратегия - сделать ssh и rsync быстрее. Если вы используете доверенную сеть (читай: частную), то шифрование фактической полезной нагрузки не требуется. Вы можете использовать HPN SSH . Эта версия SSH только шифрует аутентификацию. Кроме того, rsync версии 3 начинает передачу файлов при создании списка файлов. Это, конечно, огромная экономия времени по сравнению с Rsync версии 2. Я не знаю, если это то, что вы искали, но я надеюсь, что это поможет. Кроме того, rsync каким-то образом поддерживает многоадресную передачу, хотя я не буду притворяться, что понимаю, как это сделать.


Несколько лет назад, когда я использовал системы с гораздо более медленными процессорами, я сравнил все доступные методы сжатия OpenSSH, и fount "arcfour" был самым быстрым. Это, в сочетании с включением гигантских кадров при использовании гига, приводит к значительному повышению скорости передачи.
Дерек Прессналл

2

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

find /home -mindepth 1 -maxdepth 1 -print0 | xargs -0 -n 1 -I {} -- rsync -a -e ssh {} backup@mybackupserver:/backup/

или зарезервировать набор файлов, чтобы уменьшить количество файлов.

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


Знаете ли вы разницу между: для f в /Backup/*.bak; do rsync -e ssh $ f backup @ mybackupserver; готово и rsync -re ssh /Backup/*.bak backup @ mybackupserver?
Усама ALASSIRY

Мне кажется, разница в том, что первый будет запускать rsync для каждого файла .bak (при условии, что * .bak просто совпадает с файлами) в каталоге / Backup /, а второй запускает один rsync для их передачи. Если * .bak предназначен для совпадения с каталогами, то первый не будет возвращаться в подкаталоги (при условии, что вы специально отключили -r). Как правило, вы захотите сделать второй, а не первый, пока у вас не будет слишком много файлов для его обработки.
Родни Амато

1
Имейте в виду, что использование внешнего вида для перебора каталогов или файлов, в общем, не очень хорошая идея. Он ужасно сломается, если попадет в каталог или файл с пробелом в нем.
Натан,

@ Натан, так что-нибудь типа find /Backup/ -name '*.bak' -print0 | xargs -0 -n 1 rsync -e ssh?
Hark

Я обновил пример для использования подхода xargs. Мне никогда не приходилось делать это самостоятельно, потому что у меня никогда не было каталога в / home, в котором есть пробел, но у нас должен быть лучший пример.
Родни Амато

2

У rsync есть способ делать отключенные копии. Другими словами, rsync может (концептуально) различать дерево каталогов и создавать файл исправлений, который затем можно применить к любому количеству файлов, идентичных исходному источнику.

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

Если вы храните локальную копию последнего состояния rsynced (то есть копию того, как зеркала выглядят прямо сейчас) на той же машине, что и мастер, вы можете сгенерировать этот «патч» на мастере, даже не связываясь ни с одним зеркалом:

По мастеру:

rsync --write-batch=my-batch.rsync /master/data /current/mirror

Добавьте любые другие варианты, которые вы хотите. Это сделает две вещи:

  1. Это внесет /current/mirrorизменения, чтобы отразить/master/data
  2. Это создаст двоичный файл исправления (или пакетный файл), который будет вызван my-batch.rsyncдля последующего использования.

Перенесите my-batch.rsyncфайл с мастера на все ваши зеркала, а затем на зеркала примените патч так сказать:

rsync --read-batch=my-batch.rsync /local/mirror

Преимущества такого подхода:

  • мастер не завален
  • нет необходимости координировать / иметь доступ к мастеру / зеркалу (ам) одновременно
  • разные люди с разными привилегиями могут выполнять работу над мастером и зеркалом (ами).
  • не нужно иметь канал TCP (ssh, netcat, что угодно; файл можно отправить по электронной почте ;-))
  • автономные зеркала можно синхронизировать позже (просто подключите их и примените патч)
  • все зеркала гарантированно идентичны (так как они применяют один и тот же «патч»)
  • все зеркала могут быть обновлены одновременно (поскольку --read-batchна самом зеркале интенсивно работает только процессор)
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.