Резервное копирование RSync хранилища Subversion с помощью Rsyncrypto - PullRequest
Новая
       22

Резервное копирование RSync хранилища Subversion с помощью Rsyncrypto

1 голос
/ 08 сентября 2010

Ситуация

У меня довольно большой репозиторий Subversion, который я пытаюсь эффективно выполнить резервное копирование.Размер репозитория составляет около 6 ГБ и продолжает расти.Размер некоторых крупных коммитов составляет от 500 до 1 ГБ.

Я пытаюсь сделать резервную копию этого репозитория в удаленном расположении через восходящую интернет-линию.

Объяснение бесполезногоего размер

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

Как

Вот что я на самом деле делаю:

  1. Резервное копированиехранилище в рабочую папку на сервере, используя "svnadmin hotcopy SRCDIR TGTDIR"
  2. Шифрование и сжатие этого хранилища с использованием "rsyncrypto -r SRCPATH DSTPATH ​​CEYSPATH CERTIFICATE"
  3. Резервное копирование этой зашифрованной версии в стороннее расположение, используя "rsync -Crtv" (на самом деле cwRsync, потому что я работаю в Windows)

Проблема

Сначала я должен сказать, что это работает, хотя у него все еще есть основная проблема.

Проблема заключается в том, что я ожидал, что каждый раз процесс будетвыполнить, будут скопированы только файлы / данные новых ревизии ([repos] / db / revs / 0 / ...), что потребует только пропускную способность и время при выполнении большого коммита.Однако вместо этого:

  • Если я запускаю только шаг № 3 много раз, rsync ведет себя так, как должен, и ничего не копируется, потому что ничего не изменилось.
  • Если я запускаю только шаги # 2& # 3 много раз rsync также ведет себя хорошо.Зашифрованная версия всегда одинакова, и rsync не должен ничего передавать.
  • Но, похоже, каждый раз, когда я запускаю все три шага (с новым коммитом,репозиторий) весь репозиторий перезагружается полностью .Таким образом, во-первых, победив всю цель использования rsync.

Как будто файлы в [repos] / db / revs / 0 / ... меняются каждый раз, когда я делаю горячую копию.

Вопросы

Это ожидаемое поведение от "горячей копии svnadmin", когда [repos] / db / revs / 0 / ... меняются с одногогорячая копия другому?

Любые предложения или варианты, которые я мог бы использовать, чтобы сделать эту горячую копию rsync friendly или сказать rsyncable ?

Я не совсем уверенчто при использовании «svnadmin dump» во всем хранилище будет получен «rsyncable» файл .

1 Ответ

2 голосов
/ 22 сентября 2010

Я не знаю подробностей о том, как Subversion хранит свои файлы резервных копий, поэтому я не знаю, должна ли горячая копия из r5678 быть идентичной блоку горячей копии из r6789 (что и нужно сделать rsyncэффективная копия).Когда мы выполняем резервное копирование нашего репозитория разработки, мы каждую неделю делаем полное резервное копирование (горячее копирование, а затем выполняем резервное копирование всего, сколько бы ни было), и выполняем инкрементное резервное копирование каждый день, используя следующую команду: 

svnadmin dump /path/to/repos -r latest-backed-up-rev:latest-repos-rev --incremental --deltas

Опция --incremental означает «Это должно быть применено к хранилищу в ревизии last-backed-up-rev», а параметр --deltas использует двоичный формат, который не намного больше фактического изменения самого размера хранилища.Если вы замените шаг 1 дампом, который добавляет только один маленький файл, то ваш rsync будет работать нормально.

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

...