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

Antes de perder cualquier información, permítame tratar de presentar una perspectiva de administrador de sistemas a esta pregunta.

Solo hay una razón por la que creamos copias de seguridad: para que sea posible restaurar cuando algo sale mal, ya que invariablemente lo hará. 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". Desde git almacena objetos completos (aunque esté comprimido) y luego los difunde más tarde (por ejemplo, cuando ejecuta git gc ) , y mantiene el historial para siempre , lo hará tiene una gran cantidad de datos almacenados que en realidad no necesita o ni siquiera 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 elimine las revisiones antiguas de un repositorio de git sin muchos daños colaterales.
• La restauración se limita a los puntos en el tiempo que ha almacenado en el repositorio, y como los datos son tan grandes, retroceder más de una cantidad de tiempo trivial puede ser lento. Un sistema de respaldo diseñado para este propósito limita la cantidad de datos almacenados y, al mismo tiempo, brinda mayor granularidad y brinda restauraciones más rápidas, lo que reduce el tiempo de inactividad en caso de un desastre. Las soluciones de copia de seguridad compatibles con la base de datos ( ejemplo ) también pueden proporcionar una copia de seguridad continua , lo que garantiza que ni una sola transacción se pierde.
• Es probable que los compromisos también sean lentos y se vuelvan más lentos a medida que la base de datos crece. Recuerde que git es esencialmente un almacén de datos clave-valor asignado a 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 tiempo supere el intervalo de copia de seguridad, y en ese momento ya no puede cumplir con su SLA. Los sistemas de copia de seguridad adecuados también tardan más tiempo en realizar copias de seguridad a medida que los datos crecen, pero no tan dramáticamente, 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 cosas interesantes que puedes hacer con un volcado de base de datos si lo pones en git, en general no puedo recomendarlo para mantener copias de seguridad. Especialmente desde que los sistemas de copia de seguridad están ampliamente disponibles (y muchos son incluso de código abierto) y trabajan mucho mejor para mantener sus datos seguros y hacerlos más accesibles. Es posible recuperar lo más rápido posible.

Mis dos centavos: No creo que sea una buena idea. GIT hace algo así como "almacenar instantáneas de un conjunto de archivos en diferentes momentos en el tiempo", por lo que puede usar GIT perfectamente para algo así, pero eso no significa que deba . GIT está diseñado para almacenar 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 comodidad.

Permítame asumir 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. que la versión 1.0. Una solución más sencilla sería almacenar el esquema de la base de datos, como un conjunto de scripts SQL con declaraciones CREATE , 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 instalado previamente.

El contenido real de esas tablas CREATE -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 iguales.

Ya que desea hacer una copia de seguridad del contenido de la base de datos, le sugiero que utilice un script de copia de seguridad que etiqueta 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 no pertenecen a un sistema de control de versiones.

EDIT :

Después de leer la publicación original que motivó la pregunta , creo que esto es aún más dudoso. idea. El punto clave es que el comando mysqldump transforma el estado actual de una base de datos en una serie de sentencias SQL INSERT , y GIT puede diferenciarlas para obtener solo las filas de la tabla actualizadas.

La parte mysqldump es correcta, ya que es uno de los métodos de copia de seguridad listado en la documentación de MySQL. La parte de GIT es donde el autor no se da cuenta de que los servidores de bases de datos mantienen un registro de transacciones para recuperarse de bloqueos, incluyendo MySQL . Es utilizando este registro , no GIT, lo que debería Crea copias de seguridad incrementales para tu 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 inflar un repositorio GIT hasta 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 de GIT está diseñado para archivos de datos, no para archivos binarios o volcados como un archivo de volcado de copia de seguridad de MySQL . El hecho de que puedas hacerlo no significa automáticamente que debas hacerlo. Además, su repositorio, considerando una nueva copia de seguridad de la base de datos para cada nueva confirmación, crecerá dramáticamente, utilizando una gran cantidad de 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 copia de seguridad y tener siempre listo un archivo de copia de seguridad cuando necesite restaurar la base de datos cuando algo de su código no funcione, pero las herramientas de control de origen no están diseñadas para almacenar datos binarios.

Por estos motivos, 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á un montón de trabajo extra e inútil. En lugar de usar GIT para almacenar las 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 la 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 copia de seguridad 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 ni pérdida de datos, lo que reduce 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, ya que sus copias de seguridad están limitadas a los puntos en el tiempo que almacenó en el repositorio de GIT, y reduce el tiempo de inactividad. del sistema, porque el rendimiento de su repositorio GIT se reducirá drásticamente al tener una gran cantidad de datos para almacenar.

Entonces, no recomiendo almacenar las copias de seguridad utilizando GIT, en su lugar use 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 sea 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 fin de ser restaurados 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 los entornos de producción son bastante pesados y deben eliminarse después de realizar copias de seguridad completas con regularidad. También es inútil ponerlos en git, ya que en cierto sentido ya son un repositorio.