Existe-t-il un moyen simple de sauvegarder un référentiel git complet, y compris toutes les branches et balises?

Pourquoi ne pas en faire un clone?

git clone --mirror other/repo.git

Chaque référentiel est une sauvegarde de sa télécommande.

git bundle

J'aime cette méthode, car elle ne génère qu'un seul fichier, plus facile à copier.
Voir ProGit: petit paquet de joie .
Voir aussi « Comment puis-je envoyer un e-mail à quelqu'un dans un référentiel git? », Où la commande

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

est détaillé:

git bundlene contiendra que les références affichées par git show-ref : cela inclut les têtes, les balises et les têtes distantes.
Il est très important que la base utilisée soit détenue par la destination.
Il est normal de faire preuve de prudence, car le fichier bundle contient des objets déjà dans la destination, car ceux-ci sont ignorés lors de la décompression à la destination.

Pour utiliser ce bundle, vous pouvez le cloner, en spécifiant un dossier inexistant (en dehors de tout dépôt git):

git clone /tmp/foo-all newFolder

En développant d'autres réponses, voici ce que je fais:

Configurez le dépôt: git clone --mirror user@server:/url-to-repo.git

Ensuite, lorsque vous souhaitez actualiser la sauvegarde: git remote update partir de l'emplacement de clonage.

Cela sauvegarde toutes les branches et balises, y compris les nouvelles qui sont ajoutées plus tard, bien qu'il soit intéressant de noter que les branches supprimées ne sont pas supprimées du clone (ce qui peut être une bonne chose pour une sauvegarde).

Ceci est atomique et n'a donc pas les problèmes qu'une simple copie aurait.

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

Développant les excellentes réponses de KingCrunch et VonC

J'ai combiné les deux:

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

Après cela, vous avez un fichier appelé reponame.bundlequi peut être facilement copié. Vous pouvez ensuite créer un nouveau référentiel git normal à partir de celui-ci en utilisantgit clone reponame.bundle reponame .

Notez que git bundleseules les copies des commits menant à une référence (branche ou balise) dans le référentiel. Les commits enchevêtrés ne sont donc pas stockés dans le bundle.

Tout est contenu dans le .gitrépertoire. Sauvegardez simplement cela avec votre projet comme vous le feriez pour n'importe quel fichier.

utiliser git bundle ou clone

copier le répertoire git n'est pas une bonne solution car ce n'est pas atomique. Si vous avez un référentiel volumineux dont la copie prend beaucoup de temps et que quelqu'un le pousse vers votre référentiel, cela affectera votre sauvegarde. Le clonage ou la création d'un bundle n'aura pas ce problème.

Vous pouvez sauvegarder le référentiel git avec git-copy à une taille de stockage minimale.

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

Ensuite, vous pouvez restaurer votre projet avec git clone

git clone /backup/project.repo.backup project

La bonne réponse IMO est git clone --mirror . Cela sauvegardera entièrement votre dépôt.

Le miroir de clonage Git clonera le référentiel entier, les notes, les headers, les refs, etc. et est généralement utilisé pour copier un référentiel entier sur un nouveau serveur git. Cela déroulez un toutes les branches et tout, l' ensemble du référentiel.

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

• Normalement, le clonage d'un dépôt n'inclut pas toutes les branches, uniquement Master.

• Copier le dossier de dépôt ne "copiera" que les branches qui ont été extraites ... donc par défaut c'est la branche principale uniquement ou d'autres branches que vous avez extraites précédemment.

• La commande Git bundle n'est pas non plus ce que vous voulez: "La commande bundle va empaqueter tout ce qui serait normalement poussé sur le câble avec une commande git push dans un fichier binaire que vous pouvez envoyer par e-mail à quelqu'un ou mettre sur un lecteur flash, puis dégrouper dans un autre référentiel. " (De Quelle est la différence entre git clone --mirror et git clone --bare )

Ce fil de discussion a été très utile pour obtenir des informations sur la manière dont les sauvegardes des dépôts git pouvaient être effectuées. Je pense qu'il manque encore quelques indices, informations ou conclusions pour trouver la "bonne voie" (tm) pour soi-même. Par conséquent, partager mes pensées ici pour aider les autres et les mettre en discussion pour les améliorer. Merci.

