BACKUP Y RECUPERACION DE LA BASE DE DATOS (PARTE II)
Se muestra los conceptos sobre el respaldo de la base de datos. Estos incluyen un backup regular de datos y de la información del log.
Estos backups son realizados mediante el calendario de planificación de base de datos, transacción DB13.
Transacción DB13: configuración del calendario de la base de datos, ya sea backups o cualquier tarea relacionada como por ejemplo correr estadísticas, chequeos, etc.
CONCEPTO DE BACKUP
Un backup regular de los data files, la información de log y los datos estructurados de información de la base de datos.
El backup de los data files y la información de log, se realiza en pasaos diferentes.
Todos los data files y los datos estructurados son respaldados en un solo paso.
En otro paso, la información de log se respalda de forma separada.
En un sistema SAP se pueden planificar ambos pasos (excepto en un plataforma AS400) como acciones regulares utilizando el calendario de planificación de base de datos. Transacción DB13.
ESCENARIO PARA LA RECUPERACION DE UNA BASE DE DATOS
Recuperar una base de datos, dependerá no solamente de la disponibilidad del backup de data files, sino también de los backups de información de log con la que contemos.
Sí un backup de data file se pierde o esta corrupto, una recuperación puede darse con el ultimo backup valido de data files y luego recuperarla a un punto más reciente en el tiempo, si los respaldos de información de log están disponibles sin ningún faltante.
Esto significa que tenemos que contar con todos los backup de información de log que se realizaron a partir del backup de data files que utilizamos para la recuperación hasta el punto en el tiempo que necesitemos recrear la base de datos.
ESCENARIOS PARA MODOS DE RECUPERACON
21 22 23 24 25 26
…!.........!..............
…T1……T2
Recuperar la base de datos (con pérdida de datos)
Si ocurre un accidente en un punto entre T1 y T2, todos los datos respaldados en el backup de data files T1 son recreados con la recuperación.
Si ninguna acción se realiza luego se esto, todos los cambios a la información (creación, modificación o borrado) que fueron realizados después del punto T1 se pierden.
Recuperar la base de datos (sin pérdida de datos)
Todos los datos del backup de data files T1 son recuperados. (algunas BBDD permite recuperas solamente los data files que faltan o inclusive objetos específicos de la base de datos, como tablas)
Luego toda la información del log consecutiva respaldada desde el punto T1 (22,23,..) son tomados para la recreación de la base de datos.
El último paso el archivo de información de log que tenía la base de datos hasta el punto del accidente es recuperado.
Con esto tenemos tos la información en el mismo estado que en el punto en el que ocurrió el problema.
Solamente si toda la información de log desde el último backup de data files está disponible se realizará una recuperación de la base de datos sin perdidas.
ALMACENANDO LOS BACKUP DE DAT FILES E INFORMACION DE LOG
La información de log respaldada en los backups es borrada a nivel de sistema operativo para evitar problemas de espacio en disco.
Es posible recuperar el sistema, aunque un bakcup de data files este defectuoso, si contamos con el anteriores y el predecesor, utilizando los data backup files e información de log más antiguos del último backup de data files.
OTRAS CONSIDERACIONES
Algunas bases de datos también requieren de la información de log para poder realizar una recreación de la base de datos.
CICLO DE BACKUP
Por lo menos un backup online debería realizarse de la base de datos con su subsecuente backup completo de información de log.
Los medios de backup utilizados pueden ser sobrescrito nuevamente cada 28 días (es una recomendación)
SAP recomienda que la duración de un ciclo de backup sea de 28 días. Esto quiere decir que los backups son sobrescritos cada 28 días.
SAP recomiendo realizar un backup completo diariamente de un sistema productivo.
Algunas bases de datos ofrecen la opción de realizar backups diferenciales o incrementales de data files, (estos backups serán referidos como backups parciales)
Si se utiliza la estrategia de backup parcial, debe realizarse un backup completo cada semana. Deberían haber por lo menos cuatro backups completos de la base de datos en un ciclo de backup
La información de log debería respaldarse una vez al día.
Es recomendable duplicar los medios de backup para la información de log, para asegurar que contamos con todos los backups de log en caso de que alguno se encuentre defectuoso.
Muchas compañías realizan backup de log cada 30 minutos.
Es recomendable realizar backup de data file e información de log con verificación al menos una vez en el ciclo. Esto asegura que el backup es legible en el dispositivo de backup pero incremente el tiempo total del respaldo del a información.
PLANIFICACION Y MONITOREO DE BACKUPS
Utilizaremos la transacción DB13
Hay que verificar diariamente si los backups se han completado satisfactoriamente.
El calendario muestra con un código de colores el estado. En verde, exitoso, amarillo exitoso con advertencia, rojo fallido.
Lista de códigos
Light Blue -> Planificado
Dark Blue -> En ejecución
Green -> Termino correctamente
Yellow -> Termino con avisos
Red -> Termino con errores
Dary Yellow -> no disponible
Dark Red -> Programación fallida.
La transacción DB12: muestra información adicional, la cual nos permite visualizar los registros de sucesos de las actividades realizadas en la base de datos. Además de listado de registros, nos permite visualizar las áreas de datos y log utilizadas por la base de datos.
Transacción DB13C: a partir de SAP WEB App. Server 6.10 es posible controlar y monitorear los backups para todos los sistemas del landsacpe con el calendario de planificación central. La planificación se transfiere a los sistemas remotos utilizando una conexión de tipo RFC
El botón de documentación, nos puede dar mayor información sobre las tareas que son posibles realizar desde la transacción DB13 y recomendaciones.