Comment configurer des sauvegardes de base de données automatisées pour le serveur ownCloud

Vous découvrez les failles d'un plan de sauvegarde au pire moment : une mise à jour échoue, une table de base de données est corrompue ou un serveur disparaît, et la seule « sauvegarde » disponible est une copie des fichiers utilisateur. C'est insuffisant pour ownCloud Server. La base de données contient des données critiques de l'application, comme les utilisateurs, les partages, les métadonnées des fichiers et les données de configuration. Un plan de récupération fiable nécessite la base de données, ainsi que les fichiers et la configuration correspondant à l'état du serveur à ce moment précis.

Ce guide présente une méthode pratique pour automatiser les sauvegardes de bases de données ownCloud sous Linux, depuis la sauvegarde manuelle jusqu'à la mise en place d'une tâche planifiée et vérifiée. Les exemples se concentrent sur MySQL/MariaDB, moteurs recommandés par ownCloud, mais une variante PostgreSQL est également fournie. Les commandes sont conformes à la documentation d'administration d'ownCloud Server 11.0, tout en précisant les différences pour les installations traditionnelles sans Docker.

Tout d'abord, il est important de comprendre ce qu'une sauvegarde de base de données ne couvre pas.

La sauvegarde de la base de données ne représente qu'une partie d'une sauvegarde ownCloud. La documentation de sauvegarde d'ownCloud Server 11.0 détaille la base de données ainsi que le répertoire de configuration, le répertoire de données, les répertoires d'applications (le cas échéant) et les fichiers de thème personnalisés. Le répertoire de données pouvant également contenir des clés de chiffrement, une sauvegarde de la base de données seule ne permet pas de reconstruire un serveur complet après une perte totale de données.

Utilisez l'automatisation ci-dessous pour la protection de la base de données, mais associez-la à une stratégie de sauvegarde au niveau fichier ou à la création d'instantanés pour le reste de votre installation ownCloud. Pour obtenir un point de restauration parfaitement cohérent, effectuez la sauvegarde de la base de données et la sauvegarde des fichiers simultanément lors de la même fenêtre de maintenance.

Étape 1 : Confirmer quelle base de données ownCloud utilise

Avant de rédiger une commande de sauvegarde, identifiez le type de base de données, l'hôte, le nom de la base de données et l'utilisateur. Sur une installation ownCloud classique, ces informations sont généralement disponibles dans config/config.phple répertoire `/etc/owncloud`. Vous pouvez également consulter la configuration système à l'aide de l'outil en ligne de commande ownCloud. Par exemple, depuis le répertoire ownCloud :

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

Dans le cadre d'un déploiement Docker Compose, la documentation actuelle utilise des commandes telles que :

docker compose exec owncloud occ config:list system

Recherchez des valeurs telles que dbtype, dbhost, dbname, et dbuser. ownCloud Server 11.0 prend officiellement en charge MySQL/MariaDB et PostgreSQL, MySQL ou MariaDB étant recommandés pour les déploiements normaux.

Étape 2 : Créer un emplacement de sauvegarde protégé

Créez un répertoire dédié non accessible via le Web. L'appartenance à l'utilisateur root est un choix judicieux par défaut lorsque la tâche planifiée s'exécute depuis le 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

Vérifiez l'espace libre avec df -h /var/backups/owncloud-db. Une tâche de sauvegarde qui remplit silencieusement le disque système peut provoquer une seconde panne tout en essayant de se prémunir contre la première.

Étape 3 : Ne pas inclure les informations d’identification de la base de données dans la commande cron

Ne saisissez pas le mot de passe de la base de données directement dans la ligne crontab. Pour MySQL ou MariaDB, un fichier d'options client accessible en lecture par l'administrateur est simple et fonctionne parfaitement avec les tâches automatisées. Créez/etc/owncloud/db-backup.cnf :

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

Ensuite, limitez-le :

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

Utilisez les valeurs réelles de votre configuration ownCloud. Si votre base de données est distante, indiquez l'hôte approprié. La documentation MySQL décrit les fichiers d'options pour les programmes clients ; cette approche évite d'exposer directement le mot de passe dans une commande planifiée.

Étape 4 : Exécutez une sauvegarde manuelle en mode maintenance

La procédure de sauvegarde officielle d'ownCloud recommande d'empêcher tout accès normal et de placer l'instance en mode maintenance avant de sauvegarder la base de données. Pour un déploiement Docker Compose :

docker compose exec owncloud occ maintenance:mode --on

Pour une installation traditionnelle depuis le répertoire ownCloud :

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

Le mode maintenance bloque toute activité utilisateur normale pendant la création du point de restauration. Par conséquent, une tâche automatisée doit s'exécuter pendant une période de faible trafic et désactiver systématiquement le mode maintenance, même en cas d'échec de la sauvegarde.

Pour MySQL ou MariaDB, testez une sauvegarde manuelle :

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 documentation d'ownCloud utilise cette méthode . La documentationmysqldump --single-transaction MySQL sur mysqldump explique qu'elle crée un instantané cohérent pour les tables transactionnelles telles qu'InnoDB sans verrouiller les tables pendant la sauvegarde. Cette option traite les lignes en continu plutôt que de mettre en mémoire tampon une grande table.--single-transaction--quick

