Git (concrétamente bitbucket) como sistema backup

[Alberto Gimeno Brieba]

Buenas,

Un tema más técnico de lo que estoy acostumbrado a comentar por esta lista.

Me pregunto si habéis utilizado git como sistema de backups, o si os lo habéis planteado. Es una idea que me surgió el otro día, y buscando un poco se ve que no soy el primero :P El funcionamiento y sus ventajas serían:

- Git es rápido

- Maneja bien ficheros binarios

- Es distribuido: puedes replicar las copias en diferentes repositorios de manera muy transparente.

- Es seguro, a nivel de protocolo puede ir cifrado y los SHA1 de los commits aseguran la integridad.

- Tendrías backups incrementales (ej: si tu BD ocupa 1Gb y aumenta 10Mb cada día y haces snapshots todos los días en una semana acabarías con más de 7Gb, pero con una copia incremental tendrías 1Gb y pico).

- Puedes volver atrás en el tiempo de forma sencilla.

- Puedes crear un clon del entorno de producción en un plis. (clon, nunca mejor dicho :)

- Si externalizas el repositorio de git a un servicio tipo github o bitbucket te ahorras incluso el mantenimiento del almacenamiento de las copias.

El principal inconveniente que le encontraba era el volumen de almacenamiento. Pero veo que bitbucket da repositorios privados gratuitos sin límite de almacenamiento!!

https://bitbucket.org/account/signup/?plan=5_users

Mi idea sería meter tanto los dumps de la base de datos como ficheros generados por el usuario (uploads de imágenes y tal), y correr un cron que vaya haciendo commits y push. En otro repositorio diferente estaría el código fuente de la aplicación.

Qué problemas le veis? Le veis alguna ventaja más?

Saludos!

PD: ya que voy a usar redis el backup es todavía más sencillo ya que el dump es atómico.

---
Alberto Gimeno Brieba
http://twitter.com/gimenete
http://gimenete.net

[Fernando Val]

De cara a protección de datos? Es seguro?

--
Fernando Val
Designer & Front-end Samurai
http://www.fernandoval.es

Twitter: http://twitter.com/#!/aaromnido

[Luis Miguel Morillas]

El día 20 de febrero de 2012 11:57, Alberto Gimeno Brieba
<gime...@gmail.com> escribió:

Yo uso bitbucket con mercurial pero sólo para gestión de código, no
para backups de datos. La clave sería ver la eficiencia de git con los
binarios y asegurarte de que no vas a provocar inconsistencias porque
git es tan flexible que puedes no dejar rastro de algunos commits.

Saludos,

-- luismiguel

[Iván Loire]

Para evitar esos problemas le puedes pasar antes un sencillo script de cifrado asimétrico (para no dejar la clave en el mismo servidor)

iván

2012/2/20 Fernando Val <aaro...@gmail.com>

--
ivan loire
web/software developer.

iloire.com

[Fernando Val]

Pero no solo es cuestión de clave. Y los datos personales? No sé, igual estoy quivocado.

[Iván Loire]

Supongo que eso lo tendría que decir un abogado, pero lo de proteger esa información mediante cifrado entiendo que es una responsabilidad ineludible.

[Alberto Gimeno Brieba]

Buenas,

No le veo mayor inconveniente. En ppio tienes el mismo problema que en cualquier otra plataforma que uses de backups, cloud hosting, etc. Tienes el mismo problema que si haces backups en Amazon S3, o tu proveedor de hosting habitual. En definitiva también tu aplicación estará corriendo en algún servidor externo (a no ser que la hospedes tú que no es lo común). Y los bakcups elijas lo que elijas normalmente también los tendrás en un servidor externo.

Saludos.

---
Alberto Gimeno Brieba
http://twitter.com/gimenete
http://gimenete.net

2012/2/20 Iván Loire <iv...@iloire.com>

[Daniel Navarro]

Realmente el tema de la privacidad por los datos que subas a git o cualquier otro repositorio, entiendo que no es diferente a los que existen en la base de datos de una web, por ejemplo de e-commerce.

En ese caso, lo que hay que exigir legalmente, es que la empresa que proporciona el hosting cumpla con los requisitos de la LOPD. Si la empresa que presta el servicio son empresas españolas, todas están obligadas a hacerlo, así que en ese caso no hay problema, pero como siempre, es complicado que una empresa española preste ese servicio...

--

________________________________

Daniel Navarro Murillo
NV Ingeniería
C/ Diputados 11, local. 50004 Zaragoza (Spain)

