Полностью сделать резервную копию git-репо?

Есть ли простой способ сделать резервную копию всего репозитория git, включая все ветви и теги?

Источник

14 ответов

Решение

Как насчет просто сделать его клоном?

git clone --mirror other/repo.git

Каждый репозиторий является резервной копией своего удаленного.

Источник 
git bundle

Мне нравится этот метод, так как в результате получается всего один файл, который легче копировать.
Смотрите ProGit: маленький пучок радости.
Смотрите также " Как я могу послать кому-нибудь письмо с git-репозиторием?", Где команда

git bundle create /tmp/foo-all --all

подробно:

git bundle будет упаковывать только те ссылки, которые отображаются с помощью git show-ref: сюда входят заголовки, теги и удаленные заголовки.
Очень важно, чтобы используемая основа удерживалась пунктом назначения.
Можно допустить ошибку, если в файле пакета содержатся объекты, уже находящиеся в месте назначения, так как они игнорируются при распаковке в месте назначения.

Для использования этого пакета вы можете клонировать его, указав несуществующую папку (вне любого git-репо):

git clone /tmp/foo-all newFolder
Источник

Расширяя великолепные ответы KingCrunch и VonC

Я объединил их обоих:

git clone --mirror git@some.origin/reponame reponame.git
cd reponame.git
git bundle reponame.bundle --all

После этого у вас есть файл с именем reponame.bundle это можно легко скопировать вокруг. Затем вы можете создать новый нормальный git-репозиторий, используя git clone reponame.bundle reponame,

Обратите внимание, что git bundle копирует только коммиты, которые ведут к некоторой ссылке (ветви или тегу) в хранилище. Таким образом, запутанные коммиты не сохраняются в связке.

Источник

Расширяя некоторые другие ответы, это то, что я делаю:

Настройте репо: git clone --mirror user@server:/url-to-repo.git

Затем, когда вы хотите обновить резервную копию: git remote update с места клона.

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

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

См. http://www.garron.me/en/bits/backup-git-bare-repo.html

Источник

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

Итак, начнем с ответа на исходный вопрос:

  • Цель состоит в том, чтобы максимально приблизиться к "полной" резервной копии репозитория git.

Затем дополнив его типичными пожеланиями и указав некоторые предварительные настройки:

  • Резервное копирование с помощью "горячего копирования" предпочтительно во избежание простоя службы.
  • Недостатки git будут устранены дополнительными командами.
  • Сценарий должен выполнять резервное копирование, чтобы объединить несколько шагов для одного резервного копирования и избежать человеческих ошибок (опечаток и т. Д.).
  • Кроме того, сценарий должен выполнить восстановление для адаптации дампа к целевой машине, например, даже конфигурация исходной машины могла измениться с момента резервного копирования.
  • Среда - это git-сервер на Linux-машине с файловой системой, поддерживающей жесткие ссылки.

1. Что такое "полная" резервная копия репозитория git?

Есть разные точки зрения на то, что такое "100%" резервное копирование. Вот два типичных.

# 1 точка зрения разработчика

  • Содержание
  • Ссылки

git - это инструмент разработчика, который поддерживает эту точку зрения через git clone --mirror а также git bundle --all.

#2 точка зрения администратора

  • Файлы содержимого
    • Особый случай "packfile": git объединяет и сжимает объекты в packfile во время сборки мусора (см. git gc)
  • конфигурация git
    • см. https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain
    • документы: человек git-config, человек gitignore
    • .git / config
    • .git / description (для хуков и инструментов, например, после получения электронной почты, gitolite, GitWeb и т. д.)
    • .git / крючки /
    • .git / info/ (файл исключения репозитория и т. д.)
  • Необязательно: конфигурация ОС (разрешения файловой системы и т. Д.)

git - это инструмент разработчика, который оставляет это администратору. Резервное копирование конфигурации git и конфигурации ОС следует рассматривать отдельно от резервной копии содержимого.

