¿Es una buena idea hacer una copia de seguridad de una base de datos MySQL en Git?

Estoy tratando de mejorar la situación de la copia de seguridad de mi aplicación. Tengo una aplicación Django y una base de datos MySQL. Leí un artículo que sugiere hacer una copia de seguridad de la base de datos en Git.

Por un lado, me gusta, ya que mantendrá una copia de los datos y el código sincronizados.

Pero Git está diseñado para el código, no para los datos. Como tal, hará un montón de trabajo adicional para diferenciar el volcado de MySQL en cada confirmación, lo que no es realmente necesario. Si comprimo el archivo antes de almacenarlo, ¿git todavía diferirá los archivos?

(El archivo de volcado está actualmente sin comprimir 100MB, 5.7MB cuando está comprimido).

Editar: el código y las definiciones del esquema de la base de datos ya están en Git, en realidad son los datos los que me preocupan hacer una copia de seguridad ahora.

Antes de perder cualquier dato, permítame intentar presentar una perspectiva de administrador de sistemas a esta pregunta.

Solo hay una razón por la que creamos copias de seguridad: para hacer posible la restauración cuando algo sale mal, como siempre ocurrirá. Como tal, un sistema de respaldo adecuado tiene requisitos que van mucho más allá de lo que git puede manejar razonablemente.

Estos son algunos de los problemas que puedo prever al intentar hacer una copia de seguridad de su base de datos en git:

• El repositorio crecerá dramáticamente con cada "copia de seguridad". Dado que git almacena objetos completos (aunque comprimidos) y luego los difunde más tarde (por ejemplo, cuando ejecuta git gc) , y mantiene el historial para siempre , tendrá una gran cantidad de datos almacenados que realmente no necesita ni desea. Es posible que deba limitar la cantidad o el período de retención de las copias de seguridad que realiza para ahorrar espacio en el disco o por razones legales, pero es difícil eliminar las revisiones anteriores de un repositorio git sin mucho daño colateral.
• La restauración se limita a los puntos de tiempo que ha almacenado en el repositorio, y dado que los datos son tan grandes, retroceder más de una cantidad de tiempo trivial puede ser lento. Un sistema de copia de seguridad diseñado para este propósito limita la cantidad de datos almacenados mientras que potencialmente proporciona más granularidad, y proporciona restauraciones más rápidas, reduciendo el tiempo de inactividad en caso de desastre. Las soluciones de respaldo compatibles con la base de datos ( ejemplo ) también pueden proporcionar respaldo continuo , asegurando que no se pierda una sola transacción.
• Es probable que los commits también sean lentos y se vuelvan más lentos a medida que crece la base de datos. Recuerde que git es esencialmente un almacén de datos de valores clave mapeado en un sistema de archivos y, por lo tanto, está sujeto a las características de rendimiento del sistema de archivos subyacente. Es posible que este período de tiempo exceda eventualmente el intervalo de respaldo, y en ese punto ya no puede cumplir con su SLA. Los sistemas de copia de seguridad adecuados también tardan más en hacer una copia de seguridad a medida que crecen los datos, pero no de manera tan dramática, ya que administrarán automáticamente su propio tamaño en función de la política de retención que haya configurado.

A pesar del hecho de que aparentemente hay varias cosas interesantes que puede hacer con un volcado de base de datos si lo coloca en git, en general no puedo recomendarlo con el propósito de mantener copias de seguridad. Especialmente porque los sistemas de respaldo están ampliamente disponibles (y muchos son incluso de código abierto) y funcionan mucho mejor para mantener sus datos seguros y hacer posible la recuperación lo más rápido posible.

Mis dos centavos: no creo que sea una buena idea. GIT hace algo como "almacenar instantáneas de un conjunto de archivos en diferentes momentos", por lo que puede usar perfectamente GIT para algo así, pero eso no significa que deba hacerlo . GIT está diseñado para almacenar el código fuente, por lo que le faltaría la mayor parte de su funcionalidad y estaría intercambiando mucho rendimiento por solo un poco de conveniencia.

Permítame suponer que la razón principal por la que está pensando en esto es "mantener una copia de los datos y el código sincronizados", y que esto significa que le preocupa que la versión 2.0 de su código necesite un esquema de base de datos diferente a la versión 1.0 . Una solución más simple sería almacenar el esquema de la base de datos, como un conjunto de scripts SQL con CREATEdeclaraciones, a lo largo del código fuente en su repositorio Git. Luego, una parte de su procedimiento de instalación sería ejecutar esos scripts en un servidor de base de datos previamente instalado.

El contenido real de esas CREATEtablas just -d no tiene nada que ver con la versión de su código fuente. Imagine que instala su software, versión 1.0, en el servidor A y en el servidor B, que son utilizados en diferentes compañías por diferentes equipos. Después de algunas semanas, el contenido de las tablas será muy diferente, aunque los esquemas sean exactamente los mismos.

