Cómo configurar copias de seguridad automáticas de la base de datos para ownCloud Server

La debilidad de un plan de respaldo se descubre en el peor momento posible: una actualización falla, una tabla de la base de datos se daña o un servidor desaparece, y la única copia de seguridad es una copia de los archivos de usuario. Esto no es suficiente para ownCloud Server. La base de datos almacena información crítica de la aplicación, como usuarios, recursos compartidos, metadatos de archivos y datos de configuración. Un plan de recuperación confiable requiere tanto la base de datos como los archivos y la configuración correspondientes a ese momento.

Esta guía muestra una forma práctica de automatizar las copias de seguridad de la base de datos de ownCloud en Linux, desde una copia manual hasta una tarea programada y verificada. Los ejemplos se centran en MySQL/MariaDB, ya que ownCloud recomienda estos motores, e incluye una variante para PostgreSQL. Los comandos se ajustan a la documentación de administración actual de ownCloud Server 11.0, y también se indican las diferencias en los comandos para instalaciones tradicionales sin Docker.

Primero, comprenda qué no cubre una copia de seguridad de la base de datos.

Una copia de seguridad de la base de datos es solo una parte de la copia de seguridad de ownCloud. La documentación de copia de seguridad de ownCloud Server 11.0 incluye la base de datos, el directorio de configuración, el directorio de datos, los directorios de aplicaciones (cuando corresponda) y los archivos de temas personalizados. El directorio de datos también puede contener claves de cifrado, por lo que una copia de seguridad solo de la base de datos no puede reconstruir un servidor completo tras la pérdida total del almacenamiento.

Utilice la automatización que se describe a continuación para la protección de la base de datos, pero combínela con una estrategia de copia de seguridad o instantánea a nivel de archivo para el resto de la instalación de ownCloud. Cuando necesite un punto de recuperación totalmente consistente, coordine la copia de seguridad de la base de datos y la de los archivos en la misma ventana de mantenimiento.

Paso 1: Confirma qué base de datos utiliza ownCloud.

Antes de escribir un comando de copia de seguridad, identifique el tipo de base de datos, el host, el nombre de la base de datos y el usuario. En una instalación clásica de ownCloud, estos valores normalmente están disponibles en config/config.php. También puede inspeccionar la configuración del sistema con la herramienta de línea de comandos de ownCloud. Por ejemplo, desde el directorio de ownCloud:

sudo -u www-data ./occ config:list system

En un despliegue de Docker Compose, la documentación actual utiliza comandos como:

docker compose exec owncloud occ config:list system

Busque valores como dbtype, dbhost, dbname, y dbuser. ownCloud Server 11.0 admite oficialmente MySQL/MariaDB y PostgreSQL, aunque se recomienda MySQL o MariaDB para implementaciones normales.

Paso 2: Cree una ubicación de copia de seguridad protegida.

Cree un directorio dedicado que no sea accesible desde la web. La propiedad root es una opción predeterminada sensata cuando la tarea programada se ejecuta desde el crontab de root:

sudo mkdir -p /var/backups/owncloud-db
sudo chown root:root /var/backups/owncloud-db
sudo chmod 700 /var/backups/owncloud-db

Compruebe el espacio libre con df -h /var/backups/owncloud-db. Una tarea de copia de seguridad que llena silenciosamente el disco del sistema puede provocar una segunda interrupción al intentar protegerse contra la primera.

Paso 3: Mantenga las credenciales de la base de datos fuera del comando cron.

No introduzca la contraseña de la base de datos directamente en la línea de crontab. Para MySQL o MariaDB, un archivo de opciones de cliente legible por el usuario root es sencillo y funciona bien con trabajos desatendidos. Crear /etc/owncloud/db-backup.cnf:

[client]
user=ownclouduser
password=REPLACE_WITH_DATABASE_PASSWORD
host=localhost

Entonces, restringe su uso:

sudo chown root:root /etc/owncloud/db-backup.cnf
sudo chmod 600 /etc/owncloud/db-backup.cnf

Utilice los valores reales de su configuración de ownCloud. Si su base de datos es remota, configure el host correspondiente. El manual de MySQL documenta los archivos de opciones para los programas cliente, y este método evita exponer la contraseña directamente en un comando programado.

