Avatars perdus après restauration. Comment les récupérer ?

Soutien
41

Bonjour @ariznaf,

Avant de tirer cette conclusion, pourriez-vous s’il vous plaît vous rendre sur toutes vos installations, accéder au dossier partagé de chacune d’elles et exécuter la commande suivante pour chaque installation, puis me communiquer les résultats ?

# du -sh uploads

Par exemple, sur nos installations, j’ai fait ceci :

Installation originale :

# du -sh uploads
2.5G uploads

Installation uniquement Socket (avant la correction du problème) :

# du -sh uploads
444K uploads

Cela m’a donné l’indice nécessaire pour voir que je devais copier manuellement le dossier uploads ; et une fois le problème identifié, la solution est simple.

Si vous vérifiez tous vos différents dossiers uploads avec du -sh uploads dans tous les répertoires partagés, cela vous donnera un indice précieux sur ce qui se passe.

S’ils sont différents, alors vous saurez que certains uploads manquent et vous pourrez les corriger manuellement.

S’ils sont tous identiques (peu probable), alors le problème devient plus intéressant :slight_smile:

42

J’ai trouvé le problème (pas la solution).
Le problème ne réside pas dans la restauration elle-même, mais dans le changement du nom du serveur.

Laissez-moi expliquer comment j’ai effectué la restauration (au cas où il manquerait une étape).

J’ai téléchargé une copie fraîche de Discourse depuis GitHub.
J’ai lancé le processus docker-setup.
Avant de lancer l’application et de procéder à la restauration, j’ai édité app.yml pour configurer l’accès au socket.
Et j’ai changé le nom de l’hôte en b.domain.com (dans l’original, c’était a.domain.com).

J’ai configuré le reverse proxy nginx avec SSL pour diriger le trafic HTTPS sur le port 443 vers le socket Discourse.
Puis j’ai reconstruit (launcher rebuild app) et redémarré nginx (service nginx restart).
J’ai accédé à https://b.domain.com pour effectuer la première configuration de Discourse.
Je l’ai configuré pour restaurer depuis S3 et j’ai restauré la dernière sauvegarde faite depuis la base de données et les uploads (sans miniatures).
Après la restauration, vous êtes déconnecté.
J’ai édité app.yml pour copier le fichier app.yml de l’ancien site (afin d’obtenir la même configuration et les mêmes plugins).
J’ai changé le nom de l’hôte en b.domain.com dans app.yml.

À nouveau, une reconstruction et un redémarrage de nginx.

LE PROBLÈME persiste : les images de profil (miniatures) de tous ceux qui ont modifié leur profil sont remplacées par l’image de profil blanche par défaut.
Notre logo en haut à gauche a également disparu.

@Stephen, force_https était activé (comme sur le serveur d’origine, sans problème). J’ai essayé de l’activer et de le désactiver, sans effet. Je l’ai laissé activé, car nous souhaitons que notre site soit accessible via HTTPS (de toute façon, le trafic HTTP sur le port 80 est redirigé en permanence vers HTTPS sur le port 443 dans notre configuration nginx).

@riking, j’ai utilisé sidekiq et déclenché le job avatarmissing, qui semblait se terminer correctement en quelques millisecondes. Juste au cas où il s’agissait d’un processus long, j’ai attendu presque 24 heures pour voir si les images de profil étaient reconstruites.
Mais aujourd’hui, nous avons le même problème : aucune image d’avatar (pour les personnes qui ont téléchargé une image de profil) et aucune image de logo.

Après cela, j’ai essayé de voir si le problème venait du changement de nom, comme l’avait suggéré @Stephen.

J’ai rétabli le nom de l’hôte dans app.yml et nginx à a.domain.com (l’original) et j’ai reconstruit et redémarré nginx.
J’ai modifié mon fichier hosts local pour pointer a.domain.com vers l’adresse IP du nouveau serveur, et j’ai fait un ping pour vérifier qu’il accédait bien à la nouvelle IP.

ET VOILÀ : nous avons retrouvé nos avatars et notre profil.

Donc, le problème ne vient pas de la restauration elle-même, mais du fait que le chemin complet de l’URL est enregistré et qu’il tente d’accéder aux ressources depuis le mauvais emplacement.
C’est étrange de toute façon, car le serveur d’origine est toujours en ligne (il aurait dû trouver les images même depuis le mauvais emplacement, c’est-à-dire le serveur d’origine au lieu du nouveau).

