How to Set Up Automated Database Backups for ownCloud Server

You discover the weakness in a backup plan at the worst possible time: an upgrade fails, a database table is damaged, or a server disappears, and the only “backup” is a copy of the user files. That is not enough for ownCloud Server. The database holds critical application state such as users, shares, file metadata, and configuration data. A reliable recovery plan needs the database as well as the files and configuration that belong to the same point in time.

This guide shows a practical way to automate ownCloud database backups on Linux, starting with a manual dump and ending with a scheduled, verified job. The examples focus on MySQL/MariaDB because ownCloud recommends those engines, and a PostgreSQL variant is included. The commands are aligned with the current ownCloud Server 11.0 administration documentation, while also noting the command difference for traditional non-Docker installations.

First, understand what a database backup does not cover

A database dump is only one part of an ownCloud backup. The ownCloud Server 11.0 backup documentation lists the database together with the configuration directory, data directory, app directories when applicable, and custom theme files. The data directory can also contain encryption keys, so a database-only backup cannot reconstruct a complete server after total storage loss.

Use the automation below for database protection, but pair it with a file-level backup or snapshot strategy for the rest of the ownCloud installation. When you need a fully consistent recovery point, coordinate the database dump and the file backup in the same maintenance window.

Step 1: Confirm which database ownCloud uses

Before writing a backup command, identify the database type, host, database name, and user. On a classic ownCloud installation, these values are normally available in config/config.php. You can also inspect system configuration with the ownCloud command-line tool. For example, from the ownCloud directory:

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

On a Docker Compose deployment, the current documentation uses commands such as:

docker compose exec owncloud occ config:list system

Look for values such as dbtype, dbhost, dbname, and dbuser. ownCloud Server 11.0 officially supports MySQL/MariaDB and PostgreSQL, with MySQL or MariaDB recommended for normal deployments.

Step 2: Create a protected backup location

Create a dedicated directory that is not web-accessible. Root ownership is a sensible default when the scheduled task runs from root's crontab:

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

Check free space with df -h /var/backups/owncloud-db. A backup job that silently fills the system disk can create a second outage while trying to protect against the first one.

Passaggio 3: non includere le credenziali del database nel comando cron

Non inserire la password del database direttamente nella riga crontab. Per MySQL o MariaDB, un file di opzioni client leggibile da root è semplice e funziona bene con i processi non presidiati. Crea /etc/owncloud/db-backup.cnf:

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

Quindi limitalo:

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

Utilizza i valori reali della tua configurazione ownCloud. Se il tuo database è remoto, imposta l'host appropriato. Il manuale di MySQL documenta i file di opzione per i programmi client e questo approccio evita di esporre direttamente la password in un comando pianificato.

Passaggio 4: Eseguire un backup manuale in modalità di manutenzione

La procedura di backup ufficiale di ownCloud prevede di impedire l'accesso normale e di mettere l'istanza in modalità di manutenzione prima di eseguire il backup del database. Per una distribuzione con Docker Compose:

docker compose exec owncloud occ maintenance:mode --on

Per un'installazione tradizionale dalla directory di ownCloud:

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

La modalità di manutenzione blocca la normale attività dell'utente durante la creazione del punto di ripristino. Ciò significa che un'attività automatizzata dovrebbe essere eseguita durante un periodo di basso traffico e deve sempre disattivare la modalità di manutenzione, anche in caso di errore durante il dump.

Per MySQL o MariaDB, prova con un dump manuale:

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 documentazione di ownCloud utilizza mysqldump --single-transaction. La documentazione di riferimento di MySQL per mysqldump spiega che --single-transactioncrea uno snapshot coerente per le tabelle transazionali come InnoDB senza mantenere i blocchi della tabella per tutta la durata del dump. L' --quickopzione esegue lo streaming delle righe anziché memorizzare in un buffer una tabella di grandi dimensioni in memoria.

Al termine del backup manuale, disattivare la modalità di manutenzione con il comando corrispondente:

docker compose exec owncloud occ maintenance:mode --off

O:

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

Passaggio 5: Inserire la logica di backup in uno script a prova di errore

Lo script dovrebbe interrompersi in caso di errori, registrare un timestamp, abilitare la modalità di manutenzione, creare il dump, verificare il file compresso, applicare i criteri di conservazione e garantire che la modalità di manutenzione sia disabilitata all'uscita. L'esempio seguente presuppone un'installazione classica in /var/www/owncloude un database MySQL/MariaDB denominato 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

