GIT como herramienta de respaldo

101

En un servidor, instale git

cd /
git init
git add .
git commit -a -m "Yes, this is server"

Luego /.git/apunte a una unidad de red (SAN, NFS, Samba, lo que sea) o un disco diferente. Use un trabajo cron cada hora / día, etc. para actualizar los cambios. El directorio .git contendría una copia versionada de todos los archivos del servidor (excluyendo los inútiles / complicados como / proc, / dev, etc.)

Para un servidor de desarrollo no importante donde no quiero la molestia / costo de configurarlo en un sistema de respaldo adecuado, y donde los respaldos solo serían convenientes (es decir, no necesitamos respaldar este servidor pero ahorraría en algún momento si las cosas salieron mal), ¿podría ser una solución de respaldo válida o simplemente se caerá en una gran pila de popó?

Mancha
fuente
3
¿no funciona sparkleshare con una idea similar?
B14D3
@ B14D3 Creo que sparkleshare es más como una especie de cosa tipo dropbox, pero lo investigaré
Smudge
2
tienes razón, pero usando git para hacer algún tipo de cosa de copia (copiando a varias PC y controlando versiones de archivos);)
B14D3
El gran problema con esto es que no hay un control central: debe tener acceso directo (ssh) a la máquina para realizar cualquier forma de mantenimiento o validación de respaldo. Siempre encuentro que instalar una aplicación en las cajas para hacer una copia de seguridad y luego administrarlas desde una ubicación central es una victoria mucho mayor.
hafichuk
@hafichuk Con herramientas como Puppet / Chef no es un gran problema, pero entiendo tu punto.
Mancha

Respuestas:

88

No eres una persona tonta. Usarlo gitcomo mecanismo de respaldo puede ser atractivo y, a pesar de lo que otras personas han dicho, gitfunciona bien con archivos binarios. Lea esta página del Libro Git para obtener más información sobre este tema. Básicamente, dado gitque no está utilizando un mecanismo de almacenamiento delta, realmente no le importa cómo se vean sus archivos (pero la utilidad de git diffes bastante baja para los archivos binarios con una configuración estándar).

El mayor problema con el uso gitde la copia de seguridad es que no conserva la mayoría de los metadatos del sistema de archivos. Específicamente, gitno registra:

  • grupos de archivos
  • propietarios de archivos
  • permisos de archivo (que no sea "es ejecutable")
  • atributos extendidos

Puede resolver esto escribiendo herramientas para registrar esta información explícitamente en su repositorio, pero puede ser complicado hacerlo correctamente.

Una búsqueda en Google de metadatos de copia de seguridad de git produce una serie de resultados que parecen valer la pena leer (incluidas algunas herramientas que ya intentan compensar los problemas que he planteado aquí).

etckeeper fue desarrollado para realizar copias de seguridad /etcy resuelve muchos de estos problemas.

larsks
fuente
16
+1 por mencionar ACL / permisos
Larry Silverman
23
Git tampoco almacena directorios vacíos.
Flimm
y también apesta para rastrear el movimiento / cambio de nombre de archivos, a través del historial.
cregox
1
Dado que git no trata muy bien los archivos binarios, es posible que también desee examinar el anexo de git , que ayuda a hacerlo mejor. Sin embargo, sí cambia la idea de lo que es git.
Wouter Verhelst
1
mi opinión es que se puede usar Git a los datos de copia de seguridad, pero no servidores enteros
EKanadily
21

No lo he usado, pero puedes mirar bup, que es una herramienta de respaldo basada en git.

estofado
fuente
Nunca visto bup antes, se ve interesante
Smudge
1
Empecé a usar bup recientemente, solo unos días antes de que mi disco duro fallara;) La restauración funcionó bien, ¡así que lo recomiendo!
André Paramés
1
@ AndréParamés, entonces, lo que estás diciendo es que justo después de instalar bup, tu disco duro se bloqueó ... mmmmhh ... :) es broma
hofnarwillie
12

