Backup y Recuperación de la dB
Se muestran los conceptos de respaldo de la base de datos. Estos conceptos incluyen un backup regular de datos y de la información de log. Estos backups son realizados mediante el calendario de planificación de base de datos, transacción DB13.
- El concepto de backup
El concepto de backup para la base de datos siempre incluye un backup regular de los data files, la información de log y los datos estructurales de infomración de la base de datos misma.
El backup de los data files y la información de log se realiza en pasos 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.
Se pueden planifica ambos pasos en un sistema SAP (excepto en una plataforma AS400) como acciones regulares utilizando el calendario de planificación de dB. Transacción DB13.
- Los escenarios para la recuperación de una dB.
El momento al cual podremos recrearla de manera consistente dependerá no solamente de la disponibilidad del backup de data files con el que contemos, sino también de la disponibilidad de los backups de información de log con la que contemos.
Si un backup de data files se pierde o está corrupto, una recuperación puede basarse en el último backup válido 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 backups 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.
- Recuperar la base de datos (con perdida de datos).
En el caso de un accidente del disco duro ocurre en un determinado momento 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 de esto, todos los cambios a la información (creación, modificación o borrado) que fueron realizados después del punto t1 se perderán.
- Recuperar la base de datos (sin perdida de datos)
Todos los datos del backup de data files t1 son recuperados. Algunas bases de datos permiten recuperar solamente los data files que faltan o inclusive objetos específicos de la dB como por ejemplo una tabla determinada.
Toda información de log consecutiva respaldada desde el punto t1, son tomados para la recreación de la base de datos. En el ultimo paso, el archivo de información de log que tenía la base de datos hasta el punto del accidente es recuperado. Esto significa que toda la información ahora está en el mismo estado hasta el punto en el que ocurrió la falla del disco duro.
Únicamente si toda la información de log desde el último backup de data files está disponible, sin faltantes, la recuperación de la dB será sin pérdida de datos.
- Almacenando los backups de data files e información de log.
La información de log respaldada en los backups es borrada a nivel de SO para evitar problemas de espacio en el disco. Si un accidente ocurre en el punto t5 y un medio de backup del backup de data files t3 se encuentra defectuoso, un backup anterior en el tiempo (en este caso, t1) debe ser utilizado.
Para recuperar la base de datos sin pérdida de información, es absolutamente necesario con todos los backups de información de log (en caso de t2 y t4) que se generaron luego del backup de data files en el punto t1. Por esto es necesario mantener siempre backups de data files e información de log más antiguos del ultimo backup de data files.
Algunas dB requieren de la información de log para poder realizar una recreación de la dB. Por lo tanto deberíamos asegurarnos que se realicen backups tanto de data files como de la información de log regularmente.
- El ciclo de Backup
Hay diferentes variantes para un completo backup de data files diario, dependiendo de la dB. Al menos un bck online debería realizarse de la dB, con un subsecuente bck completo de información de log.
Los medios de bck utilizados pueden ser sobrescritos nuevamente cada 28 días, bajo recomendación de SAP, lo que significa que los bck de data files e información de log son sobrescritos después de 28 días.
En un sistema PRD_SAP se recomienda realizar un bkc completo de manera diaria. Algunas dB tienen la opción de bck incrementales o diferenciales de data files, lo que no realiza un completo bck de la dB.
Si se utiliza un bck parcial de dB como estrategia diaria de bck, se debería realizar un bck completo al menos una vez por semana. Debería haber al menos cuatro bck completos de la dB contenidos en un ciclo de bck.
La información de log debería respaldarse al menos una vez por día. También es recomendable duplicar los medios de bck para la información de log para asegurar que contamos con todos los bck de log en caso de que alguno se encuentre defectuoso.
También es recomendable realizar un bck de data file e información de log con verificación al menos una vez en el ciclo. Esto asegura que el bck es legible en el dispositivo de bck, pero incrementa el tiempo total del respaldo de la información.
- La Planificación y el Monitoreo de Backups
La transacción DB13 sirve para planificar y monitorear bck regulares.
Para verificar diariamente si los bck se han completado satisfactoriamente. En el calendario de planificación, un bck exitoso se muestra en verde o amarillo (cuando hay alguna advertencia). Cuando el indicador este en rojo, entonces un error sucedió durante la ejecución del bck, por lo tanto es inutilizable.
Transacción DB12
La transacción además del listado de registros, nos permite visualizar las áreas de datos y log utilizadas por la base de datos.