Hacer una copy de security de un DB con Git, ¿una buena idea?

La forma en que lo veo descargando un DB de PostgeSQL en un gran file SQL y luego confirmando y enviando a un repository de Git remoto puede ser una excelente solución de respaldo: obtengo un historial de todas las versiones, hash, transporte seguro, unidireccional (muy difícil para desorderar y eliminar datos presionando), almacenamiento eficiente (suponiendo que no hay binarys) y ninguna posibilidad de que una nueva image corrompa la copy de security (que es el riesgo con rsync).

¿Alguien ha usado este enfoque, especialmente con pg, y puede compartir su experiencia? Trampas?

Aquí están los detalles del script completo sobre cómo hacer esto para postgres.

Crear un usuario de copy de security

Los scripts presuponen la existencia de un usuario llamado 'copy de security' que tiene acceso a todos (superusuario) o a la database específica. Las cnetworkingenciales se almacenan en el file .pgpass en el directory de inicio. Ese file se ve así (suponiendo que la contraseña es secreta).

~ / .pgpass

*:*:*:backup:secret 

Asegúrate de configurar la security correcta en .pgpass o se ignorará

 chmod 0600 ~/.pgpass 

Copia de security de una única base

Esto descarga una database específica.

backup.sh

 pg_dump dbname -U backup > backup.sql git add . git commit -m "backup" git push origin master 

Nota: es probable que no desee utilizar ninguna opción de split de files para el volcado de DB, ya que cualquier inserción / eliminación causará un efecto 'dominó' y cambiará todos los files creando más deltas / cambios en git.

Copia de security de todas las bases de datos en esta máquina

Este script va a volcar todo el clúster de la database (todas las bases de datos):

 pg_dumpall -U backup > backup.sql git add . git commit -m "backup" git push origin master 

Nota: es probable que no desee utilizar ninguna opción de split de files para el volcado de DB, ya que cualquier inserción / eliminación causará un efecto 'dominó' y cambiará todos los files creando más deltas / cambios en git.

Progtwigrlo para ejecutar

El último paso es agregar esto a un trabajo cron. Entonces, 'crontab -e' y luego agregue algo como lo siguiente (se ejecuta todos los días a la medianoche)

 # mh dom mon dow command # run postgres backup to git 0 0 * * * /home/ubuntu/backupdbtogit/backup.sh 

Restaurar

Si necesita restaurar la database, finalizará la versión que desea restaurar y luego pasará a la página. (más detalles al respecto aquí http://www.postgresql.org/docs/8.1/static/backup.html#BACKUP-DUMP-RESTORE )

para una sola database:

 psql dbname < infile 

para todo el grupo

 psql -f infile postgres 

Espero que ayude. Nada de esto fue particularmente complicado, pero siempre es tedioso search todas las partes.


Se estrelló en el server con RAM limitada

Experimenté un problema con el error de Git en un impulso. Esto se debió a que git usaba mucha memory, varias confirmaciones se habían copydo. Resolví la falla montando el server git repo en mi máquina local (que tiene mucha RAM). Monté el disco del server usando sshfs y luego me comprometí desde la máquina de mi estación de trabajo. Después de hacer esto, el server de memory baja reasumió commits sin ningún problema.

Una mejor alternativa es limitar el uso de memory de git durante el package (de ¿Hay alguna forma de limitar la cantidad de memory que utiliza "git gc"? ).

 git config --global pack.windowMemory "100m" git config --global pack.packSizeLimit "100m" git config --global pack.threads "1" 

Nota: Todavía no he intentado establecer un límite de memory, ya que no he tenido el problema de falla de inserción nuevamente.

Sin duda lo recomendaría. La gente lo ha estado haciendo también, principalmente en MySQL, pero no creo que haya mucha diferencia:

http://www.viget.com/extend/backup-your-database-in-git/

Otro enfoque es usar instantáneas de ZFS para copys de security.

http://www.makingitscale.com/2010/using-zfs-for-fast-mysql-database-backups.html

En general, debe utilizar una herramienta de copy de security para realizar copys de security y una herramienta de control de versiones para realizar el control de versiones. Son similares, pero no son lo mismo.

Algunas personas mezclan las dos, donde, por ejemplo, esencialmente todo lo que está en la database es la versión, y eso no tiene que ser incorrecto, pero tenga en claro lo que quiere.

Si está hablando solo del esquema, entonces probablemente no puede hacer mucho mal con "copys de security" usando Git. Pero si desea hacer una copy de security de los datos, las cosas pueden complicarse. Git no es muy bueno con files grandes. Puede usar algo como git-annex para abordar eso, pero luego necesita un mecanismo de copy de security separado para crear los files externos. Además, el uso de methods de copy de security "adecuados" como pg_dump o WAL archiving brinda otras ventajas, como la capacidad de restaurar subsets de bases de datos o realizar una recuperación puntual.

Probablemente también quiera hacer copys de security de otras partes de un sistema operativo. ¿Cómo haces eso? Preferiblemente no con un sistema de control de versiones, ya que no conservan tan bien los permissions de files, las marcas de time y los files especiales. Por lo tanto, tendría sentido vincular la copy de security de su database con su sistema de respaldo existente.

Hice esto en $ day_job, pero es con MySQL.

Tuve que escribir un script para dividir el file mysqldump monolítico en files individuales para que pueda get buenos informes de diferencias y también porque git maneja mejor los files pequeños.

El script divide el file sql monolítico en esquemas de tabla sql individuales y datos.

También tuve que asegurarme de que cada statement insertada de sql no esté en la misma línea para poder tener informes de diferencias legibles.

Una ventaja de mantener el volcado en git es que puedo ejecutar "git log –stat" para get una visión general de qué tablas cambiaron entre las revisiones de la "copy de security".