Comment sauvegarder Nextcloud avec Restic et Cron

Scénario illustratif (hypothétique) : Jordan administre un petit serveur Nextcloud sous Ubuntu. Les fichiers de l’application se trouvent dans `/usr/ local /var/www/nextcloud/`, les fichiers utilisateur dans ` /srv/nextcloud-data/usr/local/`, la base de données Nextcloud est stockée dans MariaDB, et un serveur Linux distant est accessible via SSH. Jordan souhaite une sauvegarde nocturne consultable et restaurable, et non une simple tâche cron exécutée sans erreur.

Cet exemple fournit à Jordan un flux de travail Restic et cron reproductible. Les chemins d'accès, les comptes de service, les noms de bases de données et la planification sont donnés à titre d'exemple ; remplacez-les par les valeurs de votre installation. Les commandes ne signifient pas que cette configuration a été exécutée ou testée sur un serveur réel.

Que doit contenir une sauvegarde Nextcloud utilisable ?

Une simple copie de dossier peut ne pas contenir les informations nécessaires à Nextcloud pour reconnecter les fichiers, les utilisateurs, les partages et les paramètres. Le manuel d'administration de Nextcloud 35 indique cinq éléments à conserver : le répertoire de configuration, les applications personnalisées (le cas échéant), le répertoire de données, le répertoire du thème et la base de données. Le guide de restauration précise que la base de données, le répertoire de données et les fichiers de configuration sont indispensables. Consultez le manuel correspondant à votre version de Nextcloud avant d'adapter cet exemple.

Jordan choisit de sauvegarder l'intégralité du répertoire d'application, incluant la configuration, les applications et les thèmes, ainsi que le répertoire de données et une sauvegarde de la base de données. Une copie distincte de chaque emplacement de stockage externe est également nécessaire si Nextcloud stocke le contenu utilisateur en dehors de ce répertoire /srv/nextcloud-data. Restic ne peut protéger que les chemins accessibles au processus de sauvegarde.

Les instructions officielles de sauvegarde de Nextcloud décrivent le mode maintenance et les sauvegardes de la base de données. Ses instructions de restauration expliquent pourquoi la base de données et l'arborescence des fichiers doivent provenir d'un point de récupération compatible.

1. Préparez Restic et ses identifiants.

Installez Restic depuis une source de paquets fiable et assurez-vous qu'il est accessible au compte qui exécutera la tâche. Cet exemple suppose que la tâche s'exécute en tant que root afin de pouvoir lire les fichiers Nextcloud et la sauvegarde de la base de données. Il utilise un dépôt SFTP distant ; ainsi, une panne du serveur d'applications de Jordan n'entraînerait pas la suppression de l'unique copie de sauvegarde.

restic version

install -d -m 700 /root/.config/restic
install -d -m 700 /root/.config/nextcloud

Créez un mot de passe robuste pour votre dépôt Restic et enregistrez-le /root/.config/restic/nextcloud-passwordavec les droits d'administrateur uniquement. Conservez une copie de récupération sécurisée de ce mot de passe dans un emplacement distinct du serveur et du dépôt. Restic chiffre les données du dépôt, mais la perte du mot de passe peut rendre ces sauvegardes chiffrées inutilisables. Ne saisissez jamais le mot de passe directement dans le script ou la ligne cron.

Configurez l'accès SSH non interactif pour le compte de sauvegarde sur l'hôte distant et vérifiez sa clé d'hôte via un canal de confiance. Indiquez ci-dessous l'emplacement du dépôt dans un répertoire où ce compte dispose des droits d'écriture :

export RESTIC_REPOSITORY='sftp:backup@vault.example.net:/srv/restic/nextcloud'
export RESTIC_PASSWORD_FILE='/root/.config/restic/nextcloud-password'
restic init

Initialisez un dépôt une seule fois. Le guide de préparation des dépôts de Restic documente les systèmes de stockage pris en charge et leur initialisation. Traitez le fichier de mots de passe et la clé SSH comme des informations d'identification sensibles et limitez leur accès.

2. Maintenez la base de données et les fichiers à un niveau compatible.

Nextcloud recommande le mode maintenance pour les sauvegardes car il bloque les nouvelles connexions et verrouille les sessions existantes afin d'éviter les incohérences de données. La commande doit être exécutée en tant qu'utilisateur HTTP ; sur une installation Ubuntu standard, cet utilisateur est généralement « admin » www-data. La fenêtre de maintenance de Jordan s'étend sur la durée de la sauvegarde de la base de données et de la sauvegarde Restic ; les utilisateurs ne peuvent donc pas travailler sur Nextcloud pendant cette période.