Puede ser una solución de respaldo válida, etckeeper se basa en esta idea. Pero vigile los .gitpermisos del directorio; de lo contrario, presionar /etc/shadowpuede ser legible en el .gitdirectorio.

Roca
fuente
11

Aunque técnicamente podrías hacer esto, pondría dos advertencias en contra:

1, está utilizando un sistema de control de versión de origen para datos binarios. Por lo tanto, lo está utilizando para algo para lo que no fue diseñado.

2, me preocupa su proceso de desarrollo si no tiene un proceso (documentación o automatizado) para construir una nueva máquina. ¿Qué pasa si te golpean comprar un autobús, quién sabría qué hacer y qué era importante?

La recuperación ante desastres es importante, sin embargo, es mejor automatizar (guiar) la configuración de un nuevo cuadro de desarrollo que simplemente hacer una copia de seguridad de todo. Seguro usa git para tu script / documentación pero no para cada archivo en una computadora.

Phil Hannent
fuente
44
Todos los cuadros de desarrollo provienen de archivos KickStart, y en realidad el cuadro promedio dura aproximadamente 2 o 3 meses antes de que se reconstruya. Pero la gente cambia las configuraciones y hace cosas, reconstruimos las cajas y la gente dice "oye, sé que no lo puse en el control de la fuente, pero tenía algo de mierda en esa caja" y me río de ellos por ser estúpidos. Todo alrededor, buenos tiempos. Los datos binarios serían una perra, es algo que pasé por alto totalmente mientras estaba en la ducha.
Mancha
Aplaudo su actitud hacia aquellos que no siguen los principios básicos. Personalmente, tengo una situación similar a la tuya, sin embargo, tengo un repositorio git que enlaza todos los archivos de configuración que podrían ser importantes en lugar de un todo. Además de un documento txt con pasos de configuración.
Phil Hannent
1
Creo que git funciona bastante bien para archivos binarios, la mayor parte del repositorio de Google Android son repositorios de ejecutables precompilados.
user377178
6

Utilizo git como respaldo para mi sistema Windows, y ha sido increíblemente útil. Al final de la publicación, muestro los scripts que uso para configurar en un sistema Windows. Usar git como respaldo para cualquier sistema ofrece 2 grandes ventajas:

  1. A diferencia de las soluciones comerciales que a menudo usan su propio formato propietario, su copia de seguridad está en un formato de código abierto que es ampliamente compatible y está muy bien documentado. Esto le da un control total de sus datos. Es muy fácil ver qué archivos cambiaron y cuándo. Si desea truncar su historial, también puede hacerlo. ¿Quieres borrar algo de tu historia? No hay problema. Recuperar una versión de su archivo es tan simple como cualquier comando git.
  2. Tantos o pocos espejos como desee, y todos pueden tener tiempos de respaldo personalizados. Obtendrá su espejo local, que no está cargado por el lento tráfico de Internet, y por lo tanto le brinda (1) la capacidad de hacer copias de seguridad más frecuentes durante todo el día y (2) un tiempo de restauración rápido. (Las copias de seguridad frecuentes son una gran ventaja, porque creo que la mayor parte del tiempo que pierdo un documento es por error del usuario. Por ejemplo, su hijo sobrescribe accidentalmente un documento en el que ha estado trabajando durante las últimas 5 horas). Pero obtendrá su espejo remoto, que ofrece la ventaja de la protección de datos en caso de desastre local o robo. ¿Y si desea que su espejo remoto retroceda en un momento personalizado para ahorrar ancho de banda de Internet? No hay problema.

En pocas palabras: una copia de seguridad de git le brinda una increíble cantidad de poder para controlar cómo se realizan sus copias de seguridad.

Configuré esto en mi sistema de Windows. El primer paso es crear el repositorio local de git donde comprometerá todos sus datos locales. Recomiendo usar un segundo disco duro local, pero usar el mismo disco duro funcionará (pero se espera que empuje esto en algún lugar remoto, o de lo contrario se atornillará si el disco duro muere).

Primero deberá instalar cygwin (con rsync) y también instalar git para Windows: http://git-scm.com/download/win