Une fois la sauvegarde manuelle terminée, désactivez le mode maintenance à l'aide de la commande correspondante :

docker compose exec owncloud occ maintenance:mode --off

ou:

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

Étape 5 : Intégrez la logique de sauvegarde dans un script à sécurité intégrée

Le script doit s'arrêter en cas d'erreur, enregistrer un horodatage, activer le mode maintenance, créer la sauvegarde, vérifier le fichier compressé, appliquer la période de rétention et garantir la désactivation du mode maintenance à la fin du script. L'exemple suivant suppose une installation classique /var/www/owncloudet une base de données MySQL/MariaDB nomméeowncloud :

#!/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

Enregistrez le fichier /usr/local/sbin/owncloud-db-backup.sh, rendez-le exécutable avec `docker ps` chmod 700, puis exécutez-le manuellement. Si votre ownCloud est conteneurisé, remplacez les deux occlignes par les commandes de maintenance Docker Compose correspondant à votre déploiement.

Étape 6 : Planifiez-la avec cron

Une fois l'exécution manuelle réussie, planifiez le script. Ouvrez le crontab de root :

sudo crontab -e

Pour une course quotidienne à 2h15 du matin :

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

Choisissez un horaire correspondant à votre utilisation habituelle. Si la base de données est volumineuse, mesurez d'abord la durée d'une exécution manuelle, car le mode maintenance entraîne une interruption de service visible. Assurez-vous également que cron dispose d'un environnement prévisible : utilisez des chemins absolus dans le script si les commandes requises ne figurent pas dans la configuration par défaut de cron PATH.

Étape 7 : Vérifiez chaque sauvegarde au lieu de vous fier à l’horodatage.

Un fichier daté du jour même ne constitue pas une preuve de récupération de la sauvegarde. Vérifiez au minimum que le fichier n'est pas vide, que gzip ne signale aucune corruption et que le journal des tâches ne contient aucune erreur de vidage.

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

Pour un test plus rigoureux, restaurez une sauvegarde récente dans une base de données éphémère sur un système hors production. Ne testez pas la restauration en écrasant votre base de données en production. Un exercice de restauration complet vérifie bien plus que l'intégrité des fichiers : il confirme les identifiants, les privilèges de la base de données, la compatibilité de la sauvegarde et la procédure de récupération que votre équipe utiliserait réellement.

Étape 8 : Vérifier que ownCloud fonctionne de nouveau normalement.

Une fois le script terminé, le mode maintenance devrait être désactivé et les utilisateurs devraient pouvoir se connecter normalement. Consultez l'interface web et examinez le journal de sauvegarde. Une automatisation robuste ne se contente pas de créer une sauvegarde ; elle gère les erreurs de manière sécurisée et ne bloque pas le service en mode maintenance.

Qu'est-ce qui change si vous utilisez PostgreSQL ?

La documentation de sauvegarde d'ownCloud utilise pg_dumpun format d'archive pour PostgreSQL. La documentation officielle de PostgreSQL concernant pg_dump indique que ce pg_dumpdernier crée une exportation cohérente même lorsque la base de données est en cours d'utilisation. Le chapitre plus général consacré à la sauvegarde et à la restauration de PostgreSQL distingue également les sauvegardes logiques des sauvegardes du système de fichiers et de l'archivage continu.

Une commande simple orientée ownCloud est :

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

Pour l'automatisation, privilégiez le mécanisme de fichiers de mots de passe pris en charge par PostgreSQL plutôt que son intégration PGPASSWORDdans le script. Conservez les mêmes principes de maintenance, de conservation, de journalisation et de test de restauration.

Combien de sauvegardes devez-vous conserver ?

Il n'existe pas de durée de conservation unique convenant à tous les serveurs ownCloud. La durée de conservation doit être adaptée à la fréquence d'évolution des données, à la capacité de stockage disponible et à la période sur laquelle vous pourriez avoir besoin de revenir. Quatorze sauvegardes quotidiennes de la base de données constituent un exemple raisonnable pour un petit serveur, mais ne représentent pas une exigence universelle.

Auto-vérification finale

Votre sauvegarde automatisée de base de données est prête uniquement lorsque toutes ces conditions sont remplies :

• Vous savez si le serveur utilise MySQL/MariaDB ou PostgreSQL et vous avez vérifié le nom et l'hôte corrects de la base de données.
• Le répertoire de sauvegarde est protégé et dispose de suffisamment d'espace libre.
• Les informations d'identification ne sont pas exposées dans la commande crontab.
• Une sauvegarde manuelle s'effectue avec succès avant que la planification ne soit activée.
• Le script quitte toujours le mode maintenance, même après un échec de vidage mémoire.
• La tâche planifiée écrit un journal et crée une sauvegarde non vide à temps.
• Les anciens dépôts sont enlevés conformément à une politique de rétention délibérée.
• Une sauvegarde récente a été restaurée avec succès sur une base de données hors production.
• La sauvegarde de la base de données est associée à des sauvegardes des données, de la configuration et des autres répertoires nécessaires d'ownCloud.

Si l'un de ces contrôles échoue, corrigez le problème avant de vous fier à l'automatisation. Un système de sauvegarde n'est utile que si la procédure de restauration a été testée.