tel.: +34 976 432 838 / +34 652 823 614
mail: dnav...@nvingenieria.com
web: www.nvingenieria.com

 

 

Este correo electronico y en su caso, cualquier fichero anexo al mismo, puede contener informacion de caracter confidencial exclusivamente dirigida a su(s) destinatario(s). En caso de haber recibido este correo electronico por error, le informamos de la prohibición legal de divulgacion, archivo, alteracion, copia o distribucion a terceros del mismo. Así mismo, le rogamos notifique inmediatamente esta circunstancia a la dirección del remitente o a la dirección in...@nvingenieria.com. Le agradecemos de antemano su colaboracion.

Information in this email and any attachments is confidential and intended solely for the use of the individual(s) to whom it is addressed. If you are not the named recipient you should not keep, disseminate, distribute, copy or alter this email and shall bear the sole responsibility and liability for any unauthorized use. If you are not the addressee indicated in this message, you should permanently delete this message and its attachments and notify it to the sender or by in...@nvingenieria.com. We thank you in advance for your collaboration.

[Dani Latorre]

Según he leído en alguna ocasión en otros foros, con que la empresas de US cumplan la Safe Harbor ya no habría ningún problema legal. No sé si es el caso de bitbucket o no, Amazon por ejemplo creo que sí cumple la directiva.

http://en.wikipedia.org/wiki/International_Safe_Harbor_Privacy_Principles

--
Daniel Latorre
My website: http://www.danilat.com/

[Alberto Gimeno Brieba]

Gracias por los comentarios sobre la LOPD.

¿Como solución técnica cómo lo veis? (en todo caso siempre puedes montar un servidor git en cualquier otro lado, pero he comentado lo de bitbucket porque podía salirte gratis :)

---
Alberto Gimeno Brieba
http://twitter.com/gimenete
http://gimenete.net

2012/2/20 Dani Latorre <dani...@gmail.com>

[Daniel Navarro]

Yo para código uso github, pero para los dumps de las bases de datos no me lo había planteado nunca.

Para eso he aplicado varias soluciones, pero la verdad, de momento no he encontrado la solución que sirva para todo (y si tiene que ser gratis, menos aún).

Al final normalmente opto por pagar un poco más y que se la empresa de hosting la que me de ese servicio, pero también suelo hacer dumps con un script y me los bajo a local (a un ordenador viejo con un disco duro externo). Luego los voy borrando de forma que siempre tengo diarios de los de la última semana, semanales del último mes y mensuales hasta los seis meses. También dejo algunos en el propio servidor.

Cuando la base de datos empieza a ser grande, siempre opto por contratar alguna solución de backup en la propia empresa de hosting. Normalmente espacio en un disco NFS al que voy haciendo copias de todo con un script (ficheros y base de datos).

Si al final te decides por github, ya nos contarás.

[Iván Loire]

A mi cuando me lo comentaste me pareció una buena idea.

De hecho la iba a poner en práctico en el corto plazo.

El primero que lo haga que cuente :D

saludos!

iván

2012/2/20 Alberto Gimeno Brieba <gime...@gmail.com>

[Alberto Gimeno Brieba]

Otra ventaja que se me ha olvidado comentar es que desaparece el problema de borrar backups viejos.

---
Alberto Gimeno Brieba
http://twitter.com/gimenete
http://gimenete.net

2012/2/20 Iván Loire <iv...@iloire.com>

[Fernando Pérez]

He tratado de buscar informaci�n de c�mo maneja los binarios GIT, pero
no he tenido mucha suerte.

Cuando dices que Git maneja bien ficheros binarios, a qu� te refieres ?

Lo digo porque en lo �nico que se me ocurre que puede haber problemas es
en los binarios y los dump de la base de datos, o los comprimes u
ocupar�n mucho espacio, con lo que se convierten en binarios. Las
fotos, por descontado.

Quiz� una mezcla de simple almacenamiento de archivos (backups
incrementales de base de datos, im�genes, etc..) y
http://git-annex.branchable.com/ Podr�a ser una soluci�n intermedia.

O quiz� es que ando un poco perdido con los binarios y c�mo los manejan
los repositorios, porque nunca los he utilizado para esto.

Salu2...

El 20/02/2012 11:57, Alberto Gimeno Brieba escribi�:
> Buenas,
>
> Un tema m�s t�cnico de lo que estoy acostumbrado a comentar por esta
> lista.
>
> Me pregunto si hab�is utilizado git como sistema de backups, o si os
> lo hab�is planteado. Es una idea que me surgi� el otro d�a, y buscando

> un poco se ve que no soy el primero :P El funcionamiento y sus

