Restaurer une version de sauvegarde spécifique de Discourse

J’ai eu un petit forum de discussion pendant quelques années et cela fonctionne bien. J’avais configuré des sauvegardes automatiques, mais je n’avais pas mis à jour la version de Discourse depuis longtemps.

Le serveur est tombé en panne, mais j’ai une sauvegarde. La sauvegarde date de l’ancienne version de Discourse, il y a environ 2 ans. Lorsque j’essaie d’installer la dernière version et de restaurer à partir de la sauvegarde, cela ne fonctionne pas. Lorsque j’essaie d’installer l’ancienne version, ce n’est pas possible : le script d’installation récupère automatiquement les nouveaux commits et l’image Docker la plus récente. J’ai même trouvé ces lignes dans le script de lancement et les ai supprimées, mais un code interne dans l’image Docker vérifie et met également à jour Git vers la dernière version.

Que dois-je faire ? Comment puis-je exécuter l’ancienne version de Discourse ou restaurer l’ancienne sauvegarde sur une nouvelle version ?

Si vous souhaitez de l’aide, vous devrez être plus précis. Cela devrait fonctionner. Il y a de fortes chances que le problème ne fonctionne pas non plus si vous avez pu installer la même version de Discourse que celle que vous aviez à l’époque.

Quelle erreur avez-vous obtenue lorsque vous avez essayé de restaurer ?

Il n’y a pas d’erreurs critiques dans la sortie de ./launcher logs app, mais le forum ne fonctionne pas. Presque tous les boutons ne fonctionnent pas, il n’y a pas de sujets et le HTML semble étrange (la page de démarrage buggée se répète et peut être défilée sans limite).

Je ne suis pas un technicien professionnel, et j’espère que vous pourrez me dire quels journaux je peux ajouter à mon rapport et où je peux les trouver.

Quelqu’un sait où je peux trouver des journaux fiables ?

Y a-t-il des erreurs dans la route /logs de votre forum ?

Le problème est que je ne peux pas accéder à /logs - « cette page n’existe pas ou est privée ». Et je ne peux pas me connecter pour vérifier.

Essayez d’utiliser la connexion administrateur à l’adresse https://forum.example.com/u/admin-login[1].


  1. On apprend quelque chose de nouveau tous les jours ! ↩︎

Merci pour le lien, mais il ne fonctionnera pas. Il envoie un e-mail, mais je n’ai pas de serveur smtp et j’utilise ce plugin : Disable Email Verification for Discourse Plugin

Peut-être que des commandes console sur le serveur sont possibles pour vérifier ce qui s’est passé ?

Autant que je sache, ce plugin est cassé. Vous ne voudrez peut-être pas l’utiliser.

1 « J'aime »

Il n’y avait pas de solution différente pour permettre aux utilisateurs de créer des comptes sans confirmation par e-mail lorsque j’ai créé un serveur.

C’est peut-être cassé maintenant, mais j’essaie au moins de restaurer l’ancienne version du forum.

1 « J'aime »

Pour le moment, je ne peux accéder à aucune donnée du forum, même si j’ai une sauvegarde. Seul le logo et les tags du forum sont affichés, et tous les boutons sont inutilisables.

1 « J'aime »

Aïe, cela complique les choses. Pourriez-vous essayer ce qui est mentionné ici pour obtenir des journaux ?

Avez-vous essayé le mode sans échec ?

Et commentez le plugin défectueux, et peut-être vos autres plugins. Vous pouvez les réactiver une fois que quelque chose fonctionne.

Les journaux de production Rails ne contiennent pas d’erreurs critiques, product_errors.log est vide.