Paso 4: Ejecute una copia de seguridad manual en modo de mantenimiento.

El procedimiento oficial de copia de seguridad de ownCloud indica que se debe impedir el acceso normal y poner la instancia en modo de mantenimiento antes de realizar la copia de seguridad de la base de datos. Para una implementación de Docker Compose:

docker compose exec owncloud occ maintenance:mode --on

Para una instalación tradicional desde el directorio ownCloud:

sudo -u www-data ./occ maintenance:mode --on

El modo de mantenimiento bloquea la actividad normal del usuario mientras se crea el punto de recuperación. Esto significa que una tarea automatizada debe ejecutarse durante un período de bajo tráfico y siempre debe desactivar el modo de mantenimiento, incluso si falla la copia de seguridad.

Para MySQL o MariaDB, pruebe con un volcado manual:

sudo mysqldump   --defaults-extra-file=/etc/owncloud/db-backup.cnf   --single-transaction   --quick   owncloud   | gzip -c > /var/backups/owncloud-db/owncloud-db-$(date +%Y%m%d-%H%M%S).sql.gz

La documentación de ownCloud utiliza mysqldump --single-transaction. La propia referencia de mysqldump de MySQL explica que --single-transactioncrea una instantánea consistente para tablas transaccionales como InnoDB sin mantener bloqueos de tabla durante la duración del volcado. La --quickopción transmite filas en lugar de almacenar en búfer una tabla grande en memoria.

Cuando se complete la copia de seguridad manual, desactive el modo de mantenimiento con el comando correspondiente:

docker compose exec owncloud occ maintenance:mode --off

o:

sudo -u www-data ./occ maintenance:mode --off

Paso 5: Coloque la lógica de respaldo en un script a prueba de fallos.

El script debe detenerse en caso de errores, registrar una marca de tiempo, habilitar el modo de mantenimiento, crear el volcado, verificar el archivo comprimido, aplicar la retención y garantizar que el modo de mantenimiento se desactive al finalizar. El siguiente ejemplo asume una instalación clásica en /var/www/owncloudy una base de datos MySQL/MariaDB llamada owncloud:

#!/bin/bash
set -Eeuo pipefail

OC_ROOT="/var/www/owncloud"
BACKUP_DIR="/var/backups/owncloud-db"
DB_NAME="owncloud"
MYSQL_CNF="/etc/owncloud/db-backup.cnf"
STAMP="$(date +%Y%m%d-%H%M%S)"
OUT="$BACKUP_DIR/owncloud-db-$STAMP.sql.gz"

cleanup() {
  cd "$OC_ROOT"
  sudo -u www-data ./occ maintenance:mode --off || true
}
trap cleanup EXIT

mkdir -p "$BACKUP_DIR"
cd "$OC_ROOT"
sudo -u www-data ./occ maintenance:mode --on

mysqldump   --defaults-extra-file="$MYSQL_CNF"   --single-transaction   --quick   "$DB_NAME" | gzip -c > "$OUT"

test -s "$OUT"
gzip -t "$OUT"

find "$BACKUP_DIR"   -type f   -name 'owncloud-db-*.sql.gz'   -mtime +14   -delete

Guárdalo como /usr/local/sbin/owncloud-db-backup.sh, hazlo ejecutable con chmod 700, y luego ejecútalo manualmente. Si tu ownCloud está en contenedores, reemplaza las dos occlíneas con los comandos de Docker Compose en modo mantenimiento que coincidan con tu implementación.

Paso 6: Programarlo con cron.

Una vez que la ejecución manual se haya realizado correctamente, programe el script. Abra el crontab de root:

sudo crontab -e

Para correr diariamente a las 2:15 AM:

15 2 * * * /usr/local/sbin/owncloud-db-backup.sh >> /var/log/owncloud-db-backup.log 2>&1

Elija un horario que se ajuste a su patrón de uso real. Si la base de datos es grande, primero mida cuánto tiempo tarda la ejecución manual, ya que el modo de mantenimiento genera una interrupción visible del servicio. Además, asegúrese de que cron tenga un entorno predecible: utilice rutas absolutas en el script si los comandos necesarios no están en la ruta predeterminada de cron PATH.

