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

Question

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

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

Answer 1

Вы беспокоитесь о горячей копии или беспокоитесь о резервном копировании только раз в неделю?

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

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

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

Answer 2

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

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

Answer 3

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

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

Добавление

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

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

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

Затем используйте robocopy / ваш инструмент копирования, чтобы переместить файл в другое место. Это полезно, если вы хотите полностью переместить файлы с сервера репо, но внешний доступ к subverion отсутствует.

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

svnadmin create c:\svn\project

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

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

Вы можете использовать этот метод как запасной вариант для Hotcopy. Между ними вы сможете восстановить репо.

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

Answer 4

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

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

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

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

Answer 5

Если вы скопируете поврежденное хранилище поверх поверх вашей ранее неиспорченной резервной копии, тогда да, вы потеряете свою неиспорченную резервную копию.

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

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

Answer 6

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