> ventajas ser�an:
>
> - Git es r�pido

> - Maneja bien ficheros binarios
> - Es distribuido: puedes replicar las copias en diferentes
> repositorios de manera muy transparente.
> - Es seguro, a nivel de protocolo puede ir cifrado y los SHA1 de los
> commits aseguran la integridad.

> - Tendr�as backups incrementales (ej: si tu BD ocupa 1Gb y aumenta
> 10Mb cada d�a y haces snapshots todos los d�as en una semana acabar�as
> con m�s de 7Gb, pero con una copia incremental tendr�as 1Gb y pico).
> - Puedes volver atr�s en el tiempo de forma sencilla.
> - Puedes crear un clon del entorno de producci�n en un plis. (clon,

> nunca mejor dicho :)
> - Si externalizas el repositorio de git a un servicio tipo github o
> bitbucket te ahorras incluso el mantenimiento del almacenamiento de
> las copias.
>
> El principal inconveniente que le encontraba era el volumen de
> almacenamiento. Pero veo que bitbucket da repositorios privados

> gratuitos sin l�mite de almacenamiento!!
> https://bitbucket.org/account/signup/?plan=5_users
>
> Mi idea ser�a meter tanto los dumps de la base de datos como ficheros
> generados por el usuario (uploads de im�genes y tal), y correr un cron

> que vaya haciendo commits y push. En otro repositorio diferente

> estar�a el c�digo fuente de la aplicaci�n.
>
> Qu� problemas le veis? Le veis alguna ventaja m�s?
>
> Saludos!
>
> PD: ya que voy a usar redis el backup es todav�a m�s sencillo ya que
> el dump es at�mico.

[Alberto Gimeno Brieba]

Buenas,

La unidad mínima de contenido interna para git se llama blob (que supongo que viene de binary large object como en sql). "A "blob" object is nothing but a chunk of binary data"

http://book.git-scm.com/1_the_git_object_model.html

En esta pregunta en StackOverflow también lo comentan:

http://stackoverflow.com/questions/3601672/how-does-git-deal-with-binary-files

Aquí más:

http://stackoverflow.com/questions/4697216/is-git-good-with-binary

Supongo que aunque tengas que comprimir un dump para que ocupe menos, largas porciones del fichero se mantendrán igual y será eficiente en el repositorio. En mi caso (redis) el dump ya es binario.

Saludos!

---
Alberto Gimeno Brieba
http://twitter.com/gimenete
http://gimenete.net

2012/2/20 Fernando Pérez <fpe...@percea.com>

He tratado de buscar información de cómo maneja los binarios GIT, pero no he tenido mucha suerte.

Cuando dices que Git maneja bien ficheros binarios, a qué te refieres ?

Lo digo porque en lo único que se me ocurre que puede haber problemas es en los binarios y los dump de la base de datos, o los comprimes u ocuparán mucho espacio, con lo que se convierten en binarios.  Las fotos, por descontado.

Quizá una mezcla de simple almacenamiento de archivos (backups incrementales de base de datos, imágenes, etc..) y http://git-annex.branchable.com/  Podría ser una solución intermedia.

O quizá es que ando un poco perdido con los binarios y cómo los manejan los repositorios, porque nunca los he utilizado para esto.

Salu2...

El 20/02/2012 11:57, Alberto Gimeno Brieba escribió:

Buenas,

Un tema más técnico de lo que estoy acostumbrado a comentar por esta lista.

Me pregunto si habéis utilizado git como sistema de backups, o si os lo habéis planteado. Es una idea que me surgió el otro día, y buscando un poco se ve que no soy el primero :P El funcionamiento y sus ventajas serían:

- Git es rápido

- Maneja bien ficheros binarios
- Es distribuido: puedes replicar las copias en diferentes repositorios de manera muy transparente.
- Es seguro, a nivel de protocolo puede ir cifrado y los SHA1 de los commits aseguran la integridad.

- Tendrías backups incrementales (ej: si tu BD ocupa 1Gb y aumenta 10Mb cada día y haces snapshots todos los días en una semana acabarías con más de 7Gb, pero con una copia incremental tendrías 1Gb y pico).
- Puedes volver atrás en el tiempo de forma sencilla.
- Puedes crear un clon del entorno de producción en un plis. (clon, nunca mejor dicho :)

- Si externalizas el repositorio de git a un servicio tipo github o bitbucket te ahorras incluso el mantenimiento del almacenamiento de las copias.

El principal inconveniente que le encontraba era el volumen de almacenamiento. Pero veo que bitbucket da repositorios privados gratuitos sin límite de almacenamiento!!
https://bitbucket.org/account/signup/?plan=5_users