Mais en tout cas, le problème ne vient pas du processus de restauration ni d’une nécessité de réuploader les images à cause d’une quelconque corruption.

Le problème vient du changement de nom du serveur.

Maintenant, la question est : comment déplacer un forum Discourse d’un domaine/nom d’hôte à un autre ?

43

J’ai essayé de modifier à nouveau le nom d’hôte en b.domain.com.

Aucun succès.

Il semble que lorsque j’utilise l’ancien nom, cela fonctionne (mais je soupçonne maintenant qu’il récupère des images et d’autres éléments depuis l’ancien serveur qui est toujours en ligne, car je reçois de nouveaux messages et notifications provenant de nouveaux messages sur l’ancien serveur, même si j’ai modifié l’adresse IP pour a.domain.com dans mon fichier hosts).

J’ai suivi les instructions de ce sujet pour changer le nom d’hôte :

J’avais pensé que faire remapper a.domain.com vers b.domain.com par Discourse résoudrait le problème.
Même après avoir exécuté la commande rake posts:rebake, le résultat est le même.

J’ai perdu les avatars et le logo, et les images insérées dans les messages sont également perdues.

Enfin, comme suggéré par @neounix, j’ai décompressé à nouveau tous les fichiers uploadés pour remplacer les destinations dans shared/standalone/uploads/, mais sans succès, les résultats sont identiques.

44

Y a-t-il vraiment des informations précieuses dans votre base de données ? Il serait peut-être plus simple de tout recommencer à zéro, sans se soucier des migrations de serveur.

45

Toutes les données et tous les messages depuis le début du forum, il y a plusieurs mois ?

Comme je l’ai déjà dit, j’ai pu déplacer le serveur vers un autre en l’arrêtant, en copiant toutes les données vers un nouveau serveur, puis en le redémarrant.

Mais le support m’a indiqué que la méthode correcte consiste à utiliser la sauvegarde standard et à restaurer la base de données.

J’essaie de le faire, mais à chaque fois, je rencontre un problème.
J’ai également besoin d’un serveur de test pour vérifier l’impact des plugins, des modifications ou des mises à jour avant de les appliquer en production.

Je ne peux pas attendre qu’un incident se produise sur le serveur pour vérifier si je peux le restaurer ou non.

Les tests de restauration jusqu’à présent se sont tous soldés par un problème, laissant le système dysfonctionnel, avec perte d’images ou d’autres éléments.

46

En suivant cette saga :

https://meta.discourse.org/t/postgresql-12-update/151236/193

J’ai essayé la méthode « sauvegarde et restauration sur une autre instance Discourse » et je me retrouve maintenant face à ce problème. J’ai essayé tous les trucs du métier (le job Sidekiq, le rebake…) : y a-t-il une « piste » sur ce qui pourrait causer cela ? Juste pour que je puisse essayer de trouver quelque chose.

(Une chose que je dois vous accorder : avec tout cela, je passe de « ouais, je comprends un peu ça » à un doctorat en PostgreSQL, un doctorat en Redis… :stuck_out_tongue: Il me reste juste à maîtriser Ruby et les environnements de développement locaux, et je pourrai peut-être être utile à la communauté :stuck_out_tongue: )

47

Tous les avatars ont-ils disparu ou seulement une partie ? Les avatars personnalisés sont essentiellement des Téléchargements. D’autres téléchargements fonctionnent-ils comme prévu ?

Accédez à la console Rails et vérifiez l’enregistrement de l’avatar non fonctionnel dans la base de données. Ont-ils les bonnes URL, taille de fichier, largeur, hauteur, extension ?

User.find_by_username('Overgrow').user_avatar
User.find_by_username('Overgrow').uploaded_avatar

Ils doivent également avoir leurs versions optimisées présentes. Vous pouvez le vérifier ainsi :

OptimizedImage.where(upload_id: upload_id).where(version: 2)
48

Tout d’abord, un grand merci pour votre aide @Overgrow.