Como desea hacer una copia de seguridad del contenido de la base de datos, le sugiero que utilice un script de copia de seguridad que etiquete el volcado de copia de seguridad con la versión actual del software al que pertenece el volcado. El script debe estar en el repositorio GIT (para que tenga acceso a la cadena de versión del código fuente), pero los volcados en sí no pertenecen a un sistema de control de versiones.

EDITAR :

Después de leer la publicación original que motivó la pregunta , me parece una idea aún más dudosa. El punto clave es que el mysqldumpcomando transforma el estado actual de una base de datos en una serie de INSERTinstrucciones SQL , y GIT puede diferenciarlas para obtener solo las filas actualizadas de la tabla.

La mysqldumpparte es sólida, ya que este es uno de los métodos de copia de seguridad enumerados en la documentación de MySQL. La parte GIT es donde el autor no nota que los servidores de bases de datos mantienen un registro de transacciones para recuperarse de fallas, incluido MySQL . Está utilizando este registro , no GIT, que debe crear copias de seguridad incrementales para su base de datos. Esto tiene, ante todo, la ventaja de que puede rotar o vaciar los registros después de la recuperación, en lugar de hinchar un repositorio GIT en el infinito y más allá ...

Personalmente, no creo que sea una buena idea usar un sistema de versión de control de origen para almacenar los archivos de copia de seguridad, porque el control de versión GIT está diseñado para archivos de datos, no para archivos binarios o archivos de volcado como un archivo de volcado de copia de seguridad MySQL. El hecho de que pueda hacerlo no significa automáticamente que deba hacerlo. Además, su repositorio, considerando una nueva copia de seguridad de la base de datos para cada nueva confirmación, crecerá drásticamente, utilizando mucho espacio en el disco duro y el rendimiento de GIT se verá afectado, resultando en un sistema de control de fuente lento. Para mí, está bien ejecutar una estrategia de respaldo y siempre he preparado un archivo de respaldo cuando necesita restaurar la base de datos cuando algo en su código falla, pero las herramientas de control de fuente no están hechas para almacenar datos binarios.

Por estas razones, no veo ninguna utilidad para almacenar los archivos de copia de seguridad para el día 1 y para el día 2, y luego ver las diferencias entre los dos archivos de copia de seguridad. Requerirá mucho trabajo extra e inútil. En lugar de usar GIT para almacenar copias de seguridad de la base de datos cuando confirma un nuevo código, almacene las copias de seguridad de la base de datos en una ruta diferente, separadas por fecha y hora, e inserte en su código alguna referencia a las nuevas copias de seguridad de la base de datos creadas para cada versión, usando las etiquetas, como alguien ya sugirió.

Mi nota final sobre las copias de seguridad de la base de datos y GIT: Un administrador de base de datos, cuando necesita restaurar una base de datos porque se han perdido algunos datos, no necesita verificar las diferencias entre el archivo de respaldo para el día 1 y el archivo de respaldo para el día 2, solo necesita saber cuál es el último archivo de respaldo que le permitirá restaurar la base de datos, sin ningún error y pérdida de datos, reduciendo el tiempo de inactividad. De hecho, la tarea de un administrador de base de datos es hacer que los datos estén disponibles para la recuperación lo antes posible, cuando el sistema, por alguna razón, falla. Si almacena las copias de seguridad de la base de datos en GIT, vinculadas a sus confirmaciones, no permite que el administrador de la base de datos restaure los datos rápidamente, porque sus copias de seguridad están limitadas a los puntos de tiempo que almacenó en el repositorio de GIT y para reducir el tiempo de inactividad del sistema,

Entonces, no recomiendo almacenar las copias de seguridad utilizando GIT, utilice en su lugar una buena solución de software de copia de seguridad (hay algunas de ellas aquí ), que proporcionará más granularidad y le permitirá mantener sus datos seguros y protegidos, y hacer que su Recuperación de datos simple y rápida en caso de desastres.

No debe almacenar datos binarios en Git, especialmente en la base de datos.
Los cambios de código y los cambios de DML de la base de datos son cosas totalmente diferentes.

MySQL y Oracle pueden escribir registros de archivos con el propósito de restaurarlos en cualquier momento. Simplemente haga una copia de seguridad de esos registros en un lugar seguro y estará bien.

Usar Git para hacer una copia de seguridad de estos "registros de archivo" no tiene sentido. Los registros de archivo en entornos de producción son bastante pesados ​​y deben eliminarse después de realizar copias de seguridad completas regulares. También es inútil ponerlos en git, ya que en cierto sentido ya son un repositorio.