Skip to end of metadata
Go to start of metadata

Índice

0. Visión general

WBSAirback®  provee una solución unificada para la consolidación de almacenamiento y archivado de datos, así como la gestión de la seguridad de los mismos, permitiendo establecer diferentes niveles de acceso a estos en virtud de sus requerimientos de disponibilidad.


WBSAirback®  supone una nueva generación en los sistemas de gestión y protección del almacenamiento, incluyendo funcionalidades capaces de gestionar almacenamiento heterogéneo para su uso como almacenamiento primario o como repositorio de backup, así como funcionalidades para la gestión del ciclo de vida del backup. Dichas funciones son gestionadas de una manera muy sencilla debido a que abstraen parte de la complejidad técnica y conceptual de los mencionados servicios.

WBSAirback® está basado en una plataforma de tipo appliance que integra todos los componentes lógicos necesarios en una única plataforma. No requiere la adquisición ni instalación de sistemas operativos ni aplicaciones de terceros para funcionar. Puede adquirirse como un appliance físico incluyendo la plataforma hardware adecuada a cada necesidad, o como un appliance virtual incluyendo los ficheros estándar necesarios para desplegar una máquina virtual en las principales plataformas de virtualización.

A través de una sencilla interfaz web accesible desde cualquier navegador, se puede realizar toda la administración y configuración del sistema y de sus funcionalidades principales.

Desde dicha interfaz se realiza la actualización de versiones, actualizaciones, parches, etc. con tan sólo dos o tres clicks.

El esquema general de la solución es el siguiente:

Figura 0: Visión general WBSAirback®

En el presente documento se presenta el módulo de protección de entornos SAP HANA mediante el plugin SAP HANA de WBSAirback®, que se basa en el plugin homónimo de Bacula Enterprise Edition.

1. Introducción

SAP HANA es una tecnología que surgió, entre otras cosas, como respuesta de SAP al potencial que alberga el Big Data. Ofrece entornos optimizados para el procesamiento de transacciones y analítica en tiempo real, permitiendo, además múltiples opciones de despliegue. La base de datos de SAP HANA hace posible responder en tiempo real a los insights de negocio que sean detectado gracias al análisis de Big Data y crear aplicaciones de negocio que, de otra manera, resultarían muy costosas.

Sus capacidades como base de datos en memoria la convierten en una solución perfecta para combinar servicios de base de datos, procesamiento de datos y plataforma de aplicaciones todo en uno. Se beneficia de las más actuales tecnologías hardware y combina técnicas de almacenamiento de datos, procesamiento masivo paralelo (MPP) y utiliza la memoria física para optimizar el rendimiento. Con esto, SAP HANA es capaz de ofrecer librerías para implementar planificación predictiva, procesamiento de datos o business analitics entre otros. Además, a pesar de ser una base de datos que trabaja en memoria, ofrece capacidades de resiliencia avanzada, siendo posible reiniciarla como una base de datos tradicional en disco en el caso de producirse cualquier evento de fallo, sin perder datos por ello.

Todo esto supone una gran ventaja para las empresas, las cuales incrementan su capacidad de adaptación y reacción rápida a los cambios en el mercado, por lo que muchas de ellas han decidido migrar parte o la totalidad del core de su negocio a esta tecnología.

Como hemos comentado, SAP HANA realiza todo su procesamiento en memoria. Para evitar pérdidas de datos con este tipo de arquitectura, SAP HANA escribe regularmente su información en almacenamiento persistente, donde quedan almacenados sus logs transaccionales y sus datos. Gracias a esto, SAP HANA puede evitar pérdidas de datos ante eventos de pérdida de corriente o fallos puntuales. No obstante, esto no protege a la solución de daños en los sistemas de almacenamiento, corrupción de datos o fallos humanos entre muchos otros posibles problemas. Es aquí donde se hace necesaria una solución de backup externa, capaz de respaldar, archivar y reciclar los datos de forma eficiente y automatizada a otro tipo de almacenamiento externo. 

WBSAirback® posee un módulo capaz de proteger de forma completa las bases de datos desplegadas con esta tecnología a través del presente plugin de backup SAP HANA, que implementa la interfaz BACKINT de forma nativa, para poder integrar los procesos de backups de este tipo de entornos de forma natural y aprovechando todas las capacidades de la solución, como son deduplicación, compresión, flexibilidad, escalabilidad, interoperabilidad o alto rendimiento, entre muchos otros.

Este módulo se basa en el plugin SAP HANA de Bacula Enterprise Edition, el cual se encuentra certificado con SAP.

2. Funcionalidades

El plugin para SAP HANA  implementa de forma nativa la interfaz oficial de SAP BACKINT (HDBBACKINT) para crear las copias de respaldo. Por lo tanto, funciona conjuntamente a las herramientas nativas de administración asociadas a  SAP HANA, como pueden ser hdbsql, HDBSettings o SAP HANA Studio entre otras. De esta forma se mantiene toda su potencia y versatilidad y se hace el envío de la información a recursos de WBSAirback® de forma transparente. Por lo tanto, este plugin soporta todas las características asociadas a procesos de backup nativos de SAP HANA, como son:

  • Backup de datos Full
  • Delta backups (Incremental / Diferencial)
  • Redo Logs backup
  • Multiplexado en canales
  • Online backups
  • etc

A nivel de restauración, es posible aplicar restauración de datos directa sobre sistemas SAP/SAP-HANA online, pero también restauración de datos de forma externa. De la misma forma que con el backup, los procesos de restauración tienen toda la flexibilidad nativa que ofrecen las propias herramientas de administración de SAP HANA.

A continuación, se presenta la arquitectura de la solución:

Figura 2.1: Arquitectura Plugin SAP HANA

3. Compatibilidad

Este plugin está soportado para la plataformas SAP HANA 2.04 (Backint 1.04).

Los sistemas operativos soportados son:

  • Red Hat Enterprise Linux (a partir de su versión 6)
  • Suse Linux Enterprise Edition (a partir de su versión 12)

Por último, este plugin se encuentra disponible a partir de WBSAirback® v19.0.

5. Limitaciones

Actualmente, el plugin presenta las siguientes limitaciones:

  • No se soporta la opción de montaje/desmontaje -f
  • En discos tipo split no se soporta suspender/reanudación
  • No está soportada la copia de archivos procedentes de storage snapshots o clones
  • Trabajos vacíos no son purgados con un comando de borrado lanzado desde backint

6. Configuración y despliegue

Para poder utilizar el plugin SAP HANA es necesario habilitar los códigos de servicio asociados:

  • SAP y SAP-HANA

Puede consultar sus códigos de servicio tanto en la sección de suscripción como en la de estado general:

Figura 6.1: Códigos de servicio SAP y SAP-HANA

La configuración de este plugin consiste en desplegar agente y plugin en los clientes que tienen instalado el servicio SAP HANA y configurar en WBSAirback® los trabajos de comunicación y de lanzamiento de procesos de backup y restauración oportunos.

6.1. Configuración de cliente SAP HANA

6.1.1 Despliegue de agente y plugin

El primer paso para configurar el cliente consiste en desplegar los paquetes correspondientes a las librerías comunes, agente de backup y plugin SAP HANA en el equipo donde se encuentra el servicio de BBDD de SAP HANA. Con el código de servicio activo, todos los paquetes estarán disponibles en la sección de descarga de agentes del producto:

Figura 6.1.1.1: Paquetes de despliegue de cliente SAP HANA en RHEL 7

Una vez se encuentran todos los paquetes disponibles, es posible instalarlos utilizando los comandos oportunos del gestor de paquetes y los nombres de los paquetes descargados. Por ejemplo:

Despliegue de agente
rpm -i bacula-enterprise-libs-12.0.2-19090610.su122.x86_64.rpm 
rpm -i bacula-enterprise-client-12.0.2-19090610.su122.x86_64.rpm 
rpm -i bacula-enterprise-sap-hana-plugin-12.0.2-19090610.su122.x86_64.rpm 

A nivel de permisos será necesario aplicar el usuario y grupo del administrador de BBDD al directorio completo de bacula. Por ejemplo

Permisos
// Si nuestro directorio de BBDD tiene este usuario y grupo
user@host:/> ls -dl /usr/sap/HXE/
drwxr-xr-x 5 hxeadm sapsys 64 jul 30 05:27 /usr/sap/HXE/

// Aplicaremos los mismos permisos al directorio de /opt/bacula/
user@host:/>chown -R hxeadm:sapsys /opt/bacula/

El siguiente paso consiste en configurar correctamente el servicio bacula-fd en su archivo /opt/bacula/etc/bacula.conf, donde tendremos que aplicar el password correcto e indicar el directorio de plugins:

bacula-fd.conf
#
# List Directors who are permitted to contact this File daemon
#
Director {
  Name = airback-dir
  Password = "<MismoPassQueClienteEnInterfazWBSAirback>"
}

#
# "Global" File daemon configuration specifications
#
FileDaemon {                          # this is me
  Name = saphana-lab-fd
  FDport = 9102                  # where we listen for the director
  WorkingDirectory = /opt/bacula/working
  Pid Directory = /opt/bacula/working
  Maximum Concurrent Jobs = 20
  Plugin Directory = /opt/bacula/plugins
}

