Я использую rdiff-резервное копирование для резервного копирования файлов с моего сервера на резервный сервер. Я запускаю резервную копию, используя команду, похожую на:
rdiff-backup user@example.com::/home/user/data/complete complete
Эта резервная копия работает хорошо. Однако на странице функций Rdiff-backup говорится:
Эффективная пропускная способность: rdiff-backup зависит от librsync и, таким образом, использует тот же алгоритм сравнения, что и rsync (однако, rsync и rdiff-backup, строго говоря, не имеют общего кода). [...] Например, предположим, что вы слегка изменили большой файл A для создания большого файла A ', и A все еще находится в удаленной системе. Когда rdiff-backup запущен, он отправлять только через diff A-> A ' [...]
Файлы на удаленном компьютере представляют собой дампы базы данных, созданные с использованием mysqldump, которые создаются ежечасно. Данные не сильно меняются от часа к часу. Каждое имя файла имеет формат YYYYMMDDHHMM.sql.
Основываясь на моей интерпретации вышеупомянутой «функции», rdiff-backup должен отправлять небольшую разницу для создания файла на основе других файлов в каталоге - другими словами, если A prime это последняя резервная копия и A это резервная копия T-1, она должна отправить небольшую разницу, чтобы получить от A к A prime.
Однако совершенно очевидно, что это не работает таким образом. Он отправляет весь новый файл, даже если новый файл немного отличается. Я ожидаю, что передача данных будет составлять несколько мегабайт, но это передача сотен мегабайт.
Также из страница руководства:
rdiff-резервное копирование жестяная банка также работают с эффективным использованием полосы пропускания по каналу, как rsync (1). Таким образом, вы можете использовать ssh и rdiff-backup для безопасного резервного копирования жесткого диска в удаленное место, и будут передаваться только различия. Используя настройки по умолчанию, rdiff-backup требует, чтобы удаленная система принимала ssh-соединения, и чтобы rdiff-backup был установлен в PATH пользователя на удаленной системе. Для получения информации о других возможностях см. Раздел «УДАЛЕННОЕ УПРАВЛЕНИЕ».
Итак, мой вопрос:
В вашем сообщении вы каждый час генерируете уникальный дамп sql YYYYMMDDHHMM.sql
Это каждый раз новый файл с уникальным именем.
Если вы меняли файлы в источнике (вместо создания новых файлов) - тогда эта функция применима.
В противном случае он смотрит на источник, обнаруживает совершенно новый файл ГГГГММДДЧЧ + 1MM.sql, он не знает, что в конечном файле с именем YYYYMMDDHHMM.sql очень близко, и он начнет синхронизировать файл YYYYMMDDЧЧ + 1MM.sql по назначению.
Если хотите воспользоваться этой функцией - тогда при новом файле ГГГГММДДЧЧ + 1MM.sql создается в источнике - вам нужно будет запустить какой-то скрипт, который подключится к месту назначения и сделает копию файла YYYYMMDDHHMM.sql
cp YYYYMMDDHHMM.sql YYYYMMDDHH+1MM.sql<br>
После этого запустите синхронизацию.
Таким образом, он обнаружит, что у места назначения есть файл с таким же именем, и, надеюсь, попытается использовать этот алгоритм частичной синхронизации.