Fazer backup completo de um repositório git?


136

Existe uma maneira simples de fazer backup de um repositório Git inteiro, incluindo todas as ramificações e tags?


2
Eu acho que você está se referindo a um repositório local do git aqui.
Ztyx


3
A resposta correta é fazer um: git clone --mirror git@example.com/your-repo.git Isso irá copiar todo o seu repositório, notas, ramos, rastreamento, etc.
John

Fiz algumas pesquisas na web que não incluíam essa pergunta em seus resultados: "git clone absolutamente tudo que é ramificado"; "git clona tudo no repositório"; "git clona um repositório com todas as notas das tags".
#

Respostas:


64

Que tal fazer um clone disso?

git clone --mirror other/repo.git

Todo repositório é um backup do seu controle remoto.


7
@ Daniel: Se você clonar um repositório, você buscará todos os ramos, mas apenas o padrão será verificado. Tente git branch -a. Talvez seja mais óbvio assim: Após a clonagem de um repositório, você não busca todos os ramos, mas todos os commit. As ramificações fazem referência apenas a uma confirmação existente.
KingCrunch

1
Eu acho que ele conhece bem o comando clone, se ele pode fazer uma pergunta dessas, e claramente não é suficiente para ele (porque é um clone e não um despejo). Os despejos são coisas diferentes das cópias simples, por exemplo: 1) eles não precisam ser ótimos (ou mesmo capazes) para o trabalho normal 2), mas precisam ter uma boa resistência e capacidade de reparo contra corrupção de dados.
peterh - Restabelece Monica

@ Peter Claro, mas git clonecobre tudo isso. (1) é opcional, não é um requisito. Se o resultado ainda estiver otimizado, ainda será um backup (2) já coberto pelo próprio git. - O ponto que gostaria de mencionar é que, se git clonejá abordamos os pontos relevantes, para o que você precisa de uma ferramenta diferente? Embora eu prefira também git bundle, não acho que minha resposta seja errada ou inválida. Você pode ver as duas abordagens como backup a quente ou a frio.
precisa saber é o seguinte

e as permissões de arquivo? o clone git necessariamente copia esses arquivos? depende das opções que acredito
antirealm

192
git bundle

Eu gosto desse método, pois resulta em apenas um arquivo, mais fácil de copiar.
Veja ProGit: pequeno pacote de alegria .
Consulte também " Como posso enviar um repositório git para alguém por e-mail? ", Onde o comando

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

é detalhado:

git bundleempacotará apenas referências que são mostradas pelo git show-ref : isso inclui cabeças, tags e cabeças remotas.
É muito importante que a base usada seja mantida pelo destino.
É bom errar por precaução, fazendo com que o arquivo do pacote contenha objetos que já estão no destino, pois eles são ignorados ao descompactar no destino.


Para usar esse pacote, você pode cloná-lo, especificando uma pasta inexistente (fora de qualquer repositório git):

git clone /tmp/foo-all newFolder

11
adicione --todos para backup completo
consulte

1
Esta git bundleé a resposta correta na minha opinião, e não a aceita. Eu acho que ele conhece bem o comando clone, se ele pode fazer uma pergunta dessas, e claramente não é suficiente para ele (porque é um clone e não um despejo). Os despejos são coisas diferentes das cópias simples, por exemplo: 1) eles não precisam ser ótimos (ou mesmo capazes) para o trabalho normal 2) mas precisam ter uma boa resistência e capacidade de reparo contra corrupção de dados 3) Geralmente é útil se eles são facilmente flexíveis para backups incrementais, embora não seja um objetivo nas cópias.
peterh - Restabelece Monica

3
Note-se que nem git bundleou git clonefica tudo , por exemplo, os scripts de gancho.
Zitrax

2
@Zitrax Sim, é por design. Os ganchos podem ser perigosos ou incluir informações confidenciais.
VonC

Posso usar git bundleem um repositório remoto?
Ryan Shillington

24

Expandindo algumas outras respostas, é isso que eu faço:

Configure o repositório: git clone --mirror user@server:/url-to-repo.git

Então, quando você deseja atualizar o backup: git remote updatedo local do clone.

Isso faz o backup de todas as ramificações e tags, incluindo as novas que são adicionadas posteriormente, embora seja interessante notar que as ramificações excluídas não são excluídas do clone (o que para um backup pode ser uma coisa boa).

Isso é atômico e, portanto, não tem os problemas que uma cópia simples teria.

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


20

Expandindo as ótimas respostas de KingCrunch e VonC

Eu combinei os dois:

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

