¿Es viable manejar copys de security de MySQL con git?

Hoy tuve esta muy buena idea para hacer una copy de security de mi database: poner el file de volcado en un repository de git, luego comprometerlo en cada volcado para que tenga la copy más reciente, pero pueda retroceder fácilmente a cualquier copy de security anterior. También puedo get fácilmente una copy del repository de forma regular para mantener una copy en mi propia computadora como copy de security de las copys de security. 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 copys de security de bases de datos en el server y mantener copys networkingundantes en otro lugar?

Normalmente no conservas todas las copys de security (o instantáneas) para siempre. Un repository git mantiene cada logging que hagas. 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.

Dado que los puntos fuertes 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 copys de security) consideraría usar un VCS diferente con un historial más maleable.

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

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

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

Git no tiene ningún límite de tamaño de file, pero diferirá el contenido de su último volcado con el almacenado previamente en el repository, lo que requerirá al less la misma cantidad de memory que los tamaños de ambos files agregados juntos, por lo que Me imagino que comenzará a ser muy lento, muy rápido con files de más de 100 MB (o incluso 10 MB).

Git no fue creado para tratar con files de este tipo (es decir, files 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á save el historial de versiones, pero está más adaptado a los files que no se pueden diferir efectivamente.

Si está utilizando MySQL (y posiblemente otros) y tiene habilitado el logging binary, puede considerar la posibilidad de configurar un repository git para el directory de su logging bin y desarrollar una estrategia para comprometer regularmente las actualizaciones del binlog.

En MySQL, el binlog almacena las consultas que cambian los datos a cualquier tabla en la database. Si sincroniza sus confirmaciones con volcados regulares de la database, 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.