Esiste un modo semplice per eseguire il backup di un intero repository git compresi tutti i rami e i tag?

Che ne dici di farne un clone?

git clone --mirror other/repo.git

Ogni repository è un backup del suo telecomando.

git bundle

Mi piace quel metodo, in quanto risulta in un solo file, più facile da copiare.
Vedi ProGit: piccolo fascio di gioia .
Vedi anche " Come posso inviare a qualcuno un repository git? ", Dove è il comando

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

è dettagliato:

git bundleimpacchetterà solo i riferimenti mostrati da git show-ref : questo include head, tag e head remoti.
È molto importante che la base utilizzata sia detenuta dalla destinazione.
Va bene sbagliare sul lato della cautela, facendo sì che il file bundle contenga oggetti già nella destinazione, poiché questi vengono ignorati quando si decomprime nella destinazione.

Per usare quel bundle, puoi clonarlo, specificando una cartella inesistente (al di fuori di qualsiasi repository git):

git clone /tmp/foo-all newFolder

Espandendo su alcune altre risposte, questo è quello che faccio:

Imposta il repository: git clone --mirror user@server:/url-to-repo.git

Quindi, quando si desidera aggiornare il backup: git remote update dalla posizione del clone.

Questo esegue il backup di tutti i rami e tag, compresi quelli nuovi che vengono aggiunti in seguito, anche se vale la pena notare che i rami che vengono eliminati non vengono eliminati dal clone (che per un backup potrebbe essere una buona cosa).

Questo è atomico, quindi non ha i problemi che una semplice copia avrebbe.

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

Espandendo le grandi risposte di KingCrunch e VonC

Li ho combinati entrambi:

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

Dopo di che hai un file chiamato reponame.bundleche può essere facilmente copiato. È quindi possibile creare un nuovo repository git normale da tale utilizzo git clone reponame.bundle reponame.

Si noti che git bundlesolo le copie eseguono il commit che portano a qualche riferimento (branch o tag) nel repository. Quindi i commit aggrovigliati non vengono archiviati nel bundle.

Tutto è contenuto nella .gitdirectory. Esegui il backup insieme al tuo progetto come faresti con qualsiasi file.

usa git bundle o clona

copiare la directory git non è una buona soluzione perché non è atomica. Se si dispone di un repository di grandi dimensioni che richiede molto tempo per essere copiato e qualcuno spinge nel proprio repository, ciò influirà sul backup. La clonazione o la creazione di un pacchetto non avrà questo problema.

È possibile eseguire il backup del repository git con git-copy alla dimensione minima di archiviazione.

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

Quindi puoi ripristinare il tuo progetto con git clone

git clone /backup/project.repo.backup project

La risposta corretta IMO è git clone --mirror . Ciò eseguirà il backup completo del repository.

Git clone mirror clonerà l'intero repository, note, head, refs, ecc. E viene generalmente utilizzato per copiare un intero repository su un nuovo server git. Questo eliminerà tutti i rami e tutto, l' intero repository.

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

• Normalmente la clonazione di un repository non include tutti i rami, ma solo il Master.

• La copia della cartella dei repository "copia" solo i rami che sono stati inseriti ... quindi, per impostazione predefinita, si tratta solo del ramo Master o di altri rami che hai estratto in precedenza.

• Anche il comando bundle Git non è quello che vuoi: "Il comando bundle impacchetterà tutto ciò che normalmente verrebbe trasferito via cavo con un comando git push in un file binario che puoi inviare via e-mail a qualcuno o mettere su un'unità flash, quindi disaggregarsi in un altro repository ". (Da Qual è la differenza tra git clone --mirror e git clone --bare )

Questo thread è stato molto utile per ottenere alcune informazioni su come eseguire i backup dei repository git. Penso che manchi ancora qualche suggerimento, informazione o conclusione per trovare il "modo corretto" (tm) per se stessi. Pertanto, condividendo i miei pensieri qui per aiutare gli altri e metterli in discussione per migliorarli. Grazie.

