Automatisez les sauvegardes Nextcloud cohérentes avec Restic et Cron

Pour une sauvegarde fiable de Nextcloud, suspendez l'activité des utilisateurs, exportez la base de données, puis utilisez Restic pour capturer cette exportation ainsi que les répertoires d'application et de données. Placez cette tâche dans un script appartenant à l'utilisateur root et planifiez-la avec cron ; vérifiez les instantanés et effectuez une restauration test avant de vous fier à la planification.

Cet exemple suppose un serveur Debian ou Ubuntu, une installation Nextcloud directe à l'emplacement indiqué /var/www/nextcloud, un répertoire de données distinct à l'emplacement indiqué /srv/nextcloud-dataet une base de données MariaDB. Remplacez ces valeurs par vos chemins d'accès et le nom de votre base de données. Les étapes ont été vérifiées par rapport au manuel d'administration de Nextcloud 35 et à la documentation de Restic 0.19.1 en octobre 2026.

Que doit contenir une sauvegarde Nextcloud ?

Les instructions de sauvegarde de Nextcloud indiquent que la configuration, les données, la base de données, le thème et les applications personnalisées sont les éléments importants à conserver. La sauvegarde du répertoire d'application complet inclut généralement sa configuration et les applications intégrées, mais vérifiez si des applications personnalisées, des thèmes ou le répertoire de données se trouvent ailleurs sur votre serveur. Indiquez chaque chemin d'accès dans la commande Restic.

Le mode maintenance verrouille les sessions en cours et empêche les nouvelles connexions pendant la sauvegarde. Cela réduit le risque de modification intempestive de la base de données et des fichiers, mais rend Nextcloud indisponible pendant toute la durée de l'opération. Pour un volume de données important, planifiez la sauvegarde pendant une période de faible activité. Si votre serveur exécute des processus ou des scripts externes qui écrivent directement dans le répertoire de données, suspendez-les également.

Les instructions officielles de sauvegarde de Nextcloud expliquent les composants et les options d'exportation de la base de données. Cette procédure utilise MariaDB ; pour PostgreSQL, MySQL ou SQLite, utilisez les commandes de sauvegarde et de restauration correspondantes dans la section « Base de données » du manuel .

Préparez Restic et protégez ses identifiants

Installez Restic et le client MariaDB à partir de la source de paquets de confiance de votre distribution. Choisissez un dépôt sur un disque différent ou une cible de sauvegarde distante. Un dépôt stocké uniquement sur le serveur Nextcloud ne protège pas contre la perte de ce serveur ou de son stockage. Ne placez pas le dépôt dans l'un des répertoires sauvegardés.

Restic chiffre les données du dépôt, mais vous avez besoin du mot de passe pour les restaurer. Créez un fichier de mots de passe et conservez-en une copie protégée hors du serveur, par exemple dans un gestionnaire de mots de passe sécurisé. Si le mot de passe est perdu, le dépôt chiffré sera illisible. Évitez de saisir le mot de passe directement dans la ligne de commande, une tâche cron ou un script.

sudo install -d -m 700 /root/.config/restic
sudo install -m 600 /dev/null /root/.config/restic/nextcloud-password
sudo install -m 600 /dev/null /root/.config/restic/nextcloud.env

Enregistrez en lieu sûr le mot de passe Restic choisi dans le fichier de mots de passe. Indiquez l'emplacement du dépôt et le chemin d'accès au fichier de mots de passe dans le fichier d'environnement :

RESTIC_REPOSITORY=/mnt/backup/nextcloud
RESTIC_PASSWORD_FILE=/root/.config/restic/nextcloud-password

Pour un serveur distant, utilisez l'URL et les identifiants du dépôt documenté de ce serveur, stockés avec des permissions restreintes. Restic documente la configuration du dépôt et la variable d'environnement password-file prise en charge dans son guide de préparation des dépôts . Initialisez un nouveau dépôt une seule fois, et non à chaque exécution.

set -a
. /root/.config/restic/nextcloud.env
set +a
restic init

Les identifiants MariaDB doivent également être protégés. Configurez un fichier d'options client accessible en lecture par l'utilisateur root, contenant par exemple /root/.my.cnfl'utilisateur, le mot de passe et l'hôte de la base de données, puis définissez ses permissions 600. Le script ci-dessous transmet ce fichier à mariadb-dump, afin que le mot de passe de la base de données n'apparaisse pas dans les arguments du processus.

Créez un script de sauvegarde qui remet Nextcloud en service.

Enregistrez le fichier suivant sous le nom /usr/local/sbin/nextcloud-restic-backup. Ajustez NC_DATA_DIRet DB_NAMEpour qu'ils correspondent config/config.php. Le script active le mode maintenance, exporte MariaDB, sauvegarde l'application, les données et une sauvegarde SQL temporaire, puis désactive le mode maintenance même si une commande ultérieure échoue.

#!/usr/bin/env bash
set -Eeuo pipefail
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

