Одиночный (архивный) файл RSync, который меняется каждый раз

Я работаю над утилитой резервного копирования с открытым исходным кодом, которая создает резервные копии файлов и передает их в различные внешние хранилища, такие как Amazon S3, Rackspace Cloud Files, Dropbox и на удаленные серверы по протоколам FTP/SFTP/SCP.

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

Позвольте мне дать вам краткое изложение того, что происходит, когда создается резервная копия. По сути, он начнет сбрасывать базы данных, такие как MySQL, PostgreSQL, MongoDB, Redis. Это может занять несколько обычных файлов (например, изображений) из файловой системы. Как только все будет на своих местах, он соберет все это в один .tar (дополнительно он сожмет и зашифрует его с помощью gzip и openssl).

Когда все это будет сделано, у нас будет один файл, который выглядит следующим образом:
mybackup.tar.gz.enc

Теперь я хочу передать этот файл в удаленное место. Цель состоит в том, чтобы уменьшить пропускную способность и стоимость хранения. Итак, давайте предположим, что этот небольшой резервный пакет имеет размер около 1GB. Поэтому мы используем rsync, чтобы перенести это в удаленное место и удалить резервную копию файла локально. Завтра будет сгенерирован новый файл резервной копии, и оказывается, что за последние 24 часа было добавлено намного больше данных, и мы создаем новый файл mybackup.tar.gz.enc, и похоже, что мы достигли размера 1.2GB.

Теперь мой вопрос: можно ли перенести только 200MB, которые были добавлены за последние 24 часа? Я попробовал следующую команду:

rsync -vhP --append mybackup.tar.gz.enc backups/mybackup.tar.gz.enc

Результат:

mybackup.tar.gz.enc 1.20G 100% 36.69MB/s 0:00:46 (xfer#1, to-check=0/1)

отправлено 200,01 млн байт
получено 849,40 тыс. байт
8,14 млн байт/с
общий размер 1,20 ГБ
ускорение 2,01

Глядя на sent 200.01M bytes, я бы сказал, что "добавление" данных работает правильно. Теперь мне интересно, перенес ли он все 1.2GB, чтобы выяснить, сколько и что добавить к существующей резервной копии, или он действительно перенес только 200MB? Потому что, если он передал все 1.2GB, то я не вижу, чем он сильно отличается от использования утилиты scp для отдельных больших файлов.

Кроме того, если то, что я пытаюсь сделать, вообще возможно, какие флаги вы рекомендуете? Если это невозможно с rsync, есть ли какая-нибудь утилита, которую вы могли бы порекомендовать вместо этого?

Любая обратная связь очень ценится!


person Michael van Rooijen    schedule 04.03.2011    source источник


Ответы (3)


Он отправил только то, что сказал, что отправил - только передача измененных частей - одна из основных функций rsync. Он использует некоторые довольно умные алгоритмы контрольной суммы (и отправляет эти контрольные суммы по сети, но это незначительно - на несколько порядков меньше данных, чем передача самого файла; в вашем случае я бы предположил, что это .01 в 200.01M) и передает только те части, которые ему нужны.

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

person Piskvor left the building    schedule 04.03.2011
comment
Спасибо за ответ. Да, я был немного не уверен, потому что резервная копия, которую я создаю каждый раз, представляет собой совершенно новый файл. Все базы данных снова сбрасываются, образы снова собираются, и они объединяются в один новый mybackup.tar.gz.enc. Поскольку этот файл в основном представляет собой совершенно новый файл, у меня были сомнения, что он может не понять, или нарушить алгоритм, или что-то в этом роде. Но да, вы правы. Спасибо за ваш отзыв! - person Michael van Rooijen; 05.03.2011
comment
@Michael van Rooijen: Неважно, новый он или нет, важны различия между вашим локальным файлом и удаленным. Поскольку процесс дампа базы данных является детерминированным, различные дампы одной и той же базы данных будут иметь много общего. - person Piskvor left the building; 05.03.2011
comment
Верно. Когда я упаковываю все, что я вложил в файл .tar, он действительно отправляет только несколько KB для файла, который на самом деле 3.5MB. Однако, как только я сожму файл с помощью GZip, он снова начнет отправлять примерно 2MB. Таким образом, несмотря на то, что объем передаваемых данных все еще немного уменьшается, похоже, что RSync с трудом справляется со сжатыми резервными копиями. Я предполагаю, что это то же самое с шифрованием. Так что мне, вероятно, придется оставить его на уровне .tar и RSync. Спасибо за вашу помощь! - person Michael van Rooijen; 05.03.2011
comment
@Michael van Rooijen: rsync имеет встроенное сжатие (с переключателем -z), поэтому распаковка/сжатие вручную не требуется. (Кроме того, обратите внимание на параметр --fuzzy, он может быть полезен в вашей ситуации). manpagez.com/man/1/rsync - person Piskvor left the building; 05.03.2011
comment
Кроме того, если кто-то все еще читает это, у gzip есть опция --rsyncable именно для этого. - person Piskvor left the building; 17.10.2017

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

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

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

person Rob Redpath    schedule 24.10.2012
comment
FWIW В rsync, -z будут сжиматься данные файла во время передачи. Возможно, в некоторых случаях это может быть альтернативой сжатию вперед... - person rogerdpack; 27.07.2017

Новый rsync --append СЛОМАЕТ содержимое вашего файла, если в ваших существующих данных есть какие-либо изменения. (Начиная с 3.0.0)

person Tapio Rantala    schedule 22.10.2013
comment
У вас есть ссылка, чтобы уточнить это? Вы имеете в виду тот факт, что это causes rsync to update a file by appending data onto the end of the file, which presumes that the data that already exists on the receiving side is identical with the start of the file on the sending side. ? - person rogerdpack; 27.07.2017