Какой хороший и простой способ сделать резервную копию репозитория SVN на FTP-сервер?

Question

Я бы хотел сделать резервную копию моего репозитория SVN, используя tar и ftp из cronjob один раз в день. Это довольно просто, но я хотел бы убедиться, что во время резервного копирования не выполняется коммит и т. Д. Хотя бывают моменты дня и ночи, когда это маловероятно, но я бы предпочел не полагаться на это, потому что, если я уже проснулся ночью в какой-то момент, последнее, что мне нужно, - это получение SVN или резервное копирование испортил.

Я ищу очень простую, но эффективную защиту. Это нормально, если клиенты SVN получают ошибку во время выполнения резервного копирования (это не займет много времени). Должен ли я использовать

• что-то на уровне файловой системы
• некоторый скрипт SVN-хука
• что-то еще целиком

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

Answer 1

Теоретическим способом безопасного резервного копирования является использование команды svnadmin hotcopy ( подробнее здесь ). Он в основном делает копию одного репозитория (не dump , copy ), стараясь заблокировать все операции за это время.

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

Пример сценария можно найти на веб-сайте Apache Subversion Project .

Если вы сделаете дамп, помимо огромного времени, вы не будете уверены, что это будет сделано атомарно. Отвалы полезны для

• убедитесь, что вы можете перейти с одной версии на другую - подумайте о долгосрочных резервных копиях. Например, если ваш сервер обновлен с версии 1.4 до 1.5 или до 1.6, интересно сделать дамп, а затем загрузить ваши репозитории, чтобы в полной мере воспользоваться преимуществами улучшений. В некоторых более радикальных обновлениях это необходимо, потому что формат хранилища слишком сильно меняется.
• отфильтровывать файлы или объединять репозитории, это более сложные операции, не по теме здесь.

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

Answer 2

svnadmin dump /path/to/repo > repobackup_date

Теперь вы можете запускать tar, gzip, что угодно на repobackup_date, и svnadmin должен позаботиться об управлении доступом к хранилищу для вас.

Для восстановления используйте svnadmin load /path/to/repo < repobackup_date.

Answer 3

Я делаю это для всех моих производственных SVN-репозиториев.

Вы всегда должны использовать svn dump, чтобы сделать однофайловую резервную копию вашего хранилища. Это гарантирует отсутствие грязных транзакций в полете, которые могут повредить копию файловой системы. Затем просто используйте ваше любимое приложение ftp, чтобы скопировать файл.

Я предлагаю сначала запустить результаты от svn dump до gzip или какой-либо другой программы архивации.

Answer 4

Я бы рекомендовал использовать этот инструмент svn-backup . Он объединяет в себе лучшие из полных и инкрементных резервных копий репозитория и будет генерировать только один файл резервной копии на репозиторий, независимо от того, сколько раз он запущен или сколько ревизий находится в репозитории. Этот конкретный сценарий будет работать намного быстрее, чем обычный дамп svnadmin, поскольку он создает только дополнительные ревизии с момента последнего резервного копирования.

Я использовал этот сценарий, чтобы сократить время резервного копирования очень активного сервера Subversion с 8+ часов до ~ 20 минут. После завершения резервного копирования вы можете загрузить его на FTP-сервер.

Answer 5

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

Answer 6

Используйте svnadmin dump для резервного копирования, затем cURL для загрузки по FTP.