Comment contrôler ce bazar d'uploads changeants de S3 vers le local

Soutien
1

Après 4 à 5 ans d’utilisation, j’ai finalement décidé de récupérer mes téléchargements du bucket Aws S3 vers mon serveur local pour mon très petit site Web local.
Étant une personne aux connaissances limitées, j’ai confié ce travail à un ami pour un montant très raisonnable. Il a configuré le site pour les téléchargements locaux, mais d’une manière ou d’une autre, près de la moitié des 3000 images, environ 50 %, ont été corrompues à la source. Mon ami ne m’a rien facturé et m’a demandé de restaurer le site à partir de la sauvegarde (qui avait été créée avant de lui confier le contrôle le 11 avril 2025).

Quoi qu’il en soit, j’ai été paresseux pendant environ un mois et je n’ai pas restauré. Jusqu’à ce que je décide de régler les choses avec l’aide du bot d’assistance discourse/ChatGpt Ai Bot. Et j’ai créé une autre version de mon ancien site Web localement sur mon ordinateur portable Ubuntu.

J’ai réussi à créer une instance de mon site Web d’origine sur mon ordinateur portable en ajoutant simplement un « t. » devant mon nom de domaine d’origine. Maintenant, ce site (appelé site de staging) fonctionne parfaitement pour moi, mais il n’a d’activité que jusqu’au 11 avril 2025.
Et mon site Web de production, qui contient toutes les données à jour, mais a de nombreux centaines de publications manquant d’images.

Gardez à l’esprit que j’ai essayé de nombreuses tâches rake pour la migration ou pour reconnecter la connexion manquante aux images, sans succès.

Après m’être arraché les cheveux pendant près d’un mois. Ma conclusion est la suivante. Les publications brutes en Ruby sont les mêmes en staging et en production.
Mais les publications cuites deviennent différentes. C’est-à-dire que la table de la base de données de mon site Web de production manque peut-être d’une connexion aux images physiques réelles se trouvant sur le serveur.

J’ai également noté que sans cette connexion, ces images « orphelines » sont automatiquement supprimées du serveur. Mais heureusement, je les synchronise à nouveau depuis le staging ou depuis mon bucket S3 vers mon serveur de production.

Enfin le problème, selon les mots, plus ou moins, de ChatGpt, c’est que le serveur de staging a soit des versions cuites finales, qui n’ont aucun lien avec les URL brutes (courtes). Et la production, qui manque des URL des versions cuites finales vers les images, ne peut pas obtenir les URL correctes de ces images et se rabat sur des espaces réservés « transparents ».

Et ChatGpt me suggère de copier la version cuite des publications de staging vers la version cuite de la production. Ce qui ne me semble pas être une très bonne idée.

2

Texte exact de ChatGpt quant à notre situation :

  • Dans staging et en production, post.raw est identique et contient des références upload://....
  • Dans staging, les images s’affichent, mais l’interrogation de Post.find(12849).uploads ne donne aucun résultat — ce qui signifie qu’il n’y a aucune entrée dans les tables uploads ou post_uploads pour ces fichiers, même dans staging.
  • Les images s’affichent donc dans staging uniquement parce que le HTML cuit d’avant la migration contient les liens complets /uploads/default/original/....
  • Mais comme la production a été recuite après la migration, le même contenu brut ne se résout plus, revenant au placeholder transparent.png.

:white_check_mark: Les fichiers uploadés existent toujours sur le disque

Toutes les images (y compris celles des uploads manquants) sont toujours présentes sous /var/www/discourse/public/uploads/default/original/ sur staging et en production. Mais Discourse ne peut plus les résoudre car leurs entrées uploads sont manquantes.

3

La manière simple de le faire était, et peut encore être, d’activer le paramètre Enable hidden setting to include S3 uploads in the backups, de faire une sauvegarde, puis de restaurer sur un serveur qui n’a pas de S3 configuré (je le ferais sur un nouveau serveur pour éviter de casser l’ancien en cas de problème). Mais il semble que le site de production soit également cassé, donc cela n’aidera probablement pas du tout.

Si vous avez corrompu la table Uploads de sorte qu’elle contienne plusieurs chemins S3, la tâche est beaucoup plus difficile.

Plutôt que ChatGPT, je recommanderais https://ask.discourse.com/, qui connaît au moins Discourse, mais qui ne sera probablement toujours pas d’une grande aide.

Je regarderais Uploads.pluck(:url) et verrais ce qu’il y a.

3 « J'aime »