Si vous avez besoin d’aide pour identifier la cause profonde de problèmes comme celui-ci, n’hésitez pas à me le faire savoir. Je suis ravi de vous aider.
J’ai donc essayé de restaurer ma sauvegarde de 2,2 Go et j’ai obtenu ce message : la restauration a échoué :
EXCEPTION : 44 publications ne sont pas réaffectées à la nouvelle URL de téléchargement S3. La migration S3 a échoué pour la base de données ‘default’.
Je suis sur la version 2.6b6, donc une version assez récente. Le site est assez ancien, datant de 2016.
De temps en temps, nous rencontrons des sauvegardes où la réaffectation automatique et la migration vers S3 échouent pour diverses raisons.
Ce sujet est ancien, donc toute recommandation pour une action corrective serait la bienvenue. Avoir une sauvegarde que je ne peux pas réellement utiliser pour restaurer me rend un peu nerveux.
Édition : Je viens de réaliser que je suis peut-être dans le mauvais fil, car cela semble être le même problème :
J’ai réessayé et je suis toujours bloqué sur l’erreur 44 posts are not remapped.
La désactivation temporaire des uploads S3 avant la sauvegarde (proposée par @RGJ) ne résout pas le problème, et actuellement, je n’ai pas de schéma de sauvegarde fonctionnel, ce qui est vraiment très grave.
Des suggestions sur ce que je pourrais essayer ?
Bon, c’est le cas le plus étrange que j’ai vu jusqu’à présent. Je suis tombé sur ce post.
https://meta.discourse.org/t/using-object-storage-for-uploads-s3-clones/148916/160?u=ljpp
Après avoir perdu des heures là-dessus, j’ai défini DISCOURSE_CDN_URL juste pour voir, une fonctionnalité que mon site n’utilise pas. La restauration de la sauvegarde s’est déroulée avec succès.
Quelle est l’importance de ce paramètre dans ce scénario ? @Falco @pfaffman
MODIFICATION :
Je me ravise. Après avoir réussi le test, j’ai pris une nouvelle sauvegarde de la production et j’ai recommencé la migration vers un nouveau serveur. Cela a échoué à nouveau, mais le message d’erreur a changé.
EXCEPTION : rake posts:missing_uploads a identifié 3 problèmes. La migration S3 a échoué pour la base de données « default ».
MODIFICATION 2 :
J’ai donc continué à explorer la base de données et j’ai trouvé ces 3 posts.
- 2 étaient de très vieilles images, initialement publiées mais ensuite remplacées par une version modifiée par un modérateur. Elles dataient de 2016 et 2018.
- Mais le dernier était étrange. C’était un post très récent, il y a seulement quelques semaines, de ma part, contenant un lien https oneboxed vers un serveur de développement qui n’existe plus. Ainsi, un lien brisé fait échouer le processus de restauration.
J’ai simplement supprimé ces posts manuellement.
Maintenant, à nouveau, un test indique que la sauvegarde pourrait finalement réussir. Nous verrons bien.
@ljpp Je semble être dans une situation similaire avec une restauration qui échoue avec
EXCEPTION : 1 message n’est pas mappé vers la nouvelle URL de téléchargement S3. La migration S3 a échoué pour la base de données ‘default’.
Pourriez-vous préciser comment vous avez trouvé et supprimé les messages en cause ? Quelles commandes ont été utilisées ?
Il a supprimé les publications concernées.
Mais tu as réinstallé ton système, donc tu ne peux pas faire ça, n’est-ce pas ?
J’ai ce problème lors de la restauration de ma base de données. Comment avez-vous trouvé les publications incriminées ?
Je pense que le code qui effectue la vérification se trouve ici :
Donc je pense ceci :
prefix = @migrate_to_multisite ? "uploads/#{@current_db}/original/" : "original/"
base_url = File.join(SiteSetting.Upload.s3_base_url, prefix)
bad = Upload.by_users.where("url NOT LIKE '#{base_url}%'")
Et pour être sûr
good = Upload.by_users.where("url LIKE '#{base_url}%'")
Faites-moi savoir si cela fonctionne pour vous et je verrai pour créer un sujet.
discourse(prod)> prefix = @migrate_to_multisite ? “uploads/#{RailsMultisite::ConnectionManagement.current_db}/original/” : “original/”
discourse(prod)> base_url = File.join(SiteSetting.Upload.s3_base_url, prefix)
discourse(prod)> bad_uploads = Upload.by_users.where(“url NOT LIKE ‘#{base_url}%’”)
discourse(prod)> bad_uploads.count
=> 0
Cette vérification m’a donné 0 erreur
L’avez-vous fait sur le serveur d’origine ? Ou devez-vous le faire après la restauration de la base de données avant qu’elle n’effectue cette vérification, en utilisant l’option --pause ?
Je l’ai fait sur l’ancien serveur.
En restaurant, j’ai obtenu la même erreur
\[2026-01-16 13:45:52\] EXCEPTION: 3 publications n’ont pas été remappées à la nouvelle URL de téléchargement S3. La migration S3 a échoué pour la base de données « default ».\n\[2026-01-16 13:45:52\] /var/www/discourse/lib/file_store/to_s3_migration.rb:132:in `raise_or_log’
Eh bien. Zut. Je ne sais pas quoi vous dire d’autre.
Est-ce que le good a trouvé vos téléchargements ?
Je me contenterais probablement d’utiliser l’option --pause et d’arrêter la restauration avant qu’elle n’effectue cette vérification.
Je ferais ce que Richard a dit.
Je ne suis pas sûr de votre situation exacte, mais vous pourriez simplement vouloir désactiver les téléchargements S3, effectuer la sauvegarde, la restauration, puis les réactiver. Cela m’a sauvé de nombreuses fois.
Donc, je dois désactiver ces options, c’est bien ça ?
Correct.
- décocher « activer les téléchargements s3 »
- sauvegarder / télécharger
- télécharger / restaurer
- cocher « activer les téléchargements s3 »
Je ne parle pas italien quand ce n’est pas à propos de nourriture… peut-être pouvez-vous nous rendre service à tous et le copier/coller dans Google Traduction 
Désolé
Activer les téléchargements S3
Stocke les téléchargements sur l’espace disque Amazon S3. IMPORTANT : nécessite la fourniture d’identifiants S3 valides (à la fois la clé d’accès et la clé d’accès secrète).
Vous ne pouvez pas activer les téléchargements S3 car ils sont déjà activés globalement, et l’activation des téléchargements S3 au niveau du site pourrait causer des problèmes critiques avec les téléchargements.
Je suppose que vous l’avez déjà fait dans app.yml alors.
Les (nouveaux) téléchargements fonctionnent-ils correctement ? Si oui, il n’y a pas de problème.
Dans app.yml, j’ai configuré S3, c’est correct.
Alors, que dois-je faire pour sauvegarder et restaurer en toute sécurité sans vérifier les téléversements ?
Le simple fait de décocher « activer les téléversements S3 » ne fonctionne pas.