Restauration d'une sauvegarde rend Nextcloud inutilisable [pb presque résolu]

Support apps
,
1

What app is this about, and its version: Nextcloud 31.0.8~ynh2
What YunoHost version are you running: 12.1.25
What type of hardware are you using: Virtual machine

Describe your issue

Hello,

Suite à la mise à jour de Nextcloud vers 31.0.9~ynh2 qui s’est terminée en erreur, le script a restauré la sauvegarde de Nextcloud.
L’historique sur la page d’administration montrait un état indéterminé, mais l’application apparaissaient bien dans la liste des applications, aussi bien du côté utilisateur qu’administrateur.
Mais lorsque je tentais de lancer Nextcloud, j’avais une “internal error”.
Les logs m’indiquaient des tables absentes.

Après plusieurs tests, vérifications et un reboot, je me suis rendu compte que dans la base MySQL de Nextcloud, il y avait encore des tables, notamment une table OC_filecache contenant un très grand nombre de lignes.

Je suis allé voir le contenu de cette base à partir du backup (avec Klogg d’ailleurs, pratique pour ouvrir les fichiers de plusieurs Go).

Dans la table Oc_filecache se trouvait 3 994 810 lignes avec des noms de chemins vers des contenus de partages réseaux.
Dans Nextcloud, j’utilise l’application “dossier externe” pour accéder aux partages de mon NAS à partir de Nextcloud et sur un des partages, y’a des vieux dossiers avec des chemins à rallonge.

J’ai donc supprimé les tables restantes, restauré la sauvegarde Nextcloud et ai surveillé les requêtes SQL avec phpMyAdmin.
Forcément, la restauration de la table OC_filecache prend du temps : elle a pris plus de 12 h.

Quand Nextcloud a été accessible à nouveau (le lendemain), j’ai supprimé ce partage des dossiers externes. Il s’est alors lancé dans la suppression d’entrée dans la table.

Delete from 'oc_filecache' where 'storage' in (39)

Ce qui a pris aussi beaucoup de temps, tellement de temps qu’il y a eu un time-out …

Et maintenant, il est dans une opération de roll-back (mais Nextcloud est quand même accessible)

Il restaure les entrées supprimées de la table… il reste 1 284 166 sur les 3 994 810, ce sera fini demain.

J’espère que le partage ne va pas réapparaitre dans les dossiers externes.
Alors, je n’aurais plus qu’à lancer la commande Nextcloud pour nettoyer cette table OC_filecache.

Conclusion :
Il faut surveiller les tailles des tables !!

Et

Ce n’est pas parce que l’application apparait côté utilisateur et côté admin qu’elle est prête et disponible. Il peut y avoir d’autres opérations en cours. Il faut être patient ou regarder ce qui se passe. (Surtout quand on n’utilise pas des SSD…)

Si vous avez d’autres conclusions philosophiques à me partager, je suis preneur.

Share relevant logs or error messages

sept. 19 18:54:31 mariadbd[908]: 2025-09-19 18:54:31 0 [Note] InnoDB: To roll back: 1 transactions, 1284415 rows
sept. 19 18:54:46 mariadbd[908]: 2025-09-19 18:54:46 0 [Note] InnoDB: To roll back: 1 transactions, 1284166 rows

2

Ce matin, il reste 501 492 entrées !

sept. 20 07:45:16 mariadbd[908]: 2025-09-20  7:45:16 0 [Note] InnoDB: To roll back: 1 transactions, 501492 rows
3

Le roll back est terminé. La table Oc_filecache fait à nouveau 4Go :
image

Mais le dossier externe n’a pas été restauré, il n’apparaît pas dans la page de configuration des dossiers externes. Et la table oc_external_mounts ne le liste pas.

su root
sudo -u nextcloud php8.3 --define apc.enable_cli=1 /var/www/nextcloud/occ files:cleanup

ne donne pas grand-chose.

su root
sudo -u nextcloud php8.3 --define apc.enable_cli=1 /var/www/nextcloud/occ files:scan --all

ne supprime pas non plus les entrées obsolètes de la table.

Normal, ce sont des commandes pour les fichiers stockés dans Nextcloud.

Ah! mais dans la doc : Using the occ command — Nextcloud latest Administration Manual latest documentation
Il y a des commandes pour les fichiers externes !!

su root
sudo -u nextcloud php8.3 --define apc.enable_cli=1 /var/www/nextcloud/occ files_external:list
sudo -u nextcloud php8.3 --define apc.enable_cli=1 /var/www/nextcloud/occ files_external:scan ID

Cette commande nécessite de préciser l’ID du dosser externe et mon dossier extérieur n’est pas listé par files_external:list

En cherchant avec le mot clé ‘cache’ dans la doc, je trouve une commande update-db qui “Update database mimetypes and update filecache”.

su root
sudo -u nextcloud php8.3 --define apc.enable_cli=1 /var/www/nextcloud/occ maintenance:mimetype:update-db

La commande mis à jour le type mime des fichiers de la table en cache mais ne l’a pas netttoyé des entrées obsolètes.

J’ai tenté :

su root
sudo -u nextcloud php8.3 --define apc.enable_cli=1 /var/www/nextcloud/occ maintenance:repair

Mais la commande n’a pas trouvé de réparation à faire

Alors pour finir :

  • Une sauvegarde de la table oc_filecache
  • Suppression des entrées orpheline avec une boucle sur 1000 entrées
DROP PROCEDURE IF EXISTS clean_oc_cachefile_table;

DELIMITER $$

CREATE PROCEDURE clean_oc_cachefile_table()

BEGIN   
    REPEAT
        DO SLEEP(1); ## Optional, to minimise contention
        DELETE FROM oc_filecache 
        WHERE storage IN (39)
        ORDER BY fileid 
        LIMIT 1000; ## 10000 also works, this is more conservative      
    UNTIL ROW_COUNT() = 0 END REPEAT;
END$$

DELIMITER ;

CALL clean_oc_cachefile_table();

Forcement, la requête prend du temps …

Si Nextcloud ne fonctionne plus, je restaure la table et je laisse comme ca …

4

oOh, ça a fonctionné.

La table oc-filecache est redescendu à 700 000 entrées et (après optimisation de la table) à 400Mo !

image