Percy Reyes's Technical Blog - www.SQL4Junkies.com

Estrategias de Backups, Recovery Time Objective, Recovery Point Objective, Deduplicación de datos

Toda estrategia de backup debe orientarse a garantizar que, en caso de caída y daño de los data files en una base de datos, el DBA podrá restaurar la información hasta el momento de la caída, sin ninguna pérdida (o con mínima pérdida). En muchísimas empresas he observado que para todas las bases de datos, la estrategia elegida consiste en simplemente Full Backups diarios a partir de las 8 p.m., generalmente a las  11 p.m. Considero que esta estrategia de backup no se ajusta para la mayoría de empresas de hoy en día donde la información es lo más importante. 

Para bases de datos pequeñas de las que se puede hacer una copia de seguridad con rapidez, la práctica recomendada es utilizar copias de seguridad completas (Full Backups) de la base de datos. Un Full Backup de una base de datos contiene todos los datos de la base de datos. Sin embargo, a medida que la base de datos aumenta de tamaño, las copias de seguridad completas requieren una mayor cantidad de tiempo y espacio de almacenamiento. Por ello, para una base de datos grande, es necesario complementar las copias de seguridad completas con copias de seguridad diferenciales. En SQL Server 2005, se pueden efectuar los siguientes tipos de backup:

• Full Backup: Backup de toda la base de datos.
• Backup Diferencial: backup de los cambios efectuados desde el último Full Backup.
• Backup de Log: Backup del archivo de Log que contiene todos los cambios desde el último backup de log. El backup de Log tiene, por defecto, la característica de que, una vez finalizado, dispara automáticamente una operación de TRUNCATE sobre la log, lo cual libera su espacio utilizado. Sólo es posible bajo los modelos de recuperación Full y Bulk-Logged. Y cómo sabe usted que modelo de recuperación elegir?, pues le comparto este recurso que le será de mucha utilidad: http://www.mssqltips.com/tip.asp?tip=1497 
• Backup de Datafiles y Filegroups: Backup de un datafile o filegroup determinado. Es la más compleja de administrar. Se utiliza en bases de datos muy grandes.

Con base en estos tipos de backups, se pueden trazar las siguientes estrategias de backup:

• Sólo Full Backups: Indicado para bases de datos pequeñas, de sólo lectura, o de poca frecuencia de actualización.
• Full Backup + Log Backup: Indicado para bases de datos de tamaño intermedio, de alta frecuencia de actualización.
• Full Backup + Backups diferenciales + Log Backups: Indicado para bases de datos grandes, de alta frecuencia de actualización.
• Backups de Datafiles o Filegroups + Log Backups: Indicado para bases de datos muy grandes.

El objetivo de toda empresa es conseguir establecer una estrategia de contingencia para todas sus bases de datos. Sin embargo, este objetivo en su mayoría no es compatible con la estrategia actual de backup implementada, la cual no sirve de respaldo adecuado para la data ninguna empresa seria. Para establecer cualquier estrategia de backup debe medirse la frecuencia de actualización de la data, esto debe ser independientemente si sus bases de datos son grandes o pequeñas. Por ejemplo, si las base de datos de su empresa son pequeñas y estas tienen una alta frecuencia de actualización, entonces no dude en establecer la siguiente estrategia de backup: Full Backup + Backups diferenciales + Log Backups. Esta estrategia de backup se ejecutaría de la siguiente manera:

• Un Full Backup diario a las 11: 00 p.m.
• Debe realizarse Backups diferenciales cada cada 4 horas, empezando a las 11 a.m.
• Debe realizar Backups log cada hora, empezando a las 9 a.m.

Claro, el impacto de la  estrategia anterior debe medirse y considerarse evaluar otros factores (las cuales no indico en este post porque nunca terminaría de escribirlo) antes de desplegarse de acuerdo al escenario, tenga mucho cuidado. Una vez elegida la estrategia de backup, las tareas deben ser programadas para llevarse acabo automáticamente, para tal fin tenga en cuenta las siguientes recomendaciones:

1. Planifique en sentido inverso, esto equivale a partir de los requerimientos de recuperación: qué debe recuperarse y en cuánto tiempo. De esta manera, se fija el Recovery Time Objective (en qué tiempo debe restaurarse la data) y el Recovery Point Objective (qué tan actualizados deben ser los datos para cada clase de dato)
2. Salve los archivos a disco antes de migrarlos a cintas. De esa manera, se reducen las ventanas de back-up hasta en un 66%, economizando el uso de servidores y ahorrando tiempo de operación.
3. Elimine el exceso de información a respaldar. No hace falta guardar copias diarias de archivos que no han cambiado en meses. La deduplicación de archivos reduce la cantidad de espacio de almacenamiento y acelera los backups. Se han logrado reducciones de capacidad del orden de 20 a 1 usando deduplicación de datos.
4. Guarde las cintas de backup fuera de la zona de impacto de un eventual desastre y, si es posible, replicar o espejar los datos en un sitio de recuperación ante desastres lejano para que todo siga en línea si se cae el centro principal.
5. Elimine los cuellos de botella en la red. Pueden demorar los procesos de backup y recuperación. Esto se hace más evidente con la virtualización de servidores donde múltiples servidores virtuales usan la misma interfaz y tarjeta de conexión a la red. Los drives de cinta pueden ser demasiado veloces para una interfaz de red.
6. Minimice la cantidad de productos de backup que se usan. Puede ser ventajoso usar a los mejores de su clase en cierto tipo de servidor, pero soportar varios productos puede ser complicado y costoso.
7. Use varias capas de protección cuando sea adecuado. "Dependiendo de la criticidad y sensibilidad en tiempo de los datos, usamos diferentes métodos", nos dice el gerente de operaciones de SunGard Availability Services, responsable por el backup de 30 TB de datos diarios. En algunos casos, usan múltiples soluciones para un mismo set de datos, como replicación remota combinada con backup en cintas.
8. Guarde una copia del plan de recuperación junto con el backup de los datos. Cuando ocurre un desastre, los que se ocupan normalmente de la operación pueden no estar disponibles. Con una copia del plan, alguien más puede ocuparse de las acciones necesarias.
9. Pruebe el proceso de restauración completo y con el equipamiento que será usado en el caso de una emergencia. El sitio de recuperación ante desastres puede tener diferentes servidores o arquitectura de red. Si una aplicación busca una pieza de código o archivo en un servidor en especial ¿Qué ocurrirá si está en un servidor diferente? Prueben todo el sistema y no sólo si los archivos se recuperan adecuadamente.
10. Dejar la restauración rutinaria de archivos como función del help-desk para casos de archivos Word borrados accidentalmente, etc. De esta manera, los especialistas en storage pueden trabajar en la mejora de los niveles de servicio y atender al crecimiento y la flexibilidad de la operación. [Fuente].

Toda empresa tiene procedimientos, formas de trabajo, de operar de acuerdo al mercado y a su rubro, algunas empresas necesitan que su data esté disponible sólo durante el día, otras necesitan las 24 horas del día, es decir, día y noche, lo cual debe tener siempre presente al momento de elegir una estrategia de backup, mida el impacto de la ejecución automática de dichas estrategias las cuales deben distribuirse durante el día y que no afecten la performance del servidor de datos en horarios críticos, sepa distribuir la utilización de recursos de hardware, esas son mis recomendaciones y por fin he terminado este post, espero le sean de utilidad.

Saludos,