A continuación, cree su repositorio local de git (solo se ejecuta una vez):

init-repo.bat:

@echo off
REM SCRIPT PURPOSE: CREATE YOUR LOCAL GIT-REPO (RUN ONLY ONCE)

REM Set where the git repository will be stored
SET GBKUP_LOCAL_MIRROR_HOME=E:\backup\mirror


REM Create the backup git repo. 
SET GIT_PARAMS=--git-dir=%GBKUP_LOCAL_MIRROR_HOME%\.git --work-tree=%GBKUP_LOCAL_MIRROR_HOME% 
mkdir %GBKUP_LOCAL_MIRROR_HOME%
git %GIT_PARAMS% init
git %GIT_PARAMS% config core.autocrlf false
git %GIT_PARAMS% config core.ignorecase false 
git %GIT_PARAMS% config core.fileMode false
git %GIT_PARAMS% config user.email backup@yourComputerName
git %GIT_PARAMS% config user.name backup

REM add a remote to the git repo.  Make sure you have set myRemoteServer in ~/.ssh/config   
REM The path on the remote server will vary.  Our remote server is a Windows machine running cygwin+ssh.  
REM For better security, you could install gitolite on the remote server, and forbid any non-fast-forward merges, and thus stop a malicious user from overwriting your backups.
git %GIT_PARAMS% remote add origin myRemoteServer:/cygdrive/c/backup/yourComputerName.git

REM treat all files as binary; so you don't have to worry about autocrlf changing your line endings
SET ATTRIBUTES_FILE=%GBKUP_LOCAL_MIRROR_HOME%\.git\info\attributes
echo.>> %ATTRIBUTES_FILE% 
echo *.gbkuptest text>> %ATTRIBUTES_FILE% 
echo * binary>> %ATTRIBUTES_FILE% 
REM compression is often a waste of time with binary files
echo * -delta>> %ATTRIBUTES_FILE% 
REM You may need to get rid of windows new lines. We use cygwin's tool
C:\cygwin64\bin\dos2unix %ATTRIBUTES_FILE%

A continuación, tenemos nuestro contenedor de script de respaldo, que Windows Scheduler llamará regularmente:

gbackup.vbs:

' A simple vbs wrapper to run your bat file in the background
Set oShell = CreateObject ("Wscript.Shell") 
Dim strArgs
strArgs = "cmd /c C:\opt\gbackup\gbackup.bat"
oShell.Run strArgs, 0, false

A continuación, tenemos la secuencia de comandos de respaldo en sí que el reiniciador llama:

gbackup.bat:

    @echo off

REM Set where the git repository will be stored
SET GBKUP_LOCAL_MIRROR_HOME=E:\backup\mirror
REM the user which runs the scheduler
SET GBKUP_RUN_AS_USER=yourWindowsUserName
REM exclude file
SET GBKUP_EXCLUDE_FILE=/cygdrive/c/opt/gbackup/exclude-from.txt

SET GBKUP_TMP_GIT_DIR_NAME=git-renamed
for /f "delims=" %%i in ('C:\cygwin64\bin\cygpath %GBKUP_LOCAL_MIRROR_HOME%') do set GBKUP_LOCAL_MIRROR_CYGWIN=%%i

REM rename any .git directories as they were (see below command)
for /r %GBKUP_LOCAL_MIRROR_HOME% %%i in (%GBKUP_TMP_GIT_DIR_NAME%) do ren "%%i" ".git" 2> nul

SET RSYNC_CMD_BASE=C:\cygwin64\bin\rsync -ahv --progress --delete --exclude-from %GBKUP_EXCLUDE_FILE%

REM rsync all needed directories to local mirror
%RSYNC_CMD_BASE% /cygdrive/c/dev %GBKUP_LOCAL_MIRROR_CYGWIN%
%RSYNC_CMD_BASE% /cygdrive/c/Users/asmith %GBKUP_LOCAL_MIRROR_CYGWIN%
%RSYNC_CMD_BASE% /cygdrive/c/Users/bsmith %GBKUP_LOCAL_MIRROR_CYGWIN%

