If you need any help with drilling down to the root cause of issues like this, please let me know. I’m happy to help.
5 « J'aime »
So, tried to restore my 2.2GB backup and got this - the restore failed:
EXCEPTION: 44 posts are not remapped to new S3 upload URL. S3 migration failed for db ‘default’.
I am on the 2.6b6, so a fairly recent version. The site is fairly old, from 2016.
From time to time we run into backups were the automatic remapping and migration to S3 fails for various reasons.
This is an old topic, so any recommendation for corrective action? Having a backup I can’t actually use to restore makes me a little nervous.
Edit: I just realized I may be in the wrong thread, as this seems like the same issue
1 « J'aime »
Gave this another shot and I am still failing on the restore to the 44 posts are not remapped -error.
Temporary disabling of S3 uploads prior to the backup (proposed by @RGJ does not solve the issue, and currently I don’t have a working backup scheme, which is pretty damn serious.
Any suggestions on what to try?
Okay, this is the weirdest case I’ve seen so far. I stumpled upon this post.
https://meta.discourse.org/t/using-object-storage-for-uploads-s3-clones/148916/160?u=ljpp
After wasting hours on this already, I defined the DISCOURSE_CDN_URL just for kicks, a feature my site does not use. The backup was restored successfully.
What is the significance of this parameter, in this scenario? @Falco @pfaffman
EDIT:
I take that back. After success with the test, I took a fresh backup from production and once again started to migrate to a new server. It failed again, but the error message changed.
EXCEPTION: rake posts:missing_uploads identified 3 issues. S3 migration failed for db ‘default’.
EDIT2:
So I kept drilling the database and found these 3 posts.
- 2 were very old images, that were first published but then moderator replaced the images with a modified version. These were from 2016 and 2018.
- But the last 1 was odd. It was a very recent post just a couple of weeks ago by myself and it contained a oneboxed https:// link to a development server, that no longer exists. So a broken link breaks the restore process.
I simply deleted these posts manually.
Now, again, a test run shows that a backup might actually succeed. We’ll see.
2 « J'aime »
@ljpp I seem to be in a similar situation with a restore failing with
EXCEPTION: 1 posts are not remapped to new S3 upload URL. S3 migration failed for db ‘default’.
Can you elaborate on how you found and deleted the offending posts? What commands are used?
1 « J'aime »
He deleted the posts in question.
But you wiped your install so you can’t do that, right?
1 « J'aime »
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.
1 « J'aime »
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.
1 « J'aime »
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.
2 « J'aime »
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 »
3 « J'aime »
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.
1 « J'aime »
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.