Salvalo come /usr/local/sbin/owncloud-db-backup.sh, rendilo eseguibile con chmod 700, quindi eseguilo manualmente. Se il tuo ownCloud è containerizzato, sostituisci le due occrighe con i comandi di modalità di manutenzione di Docker Compose che corrispondono alla tua implementazione.

Passaggio 6: Pianificalo con cron

Dopo che l'esecuzione manuale è andata a buon fine, pianifica lo script. Apri crontab come utente root:

sudo crontab -e

Per una corsa quotidiana alle 2:15 del mattino:

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

Scegli un orario che corrisponda al tuo effettivo modello di utilizzo. Se il database è di grandi dimensioni, misura prima quanto tempo richiede l'esecuzione manuale, poiché la modalità di manutenzione crea un'interruzione del servizio visibile. Assicurati inoltre che cron abbia un ambiente prevedibile: utilizza percorsi assoluti nello script se i comandi richiesti non sono presenti nel percorso predefinito di cron PATH.

Passaggio 7: Verifica ogni backup invece di fidarti del timestamp

Un file con la data odierna non è di per sé prova che il backup sia recuperabile. Come minimo, verifica che il file non sia vuoto, che gzip non segnali alcun danneggiamento e che il registro del processo non contenga errori di dump.

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

Per un test più rigoroso, ripristina un dump recente in un database temporaneo su un sistema non di produzione. Non testare il ripristino sovrascrivendo il database di produzione. Una vera simulazione di ripristino verifica più della semplice integrità dei file: conferma le credenziali, i privilegi del database, la compatibilità del dump e la procedura di ripristino che il tuo team utilizzerebbe effettivamente.

Passaggio 8: Verificare che ownCloud sia tornato al normale funzionamento.

Al termine dello script, la modalità di manutenzione dovrebbe essere disattivata e gli utenti dovrebbero essere in grado di accedere normalmente. Controllare l'interfaccia web e rivedere il registro di backup. Un'automazione efficace non si limita alla creazione di un dump, ma è anche in grado di gestire gli errori in modo sicuro e di non lasciare il servizio bloccato in modalità di manutenzione.

Cosa cambia se si utilizza PostgreSQL?

La documentazione di backup di ownCloud utilizza pg_dumpun formato di archivio per PostgreSQL. La documentazione ufficiale di pg_dump di PostgreSQL afferma che pg_dumpcrea un'esportazione coerente anche mentre il database è in uso. Il capitolo più ampio sul backup e il ripristino di PostgreSQL distingue inoltre i dump logici dai backup del file system e dall'archiviazione continua.

Un semplice comando orientato a ownCloud è:

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

Per l'automazione, è preferibile utilizzare il meccanismo di gestione delle password supportato da PostgreSQL piuttosto che integrarlo PGPASSWORDnello script. Mantenere gli stessi principi relativi alla modalità di manutenzione, alla conservazione dei dati, alla registrazione e al test di ripristino.

Quanti backup dovresti conservare?

Non esiste un unico periodo di conservazione adatto a tutti i server ownCloud. Il periodo di conservazione deve essere scelto in base alla velocità con cui i dati cambiano, alla quantità di spazio di archiviazione disponibile e al periodo di tempo a cui potrebbe essere necessario tornare indietro. Quattordici dump giornalieri del database sono un esempio ragionevole per un server di piccole dimensioni, ma non rappresentano un requisito universale.

Verifica finale

Il backup automatico del database è pronto solo quando tutte le seguenti affermazioni sono vere:

• Sai se il server utilizza MySQL/MariaDB o PostgreSQL e hai verificato il nome corretto del database e l'host.
• La directory di backup è protetta e dispone di spazio libero sufficiente.
• Le credenziali non sono esposte nel comando crontab.
• Il backup manuale viene completato correttamente prima che venga abilitata la pianificazione.
• Lo script esce sempre dalla modalità di manutenzione, anche dopo un dump non riuscito.
• Il processo pianificato scrive un registro e crea un backup non vuoto nei tempi previsti.
• I vecchi rifiuti vengono rimossi secondo una precisa politica di conservazione.
• Un backup recente è stato ripristinato correttamente in un database non di produzione.
• Il backup del database è abbinato ai backup dei dati di ownCloud, della configurazione e di altre directory necessarie.

Se uno qualsiasi di questi controlli fallisce, è necessario risolvere il problema prima di affidarsi all'automazione. Un sistema di backup è utile solo dopo aver testato il percorso di ripristino.