2. Методы

  • "Холодная копия"
    • Остановите службу, чтобы получить монопольный доступ к ее файлам. Время простоя!
  • "Горячее копирование"
    • Сервис предоставляет фиксированное состояние для целей резервного копирования. Текущие изменения не влияют на это состояние.

3. Другие темы для размышлений

Большинство из них являются универсальными для резервного копирования.

  • Достаточно ли места для хранения полных резервных копий? Сколько поколений сохранится?
  • Требуется ли поэтапный подход? Сколько поколений будет сохранено и когда снова создать полную резервную копию?
  • Как убедиться, что резервная копия не повреждена после создания или с течением времени?
  • Поддерживает ли файловая система жесткие ссылки?
  • Поместить резервную копию в один архивный файл или использовать структуру каталогов?

4. Что git предоставляет для резервного копирования содержимого

  • git gc --auto

    • документы: человек git-gc
    • Очищает и уплотняет репозиторий.

  • git bundle --all

    • документы: man git-bundle, man git-rev-list
    • Atomic = "Горячая копия"
    • Пакеты представляют собой файлы дампа и могут напрямую использоваться с git (проверять, клонировать и т. Д.).
    • Поддерживает инкрементное извлечение.
    • Проверяется через git bundle verify.

  • git clone --mirror

    • документы: man git-clone, man git-fsck, В чем разница между git clone --mirror и git clone --bare
    • Atomic = "Горячая копия"
    • Зеркала - это настоящие репозитории git.
    • Основная цель этой команды - создать полное активное зеркало, которое периодически извлекает обновления из исходного репозитория.
    • Поддерживает жесткие ссылки для зеркал в той же файловой системе, чтобы не тратить лишнее место.
    • Проверяется через git fsck.
    • Зеркала можно использовать как основу для сценария полного резервного копирования файлов.

5. Холодное копирование