# Send all messages except skipped files back to Director
Messages {
  Name = Standard
  director = airback-dir = all, !skipped, !restored, !saved
}

En este punto ya es posible arrancar el servicio y comprobar si existe comunicación desde WBSAirback®.

6.1.2 Bconsole

El plugin SAP HANA necesita realizar consultas al catálogo de WBSAirback®, por lo tanto hay que permitir la ejecución de bconsole configurando correctamente el archivo en la ubicación /opt/bacula/sap/bconsole.conf:

bconsole.conf
#
# Bacula User Agent (or Console) Configuration File
#
#

Director {
  Name = airback-dir
  DIRport = 9101
  address = x.x.x.x
  Password = "xxxxx"
}

La dirección ip debe ser la del appliance WBSAirback® y el password se puede obtener del archivo /etc/bacula/bconsole.conf de WBSAirback® (consulte con el servicio de soporte dicho password).

Si la configuración es correcta y hay conectividad ip y por ese puerto, será posible ejecutar el comando bconsole como se muestra a continuación y con un resultado similar:

bconsole.conf
/opt/bacula/bin/bconsole -n -c /opt/bacula/sap/bconsole.conf
Connecting to Director 192.168.1.149:9101
1000 OK: 10002 airback-dir Version: 12.0.5 (01 November 2019)
Enter a period to cancel a command.
*

6.1.3 Conexión con backint

Para conectar SAP HANA con el servicio de backup de WBSAirback® es necesario enlazar la herramienta hdbbackint que incorpora el plugin con la Base de datos desplegada. Para ello es necesario realizar un symlink de este tipo:

hdbbackint
sudo ln -s /opt/bacula/bin/hdbbackint /usr/sap/<SID>/SYS/global/hdb/opt/hdbbackint

6.1.4 Configuración de servicio backint

El último paso consiste configurar correctamente el servicio backint del plugin sobre el archivo /opt/bacula/sap/backint.conf, en el cual debemos indicar:

  • Nombre de cliente definido en WBSAirback®
  • Nombre de trabajo definido en WBSAirback®
  • Comando bconsole con referencia al archivo configurado anteriormente
  • Nombre de trabajo de restauración de WBSAirback®: RestoreFiles
  • Número de trabajos concurrentes
  • [Opcional] Opciones de debug

El trabajo que indiquemos aquí, será el trabajo de comunicación que definamos en WBSAirback. Del mismo modo, cuando se lancen restauraciones desde SAP HANA, el trabajo de restauración que será invocado de forma automática será el especificado, que debe ser RestoreFiles.

A continuación se muestra un ejemplo:

backint.conf
client=SAPHana-Lab
job=SAPHana-Lab-Data-Dedup
bconsole="/opt/bacula/bin/bconsole -n -c /opt/bacula/sap/bconsole.conf"
maximumconcurrentjobs=10
waitjobcompletion=yes
restorejob=RestoreFiles
trace=/tmp/backint.log
debug=100

Podemos comprobar en este punto (si la configuración en WBSAirback® está completa) si hay comunicación y el plugin está correctamente configurado ejecutando este script:

test config
/> /opt/bacula/scripts/install-sap.sh test
1000 OK: 10002 airback-dir Version: 12.0.5 (01 November 2019)
INFO: Connection to the Director OK
INFO: Connection from the Director to the Client OK
INFO: Plugin installed correctly
INFO: Job found on the Director
INFO: FileSet configured on the Director
INFO: RestoreJob found on the Director
INFO: FileSet configured for the Restore job on the Director

Atención: Este script debe lanzarse con el usuario 'root' y después indicarle el nombre del usuario administrador de la instancia (normalmente <SID>adm)

Si obtenemos una salida similar la mostrada, la comunicación ha sido exitosa, en caso contrario, el script informará de los problemas encontrados.

6.1.5 Backup automático de logs

SAP Hana por defecto tiene activado el backup de los logs con cierta periodicidad. En general, es interesante mantener este tipo de backup, independientemente del resto de backups que podamos controlar desde WBSAirback®.

El backup de los logs, por defecto se dirige a una ruta determinada dentro de la instancia. Pero es posible hacer que este tipo de backups también se envíen a través de la interfaz BACKINT y, por tanto, hagan uso del plugin de SAP-HANA de WBSAirback®

Atención

Si se desea aplicar este tipo de configuración, es necesario hacerlo después de haber conectado con éxito el backup de datos estándar, incluyendo toda la configuración en WBSAirback® que se detalla en el punto siguiente. Si aún no lo ha hecho, vuelva a a este punto más tarde, una vez complete dicha configuración.


Para ello, en primer lugar es necesario habilitar este tipo de backup en las opciones globales de la configuración de SAP HANA, que encontraremos abriendo las opciones de administración de nuestra instancia. En ellas tendremos que activar la opción 'log_backup_using_backint' tal y como muestran las siguientes imágenes:

Figura 6.1.5.1: Opción para activar backup automático de logs en backint

Figura 6.1.5.2: Activando opción de backup automático de logs en backint

Después, es necesario configurar backint para este tipo de backups en las opciones de backup de la instancia y especificar la frecuencia deseada:

Figura 6.1.5.3: Configuración de backup de logs a través de backint

Es necesario pulsar en el botón 'guardar' para que los cambios sean efectivos.

Una vez cambiado el modo, podemos inspeccionar el catálogo de backups de log y ver cómo el tipo de backup ya es backint:

Figura 6.1.5.4: Catálogo de backup de logs (backint)

Este tipo de backups se comunicarán con WBSAirback igual que cualquier otro tipo de backup, es decir, utilizando el trabajo de comunicación que se configure y defina. Por lo tanto, veremos las ejecuciones mostradas en el catálogo de SAP HANA también en el catálogo de WBSAirback®, como nuevas ejecuciones de tipo Incremental del trabajo de comunicación. A continuación un ejemplo:

Figura 6.1.5.5: Ejecución de backup de log automático en el appliance

6.1.6. Backup del catálogo de backup

Es posible redirigir el backup del catálogo de SAP HANA, también a WBSAirback a través de Backint.

Si se decide utilizar esta característica, el proceso es muy similar al descrito en el punto anterior, pero el parámetro a activar es:

CatalogBackup
catalog_backup_using_backint

Figura 6.1.6.1: Parámetro para configurar backint en backup del catálogo

6.1.7. Clúster

En el caso de entornos tipo cluster se ha de realizar el despliegue del agente tal cual se ha explicado en los puntos 6.1.1 a 6.1.4 en cada uno de los nodos que componen el cluster y añadir la directiva 'clientcluster' en el fichero backint.conf con todos los miembros que compongan el cluster (su nombre de cliente en WBSAirback®). Ejemplo:

  • clientcluster=hxehost01,hxehost02,hxehost03

Ejemplo de backint.conf completo:

backint.conf
client=hxehost01
clientcluster=hxehost01,hxehost02,hxehost03
job=job.hxe.dedup
bconsole="/opt/bacula/bin/bconsole -n -c /opt/bacula/sap/bconsole.conf"
maximumconcurrentjobs=10
waitjobcompletion=yes
restorejob=RestoreFiles

6.1.8. Multiplexado de backup en canales

Para permitir el multiplexado en varios canales de los trabajos de backup es necesario configurar el parámetro 'parallel_data_backup_backint_channels' en el archivo global.ini, generalmente ubicado en /hana/shared/<SID>/global/hdb/custom/config/global.ini y asignarle el número de canales que se quiere emplear. Utilice el mismo valor para los canales de recuperación en el parámetro 'max_recovery_backint_channels'.

Si edita ese fichero directamente desde las utilidades de sistema, recuerde recargar la configuración (por ejemplo, utilizando el comando hdbnsutil -reconfig).

Por otro lado, en el trabajo de comunicación de WBSAirback será necesario indicar ese mismo número en el parámetro de 'Jobs en paralelo'.

El parámetro debe establecerse en la sección [backup]:

global.ini
...
[backup]
parallel_data_backup_backint_channels = 5
max_recovery_backint_channels = 5
...

En caso de modificar el número de canales de backup, considere también la parametrización del buffer de backup a través del data_backup_buffer_size. En general, se pueden considerar 512Mb para cada canal, por lo que, por ejemplo con 8 canales, tendríamos un valor de data_backup_buffer_size de 4096Mb:

global.ini
...
[backup]
parallel_data_backup_backint_channels = 8
max_recovery_backint_channels = 8
data_backup_buffer_size = 4096
...

No obstante, esto depende de las condiciones particulares de su entorno. Para más información sobre este asunto, consulta la documentación oficial de SAP HANA.

Si lo hacemos desde SAP-HANA Studio, abrimos la administración de la instancia:

Figura 6.1.8.1: Abrir administración de instancia en SAP HANA Studio

Y buscamos estas opciones bajo la sección [backup]:

Figura 6.1.8.2: Opciones de paralelismo en global.ini

6.2. Configuración en WBSAirback®

La configuración a realizar en WBSAirback® consiste en definir tantos clientes como equipos con SAP HANA tenga el entorno. Definir trabajos de comunicación para cada cliente y, por último, establecer los trabajos de ejecución necesarios para cada operación de backup o restauración que se desee integrar.

6.2.1. Cliente