Commençons donc par reprendre la question initiale:

• L'objectif est de se rapprocher le plus possible d'une sauvegarde "complète" d'un référentiel git.

Puis l'enrichissant avec les souhaits typiques et en spécifiant quelques préréglages:

• La sauvegarde via une "copie à chaud" est préférable pour éviter les temps d'arrêt du service.
• Les lacunes de git seront contournées par des commandes supplémentaires.
• Un script doit effectuer la sauvegarde pour combiner les multiples étapes d'une seule sauvegarde et éviter les erreurs humaines (fautes de frappe, etc.).
• De plus, un script doit effectuer la restauration pour adapter le vidage à la machine cible, par exemple, même la configuration de la machine d'origine peut avoir changé depuis la sauvegarde.
• L'environnement est un serveur git sur une machine Linux avec un système de fichiers prenant en charge les liens physiques.

1. Qu'est-ce qu'une sauvegarde de dépôt git "complète"?

Le point de vue diffère sur ce qu'est une sauvegarde «100%». En voici deux typiques.

Le point de vue du développeur n ° 1

• Contenu
• Références

git est un outil de développement et prend en charge ce point de vue via git clone --mirroretgit bundle --all .

# 2 Le point de vue de l'administrateur

• Fichiers de contenu
  • Cas particulier "packfile": git combine et compacte des objets en packfiles pendant le garbage collection (voir git gc)
• configuration git
  • voir https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain
  • docs: man git-config, man gitignore
  • .git / config
  • .git / description (pour les hooks et les outils, par exemple hook post-receive-email, gitolite, GitWeb, etc.)
  • .git / hooks /
  • .git / info / (fichier d'exclusion du référentiel, etc.)
• Facultatif: configuration du système d'exploitation (autorisations du système de fichiers, etc.)

git est un outil de développement et laisse cela à l'administrateur. La sauvegarde de la configuration git et de la configuration du système d'exploitation doit être considérée comme séparée de la sauvegarde du contenu.

2. Techniques

• "Cold-Copy"
  • Arrêtez le service pour avoir un accès exclusif à ses fichiers. Temps d'arrêt!
• "Copie à chaud"
  • Le service fournit un état fixe à des fins de sauvegarde. Les changements en cours n'affectent pas cet état.

3. Autres sujets auxquels réfléchir

La plupart d'entre eux sont génériques pour les sauvegardes.

• Y a-t-il suffisamment d'espace pour contenir les sauvegardes complètes? Combien de générations seront stockées?
• Une approche incrémentale est-elle souhaitée? Combien de générations seront stockées et quand créer à nouveau une sauvegarde complète?
• Comment vérifier qu'une sauvegarde n'est pas corrompue après sa création ou au fil du temps?
• Le système de fichiers prend-il en charge les liens physiques?
• Mettre la sauvegarde dans un fichier d'archive unique ou utiliser la structure de répertoires?

4. Ce que git fournit pour sauvegarder le contenu

• git gc --auto

  • docs: man git-gc
  • Nettoie et compacte un référentiel.

• git bundle --all

  • docs: man git-bundle, man git-rev-list
  • Atomic = "Hot-Copy"
  • Les bundles sont des fichiers de vidage et peuvent être directement utilisés avec git (vérifier, cloner, etc.).
  • Prend en charge l'extraction incrémentielle.
  • Vérifiable via git bundle verify.

• git clone --mirror

  • docs: man git-clone, man git-fsck, Quelle est la différence entre git clone --mirror et git clone --bare
  • Atomic = "Hot-Copy"
  • Les miroirs sont de véritables référentiels git.
  • L'intention principale de cette commande est de créer un miroir actif complet, qui récupère périodiquement les mises à jour du référentiel d'origine.
  • Prend en charge les liens physiques pour les miroirs sur le même système de fichiers pour éviter de gaspiller de l'espace.
  • Vérifiable via git fsck.
  • Les miroirs peuvent être utilisés comme base pour un script de sauvegarde de fichier complet.

5. Copie à froid

Une sauvegarde par copie froide peut toujours faire une sauvegarde de fichier complète: refuser tous les accès aux dépôts git, faire une sauvegarde et autoriser à nouveau les accès.

• Problèmes possibles
  • Il peut ne pas être facile - ou même possible - de refuser tous les accès, par exemple l'accès partagé via le système de fichiers.
  • Même si le dépôt est sur une machine cliente uniquement avec un seul utilisateur, l'utilisateur peut toujours valider quelque chose lors d'une exécution de sauvegarde automatisée :(
  • Les temps d'arrêt peuvent ne pas être acceptables sur le serveur et effectuer une sauvegarde de plusieurs dépôts énormes peut prendre du temps.
• Idées d'atténuation:
  • Empêchez l'accès direct aux dépôts via le système de fichiers en général, même si les clients sont sur la même machine.
  • Pour l'accès SSH / HTTP, utilisez les gestionnaires d'autorisation git (par exemple gitolite) pour gérer dynamiquement l'accès ou modifier les fichiers d'authentification de manière scriptée.
  • Sauvegardez les dépôts un par un pour réduire les temps d'arrêt pour chaque dépôt. Refusez un dépôt, effectuez une sauvegarde et autorisez à nouveau l'accès, puis passez au dépôt suivant.
  • Avoir un calendrier de maintenance planifié pour éviter de contrarier les développeurs.
  • Sauvegardez uniquement lorsque le référentiel a changé. Peut-être très difficile à implémenter, par exemple la liste des objets et la prise en compte des fichiers de paquets, les sommes de contrôle de la configuration et des crochets, etc.

6. Copie à chaud

Les sauvegardes de fichiers ne peuvent pas être effectuées avec des dépôts actifs en raison du risque de corruption des données par des validations en cours. Une copie à chaud fournit un état fixe d'un référentiel actif à des fins de sauvegarde. Les validations en cours n'affectent pas cette copie. Comme indiqué ci-dessus, les fonctionnalités de clone et de bundle de git prennent en charge cela, mais pour une sauvegarde "100% admin", plusieurs choses doivent être effectuées via des commandes supplémentaires.

Sauvegarde à chaud "100% admin"

• Option 1: utiliser git bundle --all pour créer des fichiers de vidage complets / incrémentiels du contenu et copier / sauvegarder les fichiers de configuration séparément.
• Option 2: utiliser git clone --mirror , gérez et copiez la configuration séparément, puis effectuez une sauvegarde complète des fichiers du miroir.
  • Remarques:
  • Un miroir est un nouveau référentiel, qui est rempli avec le modèle git actuel lors de la création.
  • Nettoyez les fichiers et répertoires de configuration, puis copiez les fichiers de configuration à partir du référentiel source d'origine.
  • Le script de sauvegarde peut également appliquer la configuration du système d'exploitation comme les autorisations de fichier sur le miroir.
  • Utilisez un système de fichiers prenant en charge les liens physiques et créez le miroir sur le même système de fichiers que le référentiel source pour gagner en vitesse et réduire la consommation d'espace pendant la sauvegarde.

7. Restaurer

• Vérifiez et adoptez la configuration git pour la machine cible et la dernière philosophie de «manière de faire».
• Vérifiez et adoptez la configuration du système d'exploitation pour la machine cible et la dernière philosophie de «façon de faire».

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

cela crée une sauvegarde et effectue la configuration, de sorte que vous puissiez faire un push git pour mettre à jour votre sauvegarde, ce que vous voulez probablement faire. Assurez-vous simplement que / path / to / backupdir et / path / to / repo sont au moins des disques durs différents, sinon cela n'a pas beaucoup de sens de le faire.

Voici deux options:

1. Vous pouvez directement prendre un tar du répertoire git repo car il contient tout le contenu nu du repo sur le serveur. Il y a une légère possibilité que quelqu'un travaille sur le repo tout en prenant une sauvegarde.

2. La commande suivante vous donnera le clone nu du repo (tout comme il est dans le serveur), puis vous pouvez prendre un tar de l'emplacement où vous avez cloné sans aucun problème.

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

S'il se trouve sur Github, accédez à bitbucket et utilisez la méthode «import repository» pour importer votre dépôt github en tant que dépôt privé.

Si c'est dans bitbucket, faites l'inverse.

C'est une sauvegarde complète mais reste dans le cloud, ce qui est ma méthode idéale.

Autant que je sache, vous pouvez simplement faire une copie du répertoire dans lequel se trouve votre dépôt, c'est tout!

cp -r project project-backup