Validando Backups y número de días a mantener de journal

Trabajando en soporte generalmente me preguntan cuántos días hay que mantener los journals. ¿Debería ser dos días o después de dos copias de seguridad? ¿Más? ¿Menos? ¿Por qué dos?

La respuesta correcta (para la mayoría de los entornos) es que se debería conservar los ficheros de journal desde la última copia de seguridad validada. Es decir, hasta que no verifique si una copia de seguridad es válida (restaurando el archivo y verificándolo con la utilidad Integrity), no puede estar seguro de que haya una buena copia de los datos y no por tanto no se deberían purgar los journals de manera segura.

Por ejemplo, imagina que necesitas restaurar el sistema después de un fallo de hardware que corrompió algunas bases de datos. El primer paso sería coger la última copia de seguridad y restaurarla. Pero, ¿qué sucede si la copia de seguridad está dañada o se guardó en un disco defectuoso? En ese caso, deberíamos buscar una copia de seguridad anterior hasta encontrar una copia correcta y válida. Tras restaurarla, sí quisiésemos recuperar hasta el último momento, deberíamos aplicar los journals desde que se hizo la copia hasta el momento del fallo. Si sólo tenemos uno o dos días, no será suficiente y podríamos perder datos.

Por tanto, ¡La única forma de asegurarse de que sus copias de seguridad sean válidas es verificándolas! Y para verificar, me refiero a restaurar las bases de datos y validar los datos en ellas. La forma de verificar los datos dentro de una base de datos es mediante la utilidad Integrity.

Cuando explico esto, la mayoría de los administradores lo consideran una tarea compleja, que lleva mucho tiempo y que es difícil de automatizar. Por eso he decidido construir un verificador de Backups súper sencillo que  permite validar los backups fácilmente. 

La utilidad es un verificador de backups sencillo para copias de seguridad realizadas con InterSystems Iris. Restaura el fichero de backup (.cbk) automáticamente y luego ejecuta un chequeo de integridad. Toda la "magia" se realiza en el método restoreAll de la clase Installer. Si quieres mejorar y personalizar la utilidad, puedes tomar prestado el código y mejorarlo enviando un correo electrónico cuando termine con los resultados de la validación (por ejemplo).

Una vez que se haya restaurado la copia de seguridad y se haya ejecutado la verificación de integridad, el log de Docker (y messages.log) contendrá los resultados de la verificación de integridad y restauración. Las bases de datos restauradas aparecerán en una carpeta llamada Restore.