Para conectar WBSAirback® con el agente desplegado en el equipo con el servicio SAP HANA, siguiendo las indicaciones del punto 6.1, se ha de dar de alta un cliente estándar, que se configura de manera estándar en la sección Clientes. Consulte el manual de producto si tiene alguna duda en este punto: v19: 04 - Backup#4.8.3Crearcliente

Para proteger clústers de SAP HANA, es necesario dar de alta como clientes cada uno de los nodos que componen el clúster (y seguir las indicaciones del punto 6.1.5).

6.2.2. Trabajo de comunicación

El flujo de trabajo en procesos de backup y restore con SAP HANA es el siguiente (consulte el diagrama de arquitectura inicial para mayor claridad):

  • SAP HANA TOOLS → Backup/Restore → Backint →  WBSAirback®

Solamente desde las herramientas nativas de SAP HANA se tiene la capacidad y potestad de iniciar procesos de backup y restauración. Por lo tanto, el plugin de WBSAirback® actúa simplemente como una interfaz que hace transparente el envío o recepción de datos a un recurso gestionado con el appliance, aunque, como se expliará en la siguiente sección 6.2.3, también se ofrece un modo de lanzar los procesos desde  WBSAirback® para así centralizar la gestión en el appliance y aprovechar también el planificador del mismo.

El modo de funcionamiento del último enlace representado Backint → WBSAirback®, en el caso del backup, se hace a través de un trabajo de comunicación que se debe dar de alta sobre el cliente SAP definido.

6.2.2.1 Configuración de patrón de ficheros

El primer paso es establecer el patrón de ficheros. Se utilizará un patrón de ficheros genérico de 'Cliente', que es necesario dejar vacío en sus inclusiones o exclusiones y seleccionar el plugin 'SAP' en la sección de plugins, tal y como muestra la imagen:

Figura 6.2.2.1.1: Patrón de ficheros de trabajo de comunicación SAP-HANA

6.2.2.2 Configuración de trabajo

Como en cualquier trabajo, será necesario tener definido previamente un Conjunto destino, asociado a su correspondiente Repositorio destino que hará referencia al tipo de almacenamiento donde se dirigirá el backup (que puede ser de tipo disco local al appliance, disco NAS, disco iSCSI, disco SAN, librería, almacenamiento objeto, etc). Como particularidades:

  • Este trabajo no debe ser planificado, por lo que la planificación quedará vacía.
  • Este trabajo no debe ser lanzado directamente
    • Este trabajo aparecerá una o más veces de forma automática cuando se ejecuten las órdenes de backup desde el equipo SAP HANA.
  • Se debe seleccionar el patrón de ficheros definido en el punto 6.2.2.1, el cual puede se compartido con todos los trabajos de comunicación, para cada uno de los clientes SAP que se deseen proteger.
  • En cuanto a la variable de trabajos en paralelo, es importante que se aumente al valor oportuno si se ha configurado multiplexado en canales (consultar sección 6.1.6).
  • La precisión debe estar desactivada (la interfaz web impide al usuario que la active por error)

Un ejemplo de trabajo quedaría como sigue:

Figura 6.2.2.2.1: Configuración de trabajo de comunicación SAP-HANA

6.2.3. Trabajo de ejecución de backup

A pesar de que, como hemos comentado en el punto anterior, sólo las herramientas de SAP HANA tienen la capacidad y potestad de iniciar procesos de backup, WBSAirback ofrece un modo muy sencillo de mantener el control de forma centralizada en el appliance y lanzar los procesos desde el mismo, ya sea manualmente o a través de una planificación. 

Se trata de crear otro trabajo diferente, en el mismo cliente, que se encargue de invocar a las herramientas de SAP HANA a través de un proceso de script.

Por lo tanto, el primer paso será crear el script correspondiente. Es posible crear un proceso de script diferente para cada tipo de backup (Full, Inc, Diff..), pero también establecer las parametrizaciones oportunas utilizando variables, para que nuestros scripts ofrezcan el mayor grado de reutilización posible. En este ejemplo vamos a mostrar 2 scripts, uno para backup full y otro para backup incremental.

Se recomienda crear un nuevo 'Sistema Operativo' de nombre SAP-Hana y agrupar ahí cualquier script que se cree:

Figura 6.2.3.1: Scripts para SAP-Hana

El siguiente sería un comando para lanzar Backup Full de la base de datos SYSTEMDB al completo:

Comando backup full genérico
/usr/sap/<SID>/SYS/exe/hdb/hdbsql -t -n <hostname>:<port> -i <instance_number> -u <user> -p <password> "backup data using backint('<prefijo>')"

Al no indicar el parámetro 'for XXX' el backup es de la base de datos SYSTEMDB, si queremos hacer Backup Full de una base de datos tenant de nombre 'tenant_database_name' , el comando sería el siguiente:

Comando backup full genérico
/usr/sap/<SID>/SYS/exe/hdb/hdbsql -t -n <hostname>:<port> -i <instance_number> -u <user> -p <password> "backup data for <tenant_database_name> using backint('<prefijo>')"

Si quisiésemos hacer Backup Diferencial:

Comando backup full genérico
/usr/sap/<SID>/SYS/exe/hdb/hdbsql -t -n <hostname>:<port> -i <instance_number> -u <user> -p <password> "backup data DIFFERENTIAL for <tenant_database_name> using backint('<prefijo>')"

Etc.

En los sucesivos ejemplos, se ha utilizado el primer script que copia la base de datos SYSTEMDB.

Es aquí, en estas sentencias de script, donde será necesario realizar todas las configuraciones específicas de backup que sean oportunas en cada caso:

  • Base de datos que deseamos respaldar
  • Tipo de backup: si deseamos hacer backup de datos o de log
  • Nivel de backup: si es Full, incremental o diferencial
  • Opciones avanzadas de parametrización
  • ...

Puesto que nuestro cliente solamente tiene una instancia, no vamos a parametrizar su nombre, pero sería perfectamente posible. Vamos a parametrizar el resto, por si pudiesen cambiar en el futuro. Por otro lado, como prefijo, el cual debe ser único para cada ejecución, vamos a utilizar el nombre completo del trabajo ejecutado, a través de la variable %j, precedido de la constante 'wbsairback_'.

El contenido del script de ejemplo quedaría de la siguiente forma:

Comando backup full ejemplo
/usr/sap/HXE/SYS/exe/hdb/hdbsql -t -n [[[hostname]]]:[[[port]]] -i [[[instance_number]]] -u [[[user]]] -p [[[password]]] "backup data using backint('wbsairback_%j')"

Siempre que se añaden variables, es necesario definirlas en su sección correspondiente. Por otro lado, es muy importante para estos scripts marcar como intérprete 'Other', de esta forma el comando se ejecutará directamente, sin invocar explícitamente a ningún intérprete y no habrá problemas con la sintaxis. El script resultante quedaría así:

Figura 6.2.3.2: Script backup Full para SAP-Hana

Tendríamos un script para Backup Incremental simplemente modificando el script de backup full con la palabra INCREMENTAL de este modo:

Comando backup full genérico
/usr/sap/<SID>/SYS/exe/hdb/hdbsql -t -n <hostname>:<port> -i <instance_number> -u <user> -p <password> "backup data INCREMENTAL using backint('<prefijo>')"

Por lo que el script para backup incremental quedaría como sigue:

Figura 6.2.3.3: Script backup Incremental para SAP-Hana

Una vez están definidos los scripts sólo queda asociarlos a sus trabajos correspondientes. Estos trabajos serán los que es posible planificar y ejecutar, por lo que recomendamos identificarlos en su nombre de algún modo claro, como por ejemplo, añadiendo el sufijo '-RUN' como veremos a continuación. 

Estos trabajos no respaldan realmente ninguna información, solamente serán utilizados para lanzar los scripts correspondientes. Para conseguirlo será necesario definir un patrón de ficheros vacío (que podemos llamar Empty, Dummy o similar) como se muestra a continuación:

Figura 6.2.3.4: Patrón dummy para scripts

Con todas estas premisas solo queda definir los trabajos. El procedimiento consiste en:

  • Añadir trabajo en el cliente SAP-HANA oportuno
  • Asignarle un nombre descriptivo, como best practice se recomienda aplicar un formato de este tipo:
    • Job.NombreCliente.DescripcionCorta.RUN
      • Ejemplo: Job.Hana01.BackupFull.Run
      • Por supuesto, ajuste separadores, mayúsculas y demás como considere oportuno
  • Aplicarle la planificación oportuna
  • Seleccionar cualquier conjunto destino por defecto (no se utilizará para almacenar ningún dato)
  • Seleccionar el patrón Dummy creado
  • Seleccionar el script correspondiente en el desplegable de scripts del formulario de trabajos
    • Asignar los valores oportunos a cada variable 
    • Pulsar en el botón +
  • Guardar

A continuación mostramos como ejemplo el trabajo asociado al script de lanzamiento de backup Full:

Figura 6.2.3.5: Formulario de trabajo RUN


Figura 6.2.3.6: Asignación de comando. Paso 01

Figura 6.2.3.7: Asignación de comando. Paso 02

6.2.4. Trabajo de ejecución de restore

Las restauraciones de SAP HANA con Backint funcionan de la misma manera que los backups, a través de un flujo como el siguiente (consulte el diagrama de arquitectura inicial para mayor claridad):

  • SAP HANA TOOLS → Restore → Backint → WBSAirback