Quindi, a partire dal raccogliere la domanda originale:

• L'obiettivo è avvicinarsi il più possibile a un backup "completo" di un repository git.

Quindi arricchendolo con i desideri tipici e specificando alcune preimpostazioni:

• Il backup tramite una "copia a caldo" è preferito per evitare tempi di inattività del servizio.
• Le carenze di git verranno risolte con comandi aggiuntivi.
• Uno script dovrebbe eseguire il backup per combinare i passaggi multipli per un singolo backup ed evitare errori umani (errori di battitura, ecc.).
• Inoltre, uno script dovrebbe eseguire il ripristino per adattare il dump alla macchina di destinazione, ad esempio anche la configurazione della macchina originale potrebbe essere cambiata dal backup.
• L'ambiente è un server git su una macchina Linux con un file system che supporta hardlink.

1. Che cos'è un backup "completo" di repository git?

Il punto di vista differisce su cosa sia un backup "100%". Eccone due tipici.

# 1 Punto di vista dello sviluppatore

• Soddisfare
• Riferimenti

git è uno strumento di sviluppo e supporta questo punto di vista tramite git clone --mirrore git bundle --all.

# 2 Punto di vista dell'amministratore

• File di contenuto
  • Caso speciale "packfile": git combina e compatta gli oggetti in file pack durante la garbage collection (vedi git gc)
• configurazione git
  • vedi https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain
  • documenti: man git-config, man gitignore
  • .git / config
  • .git / descrizione (per hook e strumenti, ad esempio hook post-ricezione-e-mail, gitolite, GitWeb, ecc.)
  • .git / ganci /
  • .git / info / (repository escludi file, ecc.)
• Opzionale: configurazione del sistema operativo (autorizzazioni del file system, ecc.)

git è uno strumento di sviluppo e lo lascia all'amministratore. Il backup della configurazione git e della configurazione del sistema operativo deve essere visto come separato dal backup del contenuto.

2. Tecniche

• "Cold-Copy"
  • Interrompere il servizio per avere accesso esclusivo ai suoi file. I tempi di inattività!
• "Hot-Copy"
  • Il servizio fornisce uno stato fisso a fini di backup. Le modifiche in corso non influiscono su quello stato.

3. Altri argomenti a cui pensare

Molti di questi sono generici per i backup.

• C'è abbastanza spazio per contenere i backup completi? Quante generazioni verranno archiviate?
• È richiesto un approccio incrementale? Quante generazioni verranno archiviate e quando creare nuovamente un backup completo?
• Come verificare che un backup non sia danneggiato dopo la creazione o nel tempo?
• Il file system supporta gli hardlink?
• Inserire il backup in un singolo file di archivio o utilizzare la struttura di directory?

4. Cosa fornisce git al backup dei contenuti

• git gc --auto

  • documenti: man git-gc
  • Pulisce e compatta un repository.

• git bundle --all

  • documenti: man git-bundle, man git-rev-list
  • Atomic = "Hot-Copy"
  • I bundle sono file di dump e possono essere usati direttamente con git (verifica, clone, ecc.).
  • Supporta l'estrazione incrementale.
  • Verificabile tramite git bundle verify.

• git clone --mirror

  • documenti: man git-clone, man git-fsck, Qual è la differenza tra git clone --mirror e git clone --bare
  • Atomic = "Hot-Copy"
  • Gli specchi sono veri e propri repository git.
  • L'intenzione principale di questo comando è quella di creare un mirror completamente attivo, che recupera periodicamente gli aggiornamenti dal repository originale.
  • Supporta hardlink per mirror sullo stesso file system per evitare di sprecare spazio.
  • Verificabile tramite git fsck.
  • Gli specchi possono essere utilizzati come base per uno script di backup di file completo.

5. Copia a freddo

Un backup con copia a freddo può sempre eseguire un backup completo del file: negare tutti gli accessi ai repository git, eseguire il backup e consentire nuovamente gli accessi.