Journaux d'erreurs Unicorn OID inconnu 17246 : impossible de reconnaître le type de 'embeddings'. Il sera traité comme une chaîne. Échec du signalement de l'erreur : Connexion refusée - connect(2) pour 127.0.0.1:6379 (redis://localhost:6379) 2 EOFError subscribe failed, reconnecting in 1 second. Pile d'appels /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-client-0.25.2/lib/redis_client/ruby_connection.rb:103:in `rescue in read' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-client-0.25.2/lib/redis_client/ruby_connection.rb:94:in `read' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-client-0.25.2/lib/redis_client.rb:535:in `next_event' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-5.4.0/lib/redis/subscribe.rb:66:in `subscription' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-5.4.0/lib/redis/subscribe.rb:17:in `subscribe' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-5.4.0/lib/redis.rb:175:in `_subscription' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-5.4.0/lib/redis/commands/pubsub.rb:17:in `subscribe' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.4.1/lib/message_bus/backends/redis.rb:293:in `global_subscribe' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.4.1/lib/message_bus.rb:769:in `global_subscribe_thread' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.4.1/lib/message_bus.rb:740:in `block in new_subscriber_thread' Échec du signalement de l'erreur : Connexion refusée - connect(2) pour 127.0.0.1:6379 (redis://localhost:6379) 3 Erreur lors de la récupération du travail : Connexion refusée - connect(2) pour 127.0.0.1:6379 Échec du signalement de l'erreur : Connexion refusée - connect(2) pour 127.0.0.1:6379 (redis://localhost:6379) 3 Erreur lors de la récupération du travail : Connexion refusée - connect(2) pour 127.0.0.1:6379 Échec du signalement de l'erreur : Connexion refusée - connect(2) pour 127.0.0.1:6379 (redis://localhost:6379) 3 Erreur lors de la récupération du travail : Connexion refusée - connect(2) pour 127.0.0.1:6379 Échec du signalement de l'erreur : Connexion refusée - connect(2) pour 127.0.0.1:6379 (redis://localhost:6379) 3 Erreur lors de la récupération du travail : Connexion refusée - connect(2) pour 127.0.0.1:6379 Échec du signalement de l'erreur : Connexion refusée - connect(2) pour 127.0.0.1:6379 (redis://localhost:6379) 3 Erreur lors de la récupération du travail : Connexion refusée - connect(2) pour 127.0.0.1:6379 Échec du signalement de l'erreur : Connexion refusée - connect(2) pour 127.0.0.1:6379 (redis://localhost:6379) 3 Job exception: Connexion refusée - connect(2) pour 127.0.0.1:6379 sidekiq-exception Échec du signalement de l'erreur : Connexion refusée - connect(2) pour 127.0.0.1:6379 (redis://localhost:6379) 3 Job exception: Connexion refusée - connect(2) pour 127.0.0.1:6379 sidekiq-exception Échec du signalement de l'erreur : Connexion refusée - connect(2) pour 127.0.0.1:6379 (redis://localhost:6379) 3 Job exception: Connexion refusée - connect(2) pour 127.0.0.1:6379 sidekiq-exception Échec du signalement de l'erreur : Connexion refusée - connect(2) pour 127.0.0.1:6379 (redis://localhost:6379) 3 Job exception: Connexion refusée - connect(2) pour 127.0.0.1:6379 sidekiq-exception Échec du signalement de l'erreur : Connexion refusée - connect(2) pour 127.0.0.1:6379 (redis://localhost:6379) 3 Job exception: Connexion refusée - connect(2) pour 127.0.0.1:6379 sidekiq-exception Échec du signalement de l'erreur : Connexion refusée - connect(2) pour 127.0.0.1:6379 (redis://localhost:6379) 3 heartbeat: Connexion refusée - connect(2) pour 127.0.0.1:6379 Échec du signalement de l'erreur : Connexion refusée - connect(2) pour 127.0.0.1:6379 (redis://localhost:6379) 3 Job exception: Connexion refusée - connect(2) pour 127.0.0.1:6379 (redis://localhost:6379) sidekiq-exception Échec du signalement de l'erreur : Connexion refusée - connect(2) pour 127.0.0.1:6379 (redis://localhost:6379) 2 Connexion refusée - connect(2) pour 127.0.0.1:6379 (redis://localhost:6379) subscribe failed, reconnecting in 1 second. Pile d'appels /usr/local/lib/ruby/3.3.0/socket.rb:1219:in `__connect_nonblock' /usr/local/lib/ruby/3.3.0/socket.rb:1219:in `connect_nonblock' /usr/local/lib/ruby/3.3.0/socket.rb:60:in `connect_internal' /usr/local/lib/ruby/3.3.0/socket.rb:141:in `connect' /usr/local/lib/ruby/3.3.0/socket.rb:647:in `block in tcp' /usr/local/lib/ruby/3.3.0/socket.rb:231:in `each' /usr/local/lib/ruby/3.3.0/socket.rb:231:in `foreach' /usr/local/lib/ruby/3.3.0/socket.rb:637:in `tcp' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-client-0.25.2/lib/redis_client/ruby_connection.rb:120:in `connect' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-client-0.25.2/lib/redis_client/connection_mixin.rb:11:in `reconnect' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-client-0.25.2/lib/redis_client.rb:769:in `block in connect' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-client-0.25.2/lib/redis_client/middlewares.rb:12:in `connect' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-client-0.25.2/lib/redis_client.rb:768:in `connect' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-client-0.25.2/lib/redis_client.rb:759:in `raw_connection' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-client-0.25.2/lib/redis_client.rb:719:in `ensure_connected' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-client-0.25.2/lib/redis_client.rb:314:in `call_v' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-5.4.0/lib/redis/client.rb:90:in `call_v' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rack-mini-profiler-4.0.1/lib/mini_profiler/profiling_methods.rb:90:in `block in profile_method' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-5.4.0/lib/redis.rb:152:in `block in send_command' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-5.4.0/lib/redis.rb:151:in `synchronize' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-5.4.0/lib/redis.rb:151:in `send_command' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-5.4.0/lib/redis/commands/strings.rb:191:in `get' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.4.1/lib/message_bus/backends/redis.rb:366:in `process_global_backlog' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.4.1/lib/message_bus/backends/redis.rb:279:in `block in global_subscribe' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.4.1/lib/message_bus/backends/redis.rb:291:in `global_subscribe' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.4.1/lib/message_bus.rb:769:in `global_subscribe_thread' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.4.1/lib/message_bus.rb:740:in `block in new_subscriber_thread' OID inconnu 17246 : impossible de reconnaître le type de 'embeddings'. Il sera traité comme une chaîne.

Les journaux Sidekiq sont vides.

Aucun problème dans les journaux Nginx.

Je vois un problème de connexion redis dans les journaux Unicord, mais les journaux Redis eux-mêmes n’ont pas d’erreurs :

9706:C 28 Aug 2025 15:11:25.025 * Fork CoW pour RDB : courant 1 Mo, pic 1 Mo, moyen 0 Mo 881:M 28 Aug 2025 15:11:25.106 * Sauvegarde en arrière-plan terminée avec succès 881:M 28 Aug 2025 15:16:26.096 * 100 changements en 300 secondes. Sauvegarde... 881:M 28 Aug 2025 15:16:26.097 * Sauvegarde en arrière-plan démarrée par le processus 10037 10037:C 28 Aug 2025 15:16:26.109 * DB sauvegardée sur disque 10037:C 28 Aug 2025 15:16:26.109 * Fork CoW pour RDB : courant 1 Mo, pic 1 Mo, moyen 0 Mo 881:M 28 Aug 2025 15:16:26.198 * Sauvegarde en arrière-plan terminée avec succès 881:M 28 Aug 2025 15:21:27.004 * 100 changements en 300 secondes. Sauvegarde... 881:M 28 Aug 2025 15:21:27.004 * Sauvegarde en arrière-plan démarrée par le processus 10365 10365:C 28 Aug 2025 15:21:27.019 * DB sauvegardée sur disque 10365:C 28 Aug 2025 15:21:27.019 * Fork CoW pour RDB : courant 1 Mo, pic 1 Mo, moyen 0 Mo 881:M 28 Aug 2025 15:21:27.105 * Sauvegarde en arrière-plan terminée avec succès 881:M 28 Aug 2025 15:26:28.030 * 100 changements en 300 secondes. Sauvegarde... 881:M 28 Aug 2025 15:26:28.031 * Sauvegarde en arrière-plan démarrée par le processus 10703 10703:C 28 Aug 2025 15:26:28.050 * DB sauvegardée sur disque 10703:C 28 Aug 2025 15:26:28.051 * Fork CoW pour RDB : courant 1 Mo, pic 1 Mo, moyen 0 Mo 881:M 28 Aug 2025 15:26:28.132 * Sauvegarde en arrière-plan terminée avec succès 881:M 28 Aug 2025 15:31:29.094 * 100 changements en 300 secondes. Sauvegarde... 881:M 28 Aug 2025 15:31:29.095 * Sauvegarde en arrière-plan démarrée par le processus 11028 11028:C 28 Aug 2025 15:31:29.109 * DB sauvegardée sur disque 11028:C 28 Aug 2025 15:31:29.110 * Fork CoW pour RDB : courant 1 Mo, pic 1 Mo, moyen 0 Mo 881:M 28 Aug 2025 15:31:29.196 * Sauvegarde en arrière-plan terminée avec succès

Les journaux Postgresql n’ont pas d’erreurs.

Comment puis-je l’activer ?

Désolé. J’ai tapé « safe-mode » au lieu de « safe mode » et je n’ai pas remarqué que ce n’était pas un lien automatique.

Merci, cela a aidé et le forum fonctionne (pas correctement, mais je peux accéder aux sujets avec du contexte).

Cependant, le forum sans mode sans échec est inutilisable, et je ne me souviens pas exactement quels plugins j’ai installés. La liste des plugins devrait être dans app.yml, mais le serveur est mort et je n’ai qu’une sauvegarde, qui ne contient pas app.yml, à ma connaissance. Que dois-je faire pour restaurer le forum et supprimer les plugins défectueux ?

La restauration sans utiliser de fichier app.yml existant ne devrait installer aucun plugin, à l’exception de ceux qui sont inclus (qui sont tous officiels).

Cependant, les thèmes et les composants de thème sont inclus dans la sauvegarde, essayez donc de les désactiver.

Essayez d’utiliser le mode sans échec et désactivez uniquement les thèmes et les composants pour être sûr que vos problèmes sont causés par l’un d’entre eux.

2 « J'aime »

Merci, cela fonctionne vraiment sans thèmes, mais où puis-je trouver des thèmes ? Dans la sauvegarde, je ne vois que deux éléments : dump.sql.gz et le dossier uploads, qui ne contient que les médias et fichiers des utilisateurs.

Vous pouvez simplement accéder aux thèmes depuis l’interface d’administration. Vous pouvez d’abord tous les désactiver, puis les activer un par un (ou autre chose).

1 « J'aime »