En este caso, el trabajo de comunicación que se genera al lanzar una restauración es 'RestoreFiles'. 

Para poder lanzar desde  WBSAirback® la restauración, la estrategia es exactamente la misma que la comentada en el punto anterior. La única diferencia es que esta vez generaremos un proceso de script con comandos de restore, pero se debe asociar igualmente a un trabajo de backup.

Para una restauración completa PITR podemos utilizar el siguiente comando:

Comando backup full genérico
/usr/sap/<SID>/<INSTANCE>/HDBSettings.sh recoverSys.py --command="RECOVER DATABASE UNTIL TIMESTAMP '<timestamp>' CHECK ACCESS" --wait --timeout=600

Debido a la complejidad sintáctica del comando, es necesario apoyarse en un script en la propia máquina cliente. En este caso crearemos el siguiente fichero con este contenido:

Comando backup full genérico
# Permisos de ejecución
/> chmod 744 /opt/bacula/sap/restore-pitr.sh

# El usuario debe ser el mismo que tiene acceso a la BBDD
/> ls -l /opt/bacula/sap/restore-pitr.sh
-rwxr--r-- 1 hxeadm sapsys 151 ene 10 14:15 /opt/bacula/sap/restore-pitr.sh

# El contenido del script será el siguiente
/> cat /opt/bacula/sap/restore-pitr.sh
su hxeadm - -c "/usr/sap/HXE/HDB90/HDBSettings.sh recoverSys.py --command=\"RECOVER DATABASE UNTIL TIMESTAMP '$1' CHECK ACCESS\" --wait --timeout=600"


Un proceso de script parametrizable, donde recordemos que podríamos parametrizar cualquier otro valor (SID, Nombre de instancia..) y que es necesario seleccionar el intérprete 'Other', quedaría como en la imagen:

Figura 6.2.4.1: Proceso de script de Restore

Para una ejecución de restauración primero hay que configurarla. Este proceso de configuración consiste en crear un trabajo en el cliente de SAP HANA, de la misma forma que se ha expuesto en los backups. 

A pesar de que vayamos a crear un trabajo de 'Backup', realmente este trabajo no respaldará nada, pues usará el patrón de ficheros vacío 'Dummy' y simplemente invocará al script de restauración.

Puesto que hemos definido como variable la fecha para aplicar PITR, en el momento de configurar el trabajo tendremos la oportunidad de indicar el valor deseado:

Figura 6.2.4.2: Fecha a introducir al seleccionar el script process de restore

Figura 6.2.4.3: Fecha tras añadir con el botón + el script process de restore

Figura 6.2.4.4: Formulario de trabajo de restauración desde  WBSAirback® 

Una vez el trabajo está creado, podremos lanzar la restauración con el botón play habitual:

Figura 6.2.4.5: Lanzamiento de restauración desde WBSAirback® 

6.2.5. Backup/restore desde SAP HANA Studio

El hecho de poder gestionar los backups y restauraciones desde WBSAirback® no impide que se puedan ejecutar otros backups desde la herramienta de administración de SAP HANA, dirigiéndolos al appliance a través de backint o a otro lugar. Simplemente es necesario acceder a las opciones de Backup y Restore de la administración de la instancia:

Figura 6.2.5.1: Opciones de backup y restore desde SAP Hana Studio

Seleccionar la opción deseada y completar el Wizard que aparecerá:

Figura 6.2.5.2: Wizard de backup desde SAP Hana Studio

7. Ejecución de backup

Una vez está configurado el plugin, es posible lanzar un backup desde línea de comandos en el entorno SAP HANA, o hacerlo directamente desde WBSAirback como se ha visto en el punto 6.2.

Si lo lanzamos desde línea de comandos, podemos esperar una salida similar a ésta:

Bash run backup
hxeadm@hxehost:/usr/sap/HXE/HDB90> /usr/sap/HXE/SYS/exe/hdb/hdbsql -t -n hxehost:39013 -i 90 -u SYSTEM -p xxxxx "backup data INCREMENTAL using backint('wbsairback_Thursday_13:46')"
0 rows affected (overall time 18,702833 sec; server time 18,700032 sec)


Si lo lanzamos desde el trabajo de ejecución de WBSAirback®  veremos esa misma información en el log del trabajo de ejecución:

Figura 7.1: Log de trabajo de ejecución

En todos los casos, es importante resaltar los trabajos de comunicación auto-generados y que son los que realmente contienen los datos respaldados:

Figura 7.2: Trabajos de comunicación auto-generados

Consultando el log de un trabajo de comunicación, podremos ver más detalles del proceso con backint:

Figura 7.3: Log de trabajo con datos respaldados (comunicación)

Del mismo modo, en el catálogo de SAP HANA podremos visualizar las ejecuciones. Si utilizamos SAP HANA Studio:

Figura 7.4: Catálogo de ejecuciones de backup de SYSTEMBD en SAP HANA Studio

También es posible consultar a la propia BBDD este mismo catálogo a través de querys, por ejemplo:

Query catalog
/usr/sap/<SID>/SYS/exe/hdb/hdbsql -t -n <host>:<port> -i 90 -u <user> -p xxxxx "select * from M_BACKUP_CATALOG order by utc_end_time desc;"

En el caso de que el backup haya sido de una BBDD tenant, en este caso HXE, podemos ver información muy similar:

Figura 7.5: Catálogo de ejecuciones de backup de tenant HXE en SAP HANA Studio

8. Ejecución de restauración

Una restauración ejecutada, genera varios log. El propio log del trabajo de ejecución y tantos trabajos de comunicación 'RestoreFiles' como sean necesarios:

Figura 8.1: Ejecuciones de restauración

El job de ejecución (sufjio RUN) muestra la salida de los scripts ejecutados

Figura 8.2: Log de ejecución

En el resto de logs podremos consultar las operaciones automáticas de recuperación de los archivos correspondientes, las cuales son invocadas en el proceso de restauración. A continuación un ejemplo:

Figura 8.3: Log de comunicación

8.1. Restauración externa (no SAP)

Con WBSAirback es posible también lanzar restauraciones de los archivos respaldados sobre otro tipo de clientes no-SAP, o sobre el propio WBSAirback® en uno de sus volúmenes locales (DAS o SAN), o bien sobre un volumen externo NAS, accesible por CIFS o NFS.

Para ello será necesario acceder a la pantalla de restauración desde el cliente SAP o desde uno de los trabajos de los que queremos obtener la información, siempre utilizando el botón 'Ficheros':

Figura 8.1.1: Restauración externa

En el ejemplo de la imagen se ha partido de un trabajo y se ha seleccionado el cliente interno airback-fd, lo cual ha mostrado el desplegable de volúmenes internos y externos que nos permitiría enviar el archivo seleccionado uno de esos volúmenes. 

8.2. Restauración individual de Esquema o tabla

SAP HANA no dispone de la funcionalidad de restauración individual de una tabla o esquema a partir de los datos de un backup. Por lo tanto, con un backup estándar realizado en WBSAirback® no será posible realizar este tipo de recuperaciones.

Sin embargo, existen alternativas a los procesos puros de backup que sí permiten realizar una recuperación de un esquema o tabla de forma individual. Hablamos de los procesos de importación y exportación. Una sentencia de exportación es capaz de enviar la estructura y datos de un elemento a una ruta particular. El proceso de importación realiza la operación inversa.

No recomendamos en absoluto utilizar procesos de importación y exportación como mecanismos que sustituyan a una estrategia de backup apropiada con los procesos que se han descrito en este documento. Pero sí pueden utilizarse estos procesos a modo de complemento, donde se presente la necesidad específica de extraer los datos de algún elemento (esquema o tabla) que puedan necesitarse de manera más habitual para su importación, sin la necesidad de pasar por un proceso de restauración completa. 

Consulte la información oficial en el portal de SAP para completar esta información:

