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.

Passo 3: Mantenha as credenciais do banco de dados fora do comando cron.

Não insira a senha do banco de dados diretamente na linha do crontab. Para MySQL ou MariaDB, um arquivo de opções do cliente legível pelo root é simples e funciona bem com tarefas automatizadas. Crie /etc/owncloud/db-backup.cnf:

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

Em seguida, restrinja-o:

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

Utilize os valores reais da sua configuração do ownCloud. Se o seu banco de dados for remoto, defina o host apropriado. O manual do MySQL documenta os arquivos de opções para programas clientes, e essa abordagem evita expor a senha diretamente em um comando agendado.

Etapa 4: Execute um backup manual no modo de manutenção.

O procedimento oficial de backup do ownCloud recomenda impedir o acesso normal e colocar a instância em modo de manutenção antes de fazer o backup do banco de dados. Para uma implantação com Docker Compose:

docker compose exec owncloud occ maintenance:mode --on

Para uma instalação tradicional a partir do diretório ownCloud:

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

O modo de manutenção bloqueia a atividade normal do usuário enquanto o ponto de recuperação está sendo criado. Isso significa que uma tarefa automatizada deve ser executada durante um período de baixo tráfego e o modo de manutenção deve sempre ser desativado, mesmo que o despejo de memória falhe.

Para MySQL ou MariaDB, teste um dump 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

A documentação do ownCloud utiliza o comando ` mysqldump` mysqldump --single-transaction. A própria referência do MySQL sobre o `mysqldump` explica que --single-transactionele cria um snapshot consistente para tabelas transacionais, como o InnoDB, sem manter bloqueios de tabela durante o processo de dump. A --quickopção `--stream` transmite as linhas em vez de armazenar uma tabela grande em buffer na memória.

Quando o backup manual estiver concluído, desative o modo de manutenção com o comando correspondente:

docker compose exec owncloud occ maintenance:mode --off

ou:

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

Passo 5: Coloque a lógica de backup em um script à prova de falhas.

O script deve parar em caso de erros, registrar um carimbo de data/hora, ativar o modo de manutenção, criar o dump, verificar o arquivo compactado, aplicar a retenção e garantir que o modo de manutenção seja desativado ao final. O exemplo a seguir pressupõe uma instalação clássica em /var/www/owncloude um banco de dados MySQL/MariaDB chamado 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

Salve o arquivo como /usr/local/sbin/owncloud-db-backup.sh, torne-o executável com chmod 700, e execute-o manualmente. Se o seu ownCloud estiver em um contêiner, substitua as duas occlinhas pelos comandos do modo de manutenção do Docker Compose que correspondem à sua implantação.

Passo 6: Agende com o cron

Após a execução manual ser bem-sucedida, agende o script. Abra o crontab do root:

sudo crontab -e

Para uma corrida diária às 2h15 da manhã:

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

Escolha um horário que corresponda ao seu padrão de uso real. Se o banco de dados for grande, primeiro meça quanto tempo leva a execução manual, pois o modo de manutenção cria uma interrupção visível do serviço. Além disso, certifique-se de que o cron tenha um ambiente previsível: use caminhos absolutos no script se os comandos necessários não estiverem no padrão do cron PATH.

Passo 7: Verifique cada backup em vez de confiar apenas no registro de data e hora.

Um arquivo com a data de hoje não comprova que o backup é recuperável. No mínimo, verifique se o arquivo não está vazio, se o gzip não reporta corrupção e se o log de tarefas não contém erros de despejo.

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 um teste mais robusto, restaure um dump recente em um banco de dados descartável em um sistema que não seja de produção. Não teste a restauração sobrescrevendo seu banco de dados em produção. Um teste de restauração real verifica mais do que a integridade dos arquivos: ele confirma as credenciais, os privilégios do banco de dados, a compatibilidade do dump e o procedimento de recuperação que sua equipe realmente usaria.

Etapa 8: Confirme se o ownCloud voltou a funcionar normalmente.

Após a conclusão do script, o modo de manutenção deverá ser desativado e os usuários poderão fazer login normalmente. Verifique a interface web e revise o log de backup. Uma automação robusta não é apenas aquela que cria um dump; é aquela que falha de forma segura e não deixa o serviço bloqueado em modo de manutenção.

O que muda se você usar o PostgreSQL?

A documentação de backup do ownCloud utiliza pg_dumpum formato de arquivo para PostgreSQL. A documentação oficial do pg_dump do PostgreSQL afirma que pg_dumpele cria uma exportação consistente mesmo enquanto o banco de dados está em uso. O capítulo mais abrangente sobre backup e restauração do PostgreSQL também distingue entre dumps lógicos, backups do sistema de arquivos e arquivamento contínuo.

Um comando simples voltado para o 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

Para automação, prefira o mecanismo de arquivo de senhas suportado pelo PostgreSQL em vez de incorporá-lo PGPASSWORDao script. Mantenha os mesmos princípios de modo de manutenção, retenção, registro e teste de restauração.

Quantos backups você deve manter?

Não existe um período de retenção único que se adapte a todos os servidores ownCloud. O período de retenção deve ser adequado à rapidez com que os dados são alterados, à quantidade de armazenamento disponível e ao período de recuperação de dados que você possa precisar. Quatorze backups diários do banco de dados são um exemplo razoável para um servidor pequeno, mas não são um requisito universal.

Autoverificação final

O backup automático do seu banco de dados estará pronto somente quando todas as seguintes afirmações forem verdadeiras:

• Você sabe se o servidor usa MySQL/MariaDB ou PostgreSQL e verificou se o nome do banco de dados e o host estão corretos.
• O diretório de backup está protegido e possui espaço livre suficiente.
• As credenciais não são expostas no comando crontab.
• Um backup manual é concluído com sucesso antes que o agendamento seja ativado.
• O script sempre sai do modo de manutenção, inclusive após uma falha no despejo de memória.
• A tarefa agendada grava um registro e cria um backup não vazio no prazo estipulado.
• Os arquivos antigos são removidos de acordo com uma política de retenção deliberada.
• Um backup recente foi restaurado com sucesso em um banco de dados de não produção.
• O backup do banco de dados é feito em conjunto com backups dos dados do ownCloud, da configuração e de outros diretórios necessários.

Se alguma dessas verificações falhar, corrija esse ponto antes de confiar na automação. Um sistema de backup só é útil quando o caminho de recuperação foi testado.