GIT como herramienta de respaldo

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ó?

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.

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

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.

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.

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.

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.

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.

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í.

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.

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!

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.

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

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.

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.

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.