Un diseño impecable de una base de datos puede dar al traste con las expectativas de una empresa si no se ha proyectado correctamente el flujo de copias de seguridad que se deben realizar. Tan importante es gestionar bien los datos como disponer de respaldos para poder recuperarlos cuando se corrompan o se pierdan. Y, háganme caso, esto va a suceder alguna vez sí o sí.
SQL Server dispone de varios tipos de copias de seguridad que dependen íntegramente del modelo de recuperación que se le haya indicado a la base de datos en su creación. Modelos de recuperación hay tres, a saber: simple, completo y de registro masivo. El modelo de recuperación simple tiene la particularidad de que trunca automáticamente el registro de transacciones según éstas van pasando a inactividad, es decir, cuando son comprobadas y escritas. Ello implica un archivo de log pequeño y manejable, pero del que no pueden hacerse copias de seguridad.
Un modelo simple de recuperación sólo admite copias de seguridad completas (toda la base de datos y sus elementos) y copias de seguridad diferenciales (lo que ha cambiado desde la última copia completa). Este modelo debería sólo escogerse en entornos de pruebas y desarrollo, cuando los datos que va a contener no son críticos y pueden ser fácilmente recreados en caso de fallo o cuando la base de datos se prevé pequeña y prácticamente estática.
El problema que adolece al modo simple se basa en el tamaño de la base de datos: si crece mucho, las copias de seguridad crecerán con ella y tardarán más tiempo en generarse. Por otro lado, si la estrategia de copias (tanto completas como diferenciales) no es buena, se puede perder mucha información irrecuperable.
(Los datos a buen recaudo)
El modelo de recuperación completa admite la realización de backup completos, diferenciales y del registro de transacciones. Bajo este modelo, las transacciones inactivas se mantienen en el log, por lo que, si no se controla bien, el archivo puede llegar a unos tamaños descomunales. Las transacciones sólo se truncan cuando se realiza una copia del registro y, para ello, es necesario disponer primero de una copia de seguridad completa como punto de partida.
Este modelo permite recuperar todos los datos perdidos incluso hasta en un momento concreto en el tiempo. En teoría es posible recuperar absolutamente el 100% de lo perdido, aunque no se haya hecho una copia se seguridad hace horas y, por supuesto, siempre y cuando el registro de transacciones no se haya estropeado con la base de datos.
Está indicado cuando los datos son críticos y no se pueden perder, cuando se necesita hacer una recuperación de un punto concreto en el tiempo y cuando se está utilizando replicación de bases de datos (mirroring).
El modelo de recuperación de registro masivo se ha creado exclusivamente como complemento del modelo de recuperación completa y tiene la particularidad de que no registra por completo las operaciones masivas a gran escala, como la importación masiva o la creación de índices. El cambio temporal al modelo de recuperación de registro masivo puede aumentar el rendimiento y reducir el uso de espacio del registro de transacciones.
Los inconvenientes que posee son mayores copias de seguridad de log y mayor riesgo de pérdida de trabajo, porque este modelo no admite la recuperación a un momento dado. Sin embargo, si el último registro de transacciones, tras un desastre, es recuperable y no contiene operaciones masivas, la restauración sería completa.
Por lo tanto, en función de la base de datos que tengamos y de sus características y cargas, la lógica nos ha de llevar por un camino o por otro. Si la base de datos es pequeñita, de sólo lectura y con mínimas actualizaciones, está claro que la estrategia que mejor nos conviene es un modo de recuperación simple con copias de seguridad completas diarias. La hora depende del horario empresarial, pero una buena elección podría ser la de las 23:00 horas.
Para una base de datos intermedia de tamaño y de actualización muy frecuente (la mayoría de las bases de datos de las pequeñas y medianas empresas) la opción pasaría por un modelo de recuperación completa con copias completas diarias (a las 23:00 horas) y copias del registro de transacciones cada 4 horas (comenzando a las 09:00 horas). Como decía antes, las horas dependerán de las jornadas laborales de los usuarios de los orígenes de datos, y es algo que, aunque parezca cuestión baladí, resulta muy importante.
En el supuesto de una base de datos muy grande y con muchas actualizaciones, la estrategia pasaría por un modelo de recuperación completa, con copias completas diarias (a las 23:00 horas), copias diferenciales cada 4 horas (comenzando a las 11:00 horas) y copias del log cada hora (empezando a las 09:00 horas).
Para bases de datos gigantescas con actualizaciones continuas y que manejan soluciones de alta disponibilidad, como pueden ser el database mirroring o el log shipping, habría que plantearse una estrategia a medida de la empresa por medio de respaldos completos, diferenciales, de registro de transacciones y parciales de archivos y grupos de archivos. Por supuesto, bajo un modelo de recuperación completa que, en determinados momentos, puede ser cambiado al modelo de registro masivo.
En el Percy Reyes’s Technical Blog, alojado en Geeks.ms, se publicaron hace tiempo una serie de recomendaciones añadidas a la hora de diseñar la estrategia de backup. Entre ellas podemos destacar algunas como planificar en sentido inverso, salvar los archivos a disco antes de migrarlos a cinta, guardar el respaldo en un lugar seguro y lejos de la zona de impacto de un eventual desastre, eliminar cuellos de botella en la red o separar las copias de seguridad de una base de datos de los procesos de otros respaldos de archivos y documentos. En esa entrada del blog se puede consultar una lista mayor y perfectamente explicada.
La buena elección de una táctica correcta a la hora de establecer las programaciones de las copias de seguridad salvará el cuello a muchos administradores de sistemas. Por supuesto, las copias deben tener sus propios controles y conjunto de notificaciones para que, si una no se está haciendo o algo raro ocurre, se nos avise automáticamente del fallo. Porque resulta, que si una copia se hace correctamente durante 35 años y 60 días, y el día 61 no se genera, den ustedes por seguro que el día 62 cascará la base de datos. Es la Ley de Murphy, ya saben.
Yo personalmente y por ser bastante cabeza, le hago un dump al sql y backup full de ese archivo derecho a cinta.
Es un poco bestia, pero funcional
Derraparon!!!
Se habla de tecnologia, pero siempre fue algo mas geek o casual…para esto ya debemos ser practicamente dba’s.
Volviendo al tema, lindo el articulo.
Yo personalmente, en el dia a dia no estoy tanto en este tema en particular…pero si estoy convencido de la tecnica a plicar depende en primera instancia en el volumen de datos, y en un segundo lugar al presupuesto. El segundo lugar puede ser peleado por los RRHH…pero calculo que siempre se habla de casos teniendo en cuenta que «la gente sabe».
Excelente artículo amigo, muchas gracias por compartirlo.