¿Es viable manejar copias de seguridad de MySQL con git?

Question

Hoy tuve esta idea genial para hacer una copia de seguridad de mi base de datos: poner el archivo de volcado en un repositorio de git y luego confirmarlo en cada volcado para que tenga la copia más reciente pero pueda retroceder fácilmente a cualquier copia de seguridad anterior. También puedo obtener fácilmente una copia del repositorio de forma regular para mantener una copia en mi propia computadora como copia de seguridad de las copias de seguridad. Definitivamente suena ingenioso.

Sin embargo, soy consciente de que las soluciones inteligentes a veces tienen fallas fundamentales. ¿Qué tipo de problemas puedo llegar a almacenar mysqldump diffs en git? ¿Vale la pena? ¿Qué hace la mayoría de la gente para tener múltiples copias de seguridad de bases de datos en el servidor y mantener copias redundantes en otro lugar?

Answer 1

Este enfoque me parece bien. Uso Git para hacer una copia de seguridad de mis propios datos importantes.

Tenga en cuenta que no está almacenando diffs: Git almacena de manera efectiva las instantáneas del estado del directorio con cada confirmación. Puede generar el diff de dos commits, pero el mecanismo de almacenamiento real no tiene nada que ver con diff.

Answer 2

Normalmente, no conserva todas las copias de seguridad (o instantáneas) para siempre. Un repositorio de git hace guarda cada registro que hayas realizado. Si alguna vez decide eliminar las revisiones antiguas (digamos revisiones de un mes a una vez por semana, de un año a una vez al mes, etc.) tendrá que hacerlo con git filter-branch, que reescribirá todo el historial. Luego, git gc para eliminar las revisiones no deseadas.

Teniendo en cuenta que las fortalezas de git son el control de versiones distribuidas y los flujos de trabajo de parche/ramificación complejos (ninguno de los cuales se aplica a instantáneas o copias de seguridad) consideraría usar un VCS diferente con un historial más maleable.

Answer 3

En teoría, esto funcionará, pero comenzará a tener problemas cuando los volcados de la base de datos se agranden.

Git no tiene ningún límite de tamaño de archivo, pero diferirá el contenido de su último volcado con el almacenado previamente en el repositorio, que requerirá al menos tanta memoria como los tamaños de ambos archivos sumados, así que me imagino que comenzará a ser muy lento, muy rápido con archivos de más de 100 MB (o incluso 10 MB).

Git no está hecho para tratar con archivos de este tipo (es decir, archivos de big data en lugar de código fuente), así que creo que esto es fundamentalmente una mala idea. Sin embargo, podría usar algo como Dropbox para almacenar los volcados, lo que le permitirá guardar el historial de versiones, pero está más adaptado a los archivos que no se pueden diferir efectivamente.

Answer 4

Si está utilizando MySQL (y posiblemente otros) y tiene habilitado el registro binario, puede considerar configurar un repositorio git para el directorio de su registro bin y desarrollar una estrategia para confirmar las actualizaciones regularmente en el binlog.

En MySQL, el binlog almacena las consultas que cambian los datos a cualquier tabla en la base de datos. Si sincroniza sus confirmaciones con volcados regulares de la base de datos, debe tener una forma versionada para restaurar los datos.

Honestamente, creo que simplemente usar las herramientas nativas de MySQL probablemente sea una mejor solución, pero lo que he esbozado aquí te permite versionar tus datos de MySQL, que es lo que creo que estabas buscando en primer lugar.