Pour MariaDB, le manuel Nextcloud recommande mariadb-dump --single-transactionde stocker les identifiants de base de données dans un fichier de configuration client protégé, par exemple `/etc/mariaDB` /root/.config/nextcloud/mariadb.cnf, plutôt que d'intégrer le mot de passe dans la commande.

[client]
user=nextcloud_backup
password=REPLACE_WITH_A_SECRET
host=localhost

Limitez l'accès au fichier chmod 600 /root/.config/nextcloud/mariadb.cnf. Créez un compte de base de données avec uniquement les privilèges requis par votre serveur et votre procédure de sauvegarde. Si votre instance Nextcloud utilise PostgreSQL ou SQLite, utilisez la méthode de sauvegarde documentée correspondante ; n'exécutez pas la commande MariaDB sans l'avoir modifiée.

3. Créez un script de sauvegarde protégé

Jordan enregistre le fichier suivant /usr/local/sbin/nextcloud-restic-backupet le rend exécutable. Il utilise un verrou pour éviter les exécutions simultanées, active le mode maintenance avant de créer la sauvegarde, sauvegarde cette sauvegarde avec les répertoires de l'application et des données, et tente de désactiver le mode maintenance même si une commande ultérieure échoue.

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

export RESTIC_REPOSITORY='sftp:backup@vault.example.net:/srv/restic/nextcloud'
export RESTIC_PASSWORD_FILE='/root/.config/restic/nextcloud-password'

NC_DIR='/var/www/nextcloud'
DATA_DIR='/srv/nextcloud-data'
DB_NAME='nextcloud'
DB_CNF='/root/.config/nextcloud/mariadb.cnf'
DUMP_DIR='/var/backups/nextcloud'
LOCK_FILE='/run/lock/nextcloud-restic-backup.lock'
STAMP=$(date -u +%Y%m%dT%H%M%SZ)
DUMP_FILE="$DUMP_DIR/nextcloud-$STAMP.sql"
maintenance_started=0

mkdir -p "$DUMP_DIR"
exec 9>"$LOCK_FILE"
flock -n 9 || { echo 'A Nextcloud backup is already running.' >&2; exit 1; }

finish() {
  result=$?
  trap - EXIT
  if [[ "$maintenance_started" == 1 ]]; then
    sudo -u www-data -- php "$NC_DIR/occ" maintenance:mode --off || result=1
  fi
  rm -f -- "$DUMP_FILE" || result=1
  exit "$result"
}
trap finish EXIT

sudo -u www-data -- php "$NC_DIR/occ" maintenance:mode --on
maintenance_started=1
mariadb-dump --defaults-extra-file="$DB_CNF" --single-transaction \
  --default-character-set=utf8mb4 --databases "$DB_NAME" > "$DUMP_FILE"
restic backup --tag nextcloud "$NC_DIR" "$DATA_DIR" "$DUMP_FILE"

Après avoir vérifié les chemins d'accès, créez l'exécutable avec les droits d'administrateur (root) et le mode de maintenance 700. Le script suppose que l'installation utilise www-dataMariaDB et les chemins d'accès indiqués ; vérifiez-les au config/config.phppréalable par rapport à la configuration de votre serveur web. Il suppose également qu'aucun autre administrateur n'a déjà activé le mode maintenance. En cas d'échec de la commande, de la sauvegarde ou du chargement via Restic, l'interpréteur de commandes se ferme avec une erreur et le système tente de rétablir le service ; consultez les journaux pour confirmer cette opération. La sauvegarde est stockée avec des permissions restrictives et supprimée après l'exécution.

Ce modèle simple rend le site inaccessible pendant toute la durée de l'analyse et du chargement avec Restic. Pour un répertoire de données volumineux, cette durée peut être excessive. Il est recommandé d'utiliser une sauvegarde coordonnée de la base de données et un instantané du stockage, ou une autre méthode de sauvegarde cohérente avec l'application si votre système de fichiers ou votre plateforme de stockage le permet. Assurez-vous que la base de données et l'instantané du stockage correspondent à un état compatible dans le temps ; copier indépendamment une base de données active et un répertoire de données en cours d'évolution peut générer une sauvegarde difficile à restaurer.

4. Planifiez la tâche avec cron

