¿Hay una manera simple de hacer una copia de seguridad de un repositorio de git completo, incluidas todas las ramas y etiquetas?

¿Qué hay de solo hacer un clon?

git clone --mirror other/repo.git

Cada repositorio es una copia de seguridad de su control remoto.

git bundle

Me gusta ese método, ya que resulta en un solo archivo, más fácil de copiar.
Ver ProGit: pequeño paquete de alegría .
Consulte también " ¿Cómo puedo enviar un correo electrónico a alguien con un repositorio git? ", Donde el comando

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

se detalla:

git bundlesólo empaquetar las referencias que se muestran por git show-ref : esto incluye cabezas, etiquetas y cabezas remotas.
Es muy importante que la base utilizada sea mantenida por el destino.
Está bien errar con precaución, ya que el archivo de paquete contiene objetos que ya están en el destino, ya que estos se ignoran al desempacar en el destino.

Para usar ese paquete, puede clonarlo, especificando una carpeta inexistente (fuera de cualquier repositorio de git):

git clone /tmp/foo-all newFolder

Ampliando algunas otras respuestas, esto es lo que hago:

Configura el repositorio: git clone --mirror user@server:/url-to-repo.git

Luego, cuando desee actualizar la copia de seguridad: git remote updatedesde la ubicación del clon.

Esto hace una copia de seguridad de todas las ramas y etiquetas, incluidas las nuevas que se agregan más tarde, aunque vale la pena señalar que las ramas que se eliminan no se eliminan del clon (lo que para una copia de seguridad puede ser algo bueno).

Esto es atómico, por lo que no tiene los problemas que tendría una copia simple.

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

Ampliando las excelentes respuestas de KingCrunch y VonC

Los combiné a ambos:

git clone --mirror [email protected]/reponame reponame.git
cd reponame.git
git bundle create reponame.bundle --all

Después de eso, tiene un archivo llamado reponame.bundleque se puede copiar fácilmente. Luego puede crear un nuevo repositorio git normal a partir de ese uso git clone reponame.bundle reponame.

Tenga en cuenta que git bundlesolo copia confirmaciones que conducen a alguna referencia (rama o etiqueta) en el repositorio. Por lo tanto, las confirmaciones de enredo no se almacenan en el paquete.

Todo está contenido en el .gitdirectorio. Simplemente respalde eso junto con su proyecto como lo haría con cualquier archivo.

use git bundle o clone

copiar el directorio git no es una buena solución porque no es atómico. Si tiene un repositorio grande que toma mucho tiempo copiar y alguien lo empuja a su repositorio, esto afectará su respaldo. Clonar o hacer un paquete no tendrá este problema.

Puede hacer una copia de seguridad del repositorio de git con git-copy en un tamaño de almacenamiento mínimo.

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

Entonces puedes restaurar tu proyecto con git clone

git clone /backup/project.repo.backup project

La respuesta correcta de la OMI es git clone --mirror . Esto respaldará completamente su repositorio.

Git clone mirror clonará todo el repositorio, notas, encabezados, referencias, etc. y se usa generalmente para copiar un repositorio completo a un nuevo servidor git. Esto desplegará todas las ramas y todo, todo el repositorio.

git clone --mirror [email protected]/your-repo.git

• Normalmente, clonar un repositorio no incluye todas las ramas, solo Master.

• Copiar la carpeta del repositorio solo "copiará" las ramas que se han extraído ... por lo que, de forma predeterminada, es solo la rama maestra u otras ramas que haya extraído anteriormente.

• El comando de paquete Git tampoco es lo que desea: "El comando de paquete empaquetará todo lo que normalmente se pasaría por el cable con un comando git push en un archivo binario que puede enviar por correo electrónico a alguien o poner en una unidad flash, luego desagrupar en otro repositorio ". (De ¿Cuál es la diferencia entre git clone --mirror y git clone --bare )

Este hilo fue muy útil para obtener algunas ideas sobre cómo se podrían hacer copias de seguridad de repositorios git. Creo que todavía le faltan algunas pistas, información o conclusión para encontrar la "forma correcta" (tm) para uno mismo. Por lo tanto, comparto mis pensamientos aquí para ayudar a otros y ponerlos a discusión para mejorarlos. Gracias.

Entonces, comenzando por retomar la pregunta original:

• El objetivo es acercarse lo más posible a una copia de seguridad "completa" de un repositorio git.

Luego enriqueciéndolo con los deseos típicos y especificando algunos ajustes preestablecidos:

• Se prefiere la copia de seguridad a través de una "copia en caliente" para evitar el tiempo de inactividad del servicio.
• Las deficiencias de git se solucionarán mediante comandos adicionales.
• Un script debe hacer la copia de seguridad para combinar los múltiples pasos para una sola copia de seguridad y evitar errores humanos (errores tipográficos, etc.).
• Además, un script debe realizar la restauración para adaptar el volcado a la máquina de destino, por ejemplo, incluso la configuración de la máquina original puede haber cambiado desde la copia de seguridad.
• Environment es un servidor git en una máquina Linux con un sistema de archivos que admite enlaces duros.

1. ¿Qué es una copia de seguridad de repositorio git "completa"?

El punto de vista difiere de lo que es una copia de seguridad "100%". Aquí hay dos típicos.

# 1 Punto de vista del desarrollador

• Contenido
• Referencias

git es una herramienta para desarrolladores y admite este punto de vista a través de git clone --mirrory git bundle --all.

# 2 Punto de vista del administrador

• Archivos de contenido
  • Caso especial "paquete de archivos": git combina y compacta objetos en archivos de paquete durante la recolección de basura (ver git gc)
• configuración de git
  • ver https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain
  • docs: man git-config, man gitignore
  • .git / config
  • .git / description (para ganchos y herramientas, por ejemplo, gancho posterior a la recepción de correo electrónico, gitolite, GitWeb, etc.)
  • .git / ganchos /
  • .git / info / (archivo de exclusión del repositorio, etc.)
• Opcional: configuración del sistema operativo (permisos del sistema de archivos, etc.)

git es una herramienta de desarrollador y lo deja al administrador. La copia de seguridad de la configuración de git y la configuración del sistema operativo debe verse como separada de la copia de seguridad del contenido.

2. Técnicas

• "Copia fría"
  • Detenga el servicio para tener acceso exclusivo a sus archivos. ¡Falta del tiempo!
• "Copia en caliente"
  • El servicio proporciona un estado fijo para fines de respaldo. Los cambios en curso no afectan ese estado.

3. Otros temas para pensar

La mayoría de ellos son genéricos para copias de seguridad.

• ¿Hay suficiente espacio para guardar las copias de seguridad completas? ¿Cuántas generaciones se almacenarán?
• ¿Se desea un enfoque incremental? ¿Cuántas generaciones se almacenarán y cuándo volver a crear una copia de seguridad completa?
• ¿Cómo verificar que una copia de seguridad no esté dañada después de la creación o con el tiempo?
• ¿El sistema de archivos admite enlaces duros?
• ¿Poner una copia de seguridad en un único archivo o usar la estructura de directorios?

4. Qué proporciona git al contenido de respaldo

• git gc --auto

  • docs: hombre git-gc
  • Limpia y compacta un repositorio.

• git bundle --all

  • docs: man git-bundle, man git-rev-list
  • Atomic = "Copia en caliente"
  • Los paquetes son archivos de volcado y se pueden usar directamente con git (verificar, clonar, etc.).
  • Soporta extracción incremental.
  • Verificable a través de git bundle verify.

• git clone --mirror

  • docs: man git-clone, man git-fsck, ¿Cuál es la diferencia entre git clone --mirror y git clone --bare
  • Atomic = "Copia en caliente"
  • Los espejos son verdaderos repositorios de git.
  • La intención principal de este comando es construir un espejo activo completo, que periódicamente recupera actualizaciones del repositorio original.
  • Admite enlaces duros para espejos en el mismo sistema de archivos para evitar el desperdicio de espacio.
  • Verificable a través de git fsck.
  • Los espejos se pueden usar como base para un script de copia de seguridad de archivos completo.

5. Copia fría

Una copia de seguridad en frío siempre puede hacer una copia de seguridad de archivos completa: denegar todos los accesos a los repositorios git, hacer copias de seguridad y permitir nuevamente los accesos.

