Hello, All!

На основе деления пользователей на тех, кто не делает бэкапы и тех, кто их будет делать, возникла задача бэкапа репозитория svn. Начал разбираться с тонкостями, но так полностью и не осознал назначение ключей svnadmin dump --incremental и --deltas. Кто-нибудь может рассказать более подробно об этих ключах и особенностях их использования, что лучше делать, а чего лучше избегать?

Дальше больше. В общем случае, бэкап занимает некоторое время. Хотелось бы для себя выбрать один из вариантов:

1. При коммите новой ревизии как-то сделать бэкап только этой ревизии (к слову сказать, как это правильно сделать?).
2. По расписанию (раз в сутки) делать бэкап всего репозитория.

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

Здравствуйте, Anton Batenev, Вы писали:

AB>В общем, приветствуются любые конструктивные предложения по организации бэкапа.

У меня такая схема:

svnadmin hotcopy c:\svn\proj1 c:\svn_backup\copy\proj1
и так все репозитарии,
потом папка c:\svn_backup\copy\ архивируется любым доступным средством

Здравствуйте, Anton Batenev, Вы писали:

AB>Hello, All!

AB>На основе деления пользователей на тех, кто не делает бэкапы и тех, кто их будет делать, возникла задача бэкапа репозитория svn. Начал разбираться с тонкостями, но так полностью и не осознал назначение ключей svnadmin dump --incremental и --deltas. Кто-нибудь может рассказать более подробно об этих ключах и особенностях их использования, что лучше делать, а чего лучше избегать?

Ключ --incremental нужен для создания инкрементального бэкапа, что следует из его названия.
То есть производится бэкап не всего репозитория, а бэкап ревизий начиная с указанной.

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

Если есть достаточное время на бэкап (ночью например) и место на диске, по-моему проще использовать обычный бэкап.

AB>Дальше больше. В общем случае, бэкап занимает некоторое время. Хотелось бы для себя выбрать один из вариантов:

AB>1. При коммите новой ревизии как-то сделать бэкап только этой ревизии (к слову сказать, как это правильно сделать?).
AB>2. По расписанию (раз в сутки) делать бэкап всего репозитория.

По-моему, по расписанию удобнее, чем тратить время на написание хуков.

AB>В общем, приветствуются любые конструктивные предложения по организации бэкапа.

У меня есть bat-файл, который:
1. Стопит сервис апача
2. Делает дамп репозитория
3. Жмёт его консольным 7Zip-ом на максимум
4. Запускает обратно апач
5. .. И кладёт архив куда надо

Эта радость автоматически запускается по ночам, нормально работает и каши не просит.

Здравствуйте, Dimentiy, Вы писали:

D>Если есть достаточное время на бэкап (ночью например) и место на диске, по-моему проще использовать обычный бэкап.

Время есть время. Сегодня полный бэкап делается за 30 минут, завтра за 5 часов. Хотелось бы иметь в запасе соломку.

AB>>1. При коммите новой ревизии как-то сделать бэкап только этой ревизии (к слову сказать, как это правильно сделать?).
AB>>2. По расписанию (раз в сутки) делать бэкап всего репозитория.
D>По-моему, по расписанию удобнее, чем тратить время на написание хуков.

Мне, пока что тоже так показалось.

AB>>В общем, приветствуются любые конструктивные предложения по организации бэкапа.
D>5. .. И кладёт архив куда надо

Вот по этому поводу. На данный момент архив дампа занимает около 100 метров. 10 дней — 1 гиг. Помимо меня на сервере бэкапится все остальное. Как можно с минимальными потерями в написании "всякого от лукавого" хранить только, скажем, 31 последний бэкап? Что-то с BAT файлами у меня просто не получается.

Здравствуйте, Anton Batenev, Вы писали:

AB>Как можно с минимальными потерями в написании "всякого от лукавого" хранить только, скажем, 31 последний бэкап? Что-то с BAT файлами у меня просто не получается.

Самый примитивный вариант:

@del dump5.zip > nul 2> nul

@rename dump4.zip dump5.zip > nul 2> nul
@rename dump3.zip dump4.zip > nul 2> nul
@rename dump2.zip dump3.zip > nul 2> nul
@rename dump1.zip dump2.zip > nul 2> nul

@rem Здесь делаем дамп и архивируем его
@echo Dump contents > dump1.zip

А так, смотря что надо.

Здравствуйте, Anton Batenev, Вы писали:

AB>Hello, All!

AB>На основе деления пользователей на тех, кто не делает бэкапы и тех, кто их будет делать, возникла задача бэкапа репозитория svn. Начал разбираться с тонкостями, но так полностью и не осознал назначение ключей svnadmin dump --incremental и --deltas. Кто-нибудь может рассказать более подробно об этих ключах и особенностях их использования, что лучше делать, а чего лучше избегать?

Если --incremental не стоит, то первая ревизия в дампе будет полной, остальные будут приращениями к ней. Т.е если ты делаешь дамп с 20 по 40 без --incremental, то 20 ревизия в дампе будет полной (т.е содержать все файлы и каталоги), а все остальные будут приращениями к ней. Благодаря этому ты можешь загрузить этот дамп в любой репозиторий.

Если же стоит --incremental, то все ревизии будут записаны в дамп как приращения к предыдущему. То есть если ты сделаешь дамп с 30 по 50, то в последстивии загрузить этот дамп сможешь только поверх полноценной 29 ревизии. Это позволяет резко уменьшить размер дампа.