Tous les avatars et emojis (et même les images du site, comme les en-têtes, etc.) étaient « présents » mais invisibles. Pour les éléments autres que les avatars, ils apparaissent comme brisés ; pour les avatars, c’est l’indicateur gris par défaut. Certaines personnes ont pu simplement en télécharger un nouveau et ceux-là sont visibles.

Lors de mes premières tentatives d’exécution de la commande, j’ai obtenu :

FATAL : le système de base de données est en mode récupération

Donc… il y a ça :eyes: (j’ai beaucoup de « déconnexions », donc je suppose que cela a un lien avec la base de données, peut-être ?)

Mais après avoir persévéré :

User.find_by_username(‘Overgrow’).user_avatar

=> #<UserAvatar:0x000055702722d200
 id: 4,
 user_id: 3,
 custom_upload_id: 20504,
 gravatar_upload_id: 12240,
 last_gravatar_download_attempt: Thu, 21 May 2020 10:16:55 UTC +00:00,
 created_at: Sat, 30 May 2019 16:33:16 UTC +00:00,
 updated_at: Thu, 21 May 2020 10:16:55 UTC +00:00>

(J’ai essayé d’en télécharger un nouveau aujourd’hui, mais cela ne fonctionne pas).

User.find_by_username(‘Overgrow’).uploaded_avatar

=> #<Upload:0x00005555cd911b58
 id: 20504,
 user_id: 3,
 original_filename: "16_2.png.jpg",
 filesize: 56220,
 width: 360,
 height: 360,
 url: "/uploads/default/original/3X/6/3/63347a46c0ca945f53613722a73c233484d642c8.jpeg",
 created_at: Thu, 15 Aug 2019 20:02:47 UTC +00:00,
 updated_at: Thu, 15 Aug 2019 20:02:47 UTC +00:00,
 sha1: "63347a46c0ca945f53613722a73c233484d642c8",
 origin: nil,
 retain_hours: nil,
 extension: "jpeg",
 thumbnail_width: 360,
 thumbnail_height: 360,
 etag: nil,
 secure: false,
 access_control_post_id: nil,
 original_sha1: nil>

OptimizedImage.where(upload_id: 20504).where(version: 2)