cacls %GBKUP_LOCAL_MIRROR_HOME% /t /e /p  %GBKUP_RUN_AS_USER%:f

REM rename any .git directories as git will ignore the entire directory, except the main one
for /r %GBKUP_LOCAL_MIRROR_HOME% %%i in (.git) do ren "%%i" "%GBKUP_TMP_GIT_DIR_NAME%" 2> nul
ren %GBKUP_LOCAL_MIRROR_HOME%\%GBKUP_TMP_GIT_DIR_NAME% .git

REM finally commit to git
SET GIT_PARAMS=--git-dir=%GBKUP_LOCAL_MIRROR_HOME%\.git --work-tree=%GBKUP_LOCAL_MIRROR_HOME% 
SET BKUP_LOG_FILE=%TMP%\git-backup.log
SET TO_LOG=1^>^> %BKUP_LOG_FILE% 2^>^&1
echo ===========================BACKUP START=========================== %TO_LOG%
For /f "tokens=2-4 delims=/ " %%a in ('date /t') do (set mydate=%%c-%%a-%%b)
For /f "tokens=1-2 delims=/:" %%a in ('time /t') do (set mytime=%%a%%b)
echo %mydate%_%mytime% %TO_LOG%
echo updating git index, committing, and then pushing to remote %TO_LOG%
REM Caution: The --ignore-errors directive tells git to continue even if it can't access a file.
git %GIT_PARAMS% add -Av --ignore-errors %TO_LOG%
git %GIT_PARAMS% commit -m "backup" %TO_LOG%
git %GIT_PARAMS% push -vv --progress origin master %TO_LOG%
echo ===========================BACKUP END=========================== %TO_LOG%

Tenemos el archivo exclude-from.txt, donde ponemos todos los archivos para ignorar:

excluir-de.txt:

target/
logs/
AppData/
Downloads/
trash/
temp/
.idea/
.m2/
.IntelliJIdea14/
OLD/
Searches/
Videos/
NTUSER.DAT*
ntuser.dat*

Tendrá que ir a cualquier repositorio remoto y hacer un 'git init --bare' en ellos. Puede probar el script ejecutando el script de respaldo. Suponiendo que todo funciona, vaya al Programador de Windows y apunte una copia de seguridad por hora hacia el archivo vbs. Después de eso, tendrás un historial de tu computadora por cada hora. Es extremadamente conveniente: ¿cada uno elimina accidentalmente una sección de texto y se lo pierde? Solo revisa tu repositorio git.

usuario64141
fuente
Es curioso: ¿funcionará también para unidades de red lentas o no estándar, como las emuladas por NetDrive o Expandrive? Me parece que la mayoría del software de respaldo falla con estas unidades de red. Además, las cosas se vuelven dolorosamente lentas y tienden a agotar el tiempo de espera, si quiero enumerar todos los archivos en la copia de seguridad y extraer archivos individuales. ¿Es git capaz de resolver estos problemas?
JustAMartin
@JustAMartin Nunca lo he probado en unidades de red, así que no puedo decirlo. Una vez que obtiene los archivos EN un repositorio de git, git es muy eficiente.
user64141
4

Bueno, no es una mala idea, pero creo que hay dos banderas rojas para levantar:

  • Si el disco duro falla, perderá todo si no está enviando su confirmación a otro servidor / unidad. (Evento si tiene un plan para ello, prefiero mencionarlo).

... pero aún así, puede ser una buena copia de seguridad para cosas relacionadas con la corrupción. O como dijiste, si la carpeta .git / está en otro lugar.

  • Esta copia de seguridad siempre aumentará de tamaño. No hay poda o rotación ni nada por defecto.

... Por lo tanto, es posible que deba indicarle a su cronjob que agregue etiquetas y luego asegúrese de que se borrará la confirmación que no está etiquetada.