--deltas же означает, вместо того, чтобы записывать в дамп каждую следующую версию некоторого файла, в дамп пишутся приращения к предыдущей. Это никак не влияет на "полноценность" дампа, но просто уменьшает его размер.

AB>Дальше больше. В общем случае, бэкап занимает некоторое время. Хотелось бы для себя выбрать один из вариантов:

AB>1. При коммите новой ревизии как-то сделать бэкап только этой ревизии (к слову сказать, как это правильно сделать?).

Если хочешь после каждой ревизии бэкап — смотри в сторону хуков. Может быть даже в поставке пример идет.

AB>2. По расписанию (раз в сутки) делать бэкап всего репозитория.

AB>В общем, приветствуются любые конструктивные предложения по организации бэкапа.

Я делаю так. Каждый день выполняется инкрементный бэкап и каждую неделю — полный. Соответственно, чтобы восстановить данные как они были утром в среду среды мне нужен полный бэкап за воскресенье и инкрементные бэкапы за понедельник и вторник.

Алгоритм бэкапа таков:

1) Получаю самую последнюю ревизию через "svn youngest"

2) Проверяю файл backup-revision в каталоге репозитория.

3a) Если такой файл есть делаю "svnadmin dump --incremental --revision FROM+1:YOUNGEST", где FROM — число из файла backup-revision. Это инкрементный дамп, он может быть загружен только поверх репозитория как он есть на момент FROM.

3b) Если файла нет — делаю дамп "svnadmin dump --revision 0:YOUNGEST". Это полный бэкап — можно загружать в пустой репозиторий.

4) Записываю YOUNGEST в файл backup-revision.

Каждую неделю просто удаляю файл backup-revision, таким образом инициируя полный бэкап.

При это останавливать Апач нет необходимости. Правда, в случае если разрешены модификации свойств предыдущих ревизий (например, коммит лога), наверное, такой механизм бэкапа не подойдет.

Здравствуйте, Dimentiy, Вы писали:

AB>>Как можно с минимальными потерями в написании "всякого от лукавого" хранить только, скажем, 31 последний бэкап? Что-то с BAT файлами у меня просто не получается.
D>Самый примитивный вариант:
D>

D>@del dump5.zip > nul 2> nul
D>@rename dump4.zip dump5.zip > nul 2> nul
D>@rename dump3.zip dump4.zip > nul 2> nul
D>@rename dump2.zip dump3.zip > nul 2> nul
D>@rename dump1.zip dump2.zip > nul 2> nul
D>@rem Здесь делаем дамп и архивируем его
D>@echo Dump contents > dump1.zip
D>

Если будет интересно, то вот

Автор: Anton Batenev
Дата: 01.02.06

какое решение у меня получилось в итоге.

Здравствуйте, Anton Batenev, Вы писали:

AB>В общем, приветствуются любые конструктивные предложения по организации бэкапа.

Всем спасибо за ответы. Есть еще вопрос. У меня хранится несколько проектов на subversion.ru. Как оттуда можно снять бэкап (для, например, разворота этого бэкапа у себя и удаления там)?

Здравствуйте, Anton Batenev, Вы писали:
AB>2. По расписанию (раз в сутки) делать бэкап всего репозитория.

AB>В общем, приветствуются любые конструктивные предложения по организации бэкапа.

У нас формат FSFS я бэкаплю (на предмет забрать домой) вообще без дампа:
на svn сервере поднят ftp-сервер и я со своей машины пускаю батник.

@wget --non-verbose -m -c ftp://ppa:password@192.168.121.53:666/_disc_c/src/*
winrar.exe u 192.168.121.53.rar -m5 -as -r 192.168.121.53\*

вгет забирает все что изменилось на локальную машину, а рара обновляет архив.

В случае настоящиего бэкапа используем аналогичный скрипт, только без wget
1. Тушим апач (чтоб никто не смог менять репозиторий)
2. Запускаем rar с который перепаковывает измененые файлы.

Здравствуйте, PPA, Вы писали:

PPA>В случае настоящиего бэкапа используем аналогичный скрипт, только без wget
PPA>1. Тушим апач (чтоб никто не смог менять репозиторий)
PPA>2. Запускаем rar с который перепаковывает измененые файлы.

И все же я не могу это осознать (по поводу тушения апача). А как, например, поступают в этом случае те, кто содержит большие хостинги для subversion проектов? Если они тоже кладут сервис, то получается, что в течении времени бэкапа все курят бамбук, что не есть правильно и должно быть какое-то нормальное решение.

Здравствуйте, Anton Batenev, Вы писали:

AB>И все же я не могу это осознать (по поводу тушения апача). А как, например, поступают в этом случае те, кто содержит большие хостинги для subversion проектов? Если они тоже кладут сервис, то получается, что в течении времени бэкапа все курят бамбук, что не есть правильно и должно быть какое-то нормальное решение.

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

Здравствуйте, Anton Batenev, Вы писали:

AB>И все же я не могу это осознать (по поводу тушения апача). А как, например, поступают в этом случае те, кто содержит большие хостинги для subversion проектов? Если они тоже кладут сервис, то получается, что в течении времени бэкапа все курят бамбук, что не есть правильно и должно быть какое-то нормальное решение.

svnadmin hotcopy или svnadmin dump. Оба работают на "живом" репозитории.