La integración de procesos de import/export en WBSAirback® puede realizarse de dos maneras diferentes:

  1. Utilizando un volumen compartido 
    1. Se puede compartir un volumen interno con el equipo cliente SAP HANA y que este vuelque los datos ahí
    2. Se puede utilizar un volumen compartido externo por otra unidad de almacenamiento y que este sea visible tanto por  WBSAirback® como por el equipo cliente SAP HANA
    3. En ambos casos:
      1. Se lanzaría el comando de exportación como un script, del mismo modo que se ha expuesto con los backups
      2. Después se catalogaría la información utilizando un proceso de backup local, a través del cliente 'airback-fd' (más información en el manual del producto: v19: 04 - Backup#4.7Patronesdeficheros)
  2. Utilizando el plugin genérico Bpipe: Backup con el plugin genérico de conexión a APIs Bpipe

Vamos a exponer a continuación los detalles de la integración a través del segundo método, usando el plugin Bpipe que no requiere de ningún elemento externo y realizaría el proceso de una forma más directa.

Necesitamos crear 2 scripts, uno para backup (exportación de objeto) y otro para restauración (importación de objeto). A continuación exponemos un ejemplo:

Bpipe export table
#!/bin/bash
#

TABLENAME=$1
TEMPPATH=/tmp/$TABLENAME

rm -rf $TEMPPATH

/usr/sap/HXE/SYS/exe/hdb/hdbsql -t -n hxehost:39013 -i 90 -u SYSTEM -p xxxxx "EXPORT \"$TABLENAME\" AS CSV INTO '$TEMPPATH' WITH REPLACE THREADS 2;" > /dev/null 2>&1

tar -cvf - $TEMPPATH

Este script de exportación simplemente realiza un comando EXPORT en SAP HANA y luego comprime el resultado para enviarlo a WBSAirback. En el caso del script de importación:


Bpipe import table
#!/bin/bash
#

cat > /tmp/file.tgz

tar -C / -xvf /tmp/file.tgz

TABLENAME=$1
/usr/sap/HXE/SYS/exe/hdb/hdbsql -t -n hxehost:39013 -i 90 -u SYSTEM -p xxxxxx "IMPORT \"$TABLENAME\" AS CSV FROM '/tmp/$TABLENAME' WITH REPLACE THREADS 2;"

rm -f /tmp/file.tgz

Se puede comprobar que la operación es exactamente la inversa. Es importante mantener el flujo de datos de salida, para el caso del backup, y el de entrada para el restore. Es decir, no introducir otros comandos que puedan modificarlo o no tendremos éxito con este método. Sí es posible meter cualquier otra instrucción que se considere necesaria, pero siempre que no modifique lo que entra y/o sale en cada caso.

En base a estos scripts, definimos un patrón de ficheros de tipo Bpipe como el que mostramos a continuación:

Figura 8.2.1: Patrón de export/import de elemento

En este ejemplo estamos utilizando una tabla llamada 'EMPLOYEE'. Nótese que sería posible parametrizar cualquier otra variable para no tener que modificar los scripts.

Una vez asociemos ese patrón a un trabajo, un backup nos respaldará la exportación de la tabla en un fichero comprimido:

Figura 8.2.2: Log backup export table

Figura 8.2.3: Fichero respaldado

Sin mayor modificación, gracias al script definido de importación, podemos recuperar desde la pantalla mostrada en la figura 8.2.3, con lo que se generará la importación esperada a través de una ejecución de restauración:

Figura 8.2.4: Log de restauración

Se ha expuesto cómo podemos completar nuestra estrategia de backup con SAP HANA mediante procesos de exportación e importación controlados desde WBSAirback, para aquellos casos donde necesitemos recuperaciones frecuentes de objetos individuales. Este mismo método vale para tablas y/o esquemas. La complejidad y el dato específico a exportar en cada caso vendrá dado por el comando SQL que se utilice. Para mayor profundidad, por favor consulte la documentación oficial de SAP sobre este asunto.

9. Deduplicación

Es posible y recomendable utilizar deduplicación con SAP HANA.

Los datos provenientes de un backup de SAP HANA vienen en modo 'random' y sin comprimir, por lo tanto podemos esperar buenos ratios de compresión.

En cuanto a la deduplicación, dependerá totalmente del cambio diario de los datos a respaldar.  No existe ningún impedimiento técnico para obtener buenos resultados, por lo que si los datos cambian poco, la deduplicación será muy buena. Por el contrario, si los datos cambian mucho y frecuentemente, podremos esperar menores valores de deduplicación y habrá que valorar si es interesante o no su uso.

10. Reciclado y retenciones

Como en cualquier sistema SGBBDD que utliza sistemas de redo-logs, es necesario llevar a cabo una estrategia correcta de reciclado y archivado de backups. De lo contrario, el crecimiento del catálogo y de los recursos de almacenamiento utilizados puede verse desbordado en cualquier momento, evitando sucesivos backups, así como afectando al rendimiento y/o al propio servicio de base de datos.

10.1 Reciclado manual desde herramientas SAP Hana

Puede consultar la información oficial de SAP para 'housekeeping' de SAP HANA en el siguiente enlace:

Tal y como se explica en ese documento, es posible eliminar backups antiguos del catálogo solamente, o del backup y del disco, a través de herramientas de SAP HANA como SAP Hana Studio o SAP Hana Cockpit. Por ejemplo, desde SAP Hana Studio basta con seleccionar el backup que queremos eliminar y proceder con la opción correspondiente del botón derecho:

Figura 10.1.1: Eliminar backup manualmente desde SAP Hana Studio

Nos permite eliminar el backup específico seleccionado, o bien todos los backups anteriores al seleccionado.

Por otro lado, una vez elegida la opción deseada, debemos indicar si queremos eliminar sólo el catálogo o catálogo y datos:

Figura 10.1.2: Eliminar catálogo y datos desde SAP Hana Studio

En este punto, aunque elijamos esta segunda opción, los datos no desparecerán de WBSAirback®WBSAirback® siempre respetará la retención configurada en su propio catálogo y el borrado de los datos debe hacerse a través del propio appliance. Por lo tanto, la operación anterior mostrada en la imagen tendrá el mismo efecto que si se hubiese seleccionado la opción 'Catalog'.

También es posible realizar borrados a través de la consola SQL:

SQL recycle
BACKUP CATALOG DELETE ALL BEFORE BACKUP_ID <backup_id>


Es importante señalar que SAP Hana no permite el borrado de backups individuales de logs desde sus herramientas (ni usando la interfaz gráfica ni usando SQL). La razón es obvia, ya que un borrado accidental de este tipo de backups podría romper la cadena de copias y hacer inviable una restauración. Solo se pueden eliminar backups de logs cuando se eliminan generaciones enteras de backups (Full+Incs dependientes), lo cual se puede conseguir, por ejemplo, con la opción de borrado de backups más antiguos al que se tenga seleccionado.

A modo de referencia, SAP recomienda las siguientes best-practice generales en cuanto a qué limpiar y cuándo, para mantener un correcto 'housekeeping' de un entorno SAP Hana:

Figura 10.1.3: Best-practices de housekeeping en cuanto a frecuencia

10.2. Reciclado automático a través de script

Lo más recomendable es utilizar un script automático que sea capaz de eliminar los backups del catálogo en base a una retención determinada.

La estrategia general de reciclado recomendada utilizando WBSAirback® pasa por lo siguiente:

  1. Definir el mencionado script con una retención X.
  2. En WBSAirback establecer una retención en el pool asociado al trabajo de comunicación, siempre superior a la retención X establecida en SAP Hana.
  3. Aplicar retenciones mayores en un posible segundo nivel de tiering, donde enviaríamos la información de los backups de SAP HANA a través de jobs de copia (ese segundo nivel podría ser una librería, un almacenamiento objeto en nube, otra unidad WBSAirback con disco local, etc).

Por lo tanto, un script de SAP Hana se encargaría de mantener el catálogo de SAP Hana controlado. Por su parte WBSAirback®, irá archivando y/o eliminando de su propio catálogo y de su almacenamiento gestionado, aquellos backups que ya no forman parte del catálogo de SAP HANA. Para ello utilizará sus rutinas generales de reciclado (delte-purged-volumes).

SAP no proporciona una herramienta automática nativa para realizar esta tarea de forma nativa, por lo que la tarea puede realizarse de diferentes formas. Podemos emplear, por lo tanto, diferentes opciones: utilizar herramientas existentes en el mercado, utilizar scripts ya creados por la comunidad, o bien crear nuestro propio script.

Una de las más extendidas y aceptadas es 'SAPHANACleaner' y es la que vamos a detallar en este documento.

10.3. SAPHANACleaner

SAPHANACleaner es una herramienta escrita en python lo suficientemente flexible y potente como para realizar cualquier tipo de operación de 'housekeeping' de un entorno SAP Hana y se complementa perfectamente con un ciclo de vida de backup usando WBSAirback®. Podemos descargar la herramienta desde el siguiente enlace: https://github.com/chriselswede/hanacleaner

En esta sección vamos a detallar la configuración, algunos usos e integración con WBSAirback®. Para un uso más avanzado o particular de SAPHANACleaner, consulte la documentación completa sobre esta herramienta que se encuentra como parte de la información provista en ese mismo enlace: https://github.com/chriselswede/hanacleaner/blob/master/hanacleaner.pdf

También podemos consultar su ayuda a través de la línea de comandos:

SAPHANACleaner help
python hanacleaner.py --help

E incluso SAP tiene algún documento que explica también los pormenores de esta herramienta: https://help.sap.com/doc/f3dd8d9fb4ab407eb15ee4bf336ae42b/9.3/en-US/Housekeeping%20for%20SAP%20HANA.pdf

Los requisitos para poder utilizar esta herramienta son:

  • Tener python instalado
  • Ejecutar la herramienta con el usuario <SID>adm
  • La herramienta necesitará los privilegios oportunos para afrontar las tareas de reciclado que se le encomienden

SAPHANACleaner conecta a través del usuario de sistema <SID>adm, su password y el puerto oportuno con la instancia de BBDD a gestionar, a través de la herramienta hdbuserstore. Necesita también, por lo tanto, un usuario en la BBDD con los privilegios oportunos. Si utilizamos SAP HANA Studio, podemos crear el usuario de este modo:

Figura 10.3.1: Creación usuario

Figura 10.3.2: Privilegios de sistema para SAP HANA Cleaner

Figura 10.3.3: Privilegios de objeto para SAP HANA Cleaner (ambas tablas requieren los mismos privilegios)

Si es necesario por políticas generales establecidas, podemos eliminar la posible caducidad del usuario de este modo:

Disable user expiring
ALTER USER HANACLEANER DISABLE PASSWORD LIFETIME;

Si se desea añadir el usuario de una forma más automatizada, también se puede hacer a través de una sentencia SQL como la que sigue:

Disable user expiring
CREATE USER HANACLEANER PASSWORD MyPassword NO FORCE_FIRST_PASSWORD_CHANGE;
ALTER USER HANACLEANER DISABLE PASSWORD LIFETIME;
GRANT AUDIT ADMIN TO HANACLEANER; GRANT AUDIT OPERATOR TO HANACLEANER;
GRANT BACKUP ADMIN TO HANACLEANER; GRANT CATALOG READ TO HANACLEANER;
GRANT LOG ADMIN TO HANACLEANER; GRANT MONITOR ADMIN TO HANACLEANER;
GRANT RESOURCE ADMIN TO HANACLEANER; GRANT TRACE ADMIN TO HANACLEANER;
GRANT SELECT, DELETE ON _SYS_STATISTICS.STATISTICS_ALERTS_BASE TO HANACLEANER;
GRANT SELECT, DELETE ON _SYS_REPO.OBJECT_HISTORY TO HANACLEANER;
GRANT SELECT, DELETE ON _SYS_STATISTICS.HOST_OBJECT_LOCK_STATISTICS_BASE TO HANACLEANER;
ALTER USER HANACLEANER DISABLE PASSWORD LIFETIME;

Es necesario añadir este usuario para cada una de las BBDDs que se gestionen. En nuestro caso de ejemplo, se añadiría para SYSTEMDB y también para HXE.

Figura 10.3.4: Usuarios para 2 BBDD

Tras esto es necesario añadir los usuarios a hdbuserstore, para lo cual ejecutamos:

Hdbuserstore
hdbuserstore set <KEY> <hostname>:<sql port> <username> <password>

La <KEY> es un nombre único que relacionaremos con cada base de datos, por ejemplo:

  • CLEANER<SID> para tentants
  • CLEANERSYSDB para SYSDB

Usando nuestro sistema de ejemplo con el tenant HXE, añadiríamos los usuarios para las dos BBDD de este modo:

Hdbuserstore
hdbuserstore set CLEANERSYSDB hxehost:39013 HANACLEANER xxxxxx
hdbuserstore set CLEANERHXE hxehost:39015 HANACLEANER xxxxxx

Una vez tenemos configurado hdbuserstore, es recomendable hacer algunas pruebas para comprobar la correcta conexión:

hdbuserstore list
/> hdbuserstore list
DATA FILE       : /usr/sap/HXE/home/.hdb/hxehost/SSFS_HDB.DAT
KEY FILE        : /usr/sap/HXE/home/.hdb/hxehost/SSFS_HDB.KEY

KEY CLEANERHXE
  ENV : hxehost:39015
  USER: HANACLENAER
KEY CLEANERSYSDB
  ENV : hxehost:39013
  USER: HANACLENAER
KEY HXESAPDBCTRLHXE
  ENV : hxehost:39015
  USER: SAPDBCTRL

Con la conexión configurada, ya podemos ejecutar el script de limpieza, por ejemplo:

cleaner
python hanacleaner.py -bd 100 -be 5 -br true -k CLEANERSYSDB

Que nos borraría las entradas de catálogo de backup más antiguas a 100 días de nuestra BBDD SYSDB y nos mantendría un mínimo de 5 backups en el catálogo.

El script nos informa de lo que ha borrado:

cleaner
Will now check most used memory in the file systems. If it hangs there is an issue with  df -h, then see if the -fs flag helps.
The most used filesystem is using 
69%
***********************************************************
2020-01-16 13:07:29
hanacleaner as hxeadm by CLEANERHXE on HXE(90)  with 
hanacleaner.py -bd 100 -be 5 -br true -k CLEANERHXE
Cleanup Statements will be executed (-es is default true)
Before using HANACleaner read the disclaimer!
python hanacleaner.py --disclaimer
***********************************************************

REMOVED:
| ENTRY_ID             | ENTRY_TYPE_NAME      | BACKUP_ID            | SYS_START_TIME                | STATE_NAME |
|        1579102982688 | complete data backup |        1579102982688 | 2020-01-15 16:43:02.701000000 | successful |
|        1579103095736 | log backup           |        1579103095736 | 2020-01-15 16:44:55.736000000 | successful |
|        1579103644601 | log backup           |        1579103644601 | 2020-01-15 16:54:04.601000000 | successful |
|        1579103654320 | log backup           |        1579103654320 | 2020-01-15 16:54:14.320000000 | successful |
|        1579104544605 | log backup           |        1579104544605 | 2020-01-15 17:09:04.605000000 | successful |
|        1579104554242 | log backup           |        1579104554242 | 2020-01-15 17:09:14.242000000 | successful |
|        1579105444609 | log backup           |        1579105444609 | 2020-01-15 17:24:04.609000000 | successful |
|        1579105454289 | log backup           |        1579105454289 | 2020-01-15 17:24:14.289000000 | successful |
|        1579106344615 | log backup           |        1579106344615 | 2020-01-15 17:39:04.615000000 | successful |
|        1579106354348 | log backup           |        1579106354348 | 2020-01-15 17:39:14.348000000 | successful |
|        1579107244620 | log backup           |        1579107244620 | 2020-01-15 17:54:04.620000000 | successful |
|        1579107254248 | log backup           |        1579107254248 | 2020-01-15 17:54:14.248000000 | successful |
|        1579108144625 | log backup           |        1579108144625 | 2020-01-15 18:09:04.625000000 | successful |
|        1579108154281 | log backup           |        1579108154281 | 2020-01-15 18:09:14.281000000 | successful |
|        1579109044630 | log backup           |        1579109044630 | 2020-01-15 18:24:04.630000000 | successful |
|        1579109054254 | log backup           |        1579109054254 | 2020-01-15 18:24:14.254000000 | successful |
|        1579109944634 | log backup           |        1579109944634 | 2020-01-15 18:39:04.634000000 | successful |
|        1579109954199 | log backup           |        1579109954199 | 2020-01-15 18:39:14.199000000 | successful |
|        1579110844638 | log backup           |        1579110844638 | 2020-01-15 18:54:04.638000000 | successful |
|        1579110854253 | log backup           |        1579110854253 | 2020-01-15 18:54:14.253000000 | successful |
|        1579111744642 | log backup           |        1579111744642 | 2020-01-15 19:09:04.642000000 | successful |
|        1579111754261 | log backup           |        1579111754261 | 2020-01-15 19:09:14.261000000 | successful |
|        1579112644646 | log backup           |        1579112644646 | 2020-01-15 19:24:04.646000000 | successful |
|        1579112654270 | log backup           |        1579112654270 | 2020-01-15 19:24:14.270000000 | successful |
|        1579113544650 | log backup           |        1579113544650 | 2020-01-15 19:39:04.650000000 | successful |
|        1579113554265 | log backup           |        1579113554265 | 2020-01-15 19:39:14.265000000 | successful |
|        1579114444655 | log backup           |        1579114444655 | 2020-01-15 19:54:04.655000000 | successful |
|        1579114454278 | log backup           |        1579114454278 | 2020-01-15 19:54:14.278000000 | successful |
|        1579115344659 | log backup           |        1579115344659 | 2020-01-15 20:09:04.659000000 | successful |
|        1579115354235 | log backup           |        1579115354235 | 2020-01-15 20:09:14.235000000 | successful |
|        1579116244664 | log backup           |        1579116244664 | 2020-01-15 20:24:04.664000000 | successful |
|        1579116254279 | log backup           |        1579116254279 | 2020-01-15 20:24:14.279000000 | successful |
|        1579117144668 | log backup           |        1579117144668 | 2020-01-15 20:39:04.668000000 | successful |
|        1579117154283 | log backup           |        1579117154283 | 2020-01-15 20:39:14.283000000 | successful |
|        1579118044673 | log backup           |        1579118044673 | 2020-01-15 20:54:04.673000000 | successful |
|        1579118054269 | log backup           |        1579118054269 | 2020-01-15 20:54:14.269000000 | successful |
|        1579118944678 | log backup           |        1579118944678 | 2020-01-15 21:09:04.678000000 | successful |
|        1579118954294 | log backup           |        1579118954294 | 2020-01-15 21:09:14.294000000 | successful |
|        1579119844682 | log backup           |        1579119844682 | 2020-01-15 21:24:04.682000000 | successful |
|        1579119854304 | log backup           |        1579119854304 | 2020-01-15 21:24:14.304000000 | successful |
|        1579120744687 | log backup           |        1579120744687 | 2020-01-15 21:39:04.687000000 | successful |
|        1579120754306 | log backup           |        1579120754306 | 2020-01-15 21:39:14.306000000 | successful |
|        1579121644691 | log backup           |        1579121644691 | 2020-01-15 21:54:04.691000000 | successful |
|        1579121654311 | log backup           |        1579121654311 | 2020-01-15 21:54:14.311000000 | successful |
|        1579122544695 | log backup           |        1579122544695 | 2020-01-15 22:09:04.695000000 | successful |
|        1579122554231 | log backup           |        1579122554231 | 2020-01-15 22:09:14.231000000 | successful |
|        1579123444699 | log backup           |        1579123444699 | 2020-01-15 22:24:04.699000000 | successful |
|        1579123454316 | log backup           |        1579123454316 | 2020-01-15 22:24:14.316000000 | successful |
|        1579124344704 | log backup           |        1579124344704 | 2020-01-15 22:39:04.704000000 | successful |
|        1579124354320 | log backup           |        1579124354320 | 2020-01-15 22:39:14.321000000 | successful |
|        1579125244709 | log backup           |        1579125244709 | 2020-01-15 22:54:04.709000000 | successful |
|        1579125254322 | log backup           |        1579125254322 | 2020-01-15 22:54:14.322000000 | successful |
|        1579126144714 | log backup           |        1579126144714 | 2020-01-15 23:09:04.714000000 | successful |
|        1579126154338 | log backup           |        1579126154338 | 2020-01-15 23:09:14.338000000 | successful |
|        1579127044719 | log backup           |        1579127044719 | 2020-01-15 23:24:04.719000000 | successful |
|        1579127054336 | log backup           |        1579127054336 | 2020-01-15 23:24:14.336000000 | successful |
|        1579127944724 | log backup           |        1579127944724 | 2020-01-15 23:39:04.724000000 | successful |
|        1579127954341 | log backup           |        1579127954341 | 2020-01-15 23:39:14.341000000 | successful |
|        1579128844729 | log backup           |        1579128844729 | 2020-01-15 23:54:04.729000000 | successful |
|        1579128854347 | log backup           |        1579128854347 | 2020-01-15 23:54:14.347000000 | successful |
|        1579129744734 | log backup           |        1579129744734 | 2020-01-16 00:09:04.734000000 | successful |
|        1579129754348 | log backup           |        1579129754348 | 2020-01-16 00:09:14.348000000 | successful |
|        1579130644738 | log backup           |        1579130644738 | 2020-01-16 00:24:04.738000000 | successful |
|        1579130654366 | log backup           |        1579130654366 | 2020-01-16 00:24:14.366000000 | successful |
|        1579131544749 | log backup           |        1579131544749 | 2020-01-16 00:39:04.749000000 | successful |
|        1579131554330 | log backup           |        1579131554330 | 2020-01-16 00:39:14.330000000 | successful |
|        1579132444753 | log backup           |        1579132444753 | 2020-01-16 00:54:04.753000000 | successful |
|        1579132454372 | log backup           |        1579132454372 | 2020-01-16 00:54:14.372000000 | successful |
|        1579133344757 | log backup           |        1579133344757 | 2020-01-16 01:09:04.757000000 | successful |
|        1579133354359 | log backup           |        1579133354359 | 2020-01-16 01:09:14.359000000 | successful |
|        1579134244762 | log backup           |        1579134244762 | 2020-01-16 01:24:04.762000000 | successful |
|        1579134254383 | log backup           |        1579134254383 | 2020-01-16 01:24:14.383000000 | successful |
|        1579135144766 | log backup           |        1579135144766 | 2020-01-16 01:39:04.766000000 | successful |
|        1579135154385 | log backup           |        1579135154385 | 2020-01-16 01:39:14.385000000 | successful |
|        1579136044771 | log backup           |        1579136044771 | 2020-01-16 01:54:04.771000000 | successful |
|        1579136054305 | log backup           |        1579136054305 | 2020-01-16 01:54:14.305000000 | successful |
|        1579136944775 | log backup           |        1579136944775 | 2020-01-16 02:09:04.775000000 | successful |
|        1579136954350 | log backup           |        1579136954350 | 2020-01-16 02:09:14.350000000 | successful |
|        1579137844779 | log backup           |        1579137844779 | 2020-01-16 02:24:04.779000000 | successful |
|        1579137854498 | log backup           |        1579137854498 | 2020-01-16 02:24:14.498000000 | successful |
|        1579138744784 | log backup           |        1579138744784 | 2020-01-16 02:39:04.784000000 | successful |
|        1579138754374 | log backup           |        1579138754374 | 2020-01-16 02:39:14.374000000 | successful |
|        1579139644788 | log backup           |        1579139644788 | 2020-01-16 02:54:04.788000000 | successful |
|        1579139654409 | log backup           |        1579139654409 | 2020-01-16 02:54:14.409000000 | successful |
|        1579140544792 | log backup           |        1579140544792 | 2020-01-16 03:09:04.792000000 | successful |
|        1579140554331 | log backup           |        1579140554331 | 2020-01-16 03:09:14.331000000 | successful |
|        1579141444797 | log backup           |        1579141444797 | 2020-01-16 03:24:04.797000000 | successful |
|        1579141454417 | log backup           |        1579141454417 | 2020-01-16 03:24:14.417000000 | successful |
|        1579142344801 | log backup           |        1579142344801 | 2020-01-16 03:39:04.801000000 | successful |
|        1579142354419 | log backup           |        1579142354419 | 2020-01-16 03:39:14.419000000 | successful |
|        1579143244806 | log backup           |        1579143244806 | 2020-01-16 03:54:04.806000000 | successful |
|        1579143254424 | log backup           |        1579143254424 | 2020-01-16 03:54:14.424000000 | successful |
|        1579144144813 | log backup           |        1579144144813 | 2020-01-16 04:09:04.813000000 | successful |
|        1579144154441 | log backup           |        1579144154441 | 2020-01-16 04:09:14.441000000 | successful |
|        1579145044818 | log backup           |        1579145044818 | 2020-01-16 04:24:04.818000000 | successful |
|        1579145054403 | log backup           |        1579145054403 | 2020-01-16 04:24:14.403000000 | successful |
|        1579145944822 | log backup           |        1579145944822 | 2020-01-16 04:39:04.823000000 | successful |
|        1579145954439 | log backup           |        1579145954439 | 2020-01-16 04:39:14.439000000 | successful |
|        1579146844828 | log backup           |        1579146844828 | 2020-01-16 04:54:04.828000000 | successful |
|        1579146854446 | log backup           |        1579146854446 | 2020-01-16 04:54:14.446000000 | successful |
|        1579147744833 | log backup           |        1579147744833 | 2020-01-16 05:09:04.833000000 | successful |
|        1579147754446 | log backup           |        1579147754446 | 2020-01-16 05:09:14.447000000 | successful |
|        1579148644838 | log backup           |        1579148644838 | 2020-01-16 05:24:04.838000000 | successful |
|        1579148654460 | log backup           |        1579148654460 | 2020-01-16 05:24:14.460000000 | successful |
|        1579149544842 | log backup           |        1579149544842 | 2020-01-16 05:39:04.842000000 | successful |
|        1579149554490 | log backup           |        1579149554490 | 2020-01-16 05:39:14.490000000 | successful |
|        1579150444847 | log backup           |        1579150444847 | 2020-01-16 05:54:04.847000000 | successful |
|        1579150454397 | log backup           |        1579150454397 | 2020-01-16 05:54:14.397000000 | successful |
|        1579151344850 | log backup           |        1579151344850 | 2020-01-16 06:09:04.850000000 | successful |
|        1579151354426 | log backup           |        1579151354426 | 2020-01-16 06:09:14.427000000 | successful |
|        1579152244855 | log backup           |        1579152244855 | 2020-01-16 06:24:04.855000000 | successful |
|        1579152254472 | log backup           |        1579152254472 | 2020-01-16 06:24:14.472000000 | successful |
|        1579153144859 | log backup           |        1579153144859 | 2020-01-16 06:39:04.859000000 | successful |
|        1579153154474 | log backup           |        1579153154474 | 2020-01-16 06:39:14.474000000 | successful |
|        1579154044863 | log backup           |        1579154044863 | 2020-01-16 06:54:04.863000000 | successful |
|        1579154054483 | log backup           |        1579154054483 | 2020-01-16 06:54:14.483000000 | successful |
|        1579154944868 | log backup           |        1579154944868 | 2020-01-16 07:09:04.868000000 | successful |
|        1579154954484 | log backup           |        1579154954484 | 2020-01-16 07:09:14.484000000 | successful |
|        1579155844873 | log backup           |        1579155844873 | 2020-01-16 07:24:04.873000000 | successful |
|        1579155854504 | log backup           |        1579155854504 | 2020-01-16 07:24:14.505000000 | successful |
|        1579156744877 | log backup           |        1579156744877 | 2020-01-16 07:39:04.877000000 | successful |
|        1579156754494 | log backup           |        1579156754494 | 2020-01-16 07:39:14.495000000 | successful |
|        1579157644882 | log backup           |        1579157644882 | 2020-01-16 07:54:04.882000000 | successful |
|        1579157654502 | log backup           |        1579157654502 | 2020-01-16 07:54:14.503000000 | successful |
|        1579158544886 | log backup           |        1579158544886 | 2020-01-16 08:09:04.886000000 | successful |
|        1579158554501 | log backup           |        1579158554501 | 2020-01-16 08:09:14.502000000 | successful |
|        1579159444892 | log backup           |        1579159444892 | 2020-01-16 08:24:04.892000000 | successful |
|        1579159454509 | log backup           |        1579159454509 | 2020-01-16 08:24:14.509000000 | successful |
|        1579160344896 | log backup           |        1579160344896 | 2020-01-16 08:39:04.896000000 | successful |
|        1579160354517 | log backup           |        1579160354517 | 2020-01-16 08:39:14.517000000 | successful |
|        1579161244901 | log backup           |        1579161244901 | 2020-01-16 08:54:04.901000000 | successful |
|        1579161254482 | log backup           |        1579161254482 | 2020-01-16 08:54:14.482000000 | successful |
|        1579162144906 | log backup           |        1579162144906 | 2020-01-16 09:09:04.907000000 | successful |
|        1579162154494 | log backup           |        1579162154494 | 2020-01-16 09:09:14.494000000 | successful |
|        1579163044911 | log backup           |        1579163044911 | 2020-01-16 09:24:04.911000000 | successful |
|        1579163054533 | log backup           |        1579163054533 | 2020-01-16 09:24:14.533000000 | successful |
|        1579163944917 | log backup           |        1579163944917 | 2020-01-16 09:39:04.917000000 | successful |
|        1579163954499 | log backup           |        1579163954499 | 2020-01-16 09:39:14.499000000 | successful |
|        1579164844922 | log backup           |        1579164844922 | 2020-01-16 09:54:04.922000000 | successful |
|        1579164854536 | log backup           |        1579164854536 | 2020-01-16 09:54:14.536000000 | successful |
|        1579165744931 | log backup           |        1579165744931 | 2020-01-16 10:09:04.931000000 | successful |
|        1579165754551 | log backup           |        1579165754551 | 2020-01-16 10:09:14.551000000 | successful |
|        1579166644940 | log backup           |        1579166644940 | 2020-01-16 10:24:04.940000000 | successful |
|        1579166654553 | log backup           |        1579166654553 | 2020-01-16 10:24:14.554000000 | successful |
|        1579167544944 | log backup           |        1579167544944 | 2020-01-16 10:39:04.944000000 | successful |
|        1579167554562 | log backup           |        1579167554562 | 2020-01-16 10:39:14.563000000 | successful |
|        1579168444949 | log backup           |        1579168444949 | 2020-01-16 10:54:04.949000000 | successful |
|        1579168454528 | log backup           |        1579168454528 | 2020-01-16 10:54:14.528000000 | successful |
|        1579169344954 | log backup           |        1579169344954 | 2020-01-16 11:09:04.954000000 | successful |
|        1579169354572 | log backup           |        1579169354572 | 2020-01-16 11:09:14.572000000 | successful |
|        1579170244959 | log backup           |        1579170244959 | 2020-01-16 11:24:04.959000000 | successful |
|        1579170254575 | log backup           |        1579170254575 | 2020-01-16 11:24:14.575000000 | successful |
|        1579171144964 | log backup           |        1579171144964 | 2020-01-16 11:39:04.964000000 | successful |
|        1579171154582 | log backup           |        1579171154582 | 2020-01-16 11:39:14.582000000 | successful |
|        1579172044968 | log backup           |        1579172044968 | 2020-01-16 11:54:04.968000000 | successful |
|        1579172054515 | log backup           |        1579172054515 | 2020-01-16 11:54:14.515000000 | successful |
|        1579172944973 | log backup           |        1579172944973 | 2020-01-16 12:09:04.973000000 | successful |
|        1579172954588 | log backup           |        1579172954588 | 2020-01-16 12:09:14.588000000 | successful |
|        1579173844978 | log backup           |        1579173844978 | 2020-01-16 12:24:04.978000000 | successful |
|        1579173854595 | log backup           |        1579173854595 | 2020-01-16 12:24:14.595000000 | successful |
|        1579174744982 | log backup           |        1579174744982 | 2020-01-16 12:39:04.982000000 | successful |
|        1579174754553 | log backup           |        1579174754553 | 2020-01-16 12:39:14.553000000 | successful |
|        1579175644987 | log backup           |        1579175644987 | 2020-01-16 12:54:04.987000000 | successful |
|        1579175654604 | log backup           |        1579175654604 | 2020-01-16 12:54:14.604000000 | successful |


1 data backup entries and 162 log backup entries were removed from the backup catalog
    (Cleaning traces was not done since -tc and -tf were both -1 (or not specified))
    (Cleaning dumps was not done since -dr was -1 (or not specified))
    (Cleaning of general files was not done since -gr was -1 (or not specified))
    (Compression of the backup logs was not done since -zb was negative (or not specified))
    (Cleaning of the alerts was not done since -ar was negative (or not specified))
    (Cleaning of unknown object locks entries was not done since -kr was negative (or not specified))
    (Cleaning of the object history was not done since -om was negative (or not specified))
    (Reclaim of free logsements was not done since -lr was negative (or not specified))
    (Cleaning of events was not done since -eh and -eu were negative (or not specified))
    (Cleaning audit logs was not done since -ur was -1 (or not specified))
    (Defragmentation was not done since -fl was negative (or not specified))
    (Reclaim of row store containers was not done since -rc was negative (or not specified))
    (Compression re-optimization was not done since at least one flag in each of the three compression flag groups was negative (or not specified))
    (Creation of optimization statistics for virtual tables was not done since -vs was false (or not specified))
    (Cleaning of the hanacleaner logs was not done since -or was negative (or not specified))

La recomendación es gestionar este script desde WBSAirback, de la misma forma que hemos integrado los procesos de backup y restore. Podemos hacer un script con 2 variables, una para los días de retención y otra para el mínimo de backups, resultando en  siguiente:

Figura 10.3.5: Script de limpieza

Ese script haría referencia a un script de sistema con un contenido similar al siguiente (dependiendo del usuario y SO, la parte de variables de entorno podría variar):

script
/:/opt/bacula/sap> cat /opt/bacula/sap/clean.sh 
sh /usr/sap/HXE/home/.profile;
python /opt/bacula/sap/hanacleaner.py -bd $1 -be $2 -br true -k $3

A la hora de enlazar este script con el job correspondiente:

Figura 10.3.6: Script de limpieza en trabajo. Paso 1

Figura 10.3.7: Script de limpieza en trabajo. Paso 2

Y ya tendríamos el trabajo a disposición para ser controlado desde el appliance con la planificación oportuna. De esta forma tendremos todos los procesos centralizados y controlados en una única plataforma.

Figura 10.3.8: Log ejemplo de limpieza

11. Referencia de comandos

A continuación, a modo de referencia rápida, se listan algunos comandos que pueden resultar útiles a la hora de administrar el backup

  • Arrancar una BBDD SYSTEMDB SAP HANA (por ejemplo, tras restore fallido):  /usr/sap/<sid>/<instancia>/HDB start
    • Ejemplo: /usr/sap/HXE/HDB90/HDB start
  • Arrancar una BBDD tenant (SystemDB debe estar arrancada previamente): /usr/sap/<sid>/SYS/exe/hdb/hdbsql -t -n <host>:<port> -i 90 -u <user> -p <pass> "ALTER SYSTEM START DATABASE HXE"
    • /usr/sap/HXE/SYS/exe/hdb/hdbsql -t -n hxehost:39013 -i 90 -u SYSTEM -p xxxxxx "ALTER SYSTEM START DATABASE HXE"
  • Parar una BBDD tenant (SystemDB debe estar arrancada previamente): /usr/sap/<sid>/SYS/exe/hdb/hdbsql -t -n <host>:<port> -i 90 -u <user> -p <pass> "ALTER SYSTEM STOP DATABASE HXE"
    • /usr/sap/HXE/SYS/exe/hdb/hdbsql -t -n hxehost:39013 -i 90 -u SYSTEM -p xxxxxx "ALTER SYSTEM STOP DATABASE HXE"
  • Mostrar información (nombre de instancia, puerto, sid...): /usr/sap/HXE/SYS/exe/hdb/hdbsql -t -n <nombreHost>:39013 -i 90 -u <username> -p <password> "\s"
    • Ejemplo: /usr/sap/HXE/SYS/exe/hdb/hdbsql -t -n hxehost:39013 -i 90 -u SYSTEM -p xxxxx "\s"
  • Mostrar puertos por los que se están ofreciendo las distintas BBDD: netstat -lntp | grep hdbnameserver

12. Referencias 

En este punto se relacionan algunos enlaces útiles sobre administración de backup para SAP HANA:

13. Versiones

Historial de versiones del presente documento:

1.0Jorge Gea

Primera versión del documento completo.

  

1.1Jorge GeaArquitectura y otros ajustes

14. Contacto

Consultas o dudas relativas al presente documento, pueden dirigirlas a:

Jorge Gea

e: jorge.gea@wbsgo.com



WBSAirback

19

WhiteBearSolutions, WBSgo y WBSAirback y sus correspondientes logos son marcas registradas propiedad de WhiteBearSolutions, S.L.

WhiteBearSolutions realiza los mayores esfuerzos para asegurar que la información facilitada en el presente documento es precisa y exacta.

No obstante, no se responsabiliza de cualquier error o inexactitud de la misma recogido en el documento.

Las especificaciones e informaciones recogidas en el presente documento pueden ser modificadas sin previo aviso.

WhiteBearSolutions (WBSgo)

Calle Severo Ochoa 3, Planta 1 Of. 7 – 28232, Las Rozas (Madrid)
t. 902 90 69 69 f. 902 90 69 70 

  • No labels