Mi idea sería meter tanto los dumps de la base de datos como ficheros generados por el usuario (uploads de imágenes y tal), y correr un cron que vaya haciendo commits y push. En otro repositorio diferente estaría el código fuente de la aplicación.

Qué problemas le veis? Le veis alguna ventaja más?

Saludos!

PD: ya que voy a usar redis el backup es todavía más sencillo ya que el dump es atómico.

[Iván Loire]

El otro dia me encontré con un artículo interestante sobre git relacionado con este tema. muy reciente además:

http://devsundar.github.com/2012/02/09/Uses-of-git/

Me acordé de ti Alberto al leerlo :)

iván

2012/2/20 Alberto Gimeno Brieba <gime...@gmail.com>

Buenas,

[Fernando Pérez]

Le echo un ojo a esto que envías y a lo que manda Iván.

Gracias.

[Alberto Gimeno Brieba]

Buenas,

Hace ya años leí este libro que recomiendo si queréis conocer las interioridades de git:

http://peepcode.com/products/git-internals-pdf

Por aquel entonces flipé. Está concebido (o al menos muy influenciado) casi como un sistemas de ficheros. Sin ir más lejos Linus Torvalds, creador de git, anteriormente hizo los primeros sistemas de ficheros de Linux. Las herramientas en línea de comandos son solamente "clientes" del "sistema de ficheros" que se almacena dentro de un directorio ".git". No es como en SVN (por ejemplo) donde en el .svn se guarda la versión justo anterior y ya está. Si entráis en un directorio .git veréis una estructura bastante compleja.

Pero bueno, en definitiva, lo que quería comentar es que muchas de las características de git lo hacen parecer un sistema de ficheros con versionado y distribuido. Vamos, que gestiona muy bien cualquier tipo de contenido (binario y texto) y no me extraña que se use para hacer wikis, bases de datos, CDN, etc.

Gracias por el enlace Iván!

Mi principal preocupación no obstante es hasta qué punto es fiable hacer "git add" en cualquier momento. Lo mejor en todo caso es asegurarse que el dump de la base de datos no esté a mitad, etc. Y también me preocupa que bloquee el acceso algún fichero en algún caso mientras haga "git add" o commit o lo que sea. Si me entero de algo más en este sentido ya os comentaré.

[Daniel Navarro]

Personalmente, eso que comentas es lo que más me gusta de git y es lo que me hizo cambiar desde CVS (sí, lo se, es algo prehistórico y ya me tocaba cambiar). 

Realmente la diferencia con SVN o con CVS es en el trabajo en local. En todos los sistemas se guardan copias incrementales, pero como dices, en SVN (o CVS) cuando trabajas en local sólo tienes la última copia.

En Git lo que tienes en local cuando te bajas el repositorio es un clon del repositorio completo y puedes trabajar con él normalmente aunque no estés online: ver el histórico, comparar con versiones anteriores, recuperar versiones anteriores, hacer commits... todo. Luego, cuando estás online, haces se sincronizan ambas copias (git push).

El único problema con el trabajo con binarios es si hay más de una persona trabajando en el proyecto, ya que git no sabe hacer los merges de ficheros binarios (sólo faltaría), pero entiendo que si lo quieres como sistema de backup, no vas a tener ese problema.

El tema de la compresión si que me 'preocupa' un poco más. Si comprimes dos dumps de la misma base de datos, con sólo unas pocas diferencias, verás que los binarios generados son muy diferentes. No se si git será capaz de encontrar similitudes más eficazmente que utilidades de comparación como diff o winmerge. 

Otra opción, aunque insisto en que son elucubraciones, sería enviar el dump sin comprimir. Al fin y al cabo, git ya comprime los datos en el repositorio, y quizá ganes en que luego sí es capaz de manejar mejor las diferencias. Eso sí, no quiero pensar lo que te costará hacer el primer push con un fichero de 1GB.

Muy buenos los enlaces... yo os dejo otro: http://progit.org/book/

[Diego Mariño]

acabo de encontrar este thread en HN… para almacenar dumps de MySQL
parece práctico

http://news.ycombinator.com/item?id=3619909

2012/2/20 Daniel Navarro <dnav...@nvingenieria.com>:

[Alberto Gimeno Brieba]

Qué bueno, el repositorio entero ocupa menos que un único dump.

---
Alberto Gimeno Brieba
http://twitter.com/gimenete
http://gimenete.net

2012/2/22 Diego Mariño <di...@ducksboard.com>