Nextcloud : backup et restore

Un backup Nextcloud utile couvre trois composants qu'il faut sauvegarder ensemble et cohérents : le data directory (les fichiers utilisateurs), la base de données, et le fichier config/config.php. Omettre l'un des trois rend la restauration impossible. Cette doc explique ce que Datacampus prend en charge, et comment compléter côté applicatif si besoin.

Ce que Datacampus sauvegarde automatiquement

Sur toute instance Nextcloud managée, l'infrastructure assure :

• Snapshots de la VM — image bloc complète, incluant système, Nextcloud, data, base, config. Rétention et fréquence selon l'offre souscrite.
• Sauvegarde du data directory — copie incrémentale vers un stockage distinct, généralement la nuit.
• Dump de la base de données — MySQL/MariaDB ou PostgreSQL, avec verrouillage cohérent.
• Rétention — variable selon l'offre ; détail dans votre contrat ou sur demande.

Le PRA (Plan de Reprise d'Activité) Datacampus couvre le scénario perte totale. Pour les restaurations granulaires (un fichier supprimé par erreur), ouvrez un ticket en précisant le chemin, l'utilisateur et la date ciblée.

Pourquoi un backup applicatif en plus ?

Le backup infra est indispensable mais lourd : restaurer une VM entière pour récupérer un seul utilisateur est disproportionné. Un backup applicatif, que vous pilotez, permet :

• Une migration (vers une autre instance, un autre hébergeur, un test).
• Un point de restauration juste avant une opération risquée (mise à jour d'app communautaire, refonte des groupes).
• Un archivage long terme hors Datacampus (politique 3-2-1).

Sur une instance managée, le backup applicatif se fait depuis votre VPS d'administration — si vous n'en avez pas, c'est Datacampus qui l'exécute sur demande. Les commandes qui suivent s'appliquent à un VPS Nextcloud que vous administrez avec accès root/SSH.

Backup applicatif — procédure complète

1. Activer le mode maintenance

Le mode maintenance garantit qu'aucune écriture n'a lieu pendant la copie : la base et le data directory restent cohérents.

sudo -u www-data php /var/www/nextcloud/occ maintenance:mode --on

Sortie attendue : Maintenance mode enabled. Les utilisateurs voient une page de maintenance et les clients tombent temporairement en erreur — c'est le prix de la cohérence.

2. Copier le data directory

Le chemin du data est indiqué dans config/config.php sous la clé datadirectory. Souvent /var/www/nextcloud/data ou un point de montage dédié.

# Copie incrémentale rsync — à relancer régulièrement, seul le delta est transféré
rsync -av --delete \
    /var/nextcloud-data/ \
    /backup/nextcloud-data/

3. Dumper la base de données

MySQL/MariaDB :

mysqldump --single-transaction --default-character-set=utf8mb4 \
    -u NEXTCLOUD_DB_USER -p NEXTCLOUD_DB_NAME \
    > /backup/nextcloud-db-$(date +%F).sql

PostgreSQL :

PGPASSWORD='MDP' pg_dump -h localhost -U NEXTCLOUD_DB_USER \
    NEXTCLOUD_DB_NAME \
    > /backup/nextcloud-db-$(date +%F).sql

Récupérez les identifiants DB dans config/config.php (dbname, dbuser, dbpassword, dbhost).

4. Copier le répertoire d'installation

Le code Nextcloud lui-même peut être réinstallé, mais la copie du répertoire capture la version exacte, les apps installées et la config.

tar -czpf /backup/nextcloud-app-$(date +%F).tar.gz \
    --exclude='/var/www/nextcloud/data' \
    /var/www/nextcloud/

Noter que l'on exclut le data directory (déjà sauvegardé à l'étape 2). Le fichier config/config.php est capturé par ce tar.

5. Lister les apps installées (utile)

sudo -u www-data php /var/www/nextcloud/occ app:list > /backup/apps-$(date +%F).txt

Fichier court mais précieux : en cas de restauration partielle, vous saurez exactement quelles apps (et quelles versions) étaient actives.

6. Désactiver le mode maintenance

sudo -u www-data php /var/www/nextcloud/occ maintenance:mode --off

Sortie : Maintenance mode disabled. Les utilisateurs retrouvent l'accès.

Script d'automatisation

#!/bin/bash
set -e
NC="/var/www/nextcloud"
DATA="/var/nextcloud-data"
DEST="/backup/nextcloud"
DATE=$(date +%F)

sudo -u www-data php $NC/occ maintenance:mode --on

rsync -a --delete $DATA/ $DEST/data/

mysqldump --single-transaction --default-character-set=utf8mb4 \
    -u DBUSER -pDBPASS DBNAME > $DEST/db-$DATE.sql

tar -czpf $DEST/app-$DATE.tar.gz --exclude=$DATA $NC/
sudo -u www-data php $NC/occ app:list > $DEST/apps-$DATE.txt

sudo -u www-data php $NC/occ maintenance:mode --off

# Rotation : on garde 7 db et 7 app
ls -1t $DEST/db-*.sql | tail -n +8 | xargs -r rm
ls -1t $DEST/app-*.tar.gz | tail -n +8 | xargs -r rm

À planifier en cron (voir la doc Tâches planifiées) la nuit, suivi d'un rsync vers un stockage externe (autre site, S3, etc.) pour respecter la règle 3-2-1.

Restaurer un fichier utilisateur (sans backup applicatif)

Avant tout réflexe de restauration infra, demandez à l'utilisateur de vérifier :

Versions (historique)

1. Dans Fichiers, clic droit sur le fichier > Détails.
2. Onglet Versions.
3. Cliquez sur la version souhaitée pour la prévisualiser, puis sur Restaurer.

Nextcloud garde plusieurs versions intermédiaires (politique par défaut : de plus en plus espacées dans le temps). Ça couvre la grande majorité des « j'ai écrasé par erreur ».

Corbeille

Panneau de gauche > Fichiers supprimés. Rétention 30 jours par défaut, configurable. L'utilisateur restaure lui-même — aucun admin requis.

Restaurer une instance complète

Symétrique du backup : on remet la VM (ou le code + data + base + config) tel quel à une date donnée.

1. Mode maintenance activé (s'il y a encore une instance qui tourne) ou instance vide à reconstruire.
2. Restaurer l'arborescence Nextcloud : tar -xzpf nextcloud-app-YYYY-MM-DD.tar.gz -C /. Permissions : chown -R www-data:www-data /var/www/nextcloud.
3. Restaurer le data directory : rsync -a /backup/nextcloud-data/ /var/nextcloud-data/. Permissions : chown -R www-data:www-data /var/nextcloud-data.
4. Restaurer la base :

   mysql -u DBUSER -p DBNAME < nextcloud-db-YYYY-MM-DD.sql

   (Pour PostgreSQL : psql.)
5. Vérifier config/config.php — si les noms d'hôte/BDD ont changé, éditer en conséquence.
6. Reconstruire le cache et désactiver la maintenance :

   sudo -u www-data php occ maintenance:repair
   sudo -u www-data php occ maintenance:mode --off

7. Tester une connexion utilisateur, un download, un upload.

Scénarios concrets

Scénario 1 — Un utilisateur a supprimé un fichier hier

Il regarde Fichiers supprimés. S'il ne trouve pas : ticket Datacampus en précisant chemin + date.

Scénario 2 — Une app communauté a cassé l'instance après update

Si vous avez fait un backup applicatif avant l'update : restauration du code + base sur le snapshot d'hier, datadir conservé (pas d'écriture corrompue, juste du code planté). Si pas de backup applicatif : ticket pour rollback du snapshot VM.

Scénario 3 — Migration vers une nouvelle instance

Nouvelle instance propre, même version Nextcloud. Procédure :

1. Backup applicatif source (mode maintenance).
2. Transfert tar + dump + datadir vers la cible.
3. Restauration sur la cible (arborescence + data + base).
4. Éditer config/config.php : overwrite.cli.url, trusted_domains, dbhost si BDD externe.
5. occ maintenance:repair, occ db:add-missing-indices, occ upgrade si version mineure change.

Scénario 4 — Tester une restauration

Un backup non testé est un backup hypothétique. Une fois par trimestre : montez une VM de test, restaurez, connectez-vous, vérifiez. C'est ce qui distingue une politique de backup d'un fantasme de backup.