Depois disso, você tem um arquivo chamado reponame.bundleque pode ser facilmente copiado. Você pode criar um novo repositório git normal a partir dele git clone reponame.bundle reponame.

Observe que git bundleapenas cópias confirmadas levam a alguma referência (ramificação ou tag) no repositório. Portanto, as confirmações de emaranhamento não são armazenadas no pacote.


1
Bom resumo. +1.
VonC 04/01/19

2
Eu acho que você quis dizer git bundle create reponame.bundle --all?
joe

Obrigado @joe por perceber isso. Definitivamente. Eu atualizarei a resposta.
Kimmo Ahokas

4

Tudo está contido no .gitdiretório Faça o backup do seu projeto como faria com qualquer arquivo.


2
Isso significa que apenas fazer o backup de TODO o conteúdo do diretório que contém o projeto Git é suficiente?
Ravindranath Akila,

1
Concordou com Sunil - isso não parece ser uma operação atômica.
jia103

1
E como você garante que nenhuma alteração seja feita nos arquivos desse diretório ao criar o backup?
Raedwald

Como Raedwald sugeriu, esse método pode resultar em um backup inconsistente e, portanto, levar à perda de dados. Portanto, essa resposta deve ser removida ou, no mínimo, alertar sobre a possibilidade de perda de dados.
Abhishek Anand

Eu acho que ele conhece copyou cpcomanda muito bem e não atende às suas necessidades. E também acho que ele pensa em um repositório vazio (embora possa ser copiado também, acho que não é um backup completo).
peterh - Restabelece Monica

4

use git bundle ou clone

copiar o diretório git não é uma boa solução, pois não é atômico. Se você tiver um repositório grande que leva muito tempo para copiar e alguém envia para o repositório, isso afetará o backup. A clonagem ou criação de um pacote configurável não terá esse problema.


3

Você pode fazer backup do repositório git com git-copy no tamanho mínimo de armazenamento.

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

Em seguida, você pode restaurar seu projeto com git clone

git clone /backup/project.repo.backup project

2
github.com/cybertk/git-copy/blob/master/bin/git-copy#L8-L36 : isso parece muito trabalho para um simples git clone --bare+ git push --force.
VonC 3/15/15

@VonC Sim, mas pode ter algum recurso adicional durante a reembalagem, ou pode explorar a estrutura interna do repositório git, que pode ser usada para alguma otimização (reestruturação do destino ou aumento de velocidade, etc.).
peterh - Restabelece Monica

3

A resposta correta IMO é git clone --mirror . Isso fará um backup completo do seu repositório.

O espelho de clone do Git clonará todo o repositório, notas, cabeças, refs, etc. e é normalmente usado para copiar um repositório inteiro para um novo servidor git. Isso abrirá todos os ramos e tudo, todo o repositório.

git clone --mirror git@example.com/your-repo.git
  • Normalmente, a clonagem de um repositório não inclui todas as ramificações, apenas o Mestre.

  • Copiar a pasta de repo apenas "copiará" as ramificações que foram puxadas ... então, por padrão, isso é apenas ramificação mestre ou outras ramificações que você efetuou check-out anteriormente.

  • O comando Git bundle também não é o que você deseja: "O comando bundle empacotará tudo o que normalmente seria enviado por fio com um comando git push em um arquivo binário que você pode enviar por e-mail para alguém ou colocar em uma unidade flash, e então desmembrar em outro repositório ". (De Qual é a diferença entre git clone --mirror e git clone --bare )


O git clone --mirror cria um backup point-in-time consistente? O que um usuário envia uma confirmação durante o backup? É rejeitado, enfileirado ou incorporado ao backup?
Benjamin Goodacre

3

Esse encadeamento foi muito útil para obter algumas idéias de como os backups dos repositórios git poderiam ser feitos. Acho que ainda faltam algumas dicas, informações ou conclusões para encontrar o "caminho correto" (tm) para si mesmo. Portanto, compartilho meus pensamentos aqui para ajudar outras pessoas e colocá-las em discussões para melhorá-las. Obrigado.

Então, começando com a pergunta original:

  • O objetivo é chegar o mais próximo possível de um backup "completo" de um repositório git.

Depois, enriquecendo-o com os desejos típicos e especificando algumas predefinições:

  • O backup através de uma "cópia a quente" é o preferido para evitar o tempo de inatividade do serviço.
  • As falhas do git serão contornadas por comandos adicionais.
  • Um script deve fazer o backup para combinar as várias etapas de um único backup e evitar erros humanos (erros de digitação, etc.).
  • Além disso, um script deve fazer a restauração para adaptar o dump à máquina de destino, por exemplo, mesmo a configuração da máquina original pode ter sido alterada desde o backup.
  • O Environment é um servidor git em uma máquina Linux com um sistema de arquivos que suporta hardlinks.

1. O que é um backup de repositório git "completo"?

O ponto de vista difere do que é um backup "100%". Aqui estão dois típicos.

Nº 1 do ponto de vista do desenvolvedor

  • Conteúdo
  • Referências

O git é uma ferramenta de desenvolvedor e suporta esse ponto de vista via git clone --mirrore git bundle --all.

# 2 Ponto de vista do administrador

  • Arquivos de conteúdo
    • Caso especial "packfile": o git combina e compacta objetos em arquivos de pacote durante a coleta de lixo (veja git gc)
  • configuração git
  • Opcional: configuração do sistema operacional (permissões do sistema de arquivos etc.)

O git é uma ferramenta de desenvolvedor e deixa isso para o administrador. O backup da configuração do git e da configuração do sistema operacional deve ser visto como separado do backup do conteúdo.

2. Técnicas

  • "Cópia a frio"
    • Pare o serviço para ter acesso exclusivo aos seus arquivos. Tempo de inatividade!
  • "Cópia a quente"
    • O serviço fornece um estado fixo para fins de backup. As mudanças em andamento não afetam esse estado.

3. Outros tópicos para pensar

A maioria deles é genérica para backups.

  • Existe espaço suficiente para armazenar os backups completos? Quantas gerações serão armazenadas?
  • É necessária uma abordagem incremental? Quantas gerações serão armazenadas e quando criar um backup completo novamente?
  • Como verificar se um backup não está corrompido após a criação ou ao longo do tempo?
  • O sistema de arquivos suporta hardlinks?
  • Colocar o backup em um único arquivo ou usar a estrutura de diretórios?

4. O que o git fornece para fazer backup de conteúdo

  • git gc --auto

    • docs: man git-gc
    • Limpa e compacta um repositório.
  • git bundle --all

    • docs: man git-bundle, man git-rev-list
    • Atomic = "Cópia a quente"
    • Pacotes são arquivos de despejo e podem ser usados ​​diretamente com o git (verificar, clonar etc.).
    • Suporta extração incremental.
    • Verificável via git bundle verify.
  • git clone --mirror

    • docs: man git-clone, man git-fsck, qual é a diferença entre git clone --mirror e git clone --bare
    • Atomic = "Cópia a quente"
    • Os espelhos são repositórios reais do git.
    • A intenção principal deste comando é construir um espelho ativo completo, que busca atualizações periodicamente no repositório original.
    • Suporta hardlinks para espelhos no mesmo sistema de arquivos para evitar desperdiçar espaço.
    • Verificável via git fsck.
    • Os espelhos podem ser usados ​​como base para um script de backup completo de arquivos.

5. Cópia a frio

