Достаточно ли "hotcopy" для резервных копий SVN или я должен беспокоиться о полных и инкрементных дампах?

для моих личных вещей я просто использую svnadmin hotcopy команда один раз в неделю, но для более критически важных репозиториев, которые включают в себя многих разработчиков, этого достаточно? Или я должен потратить время, чтобы собрать более строгую стратегию резервного копирования, которая включает полные резервные копии и инкрементные резервные копии?

hotcopy кажется самым простым способом, но я хочу иметь возможность восстановить РЕПО, если по какой-то причине он будет поврежден. Будет просто делать дамп через hotcopy позвольте мне сделать это?

7
backup svn

6 ответов

вы беспокоитесь о hotcopy или вы беспокоитесь о резервном копировании только один раз в неделю?

Hotcopy создаст безопасную и полную резервную копию вашего репозитория, даже если другие процессы (ваши разработчики, например) обращаются к репозиторию одновременно. Если вы все еще не доверяете ему, закройте весь доступ к репозиторию и сделайте резервную копию, скопировав его где-нибудь с помощью обычных инструментов файловой системы. (Разработчики не собираются работать круглосуточно, являются они?)

Если вы беспокоитесь о части раз в неделю: просто подумайте о том, что произойдет, если РЕПО исчезнет за день до следующего резервного копирования. Разве это имеет значение? Если да, делайте резервные копии чаще. Все очень просто.

ваш репозиторий слишком велик, чтобы хранить несколько дней или недель полных резервных копий? Реализуйте вращающуюся схему резервного копирования, использующую полные и инкрементные резервные копии. У вас достаточно места для резервных копий? Избавить себя от хлопот и просто в полной мере копий.

12

еще одна хорошая стратегия-сохранить второй репозиторий SVN и синхронизировать его с основным с svnsync, обычно с крючком после фиксации.

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

8

я реализовал план резервного копирования для SVN 1.4 предприятия.X репозиторий (размещенный в Windows в то время), используя python скрипт svn-backup-dumps.py

Я призываю svn-backup-dump.py С post-commit hook для запуска инкрементных резервных копий для определенной ревизии. Я использовал schtasks запланировать еженедельное" полное " резервное копирование с использованием того же сценария.

восстановление (которое нам пришлось сделать дважды из-за удаления каталога с толстыми пальцами в репозитории) относительно просто: возьмите последнюю полную резервную копию, восстановите ее. Применяйте incrementals вплоть до последней ревизии.

Я не рассматривал улучшения / изменения для 1.5 в этой области, но я считаю, что аналогичный план будет хорошо работать для вас.

2

Называйте меня старой школой, но как насчет субверсии в раздел, а затем призраков по расписанию?

вариант svnsync, предложенный Davide Gualano, тоже звучит хорошо. Я склоняюсь к этой опции, чтобы предотвратить ненужное разбиение моих дисков (это может также потереть других администраторов неправильным образом и не иметь смысла в некоторых моих средах VPS).

дополнение

в последнее время я часто использую команду svnadmin 'dump'. Это работает очень похоже на mysql dump command, в том, что он экспортирует ваш репозиторий в команды BAK create. Эта команда может быть реализована как задача crontab / scheduled, а затем скопирована на внешний диск в виде файла. Пример команды:

svnadmin dump c:\svn\project > c:\dumps\project.bak

svnadmin load c:\svn\project < c:\dumps\project.bak

затем используйте robocopy / you copying tool выбора для перемещения файла в другое место. Это полезно, если вы хотите полностью переместить файлы с сервера РЕПО, Но нет внешнего доступа к subverion.

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

svnadmin create c:\svn\project

svnadmin load c:\svn\project < c:\dumps\project.bak

Это должно устранить ошибку. Возможно, Вам потребуется воссоздать или восстановить связи с Eclipse или другими проектами. Если UUID сломан, это может повлиять на других людей, использующих проект, поэтому это должно быть рассмотрено.

Вы можете использовать этот метод в качестве запасного варианта для Hotcopy. Между ними вы сможете повторить РЕПО.

С. П. Кен, похоже, svn-backup-dumps.py был перемещен сюда: http://svn.apache.org/repos/asf/subversion/trunk/tools/server-side/svn-backup-dumps.py

2

Если вы hotcopy поврежденное РЕПО поверх вашей ранее неповрежденной резервной копии, то да, вы потеряете свою неповрежденную резервную копию.

Если вы обеспокоены этим, то, как говорили другие, вам нужно повернуть резервные копии.

вы также можете организовать автоматический запуск "svnadmin verify".

1

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

0