FMaz008
fuente
Probablemente montaríamos el directorio .git en un servidor remoto, aunque el clásico rm -Rf /nos causaría algunos problemas. Nuestro sistema de copia de seguridad actual guarda cosas durante 2 años o 50 versiones (lo que ocurra último) para que nuestra copia de seguridad aumente constantemente de todos modos. Pero me gusta la idea de agregar etiquetas, podríamos tener etiquetas "diarias", "semanales", etc.
Difuminar
+1 para requisitos de espacio cada vez mayores
hafichuk
@sam git siempre está creciendo. No puede podar la historia anterior a N años. Supongo que su sistema actual lo hace.
rds
1
Con respecto al aumento de tamaño, haga 'git gc' regularmente o antes de pasar a otro servidor (central). Sin esto, el repositorio de git puede crecer (mucho) más de lo que debería. Una vez tuve un repositorio git de 346 MB que puede reducirse a 16 MB.
Hendy Irawan
3

No lo he probado con un sistema completo, pero lo estoy usando para mis copias de seguridad de MySQL (con la opción --skip-extended-insert) y realmente me ha funcionado bien.

Tendrá problemas con los archivos de datos binarios (todo su contenido podría y cambiará) y podría tener problemas con la .gitcarpeta realmente grande. Recomendaría configurar un .gitignorearchivo y solo hacer una copia de seguridad de los archivos de texto que realmente sabe que necesita.

Scott Keck-Warren
fuente
También lo estoy usando para copias de seguridad de MySQL, con --extended-insert = false. Asegúrese de "git gc" regularmente o justo después de la confirmación.
Hendy Irawan
3

Una vez desarrollé una solución de respaldo basada en subversión. Si bien funcionó bastante bien (y git debería funcionar aún mejor), creo que hay mejores soluciones aquí.

Considero que rsnapshot es uno de los mejores, si no el mejor. Con un buen uso del enlace duro, tengo un servidor de archivos de 300 GB (con medio millón de archivos) con copias de seguridad diarias, semanales y mensuales de hasta un año. El espacio total utilizado en el disco es solo una copia completa + la parte incremental de cada copia de seguridad, pero gracias a los enlaces duros tengo una estructura de directorio "en vivo" completa en cada una de las copias de seguridad. En otras palabras, los archivos son accesibles directamente no solo en daily.0 (la copia de seguridad más reciente), sino incluso en daily.1 (yestarday) o semanalmente.2 (hace dos semanas), y así sucesivamente.

Compartiendo la carpeta de respaldo con Samba, mis usuarios pueden extraer el archivo de los respaldos simplemente apuntando su PC al servidor de respaldo.

Otra muy buena opción es rdiff-backup , pero como me gusta tener archivos siempre accesibles simplemente dirigiendo Explorer a \\ servername, rsnapshot fue una mejor solución para mí.

shodanshok
fuente
La última versión de rdiff-backup es de 2009. ¿Está extremadamente bien diseñado y no requiere actualización alguna o es simplemente un proyecto abandonado?
Mateusz Konieczny
No sé si se mantiene, pero básicamente está "hecho".
shodanshok
Al mirar savannah.nongnu.org/bugs/… parece que hubo alguna actividad tan tarde como 2015, pero se ignoran muchos informes de errores. Creo que lo clasificaré como un abandonado.
Mateusz Konieczny
2

Tuve la misma idea de hacer una copia de seguridad con git, básicamente porque permite copias de seguridad versionadas. Luego vi rdiff-backup , que proporciona esa funcionalidad (y mucho más). Tiene una interfaz de usuario realmente agradable (mira las opciones de CLI). Estoy muy feliz con eso. El --remove-older-than 2Wes muy bueno. Le permite eliminar versiones anteriores a 2 semanas. rdiff-backupalmacena solo diferencias de archivos.

Daniel
fuente
2

Soy extremadamente nuevo en git, pero ¿no son sucursales locales de forma predeterminada y debo enviarlas explícitamente a repositorios remotos? Esta fue una sorpresa desagradable e inesperada. Después de todo, ¿no quiero que todo mi repositorio local sea 'respaldado' en el servidor? Leyendo el libro git :