• Posibles problemas
  • Puede que no sea fácil, o incluso posible, negar todos los accesos, por ejemplo, el acceso compartido a través del sistema de archivos.
  • Incluso si el repositorio está en una máquina solo para clientes con un solo usuario, el usuario aún puede confirmar algo durante una ejecución de copia de seguridad automatizada :(
  • El tiempo de inactividad puede no ser aceptable en el servidor y hacer una copia de seguridad de múltiples repositorios enormes puede llevar mucho tiempo.
• Ideas para mitigar:
  • Evite el acceso directo al repositorio a través del sistema de archivos en general, incluso si los clientes están en la misma máquina.
  • Para el acceso SSH / HTTP, use los administradores de autorización git (por ejemplo, gitolite) para administrar dinámicamente el acceso o modificar los archivos de autenticación de una manera programada.
  • Copia de seguridad de repositorios uno por uno para reducir el tiempo de inactividad de cada repositorio. Niegue un repositorio, haga una copia de seguridad y permita el acceso nuevamente, luego continúe con el próximo repositorio.
  • Tener un plan de mantenimiento planificado para evitar molestias a los desarrolladores.
  • Solo copia de seguridad cuando el repositorio ha cambiado. Tal vez sea muy difícil de implementar, por ejemplo, una lista de objetos además de tener en mente los archivos de paquete, las sumas de comprobación de configuración y ganchos, etc.

6. Copia en caliente

Las copias de seguridad de archivos no se pueden hacer con repositorios activos debido al riesgo de datos corruptos por confirmaciones en curso. Una copia en caliente proporciona un estado fijo de un repositorio activo para fines de copia de seguridad. Las confirmaciones en curso no afectan a esa copia. Como se mencionó anteriormente, las funcionalidades de clon y paquete de git lo admiten, pero para una copia de seguridad "100% admin", se deben hacer varias cosas a través de comandos adicionales.

Copia de seguridad de copia en caliente "100% admin"

• Opción 1: se usa git bundle --allpara crear archivos de volcado de contenido completos / incrementales y copiar / hacer copias de seguridad de los archivos de configuración por separado.
• Opción 2: use git clone --mirror, maneje y copie la configuración por separado, luego haga una copia de seguridad completa del espejo.
  • Notas:
  • Un espejo es un nuevo repositorio, que se completa con la plantilla git actual en la creación.
  • Limpie los archivos y directorios de configuración, luego copie los archivos de configuración del repositorio original de origen.
  • La secuencia de comandos de copia de seguridad también puede aplicar la configuración del sistema operativo, como los permisos de archivo en el espejo.
  • Use un sistema de archivos que admita enlaces duros y cree el espejo en el mismo sistema de archivos que el repositorio de origen para ganar velocidad y reducir el consumo de espacio durante la copia de seguridad.

7. Restaurar

• Verifique y adopte la configuración de git para la máquina de destino y la última filosofía de "forma de hacer".
• Verifique y adopte la configuración del sistema operativo para la máquina de destino y la última filosofía de "forma de hacer".

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

esto crea una copia de seguridad y realiza la configuración, de modo que puede hacer un gran esfuerzo para actualizar su copia de seguridad, lo que probablemente es lo que desea hacer. Solo asegúrese de que / path / to / backupdir y / path / to / repo sean al menos discos duros diferentes, de lo contrario no tiene mucho sentido hacerlo.

Aquí hay dos opciones:

1. Puede tomar directamente un tar del directorio git repo ya que tiene todo el contenido desnudo del repositorio en el servidor. Existe una ligera posibilidad de que alguien esté trabajando en el repositorio mientras realiza una copia de seguridad.

2. El siguiente comando le dará el clon desnudo del repositorio (al igual que en el servidor), luego puede tomar un alquitrán de la ubicación donde ha clonado sin ningún problema.

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

Si está en Github, navegue al bitbucket y use el método "importar repositorio" para importar su repositorio github como un repositorio privado.

Si está en bitbucket, haga lo contrario.

Es una copia de seguridad completa, pero permanece en la nube, que es mi método ideal.

Hasta donde sé, puede hacer una copia del directorio en el que se encuentra su repositorio, ¡eso es todo!

cp -r project project-backup