На здоровье не экономят! Особенно на нервах и особенно на нервах начальства ;)
Задача:
- перенести репозитории на другой сервер и одновременно обновить subversion и соответственно формат репозиториев;
- настроить резервное копирование.
Решение:
Миграция
В принципе первый пункт в инете освещён (достаточно лишь погуглить):
- на исходном сервере делаем дамп:
svnadmin dump REPOS_PATH_1 > svn.dump
- копируем дамп на новый сервер и создаем чистый репозиторий:
svnadmin create REPOS_PATH_2 - восстанавливаем из дампа:
svnadmin load REPOS_PATH_2 < svn.dump
- если при таком переносе изменился URL репозитория, то для всех рабочих копий необходимо сделать:
svn switch --relocate FROM TO
Резервное копирование
Со вторым пунктом сложней, так как всяческие руководства предлагают различные подходы, да еще и частота может варьироваться (от бэкапа по cron’у до бэкапа по hook’у):
- full backup при помощи svn-hot-backup;
- incremental backup при помощи dump;
- full backup при помощи rsync.
Все подходы обладают своими плюсами и минусами. Последний вариант я нашёл на русскоязычном gentoo wiki и он меня совсем не радует, т.к. копированием (пусть даже с помощью rsync) бэкап делать не рекомендуется (если конечно нет полной уверенности, что во время бэкапа никто не будет ничего делать с самим репозиторием).
Для меня критичными факторами при выборе подхода к резервному копированию стали:
- размер бэкапа (передача по сети + скорее всего придётся раз в месяц закатывать бэкап на болванку);
- время, затрачиваемое на восстановление из бэкапа (не дай бог, но грозит простоем в работе);
- время, требуемое на создание бэкапа.
Немного статистики
Подопытные:
AMD Opteron Dual Core 1.8GHz
Репозиторий: svn 1.4.6 (r28521), размер = 1082095 byte ≈ 1.1 Gb; количество ревизий = 7424.
Результат:
Полный dump: размер = 1995399 ≈ 2 Gb; время выполнения = 2m40.919s.
Время восстановления из dump’а = 28m8.881s.
svn-hot-backup:
| Сжатие | Размер (byte) | Время выполнения |
|---|---|---|
| без сжатия | 1082095 | 1m39.870s |
| bz2 | 978042 | 10m52.235s |
| gz | 979500 | 3m4.946s |
| zip | 989585 | 3m27.555s |
Вывод
Если делать инкрементальный бэкап при помощи svnadmin dump, то получаем большое время на восстановление – не есть гуд.
Сжатие при hot-backup кажется бессмысленным – проигрыш во времени и почти никакого выигрыша в размере.
Вообще, никто не мешает на каждом commit’е делать svn-hot-backup и получать уже готовую к работе копию, но это имхо уже паранойя перебор.
Лично мне нравится вариант – раз в сутки делать hot-backup (можно еще на каждом commit’е делать dump последней ревизии). Прописываем в cron.daily:
SVN_HOTBACKUP_BACKUPS_NUMBER=2 /usr/bin/svn-hot-backup /var/svn/repo/ /var/svn/backups/
Переменная окружения SVN_HOTBACKUP_BACKUPS_NUMBER отвечает за количество бэкапов, которые необходимо сохранять (если не ноль, то старые постепенно удаляются). Ну а дальше хоть при помощи rsync на другой комп заливай, хоть на болванку катай…