Резервное копирование с холодным копированием всегда может выполнить полное резервное копирование файла: запретить любой доступ к репозиториям git, выполнить резервное копирование и снова разрешить доступ.

  • Возможные проблемы
    • Может быть непросто - или даже невозможно - запретить любой доступ, например общий доступ через файловую систему.
    • Даже если репо находится на клиентской машине с одним пользователем, пользователь все равно может что-то зафиксировать во время автоматического резервного копирования:(
    • Время простоя сервера может быть неприемлемым, а резервное копирование нескольких огромных репозиториев может занять много времени.
  • Идеи по смягчению:
    • Запретите прямой доступ к репо через файловую систему в целом, даже если клиенты находятся на одном компьютере.
    • Для доступа по SSH/HTTP используйте менеджеры авторизации git (например, gitolite) для динамического управления доступом или изменения файлов аутентификации по сценарию.
    • Резервное копирование репозиториев одно за другим, чтобы сократить время простоя для каждого репо. Запретите одно репо, сделайте резервную копию и снова разрешите доступ, а затем перейдите к следующему репо.
    • Составьте график технического обслуживания, чтобы не расстраивать разработчиков.
    • Только резервное копирование при изменении репозитория. Может быть, очень сложно реализовать, например, список объектов плюс наличие файлов пакетов, контрольные суммы конфигурации и перехватов и т. Д.

6. Горячее копирование

Резервные копии файлов не могут быть выполнены с активными репозиториями из-за риска повреждения данных в результате текущих коммитов. Горячая копия обеспечивает фиксированное состояние активного репозитория для целей резервного копирования. Текущие коммиты не влияют на эту копию. Как указано выше, функции git clone и bundle поддерживают это, но для резервного копирования "100% администратора" необходимо выполнить несколько действий с помощью дополнительных команд.

Резервное копирование "100% админ" с горячим копированием

  • Вариант 1: использовать git bundle --all для создания файлов полного / инкрементного дампа содержимого и раздельного копирования / резервного копирования файлов конфигурации.
  • Вариант 2: использовать git clone --mirror, обработайте и скопируйте конфигурацию отдельно, затем сделайте полную резервную копию файла зеркала.
    • Заметки:
    • Зеркало - это новый репозиторий, который при создании заполняется текущим шаблоном git.
    • Очистите файлы конфигурации и каталоги, затем скопируйте файлы конфигурации из исходного репозитория.
    • Сценарий резервного копирования также может применять конфигурацию ОС, например права доступа к файлам на зеркале.
    • Используйте файловую систему, которая поддерживает жесткие ссылки, и создайте зеркало в той же файловой системе, что и исходный репозиторий, чтобы увеличить скорость и уменьшить потребление пространства во время резервного копирования.

7. Восстановить

  • Проверьте и примените конфигурацию git для целевой машины и последней философии "способа работы".
  • Проверьте и адаптируйте конфигурацию ОС к целевой машине и последней философии "способа работы".
Источник

Правильный ответ IMO - git clone --mirror. Это полностью сделает резервную копию вашего репо.

Git clone mirror клонирует весь репозиторий, заметки, заголовки, ссылки и т. Д. И обычно используется для копирования всего репозитория на новый git-сервер. Это уничтожит все ветки и все, весь репозиторий.

git clone --mirror git@example.com/your-repo.git

  • Обычно клонирование репо не включает все ветви, только Мастер.

  • Копирование папки репо будет "копировать" только те ветки, которые были извлечены... поэтому по умолчанию это только ветка Master или другие ветки, которые вы извлекли ранее.

  • Команда Git bundle также не то, что вам нужно: "Команда bundle упакует все, что обычно передается по проводам, с помощью команды git push в двоичный файл, который вы можете отправить кому-либо по электронной почте или поместить на флэш-диск, а затем распаковать в другое хранилище." (В чем разница между git clone --mirror и git clone --bare)

Источник

Использовать git bundle или клонировать

копирование каталога git не является хорошим решением, поскольку оно не является атомарным. Если у вас большой репозиторий, копирование которого занимает много времени, и кто-то отправляет его в ваш репозиторий, это повлияет на резервное копирование. Клонирование или создание пакета не будет иметь этой проблемы.

Источник

Все содержится в .git каталог. Просто сохраните это вместе с вашим проектом, как любой файл.

Источник

Вы можете сделать резервную копию git-репозитория с помощью git-copy с минимальным объемом хранилища.

git copy /path/to/project /backup/project.repo.backup

Затем вы можете восстановить свой проект с git clone

git clone /backup/project.repo.backup project
Источник

Существует очень простой в использовании инструмент Python, который автоматически создает резервные копии репозиториев организаций в формате .zip, сохраняя общедоступные и частные репозитории и все их филиалы. Он работает с API Github: https://github.com/BuyWithCrypto/OneGitBackup.

Источник

Вот два варианта:

  1. Вы можете напрямую взять tar из каталога git repo, так как он содержит все содержимое репо на сервере. Существует небольшая вероятность того, что кто-то может работать над репо во время резервного копирования.

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

    git clone --bare {your backup local repo} {new location where you want to clone}
Источник 
cd /path/to/backupdir/
git clone /path/to/repo
cd /path/to/repo
git remote add backup /path/to/backupdir
git push --set-upstream backup master

это создаст резервную копию и выполнит настройку, так что вы можете сделать git push, чтобы обновить резервную копию, что, вероятно, вы и хотите сделать. Просто убедитесь, что / path / to / backupdir и / path / to / repo - это как минимум разные жесткие диски, в противном случае это не имеет особого смысла.

Источник

Если он находится на Github, перейдите к bitbucket и используйте метод "импорта репозитория", чтобы импортировать репозиторий github как частный репозиторий.

Если это в битбакете, сделайте наоборот.

Это полная резервная копия, но она остается в облаке, что является моим идеальным методом.

Источник

Насколько я знаю, вы можете просто сделать копию каталога, в котором находится ваш репо, и все!

cp -r project project-backup
Источник
Другие вопросы по тегам