Sus sucursales locales no se sincronizan automáticamente con los controles remotos en los que escribe: debe empujar explícitamente las sucursales que desea compartir. De esa manera, puede usar ramas privadas para el trabajo que no desea compartir, y subir solo las ramas temáticas en las que desea colaborar.

Para mí, esto significaba que esas ramas locales, como otros archivos que no son git en mi máquina local, corren el riesgo de perderse a menos que se realicen copias de seguridad regularmente por algún medio que no sea git. Hago esto de todos modos, pero rompió mis suposiciones sobre git 'respaldar todo' en mi repositorio. ¡Me encantaría aclarar esto!

Matthew Cornell
fuente
1
Casi todo sobre git, con la excepción de los controles remotos, es local. Eso es por diseño. Puede empujar cosas a controles remotos, y debería, particularmente si se usa como respaldo como en este escenario. Para las ramas, nuevamente, sí, debe empujarlas explícitamente si desea que se agreguen a un control remoto. Para el desarrollo, esto es genial porque a menudo quieres probar algo, pero no es necesario que esa rama de prueba se conserve indefinidamente. Una vez que tenga lo que necesita de él, es probable que lo combine en una rama de desarrollo y en la rama de prueba.
LocalPCGuy
1

Encontré que esta es una buena metodología para mis cajas de desarrollo. Cambia de ser algo que debe respaldarse solo a un punto final de implementación.

Todos los manifiestos de configuración e instalación de paquetes se almacenan en Puppet, lo que permite una fácil implementación y actualizaciones de configuración. El directorio de Puppet está respaldado con git. Kickstart se usa para hacer la implementación inicial.

También mantengo un repositorio YUM personalizado para cualquier paquete que se esté desarrollando en ese momento. Esto tiene el beneficio adicional de que los paquetes con los que estamos trabajando no se dejan solo como archivos binarios desatendidos en el sistema local; si eso sucede y los archivos se destruyen, bueno. Alguien no siguió el procedimiento adecuado.

Tim Brigham
fuente
1

Es posible que desee consultar bup en github, que fue diseñado para servir el propósito de usar git como copia de seguridad.

mcantsin
fuente
la respuesta anterior ya apunta a esa misma herramienta (bup). serverfault.com/a/341213/303467 . ¿Lo más destacado?
Javier
1

Es un enfoque que se utiliza, tiene sentido.

Keepconf usa rsync y git para este trabajo, es una envoltura sobre estas herramientas para facilitar las cosas.

Solo necesita un servidor central con teclas ssh configuradas para acceder a los servidores de respaldo y algunas líneas en el archivo de configuración. Por ejemplo, este es mi propio archivo para mantener todos / etc / y los paquetes debian instalados:

[hosts]
192.168.1.10
192.168.1.11
192.168.1.12

[files]
/etc/*
/var/lib/dpkg/status

Con eso, tengo la copia de seguridad de rsync y el git commit.

Rfraile
fuente
0

Mi opinión personal es que esto es básicamente todo al revés. Estás empujando los archivos a una solución de respaldo, en lugar de sacarlos.

Mucho mejor sería centralizar la configuración del servidor en primer lugar, y luego tirar hacia abajo, usando algo como títere.

Dicho esto, puede funcionar, simplemente no creo que sea tan bueno.

Intente buscar en Backuppc: es bastante fácil de configurar y es francamente brillante.

Sirex
fuente
0

Funcionaría un poco, pero dos advertencias.

  1. Las adiciones de archivos no se recogerán automáticamente cuando realice la confirmación. Use --porcelean om git status para encontrar cosas nuevas para agregar antes de realizar la confirmación.

  2. ¿Por qué la molestia de un montaje remoto para .ssh? Podría ser frágil porque no sabrás que falló. Use un repositorio desnudo para el otro extremo con un inicio de sesión de clave ssh normal. Siempre que el repositorio esté vacío y solo presione desde una fuente, se garantiza que funcionará sin una fusión.

Andrés
fuente