• Possibili problemi
  • Potrebbe non essere facile - o addirittura possibile - negare tutti gli accessi, ad esempio l'accesso condiviso tramite il file system.
  • Anche se il repository si trova su un computer solo client con un singolo utente, l'utente può comunque eseguire il commit di qualcosa durante un'esecuzione di backup automatizzata :(
  • I tempi di inattività potrebbero non essere accettabili sul server e l'esecuzione di un backup di più repository enormi può richiedere molto tempo.
• Idee per la mitigazione:
  • Impedire l'accesso diretto al repository tramite il file system in generale, anche se i client si trovano sulla stessa macchina.
  • Per l'accesso SSH / HTTP utilizzare i gestori delle autorizzazioni git (ad es. Gitolite) per gestire dinamicamente l'accesso o modificare i file di autenticazione in modo scriptato.
  • Backup di repository uno per uno per ridurre i tempi di inattività per ciascun repository. Negare un repository, eseguire il backup e consentire nuovamente l'accesso, quindi continuare con il repository successivo.
  • Hanno pianificato un programma di manutenzione per evitare problemi agli sviluppatori.
  • Esegui il backup solo quando il repository è stato modificato. Forse molto difficile da implementare, ad esempio un elenco di oggetti oltre a avere in mente pacchetti di file, checksum di configurazione e hook, ecc.

6. Copia a caldo

Non è possibile eseguire i backup dei file con repository attivi a causa del rischio di dati danneggiati da commit in corso. Una copia a caldo fornisce uno stato fisso di un repository attivo a fini di backup. I commit in corso non influiscono su quella copia. Come elencato sopra, le funzionalità clone e bundle di git supportano questo, ma per un backup "100% admin" è necessario eseguire diverse operazioni tramite comandi aggiuntivi.

Backup a caldo "100% admin"

• Opzione 1: utilizzare git bundle --allper creare file di dump completi / incrementali di contenuto e copiare / eseguire il backup dei file di configurazione separatamente.
• Opzione 2: utilizzare git clone --mirror, gestire e copiare la configurazione separatamente, quindi eseguire il backup completo del file del mirror.
  • Appunti:
  • Un mirror è un nuovo repository, che viene popolato con il modello git corrente al momento della creazione.
  • Pulisci i file e le directory di configurazione, quindi copia i file di configurazione dal repository di origine originale.
  • Lo script di backup può anche applicare la configurazione del sistema operativo come le autorizzazioni dei file sul mirror.
  • Utilizzare un filesystem che supporti i collegamenti fisici e creare il mirror sullo stesso filesystem del repository di origine per ottenere velocità e ridurre il consumo di spazio durante il backup.

7. Ripristina

• Controlla e adotta la configurazione git per indirizzare la macchina e la più recente filosofia del "modo di fare".
• Controlla e adotta la configurazione del sistema operativo per indirizzare la macchina e la più recente filosofia del "modo di fare".

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

questo crea un backup e rende l'installazione, in modo che tu possa fare un git push per aggiornare il tuo backup, cosa è probabilmente quello che vuoi fare. Assicurati solo che / path / to / backupdir e / path / to / repo siano almeno dischi rigidi diversi, altrimenti non ha molto senso farlo.

Ecco due opzioni:

1. È possibile prendere direttamente un tar della directory repository git in quanto ha l'intero contenuto nudo del repository sul server. Esiste una leggera possibilità che qualcuno stia lavorando al repository durante l'esecuzione del backup.

2. Il seguente comando ti darà il clone nudo del repository (proprio come è nel server), quindi puoi prendere un tar della posizione in cui hai clonato senza alcun problema.

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

Se è su Github, vai su bitbucket e usa il metodo "import repository" per importare il tuo repository github come repository privato.

Se è in bitbucket, fai il contrario.

È un backup completo ma rimane nel cloud che è il mio metodo ideale.

Per quanto ne so, puoi semplicemente fare una copia della directory in cui si trova il tuo repository, tutto qui!

cp -r project project-backup