NC_DIR=/var/www/nextcloud
NC_DATA_DIR=/srv/nextcloud-data
DB_NAME=nextcloud
RESTIC_ENV=/root/.config/restic/nextcloud.env
DB_CNF=/root/.my.cnf

set -a
source "$RESTIC_ENV"
set +a
exec 9>/run/lock/nextcloud-restic.lock
flock -n 9 || exit 0

mountpoint -q /mnt/backup || {
  echo "Backup target is not mounted" >&2
  exit 1
}

install -d -m 700 /var/backups/nextcloud
STAGE_DIR=$(mktemp -d /var/backups/nextcloud/db.XXXXXX)
maintenance_on=0

cleanup() {
  if [[ "$maintenance_on" -eq 1 ]]; then
    sudo -u www-data php "$NC_DIR/occ" maintenance:mode --off ||
      logger -t nextcloud-restic "Could not disable maintenance mode"
  fi
  rm -rf "$STAGE_DIR"
}
trap cleanup EXIT
trap 'exit 130' INT
trap 'exit 143' TERM

sudo -u www-data php "$NC_DIR/occ" maintenance:mode --on
maintenance_on=1

mariadb-dump --defaults-extra-file="$DB_CNF"   --single-transaction --default-character-set=utf8mb4 "$DB_NAME"   > "$STAGE_DIR/nextcloud.sql"
test -s "$STAGE_DIR/nextcloud.sql"

restic backup "$NC_DIR" "$NC_DATA_DIR" "$STAGE_DIR" --tag nextcloud

Définissez les droits d'accès et de propriété afin que seul l'administrateur (root) puisse modifier ou exécuter le script, puis testez-le manuellement lors d'une fenêtre de maintenance. Cette mountpointvérification empêche l'envoi silencieux d'un dépôt volumineux vers le système de fichiers local du serveur en cas de disque de sauvegarde manquant. Si votre dépôt est distant et non monté localement, remplacez cette vérification par une méthode fiable pour votre système de stockage.

Vérifiez vos chemins d'accès avant la première exécution. Si le dossier de données se trouve déjà à l'intérieur du /var/www/nextcloudrépertoire d'installation, ne considérez pas le chemin d'accès d'exemple comme correct ; utilisez le répertoire de données réel défini dans la configuration de Nextcloud. Assurez-vous également que les applications ou thèmes personnalisés stockés en dehors du répertoire d'installation sont explicitement inclus.

Planifiez une tâche cron et vérifiez le résultat.

Après une exécution manuelle réussie, ajoutez une entrée crontab root sudo crontab -e. Cet exemple lance la tâche quotidiennement à 2h30 du matin en utilisant le chemin complet du script et enregistre la sortie pour le dépannage :

30 2 * * * /usr/local/sbin/nextcloud-restic-backup >> /var/log/nextcloud-restic.log 2>&1

Cron offre un environnement limité ; le script définit donc explicitement une plage horaire PATHet charge lui-même les paramètres Restic. Vérifiez que cron est activé sur votre distribution et que cette plage horaire ne coïncide pas avec l'exécution des tâches en arrière-plan de Nextcloud ou d'autres tâches de maintenance. La documentation de crontab pour Linux décrit le format de planification et l'environnement fourni par cron.

Vérifiez que la tâche a fonctionné en contrôlant /var/log/nextcloud-restic.logla sortie réussie et en listant les instantanés récents :

sudo bash -lc 'set -a; source /root/.config/restic/nextcloud.env; set +a; restic snapshots'
sudo bash -lc 'set -a; source /root/.config/restic/nextcloud.env; set +a; restic check'

checkLa vérification standard de la structure du dépôt par Restic est plus longue et peut consommer une bande passante importante pour un dépôt distant ; planifiez des restic check --read-datavérifications périodiques ou utilisez-les --read-data-subsetpour contrôler des portions de données au fil du temps. Consultez la documentation de Restic sur l'intégrité des dépôts .

La consultation d'un instantané ne constitue pas un test de restauration. Restaurez un instantané récent dans un répertoire temporaire distinct restic restore latest --target /tmp/nextcloud-restore-test, puis vérifiez la présence des fichiers de l'application, du répertoire de données et de la sauvegarde SQL. Ne procédez pas à une restauration par-dessus une installation en production à titre de test. Pour une récupération réelle, restaurez les fichiers et la base de données en un seul ensemble cohérent ; les instructions de restauration de Nextcloud détaillent la recréation de la base de données et les considérations relatives à la synchronisation des clients.

Cette configuration permet de créer des instantanés chiffrés reproductibles, mais cron ne surveille pas ses propres défaillances et Restic ne définit pas votre politique de rétention. Consultez le journal ou configurez des alertes pour les exécutions ayant échoué, conservez une copie distincte des identifiants du dépôt et testez régulièrement la restauration. Si la fenêtre de maintenance est trop longue, utilisez des instantanés coordonnés du système de fichiers et une exportation cohérente avec la base de données, conçue pour votre plateforme de stockage, plutôt que de sauvegarder en temps réel les fichiers modifiés.