Une fois l'exécution manuelle terminée avec succès, Jordan installe le script et le programme pour une période calme. En tant que superutilisateur (root), modifiez le crontab de l'administrateur sudo crontab -eet ajoutez :

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

Cet exemple démarre à 2h15 du matin, heure locale du serveur ; choisissez une heure où la période de maintenance vous convient. L'environnement de Cron étant plus restreint qu'un shell interactif, le script PATHutilise des chemins absolus et définis explicitement les variables d'environnement. Créez le fichier journal avec des permissions restrictives et configurez la rotation des journaux, ou redirigez la sortie vers le service de journalisation standard de votre système. La planification par Cron lance uniquement la tâche : elle ne garantit ni la fin de la sauvegarde ni la réussite de la restauration.

5. Définir la rétention et vérifier le résultat

Après une sauvegarde réussie, Jordan vérifie qu'un instantané apparaît :

restic snapshots --tag nextcloud
restic check

restic checkCette opération vérifie la structure du référentiel. Elle restic check --read-datalit également les données stockées et peut consommer beaucoup de ressources réseau et disque ; planifiez-la donc en fonction de la taille du référentiel et des besoins de récupération. Le guide de conservation des snapshots de Restic explique que l’oubli des snapshots et la suppression des données non référencées sont des opérations distinctes, et que la suppression verrouille le référentiel. Commencez par un test à blanc et définissez une politique de conservation adaptée à vos exigences.

restic forget --tag nextcloud --keep-daily 7 --keep-weekly 5 \
  --keep-monthly 12 --dry-run

Examinez les instantanés qu'il propose de supprimer. Une fois satisfait, supprimez-les --dry-runet ajoutez-les--prune ; effectuez l'élagage lorsqu'il n'entre pas en conflit avec la sauvegarde nocturne. Ces durées de conservation sont données à titre d'exemple et ne constituent pas une politique universelle. Tenez compte des obligations légales de conservation, de l'espace de stockage disponible et de la période de restauration nécessaire.

Le test pertinent consiste à effectuer une restauration. Restaurez un instantané récent dans un répertoire temporaire sur un système distinct, et non en écrasant les chemins Nextcloud actifs de Jordan :

restic restore latest --tag nextcloud --target /tmp/nextcloud-restore-check

Vérifiez que l'arborescence restaurée contient bien la configuration, les données et la sauvegarde de base de données attendues, et examinez des fichiers représentatifs. Pour une restauration complète, suivez le manuel de restauration de Nextcloud dans un environnement isolé et vérifiez la connexion, l'accès aux fichiers et les partages attendus avant de lancer la procédure. La documentation de Restic explique comment sélectionner les instantanés et les cibles de restauration.

Comment savoir quand cette approche doit changer ?

La tâche cron de Jordan convient uniquement si la fenêtre de maintenance correspond à la durée de la sauvegarde et si tous les chemins de données requis sont locaux et accessibles en lecture. Modifiez la conception dès l'apparition de l'un des signes suivants :

• Le site reste en mode maintenance plus longtemps que les utilisateurs ne peuvent le supporter : prévoyez des instantanés coordonnés ou une autre méthode cohérente avec l’application.
• Les journaux indiquent des chemins manquants, des erreurs d'autorisation, un échec de la sauvegarde de la base de données ou une sortie Restic non nulle : corrigez ces problèmes avant de considérer l'instantané comme terminé.
• Les données résident sur un support de stockage externe ou sur un autre serveur : incluez une sauvegarde cohérente de ce stockage dans le plan de récupération.
• Une restauration de test ne contient pas les fichiers, la configuration, l'état de la base de données ou le code d'application/de thème requis : mettez à jour les entrées de sauvegarde et répétez l'opération.
• Le mot de passe Restic ou les identifiants SSH existent uniquement sur le serveur sauvegardé : stockez les identifiants de récupération séparément et vérifiez qu’un administrateur autorisé peut y accéder.

Pour Jordan, le succès est manifeste : le journal cron indique une exécution terminée, restic snapshotsaffiche un instantané récent étiqueté, les vérifications du dépôt ne signalent aucune erreur et une restauration permet de récupérer une instance Nextcloud cohérente. Une commande planifiée marque le début d'une procédure de sauvegarde ; seule une sauvegarde complète et restaurable des données de base de données, de configuration, d'application et d'utilisateur offre une solution de récupération viable.

Références officielles

• Manuel d'administration de Nextcloud 35 : Sauvegarde
• Manuel d'administration de Nextcloud 35 : Restauration d'une sauvegarde
• Documentation Restic 0.19.1