Paso 7: Verifique cada copia de seguridad en lugar de confiar en la marca de tiempo.

Un archivo con la fecha de hoy no es prueba de una copia de seguridad recuperable. Como mínimo, verifique que el archivo no esté vacío, que gzip no reporte corrupción y que el registro de trabajo no contenga errores de volcado.

ls -lh /var/backups/owncloud-db/
gzip -t /var/backups/owncloud-db/owncloud-db-YYYYMMDD-HHMMSS.sql.gz
tail -n 100 /var/log/owncloud-db-backup.log

Para una prueba más rigurosa, restaure una copia de seguridad reciente en una base de datos desechable de un sistema que no sea de producción. No pruebe la restauración sobrescribiendo su base de datos activa. Una prueba de restauración real verifica más que la integridad de los archivos: confirma las credenciales, los privilegios de la base de datos, la compatibilidad de la copia de seguridad y el procedimiento de recuperación que su equipo utilizaría en la práctica.

Paso 8: Confirmar que ownCloud ha vuelto a funcionar con normalidad.

Una vez finalizado el script, el modo de mantenimiento debería estar desactivado y los usuarios deberían poder iniciar sesión con normalidad. Compruebe la interfaz web y revise el registro de copias de seguridad. Una automatización robusta no solo crea un volcado de memoria, sino que también garantiza que el servicio falle de forma segura y no se quede bloqueado en modo de mantenimiento.

¿Qué cambia si utilizas PostgreSQL?

La documentación de copias de seguridad de ownCloud utiliza pg_dumpun formato de archivo para PostgreSQL. La documentación oficial de pg_dump de PostgreSQL indica que pg_dumpcrea una exportación consistente incluso mientras se utiliza la base de datos. El capítulo más amplio sobre copias de seguridad y restauración de PostgreSQL también distingue entre volcados lógicos, copias de seguridad del sistema de archivos y archivado continuo.

Un comando sencillo orientado a ownCloud es:

PGPASSWORD="REPLACE_WITH_PASSWORD" pg_dump owncloud   -h localhost   -U ownclouduser   -F tar   -f /var/backups/owncloud-db/owncloud-db-$(date +%Y%m%d-%H%M%S).tar

Para la automatización, es preferible utilizar el mecanismo de archivo de contraseñas compatible con PostgreSQL en lugar de integrarlo PGPASSWORDen el script. Mantenga los mismos principios de modo de mantenimiento, retención, registro y pruebas de restauración.

¿Cuántas copias de seguridad debería conservar?

No existe un período de retención único que se ajuste a todos los servidores ownCloud. Adapte la retención a la frecuencia con la que cambian los datos, la capacidad de almacenamiento disponible y el período de tiempo que necesite recuperar. Catorce copias de seguridad diarias de la base de datos son un ejemplo razonable para un servidor pequeño, pero no son un requisito universal.

Autocomprobación final

La copia de seguridad automatizada de su base de datos solo estará lista cuando se cumplan todas estas condiciones:

• Usted sabe si el servidor utiliza MySQL/MariaDB o PostgreSQL y ha verificado el nombre de la base de datos y el host correctos.
• El directorio de copia de seguridad está protegido y tiene suficiente espacio libre.
• Las credenciales no se exponen en el comando crontab.
• La copia de seguridad manual se completa correctamente antes de que se habilite la programación.
• El script siempre sale del modo de mantenimiento, incluso después de un volcado fallido.
• La tarea programada escribe un registro y crea una copia de seguridad no vacía a tiempo.
• Los vertederos antiguos se retiran de acuerdo con una política de retención deliberada.
• Se ha restaurado correctamente una copia de seguridad reciente en una base de datos que no es de producción.
• La copia de seguridad de la base de datos se realiza junto con copias de seguridad de los datos de ownCloud, la configuración y otros directorios necesarios.

Si alguna de esas comprobaciones falla, corrija ese punto antes de confiar en la automatización. Un sistema de respaldo solo es útil cuando se ha probado la ruta de recuperación.