Hg ( Merculrial) Политика резервного копирования
У нас есть более 500 хранилищ Hg, и мы ищем быстрое и эффективное резервное копирование. Есть ли сценарий или инструмент, который мы можем использовать для резервного копирования этих хранилищ. Мы попробовали Hg bundle, hg clone и обычное резервное копирование файловой системы, но они не помогают.
Существует ли стандартная практика или некоторая документация для политики резервного копирования репозиториев Hg?
Дополнительный вопрос: что произойдет, когда пользователь будет нажимать на набор изменений, и мы начнем резервное копирование?
Мы используем RhodeCode для публикации репозиториев Hg. Спасибо
2 ответа
Там нет стандарта. Снимок истинного уровня FS, сделанный во время push, будет в порядке, но немедленное зеркальное копирование (рекурсивное копирование) может привести к поврежденному репо, хотя его можно будет восстановить до состояния pre-push.
В прошлом я делал что-то простое:
for repo in $(find /srv/repos -type d -name .hg | sed 's/\.hg$//') ; do
hg --cwd $repo --repository $repo push ssh://backupserver/$(basename $repo)
done
Это постепенно отправляет все репозитории на удаленный ssh-сервер с полным обновлением и сохранением целостности, создавая их при необходимости.
У меня есть несколько похожее решение клонирования / извлечения с сервера резервного копирования, но я запускаю резервное копирование на крюке hg.
На главном сервере глобальный hgrc
, Я имею:
changegroup.backup = .../backup.sh
И в backup.sh
что-то вроде:
REPO=`hg root`
ts sshpass -p '...' ssh hg@backupserver "~/bin/pull.exp $REPO" 2>> $LOG
Ts (диспетчер задач) позволяет операции выполняться асинхронно. Ожидаемый скрипт обрабатывает тот факт, что хранилище может быть новым (таким образом, выполняя hg clone --noupdate
) или уже существует (таким образом выполняя hg pull
) и также может дать ключу ssh пароль по запросу.
Нажатие на второй сервер разрешено только для резервного копирования, поэтому не может возникнуть проблема с несколькими головками или необходимым усилием.
Что мне нравится в этом типе резервного копирования в реальном времени, так это то, что в случае сбоя основного сервера он должен быть гораздо быстрее переключаться на резервный.