Sinopsis
Al arrancar con la operatividad de un entorno de SAP Business One on HANA 10, a veces te encuentras con que no existen las posibilidades de instalar un SAP HANA Cockpit para la administración de HANA 2.0 o simplemente “no se presupuesto” en el alcance del proyecto.
Por las características de este tipo de proyectos (y el target de algunos clientes), muchas veces estos no cuentan con la infraestructura necesaria y el personal técnico calificado para la administración de HANA como “debería ser" siguiendo las buenas prácticas que recomienda SAP.
Esto pasa principalmente en entornos On-Premise en donde el cliente tiene que velar por la seguridad e integridad de sus datos, independientemente que la solución sea instalada bajo un hyperscaler o no.
La mayoría de los hyperscalers ofrecen soluciones de replicación, resguardo de datos, etc para garantizar los datos de los productos que podremos utilizar en ellos, pero estos a veces no son productos optados por algún perfil de clientes “muy chicos”.
En este tipo de clientes, mucho menos existe un personal disponible para realizar las políticas mínimas de respaldo/administración que requiere un sistema que utilice HANA, por lo que de alguna manera (y posterior a la instalación) hay que asegurar la operatividad del mismo ante eventos intempestivos durante su ciclo de vida.
Una forma rápida de hacerlo y con pocos recursos involucrados, es mediante la implementación de scripts que ejecuten los backups de forma programada, borren los viejos y se copien a otro sitio fuera del servidor Linux.
Nota del autor: Existen mil formas de hacer esta “tarea administrativa” (y que lo mejor es usar el HANA Cockpit de eso estamos claros) para garantizar las políticas mínimas de backup de la forma más económica posible. Esta es simplemente otra solución más que les puede servir a los consultores técnicos que implementan SAP Business One o tengan que administrar soluciones de este tipo con bases de datos HANA.
La solución
1. Tener el sistema correctamente instalado y andando (sin problemas, puede ser obvio pero es bueno cerciorarse antes de arrancar con esta tarea).
2. Una vez que hayamos cumplido con todo lo básico para tener andando B1 (en mi pasado artículo hablo de muchos tips al respecto) podemos arrancar con los siguientes pasos. Haber lanzado un backup de sistema y tenant por primera vez es clave para que arranquen los backups de log.
3. Revisar que los file systems de la instalación de HANA hayan quedado bien.
4. Crear un drive, (unidad de disco, SAN o similar) sobre algún Windows que tenga acceso al servidor Linux en donde instalamos HANA para replicar los respaldos que sacaremos desde Linux para de esta manera evitar que si perdemos esta instancia HANA perdamos toda la información del sistema.
Este drive deberá contar con al menos unas 5-10 veces el tamaño de nuestro backup completo de HANA, la idea es tener holgura para entren los backups de varios días y así tener unas políticas mínimas de resguardo de datos. A este drive lo llamaremos SAPBackups.
5. Crear una carpeta sobre /mnt (podríamos llamarla /SAPBK)
6. Una vez tengamos creada la unidad en Windows esta deberá ser “montada” en Linux también. Para esto deberíamos primero crear un usuario a nivel de la instancia local de Windows al cual llamaremos “montaje” con una clave determinada con los siguientes permisos. Algo así debería quedar:
7. Editamos con vim el archivo /etc/fstab y escribiríamos la línea necesaria para el montaje de este disco compartido y sea accesible desde Linux. Un ejemplo que funciona sería este:
//EC2AMAZ-XXXXX/BackupsB1 /mnt/SAPBK cifs user=montaje,pass=123XXX,rw,users 0 0
Al hacer un cat sobre el archivo nos debería devolver algo así:
9. Vamos al HANA Studio y creamos el usuario que realizara los respaldos programados. Lo llamaremos ZBACKUP y contará con estos privilegios :
10. Crearemos 2 scripts con el usuario root que se encargarán de los problemas de "archivos" para evitar la infame "situación de disco lleno" y otras cosas desafortunadas más que suceden cuando el cliente no tiene o no lo logra implementar una "buena" estrategia de backups.
Los scripts hacen lo siguiente:
a. El primer script lo llamaremos ZSYNCLOGS.sh. Este script se encarga de planificar cada 15 minutos en cron, entre las 5am y 23 horas (en horario nocturno se ejecutan los backups de data). En este caso se hará el borrado de los archivos "viejos" y la limpieza estará en otro script planificado con root también y que sincronizará el backup de data efectuado en el script de ejecución de backup de HANA. Se coloca el delete en el script para que limpie también los archivos viejos generados en el destino ya que normalmente solo copiara los archivos de logs recientes.
b. El Segundo script lo llamaremos ZSYNC-LIMPIEZA.sh este es un script de limpieza de backup de SYSTEMDB y del tenant NDB (en este caso nombramos el SID de HANA como NDB) y sus backups de logs - para HANA lo planificamos en el crontab de root también, ya que sincroniza el backup de data efectuado en el script de ejecución de backup de HANA. Dependiendo del espacio en el /hana/shared y del tamaño de cada juego de files de backup, dejamos n cantidad días de backup en el server Linux.
ZSYNCLOGS.sh
#!/bin/sh
rsync -avu --delete "/hana/shared/NDB/HDB00/backup" "/mnt/BACKUP/"
# the end
ZSYNC-LIMPIEZA.sh
#!/bin/sh
find /hana/shared/NDB/HDB00/backup/data/DB_NDB -type f -mtime +2 -exec rm -fv {} +
find /hana/shared/NDB/HDB00/backup/data/SYSTEMDB -type f -mtime +2 -exec rm -fv {} +
find /hana/shared/NDB/HDB00/backup/log/DB_NDB -type f -mtime +2 -exec rm -fv {} +
find /hana/shared/NDB/HDB00/backup/log/SYSTEMDB -type f -mtime +2 -exec rm -fv {} +
find /mnt/BACKUP/backup/data/DB_NDB -type f -mtime +2 -exec rm -fv {} +
find /mnt/BACKUP/backup/data/SYSTEMDB -type f -mtime +2 -exec rm -fv {} +
find /mnt/BACKUP/backup/log/DB_NDB -type f -mtime +2 -exec rm -fv {} +
find /mnt/BACKUP/backup/log/SYSTEMDB -type f -mtime +2 -exec rm -fv {} +
rsync -avu --delete "/hana/shared/NDB/HDB00/backup" "/mnt/BACKUP"
# the end
11. Con el usuario root habilitamos vía crontab -e los 2 scripts que creamos a continuación los dejamos programados para que se ejecuten a esas horas. Esto es referencial, depende de las particularidades del negocio.
0,15,30,45 5-23 * * * /hana/shared/NDB/HDB00/ZSYNCLOGS.sh
0 20 * * * /hana/shared/NDB/HDB00/ZSYNC-CLEAN.sh
12. Ahora crearemos el script que ejecuta los backups en HANA con el usuario ZBACKUP que creamos anteriormente. Para esto creamos un script llamado sh el cual se encargará de realizar los backups del tenant del SYSTEMDB y el tenant NDB (este es el tenant en donde instalamos SAP Busines One). Este script lo ejecutará el usuario ndbadm (<SIDadm>) y por lo tanto será programado con el crontab de este usuario. Los backups por defecto, van a parar a la ruta estándar de cada tenant y de esa manera (para no complicar) se dejará así. Entonces tendremos 2 juegos de backup en estas rutas y mas abajo se puede ver como quedaría el script llamando a realizar el backup:
ZBACKUP.sh
#!/bin/sh
time="$(date +"%Y-%m-%d-%H-%M-%S")"
/usr/sap/NDB/HDB00/exe/hdbsql -i 00 -n localhost:30015 -d NDB -u ZBACKUP -p 12345 "backup data using file ('$time')"
/usr/sap/NDB/HDB00/exe/hdbsql -i 00 -n localhost:30013 -d SystemDB -u ZBACKUP -p 12345 "backup data using file ('$time')"
# the end
The defaults paths:
/hana/shared/NDB/HDB00/backup/data/DB_NDB
/hana/shared/NDB/HDB00/backup/data/SYSTEMDB
13. Ahora lo que queda es programar el script con el usuario ndbadm mediante un crontab -e y ya de esa manera tendremos la planificación de los backups en HANA “automatizados”:
0 19 * * * /hana/shared/NDB/HDB00/ZBACKUP.sh
14. Los diferentes scripts deben tener permisos para que sean ejecutados a nivel de los usuarios correspondientes (root y ndbadm en cada caso).
15. Los backups se generarán de esta manera en Linux en el caso de data y log siempre tendrán el mismo juego de carpetas en relación a la cantidad de tenants que existan o se estén haciendo backups de ellos:
16. Si entramos a la locación del backup de data del tenant de SAP Business One (DB_NDB), se puede ver el juego de backups de 3 días seguidos que se ejecutaron de acuerdo a las políticas establecidas en los scripts que utilizamos (para SYSTEMDB tendríamos igual juego de archivos):
Y lo mismo para logs los cuales se ejecutan cada 15 minutos (tiempo por defecto determinado por HANA) :
17. Una vez que arranquen los backups también podremos ver como se sincroniza con Windows en el drive que destinamos para tal fin:
De esta manera tendremos replicado, al menos en 2 locaciones distintas, los juegos de backup de nuestro sistema HANA / SAP Business One. La idea es que el cliente tenga la posibilidad de copiar esos juegos de backups desde Windows y los guarde a su vez en otra locación, con el fin de resguardar los datos y así evitar eventos anómalos.
El Fin.
- SAP Managed Tags:
