Si necesitas ayuda para llegar a la causa raíz de problemas como este, por favor házmelo saber. Estoy encantado de ayudar.
Así que intenté restaurar mi copia de seguridad de 2.2 GB y obtuve esto: la restauración falló.
EXCEPCIÓN: 44 publicaciones no se han vuelto a mapear a la nueva URL de carga en S3. La migración a S3 falló para la base de datos ‘default’.
Estoy en la versión 2.6b6, que es bastante reciente. El sitio es bastante antiguo, de 2016.
De vez en cuando nos encontramos con copias de seguridad en las que la remapeo automático y la migración a S3 fallan por varias razones.
Este es un tema antiguo, ¿alguna recomendación para la acción correctiva? Tener una copia de seguridad que no puedo usar realmente para restaurar me pone un poco nervioso.
Edición: Acabo de darme cuenta de que puede que esté en el hilo incorrecto, ya que parece ser el mismo problema.
Lo intenté de nuevo y sigo fallando en la restauración con el error de que 44 publicaciones no se han vuelto a mapear.
Desactivar temporalmente las cargas a S3 antes de la copia de seguridad (propuesto por @RGJ) no resuelve el problema, y actualmente no tengo un esquema de copia de seguridad funcional, lo cual es bastante grave.
¿Alguna sugerencia sobre qué probar?
Vale, este es el caso más extraño que he visto hasta ahora. Tropecé con esta publicación.
https://meta.discourse.org/t/using-object-storage-for-uploads-s3-clones/148916/160?u=ljpp
Después de perder horas en esto, definí DISCOURSE_CDN_URL solo por probar, una característica que mi sitio no utiliza. La restauración de la copia de seguridad se realizó con éxito.
¿Cuál es la importancia de este parámetro en este escenario? @Falco @pfaffman
EDIT:
Me retracto. Tras el éxito en la prueba, tomé una copia de seguridad fresca de producción y comencé nuevamente la migración a un nuevo servidor. Falló de nuevo, pero el mensaje de error cambió.
EXCEPCIÓN: rake posts:missing_uploads identificó 3 problemas. La migración a S3 falló para la base de datos ‘default’.
EDIT2:
Así que seguí investigando la base de datos y encontré estos 3 posts.
- 2 eran imágenes muy antiguas, que fueron publicadas inicialmente pero luego un moderador las reemplazó por versiones modificadas. Estas eran de 2016 y 2018.
- Pero la última era extraña. Era un post muy reciente, de hace solo unas semanas, publicado por mí mismo, y contenía un enlace https oneboxed a un servidor de desarrollo que ya no existe. Así que un enlace roto rompe el proceso de restauración.
Simplemente eliminé estos posts manualmente.
Ahora, de nuevo, una prueba muestra que una copia de seguridad podría tener éxito. Ya veremos.
@ljpp Parece que me encuentro en una situación similar con una restauración que falla con:
EXCEPCIÓN: 1 publicación no se ha vuelto a mapear a la nueva URL de carga en S3. La migración a S3 falló para la base de datos ‘default’.
¿Podrías detallar cómo encontraste y eliminaste las publicaciones problemáticas? ¿Qué comandos se utilizan?
Eliminó las publicaciones en cuestión.
Pero borraste tu instalación, así que no puedes hacer eso, ¿verdad?
Tengo este problema al restaurar mi base de datos. ¿Cómo encontraste las publicaciones ofensivas?
Creo que el código que realiza la comprobación está aquí:
Así que creo que esto:
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}%'")
Y para mayor seguridad
good = Upload.by_users.where("url LIKE '#{base_url}%'")
Avísame si esto te funciona y veré si puedo crear un tema.
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
Esta comprobación me dio 0 errores
¿Hiciste eso en el servidor original? ¿O necesitas hacerlo después de que la base de datos se haya restaurado antes de que realice esa comprobación, usando la opción --pause?
Lo hice en el servidor antiguo.
Al restaurar obtuve el mismo error
[2026-01-16 13:45:52] EXCEPTION: 3 publicaciones no se remapean a la nueva URL de carga de S3. La migración de S3 falló para la base de datos ‘default’.
[2026-01-16 13:45:52] /var/www/discourse/lib/file_store/to_s3_migration.rb:132:in `raise_or_log’
Bueno. Vaya. No estoy seguro de qué más decirte.
¿El good encontró tus subidas?
Probablemente usaría la opción --pause y detendría la restauración antes de que hiciera esa comprobación.
Haría lo que dijo Richard.
No estoy seguro de su situación exacta, pero es posible que simplemente desee desactivar las cargas a S3, realizar la copia de seguridad, restaurar y volver a activarlas. Esto me ha salvado muchas veces.
Entonces, tengo que desactivar estas opciones, ¿correcto?
Correcto.
- desmarcar “habilitar subidas a s3”
- copia de seguridad / descarga
- subida / restauración
- marcar “habilitar subidas a s3”
No hablo italiano si no es sobre comida… tal vez nos hagas un favor a todos y lo copies/pegues en Google Translate 
Lo siento
Habilitar subidas a S3
Almacena las subidas en el espacio de disco de Amazon S3. IMPORTANTE: requiere que se proporcionen credenciales de S3 válidas (tanto la clave de acceso como el secreto de clave de acceso).
No puedes habilitar las subidas a S3 porque ya están habilitadas a nivel global, y habilitar las subidas a S3 a nivel de sitio podría causar problemas críticos con las subidas.
Supongo que ya lo hiciste en app.yml.
¿Las (nuevas) subidas funcionan correctamente? Si es así, entonces no hay ningún problema.
En app.yml tengo configurado s3, correcto.
Entonces, ¿qué tengo que hacer para hacer una copia de seguridad y restaurar de forma segura sin comprobar las subidas?
Simplemente desmarcar “habilitar subidas s3” no funciona