=> [#<OptimizedImage:0x000056366a01c1a0
  id: 95962,
  sha1: "5a32b5cc3e6f5c58d88a3c92a23076980a8ce840",
  extension: ".jpeg",
  width: 200,
  height: 200,
  upload_id: 20504,
  url: "/uploads/default/optimized/3X/6/3/63347a46c0ca945f53613722a73c233484d642c8_2_200x200.jpeg",
  filesize: 28916,
  etag: nil,
  version: 2>,
 #<OptimizedImage:0x000056366a0741e8
  id: 95942,
  sha1: "ee353c9e23511b471e1a59c1f71a2ded3e366b1e",
  extension: ".jpeg",
  width: 20,
  height: 20,
  upload_id: 20504,
  url: "/uploads/default/optimized/3X/6/3/63347a46c0ca945f53613722a73c233484d642c8_2_20x20.jpeg",
  filesize: 1270,
  etag: nil,
  version: 2>,
 #<OptimizedImage:0x000056366a074120
  id: 95943,
  sha1: "944fa9fc542a79a5c50394c75022bf84ace297e5",
  extension: ".jpeg",
  width: 30,
  height: 30,
  upload_id: 20504,
  url: "/uploads/default/optimized/3X/6/3/63347a46c0ca945f53613722a73c233484d642c8_2_30x30.jpeg",
  filesize: 1952,
  etag: nil,
  version: 2>,
 #<OptimizedImage:0x000056366a074058
  id: 95944,
  sha1: "983490e58bed58c971ffa44e440b02ce3ea72bba",
  extension: ".jpeg",
  width: 40,
  height: 40,
  upload_id: 20504,
  url: "/uploads/default/optimized/3X/6/3/63347a46c0ca945f53613722a73c233484d642c8_2_40x40.jpeg",
  filesize: 2695,
  etag: nil,
  version: 2>,
 #<OptimizedImage:0x000056366a07bf60

Donc apparemment les images sont bien là, mais elles ne s’affichent pas. Seule la silhouette grise de l’avatar par défaut apparaît.

49

Tout semble correct au niveau des enregistrements de la base de données. Vous pouvez passer à des niveaux supérieurs lors de l’investigation.

Que recevez-vous lorsque vous suivez manuellement les URL des téléchargements que vous avez listés ?

50

Si j’ajoute /uploads/default/optimized/3X/6/3/63347a46c0ca945f53613722a73c233484d642c8_2_200x200.jpeg (par exemple) après l’URL de mon Discourse, j’obtiens une erreur 404, fichier non trouvé.

Donc… ils n’existent pas ? (Je demande avec un peu d’espoir :P)

51

Vérifiez également certaines URLs de fichiers provenant de /uploads/default/original et pas seulement de /uploads/default/optimized.

404 … Cela signifie que vous devez vérifier votre dossier uploads dans /var/discourse/shared/standalone sur le système de fichiers et déterminer où se trouvent les anciens fichiers réels (s’ils existent). Une fois que vous les avez trouvés, essayez de comparer leur emplacement à celui des fichiers nouvellement téléchargés (ceux qui fonctionnent).

Vous pouvez également les restaurer manuellement à partir de la sauvegarde.

52

Merci pour l’explication.

Je viens d’y jeter un coup d’œil et de vérifier à nouveau : certains des chemins listés n’existent pas.

Ce qui est étrange, c’est que des personnes tentent d’en télécharger de nouveaux, et ces nouveaux fichiers ne fonctionnent pas non plus. Lorsque vous utilisez les commandes que vous m’avez données, vous pouvez voir un chemin qui n’existe pas non plus. Comment Discourse fait-il pour « mapper » cela ? Parce que ce que je ne parviens pas vraiment à comprendre, c’est que les fichiers manquent (même si la sauvegarde était censée les transférer), mais pourquoi les nouveaux téléchargements atterrissent-ils dans des chemins fantômes ?

53

Vérifiez le dossier tombstone à l’intérieur de votre dossier uploads : certains des fichiers manquants s’y trouvent-ils ?

54

Le seul dossier que je vois dans uploads est default… le dossier tombstone est-il réservé aux fichiers obsolètes ou quelque chose dans ce genre ?

Par ailleurs, une information supplémentaire : il s’avère que si un utilisateur tente de télécharger la même image qu’il possède déjà (même s’il modifie le nom du fichier, je suppose, d’après ce que je vois avec ces requêtes, que cela repose sur le hachage), l’image ne se chargera pas et apparaîtra vide. Une fois sauvegardé, vous verrez l’espace réservé gris.

Apparemment, si vous modifiez l’image d’une manière ou d’une autre (même simplement en l’enregistrant dans un format différent dans Photoshop), vous pouvez la retélécharger.

55

C’est un comportement normal. Le hachage du fichier de données est stocké dans la base de données pour éviter les images en double.

Que se passe-t-il lorsque vous téléversez une image via l’éditeur de composition ? L’envoi se termine-t-il ? L’image apparaît-elle dans le volet d’aperçu ?

56

Si j’écris un message et que j’y inclus une image, celle-ci s’affichera dans le panneau d’aperçu et le téléchargement se terminera, oui, c’est le comportement normal.

57

Alors à quel moment précis cette image cesse-t-elle de s’afficher ?

Vérifiez l’URL de l’image que vous voyez et localisez-la dans le système de fichiers.

Vérifiez l’URL des images qui ne fonctionnent pas (via les outils de développement web dans le navigateur). Quelle est la différence ?

Peut-être qu’elles pointent vers un domaine différent.

58

Dans le premier message, je parlais spécifiquement des avatars (via le profil de l’utilisateur), et le second concernait l’éditeur.

Ainsi, pour un message normal, si vous faites un glisser-déposer ou si vous appuyez sur le bouton « uploader une image », cela fonctionne parfaitement, comme d’habitude.

En résumé :

  • Les avatars ne s’affichent pas, seul le placeholder apparaît.
  • Les émojis personnalisés ne s’affichent pas non plus.
  • Les images du site (logo, etc.) ne s’affichaient pas non plus.
  • Si vous uploadez des images depuis le compositeur, cela fonctionne correctement.
  • Si vous essayez de re-uploader le même avatar que celui que vous aviez avant l’incident, cela ne fonctionne pas. Le comportement est le suivant : l’upload se fait, puis dans la zone où vous choisissez entre une lettre par défaut, Gravatar ou l’upload, un carré vide s’affiche. Lorsque vous confirmez votre choix et que la page se recharge, vous avez le placeholder gris.

De plus :

  • Aucun dossier Tombstone.
  • Les anciennes images se trouvent dans des répertoires (comme le montrent les requêtes que vous m’avez données) qui n’existent pas.

Laissez-moi vérifier la question du domaine. À titre d’information, lorsque je cherchais des infos, j’ai essayé :

  • Déclencher le job CreateMissingAvatars depuis Sidekiq → Pas de succès.
  • Rebake tous les posts (oui, c’est un peu tiré par les cheveux) → Pas de succès.
  • Basé sur ce thread, comme j’avais utilisé un autre domaine (en fait un sous-domaine) pour tester la restauration depuis une sauvegarde pendant que le site principal était hors ligne, je pensais que certaines URL pouvaient être incorrectes, donc j’ai exécuté ceci : discourse remap talk.foo.com talk.bar.com → Pas de succès.
59

@Iceman

Ceci est surtout à titre informatif, et peut-être même trop d’informations, mais cela pourrait vous aider, ne serait-ce que légèrement, à mieux comprendre certains des phénomènes intéressants que nous rencontrons en exécutant trois conteneurs simultanément (deux pour l’application web et un pour les données), ainsi que l’impact sur les avatars des utilisateurs.

Il est très intéressant (et, à mon avis, très cool) de voir comment le planificateur de tâches Redis / Sidekiq fonctionne lorsqu’ils s’exécutent en parallèle, mais qu’un seul est « actif du côté web de l’utilisateur » :

J’espère que vous trouverez cette brève discussion, illustrée par un exemple concret, intéressante. Elle pourrait vous apporter un peu de lumière sur le planificateur de tâches de Discourse, l’optimisation des images et les avatars, selon notre configuration :

Je suis un grand admirateur de la façon dont Discourse utilise Redis / Sidekiq pour planifier les tâches en arrière-plan ; je considère cela comme l’une des forces et des avantages clés de l’architecture logicielle de Discourse.

Note : Ces concepts s’appliquent également, de diverses manières subtiles, aux différentes étapes du processus de sauvegarde et de restauration, ainsi qu’à d’autres processus dépendants du temps. Il est donc judicieux de comprendre comment et pourquoi Sidekiq planifie les tâches en arrière-plan.

60

Merci pour l’info @neounix, c’est très utile pour mieux comprendre les « coulisses » de Discourse du point de vue de « j’apprends Rails pour pouvoir aider, mais bon sang, la courbe d’apprentissage est raide quand on essaie de corriger sa propre installation » :stuck_out_tongue:

Je me concentre actuellement sur Redis/Sidekiq pour essayer de comprendre pourquoi certains嵌ements ne fonctionnent pas, car je pense que cela peut être lié à « Bake », mais je ne peux pas l’affirmer avec certitude puisque je suis encore en train de progresser en matière de débogage (j’espère).

Concernant mon problème ici, grâce à @Overgrow, j’ai pu déterminer que :

  • En fait, le processus de sauvegarde a bien copié les fichiers dans la sauvegarde, mais n’a pas restauré les fichiers dans l’installation de Discourse. Selon l’état et/ou les correctifs de mes trois autres problèmes, je pourrais avoir besoin de restaurer une autre sauvegarde sur une autre installation et de tester à nouveau le processus de sauvegarde, mais cela pourrait être un problème pour tout le monde, je ne sais pas encore.

  • C’est pourquoi ce comportement étrange se produisait.

  • J’ai fini par ouvrir la sauvegarde et injecter les fichiers manquants dans l’installation. Tout a été récupéré sans avoir besoin de Rebake.

Cependant, les autres problèmes persistent (impossibilité de reconstruire le conteneur de données, pour lequel je suis totalement perdu, et deux problèmes qui me poussent à me concentrer sur Sidekiq et les événements, car ils pourraient être résolus ainsi : certains Oneboxes (YouTube, en particulier) ne fonctionnent pas et certaines notifications concernant des « fausses » modifications se produisent de manière récursive pour certains utilisateurs, même si aucune modification n’a eu lieu. Je pense donc que la nouvelle installation pourrait avoir des problèmes liés à ses événements, j’essaie de comprendre. :man_shrugging: