OTOBO Backup & Restore – Guía completa

OTOBO Backup & Restore – Guía completa

En esta guía nos sumergiremos a fondo en las estrategias de backup para OTOBO y analizaremos:

1. Dump de base de datos mediante mysqldump
2. Backup y restauración de volúmenes de Docker
3. Scripts propios de OTOBO backup.pl y restore.pl
4. Automatización con Cronjobs y gestión de errores
5. Archivado a largo plazo (p. ej., AWS S3)

1. Dump de base de datos con mysqldump

Ventaja: Rápido, independiente de la plataforma, contiene casi todos los tickets, usuarios y configuraciones.

Ejemplo de comando

mysqldump \
  --host=${DB_HOST} \
  --user=${DB_USER} \
  --password=${DB_PASS} \
  --column-statistics=0 \
  --single-transaction \
  --databases otobo \
  > /backup/otobo_db_$(date +'%Y%m%d_%H%M').sql

• --single-transaction: Minimiza los bloqueos de tabla (Table-Locks), OTOBO permanece disponible.
• Retención: p. ej., cada hora, últimos 72 dumps (3 días) vía Cron.

Cron-Job (cada hora, retención de 3 días)

0 * * * * /usr/local/bin/otobo_db_backup.sh

otobo_db_backup.sh crea el dump y elimina archivos con más de 3 días de antigüedad.

Ejemplo de script: otobo_db_backup.sh

#!/bin/bash
BACKUP_DIR="/backup/db"
mkdir -p "$BACKUP_DIR"
DATE=$(date +'%Y%m%d_%H%M')
FILE="$BACKUP_DIR/otobo_db_${DATE}.sql.gz"

echo "Creando DB-Dump en $FILE"
mysqldump --host=localhost --user=otobo \
  --password=SecretPass --column-statistics=0 \
  --single-transaction otobo | gzip > "$FILE"

# Eliminar dumps antiguos (más de 3 días)
find "$BACKUP_DIR" -type f -name '*.sql.gz' -mtime +3 -delete

2. Backup de volúmenes de Docker

Todos los archivos almacenados de forma persistente (adjuntos, configuración, logs) se encuentran en volúmenes de Docker.

2.1 Backup completo de los volúmenes

#!/bin/bash
DATE=$(date +'%d%m%Y_%H%M%S')
# Detener el contenedor para un sistema de archivos consistente
docker compose -f /opt/otobo-docker/compose.yml down

tar -czf "/tmp/docker_volumes_$DATE.tar.gz" /var/lib/docker/volumes

docker compose -f /opt/otobo-docker/compose.yml up -d --build

• Down/Up: Garantiza una copia limpia.
• Archivo: TAR comprimido en GZ en el directorio temporal del host.

2.2 Restauración: Volúmenes y contenedores

#!/bin/bash
# Uso: restore_volumes.sh backup_file.tar.gz
tar -xzf "$1" -C /
# Eliminar volúmenes antiguos
docker compose -f /opt/otobo-docker/compose.yml down
rm -rf /var/lib/docker/volumes
# Restaurar y reiniciar
tar -xzf "$1" -C /
docker compose -f /opt/otobo-docker/compose.yml up -d

3. Scripts de OTOBO: backup.pl & restore.pl

OTOBO proporciona sus propios scripts CLI dentro del contenedor:

# Mostrar ayuda
/opt/otobo/scripts/backup.pl -h

Opciones

Opción	Default	Descripción
-d, --backup-dir	requerido	Directorio de destino para los backups
-c, --compress	gzip	Método de compresión (gzip | bzip2)
-r, --remove-old-backups DAYS	ninguno	Elimina backups antiguos (en días)
-t, --backup-type	fullbackup	fullbackup (todo) | nofullbackup | dbonly

fullbackup: Base de datos + directorio Home (sin caché).
dbonly: Solo base de datos.

Ejemplo: Backup completo en el contenedor Docker