Um backup de cópia a frio sempre pode fazer um backup completo de arquivos: negar todos os acessos aos repositórios git, fazer backup e permitir acessos novamente.

  • Possíveis Questões
    • Pode não ser fácil - ou até possível - negar todos os acessos, por exemplo, acesso compartilhado via sistema de arquivos.
    • Mesmo se o repositório estiver em uma máquina somente cliente com um único usuário, o usuário ainda poderá confirmar algo durante uma execução de backup automatizada :(
    • O tempo de inatividade pode não ser aceitável no servidor e fazer um backup de vários repositórios enormes pode levar muito tempo.
  • Ideias para Mitigação:
    • Evite o acesso direto ao repositório via sistema de arquivos em geral, mesmo se os clientes estiverem na mesma máquina.
    • Para acesso SSH / HTTP, use gerenciadores de autorização git (por exemplo, gitolite) para gerenciar dinamicamente o acesso ou modificar arquivos de autenticação de maneira com script.
    • Os repositórios de backup são individualizados para reduzir o tempo de inatividade de cada repositório. Negue um repositório, faça backup e permita acesso novamente e continue com o próximo repositório.
    • Planeje o cronograma de manutenção para evitar transtornos aos desenvolvedores.
    • Faça backup somente quando o repositório for alterado. Talvez seja muito difícil de implementar, por exemplo, lista de objetos, além de ter arquivos de pacotes em mente, somas de verificação de configurações e ganchos, etc.

6. Cópia a quente

Os backups de arquivos não podem ser feitos com repositórios ativos devido ao risco de dados corrompidos por confirmações contínuas. Uma cópia a quente fornece um estado fixo de um repositório ativo para fins de backup. As confirmações contínuas não afetam essa cópia. Conforme listado acima, as funcionalidades de clone e pacote configurável do git suportam isso, mas para um backup "100% admin" várias coisas precisam ser feitas por meio de comandos adicionais.

Backup de cópia a quente "100% admin"

  • Opção 1: use git bundle --allpara criar arquivos de despejo completo / incremental de conteúdo e copiar / fazer backup dos arquivos de configuração separadamente.
  • Opção 2: use git clone --mirror, manipule e copie a configuração separadamente e faça o backup completo dos arquivos do espelho.
    • Notas:
    • Um espelho é um novo repositório, preenchido com o modelo git atual na criação.
    • Limpe os arquivos e diretórios de configuração e copie os arquivos de configuração do repositório de origem original.
    • O script de backup também pode aplicar a configuração do SO, como permissões de arquivo no espelho.
    • Use um sistema de arquivos que suporte hardlinks e crie o espelho no mesmo sistema de arquivos do repositório de origem para ganhar velocidade e reduzir o consumo de espaço durante o backup.

7. Restaurar

  • Verifique e adote a configuração git para atingir a máquina e a mais recente filosofia de "maneira de fazer".
  • Verifique e adote a configuração do sistema operacional para atingir a máquina e a mais recente filosofia de "maneira de fazer".

0
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

isso cria um backup e faz a configuração, para que você possa executar um git push para atualizar seu backup, o que provavelmente é o que você deseja fazer. Apenas certifique-se de que / path / to / backupdir e / path / to / repo sejam pelo menos diferentes discos rígidos, caso contrário, não faz muito sentido fazer isso.


Eu acho que ele conhece bem o comando clone, se ele pode fazer uma pergunta dessas, e claramente não é suficiente para ele (porque é um clone e não um despejo). Os despejos são coisas diferentes das cópias simples, por exemplo: 1) eles não precisam ser ótimos (ou mesmo capazes) para o trabalho normal 2) mas precisam ter uma boa resistência e capacidade de reparo contra corrupção de dados 3) Geralmente é útil se eles são facilmente flexíveis para backups incrementais, embora não seja um objetivo nas cópias.
peterh - Restabelece Monica

0

Aqui estão duas opções:

  1. Você pode pegar diretamente um tar do diretório git repo, pois ele tem todo o conteúdo do repositório no servidor. Há uma pequena possibilidade de que alguém possa estar trabalhando no repo enquanto faz backup.

  2. O comando a seguir fornecerá o clone simples de repo (exatamente como no servidor), e você poderá obter um tar do local em que você clonou sem nenhum problema.

    git clone --bare {your backup local repo} {new location where you want to clone}
    

Eu acho que ele conhece bem o comando clone ou tar, se ele pode fazer essa pergunta, e claramente não é suficiente para ele (porque é um clone e não um despejo). Os despejos são coisas diferentes das cópias simples, por exemplo: 1) eles não precisam ser ótimos (ou mesmo capazes) para o trabalho normal 2) mas precisam ter uma boa resistência e capacidade de reparo contra corrupção de dados 3) Geralmente é útil se eles são facilmente diferentes para backups incrementais, embora não seja um objetivo nas cópias.
peterh - Restabelece Monica

3
Definitivamente, ele não estava pedindo comando de alcatrão ou clone. Se você olhar de perto, eu também não estava explicando esses comandos. O que eu estava tentando explicar é o backup do Git através de um método diferente, que pode incluir vários comandos do Linux, o que não significa que estou ensinando esses comandos do Linux. Estou tentando colocar algumas idéias aqui.
Vishal sahasrabuddhe

0

Se estiver no Github, navegue até o bitbucket e use o método "import repository" para importar seu repositório do github como um repositório particular.

Se estiver no bitbucket, faça o contrário.

É um backup completo, mas permanece na nuvem, que é o meu método ideal.


-7

Até onde eu sei, você pode simplesmente fazer uma cópia do diretório em que seu repositório está, é isso!

cp -r project project-backup

Alguém pode confirmar isso? Eu sinto que esta é a abordagem correta para fazer um backup adequado.
Ravindranath Akila,

5
Eu acho que você pode acabar com um instantâneo inconsistente quando, durante a operação de cópia, as alterações são confirmadas / enviadas ao repositório. Usar comandos git como git clone --barefornecerá um instantâneo consistente.
Eelke

1
Concordou com Sunil - isso não parece ser atômico.
jia103

1
@ jia103 Nem sempre é um problema se não é atômico - você só precisa saber e ser capaz de garantir que ninguém mais possa acessar o repositório enquanto estiver trabalhando nele. Mas acho que o OP quer uma ferramenta específica, para git repos otimizada para a tarefa, provavelmente uma cópia simples de arquivo é bem conhecida por ele.
peterh - Restabelece Monica
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.