Есть ли команда, такая как rsync, которая может синхронизировать огромные разреженные файлы с одного сервера Linux на другой?
Очень важно, чтобы конечный файл оставался разреженным. Он может быть длиннее (но не больше) диска, на котором он находится. По сети следует отправлять только измененные блоки.
Я пробовал rsync, но без радости. https://groups.google.com/forum/#!topic/mailing.unix.rsync/lPOScZgFE9M
Если я напишу программу для этого, я просто изобрету велосипед? http://www.finalcog.com/synchronise-block-devices
Спасибо,
Крис.
rsync --ignore-existing --sparse ...
Для создания новых файлов в разреженном режиме
С последующим
rsync --inplace ...
Обновить все существующие файлы (включая ранее созданные разреженные) на месте.
Rsync передает только изменения в каждый файл, а с параметром --inplace следует перезаписывать только те блоки, которые были изменены, без повторного создания файла. Из их страница функций.
rsync - это программа для передачи файлов для систем Unix. rsync использует «алгоритм rsync», который обеспечивает очень быстрый метод синхронизации удаленных файлов. Он делает это, отправляя только различия в файлах по ссылке, не требуя, чтобы оба набора файлов заранее присутствовали на одном из концов ссылки.
Использование --inplace должно сработать для вас. Это покажет вам прогресс, сжатие передачи (на уровне сжатия по умолчанию), рекурсивная передача содержимого каталога локального хранилища (имеет значение первая конечная косая черта), внесение изменений в файлы на месте и использование ssh для транспорта.
rsync -v -z -r --inplace --progress -e ssh /path/to/local/storage/ \
user@remote.machine:/path/to/remote/storage/
Я также часто использую флаг -a, который делает еще несколько вещей. Это эквивалентно -rlptgoD. Я оставлю вам точное поведение, чтобы вы могли посмотреть его на странице руководства.
Взгляни на Проект Zumastor Linux Storage он реализует резервное копирование «моментальных снимков» с использованием двоичного файла «rsync» через ddsnap инструмент.
На странице руководства:
ddsnap обеспечивает репликацию блочного устройства с помощью средства создания снимков на уровне блоков, способного эффективно хранить несколько одновременных снимков. ddsnap может сгенерировать список фрагментов снимков, которые различаются между двумя снимками, а затем отправить это различие по сети. На нисходящем сервере запишите обновленные данные на блочное устройство с моментальным снимком.
В итоге я написал программу для этого:
Это коммерческое программное обеспечение стоимостью 49 долларов США за физический сервер.
Теперь я могу реплицировать разреженный файл размером 50 ГБ (содержащий 3 ГБ содержимого) менее чем за 3 минуты через широкополосную связь в домашних условиях.
chris@server:~$ time virtsync -v /var/lib/libvirt/images/vsws.img backup.barricane.com:/home/chris/
syncing /var/lib/libvirt/images/vsws.img to backup.barricane.com:/home/chris/vsws.img (dot = 1 GiB)
[........>.........................................]
done - 53687091200 bytes compared, 4096 bytes transferred.
real 2m47.201s
user 0m48.821s
sys 0m43.915s
Чтобы синхронизировать огромные файлы или блочные устройства с небольшими или средними различиями, вы можете сделать простую копию или использовать bdsync, rsync абсолютно не подходит для этого конкретного случая *.
bdsync работал у меня, кажется достаточно зрелым, история ошибок обнадеживает (небольшие проблемы, быстрое решение). В моих тестах скорость была близка к теоретическому максимуму, который вы могли получить ** (то есть вы можете выполнить синхронизацию примерно за то время, которое вам нужно для чтения файла). Наконец, это открытый исходный код и ничего не стоит.
bdsync читает файлы с обоих хостов и обменивается контрольными суммами для их сравнения и обнаружения различий. Все эти в то же время. Наконец, он создает сжатый файл исправления на исходном хосте. Затем вы перемещаете этот файл на целевой хост и запускаете bdsync во второй раз, чтобы исправить целевой файл.
При использовании его по довольно быстрому каналу (например, 100 Мбит Ethernet) и для файлов с небольшими различиями (как это чаще всего бывает на дисках виртуальных машин) он сокращает время синхронизации до времени, необходимого для чтения файла. По медленной ссылке вам нужно немного больше времени, потому что вам нужно скопировать сжатые изменения с одного хоста на другой (кажется, вы можете сэкономить время, используя хороший трюк но не тестировал). Для файлов с большим количеством изменений также следует учитывать время записи файла исправления на диск (и вам нужно достаточно свободного места на обоих хостах для его хранения).
Вот как я обычно использую bdsync. Эти команды выполняются на $LOCAL_HOST копировать" $LOCAL_FILE к $REMOTE_FILE на $REMOTE_HOST. я использую pigz (быстрее gzip), чтобы сжать изменения, ssh для запуска bdsync на удаленном хосте и rsync/ssh чтобы скопировать изменения. Обратите внимание, что я проверяю, успешно ли применен патч, но я печатаю только «Обновление успешно», когда это происходит. Возможно, вы захотите сделать что-нибудь более умное в случае неудачи.
REMOTE_HOST=1.2.3.4
LOCAL_FILE=/path/to/source/file
REMOTE_FILE=/path/to/destination/file
PATCH=a_file_name
LOC_TMPDIR=/tmp/
REM_TMPDIR=/tmp/
# if you do use /tmp/ make sure it fits large patch files
# find changes and create a compressed patch file
bdsync "ssh $REMOTE_HOST bdsync --server" "$LOCAL_FILE" "$REMOTE_FILE" --diffsize=resize | pigz > "$LOC_TMPDIR/$PATCH"
# move patch file to remote host
rsync "$LOC_TMPDIR/$PATCH" $REMOTE_HOST:$REM_TMPDIR/$PATCH
# apply patch to remote file
(
ssh -T $REMOTE_HOST <<ENDSSH
pigz -d < $REM_TMPDIR/$PATCH | bdsync --patch="$REMOTE_FILE" --diffsize=resize && echo "ALL-DONE"
rm $REM_TMPDIR/$PATCH
ENDSSH
) | grep -q "ALL-DONE" && echo "Update succesful" && rm "$LOC_TMPDIR/$PATCH"
# (optional) update remote file timestamp to match local file
MTIME=`stat "$LOCAL_$FILE" -c %Y`
ssh $REMOTE_HOST touch -c -d @"$MTIME_0" "$REMOTE_FILE" </dev/null
*: rsync крайне неэффективен с огромными файлами. Даже с --inplace он сначала прочитает весь файл на целевом хосте, ПОСЛЕ этого начнется чтение файла на исходном хосте и, наконец, перенесет различия (просто запустите dstat или аналогичный при запуске rsync и наблюдайте). В результате даже для файлов с небольшими различиями требуется примерно в два раза больше времени, чтобы прочитать файл, чтобы синхронизировать его.
**: При условии, что у вас нет другого способа узнать, какие части файлов были изменены. Снимки LVM используют растровые изображения для записи измененных блоков, поэтому они могут быть чрезвычайно быстрыми (Readme из lvmsync есть больше информации).
lvmsync Является ли это.
Вот стенограмма использования. Создает снимок LVM на источнике, переносит логический раздел. Вы можете передавать инкрементные обновления изменений с момента создания снимка так часто, как вам нравится.
Может ли репликация всей файловой системы быть решением? DRBD? http://www.drbd.org/
Может быть, здесь немного странно, но недавно я узнал, что NFS справляется с этим нормально.
Таким образом, вы экспортируете каталог на одном компьютере, затем монтируете его на другом и просто копируете файлы с помощью основных утилит, таких как cp. (Некоторые старые / старые утилиты могут иметь проблемы с разреженными файлами.)
я нашел rsync особенно неэффективен при передаче разреженных файлов.
Я не знаю о такой утилите, только о системных вызовах, которые могут ее обрабатывать, поэтому, если вы напишете такую утилиту, она может оказаться весьма полезной.
на самом деле вы можете использовать qemu-img convert для копирования файлов, но он будет работать только в том случае, если конечная FS поддерживает разреженные файлы