docker run --rm \
  --volume otobo_opt_otobo:/opt/otobo \
  --volume otobo_backup:/otobo_backup \
  rotheross/otobo:latest-10_0 scripts/backup.pl \
    --backup-dir /otobo_backup --compress gzip --remove-old-backups 7

Restauración en el contenedor

docker run --rm \
  --volume otobo_opt_otobo:/opt/otobo \
  --volume otobo_backup:/otobo_backup \
  rotheross/otobo:latest-10_0 scripts/restore.pl \
    --backup-dir /otobo_backup/20231015_123045 --backup-dir /opt/otobo

4. Automatización y gestión de errores

Script wrapper con verificación de errores

#!/bin/bash
COMPOSE_FILE="/opt/otobo-docker/compose.yml"
# Iniciar backup
docker compose -f "$COMPOSE_FILE" run --rm backup
if [ $? -ne 0 ]; then
  echo "El backup falló" >&2
  exit 1
fi
echo "Backup completado con éxito"

Antiguo: Cron para backup de volúmenes

0 */6 * * * /usr/local/bin/volume_backup.sh

Limpieza de backups antiguos

#!/bin/bash
BACKUP_DIR="/ruta/a/backups"
echo "Eliminando backups con más de 30 días en $BACKUP_DIR"
find "$BACKUP_DIR" -mindepth 1 -mtime +30 -exec rm -rf {} \\
  \;
echo "Listo."

5. Archivo a largo plazo y Cloud

• AWS S3: Carga de archivos .tar.gz y .sql.gz mediante aws cli o script de Python.
• rclone: Soporte para diversos destinos (S3, Azure Blob, FTP).
• Ventaja: Almacenamiento externo (offsite), escalabilidad ilimitada.

Diferencias con otros sistemas (contexto de backup)

En el ámbito de Backup & Restore, OTOBO y Znuny difieren en los siguientes aspectos:

• Backups de contenedores

  • OTOBO: La imagen oficial de Docker incluye un servicio de backup preinstalado con hooks de CLI (docker compose run backup), incluyendo montajes de volúmenes preparados y variables de entorno.
  • Znuny: Las configuraciones de Docker de la comunidad requieren añadir manualmente un contenedor de backup o adaptar scripts propios.

• Scripts CLI de OTOBO

  • OTOBO: backup.pl y restore.pl en la imagen soportan opciones de limpieza automática (--remove-old-backups), selección de compresión y flag de Single-Transaction.
  • Znuny: Existen scripts similares, a menudo sin --remove-old-backups o opciones avanzadas de DB-Dump; requiere adaptación manual.

• Optimizaciones de DB-Dump

  • OTOBO: Se recomienda y documenta el flag estándar --single-transaction para evitar bloqueos; la CLI asegura un uso consistente.
  • Znuny: La documentación de la comunidad suele referirse a un dump simple sin protección de transacciones, con riesgo de bloqueos bajo carga alta.

• Estrategia de Snapshot de volúmenes

  • OTOBO: Los scripts de ejemplo (p. ej., backup completo y restauración) son la referencia oficial y están probados en entornos multi-contenedor.
  • Znuny: Los scripts de snapshot varían mucho, faltan mejores prácticas oficiales; los usuarios a menudo deben definir sus propias secuencias de Down/Up.

• Automatización y plugins Cloud

  • OTOBO: Ejemplos de cargadores S3 integrados (script de Python) y módulos de configuración para Azure, Google Cloud Storage.
  • Znuny: No hay plugins core para almacenamiento en la nube; las soluciones suelen ser externas mediante rclone o scripts de carga separados.

6. Conclusión

Con estos scripts detallados y estrategias, sus datos de OTOBO estarán respaldados de forma segura, automatizable y rápidamente restaurables. Ya sea mediante DB-Dump, volúmenes de Docker o herramientas estándar de OTOBO, usted tiene todas las opciones bajo control.