Estaba migrando nuestra instancia de Discourse de un servidor a otro, y me encontré con un problema interesante…
Usamos S3 para almacenar cargas del foro. Las habilitamos hace varios años, por lo que no es algo que introdujimos en esta migración.
Después de solucionar un par de problemas más, pude importar la copia de seguridad. Pero falló en un paso relacionado con S3 con lo siguiente:
Actualizando las URLs en la base de datos...
Eliminando imágenes optimizadas antiguas...
Marcando todas las publicaciones que contienen lightboxes para volver a procesar...
72038 publicaciones fueron marcadas para volver a procesar
EXCEPCIÓN: 257 publicaciones no se remapean a la nueva URL de carga de S3. La migración de S3 falló para la base de datos 'default'.
Después de investigar un poco, pude rastrear el problema hasta esta línea:
Luego, fui a la consola de rails y pude replicar las consultas con lo siguiente:
Luego, fui a esas publicaciones en particular, y eran parte de los Informes de Rendimiento (la captura de pantalla es de después de ejecutar un script de buscar y reemplazar):
Aparentemente, esa verificación recupera cualquier publicación que contenga /uploads/default/original en el campo cooked, a pesar de que podría no ser un activo legítimo. En este caso, /uploads/default/original se usó como “texto plano”, por lo que no se perdió durante el trabajo de migración.
Pude restaurarlo completamente simplemente reemplazando el texto en esas publicaciones para que no coincidiera con el filtro. No fue un problema para mí, pero lo menciono en caso de que alguien se enfrente al mismo problema, ya que tal vez valga la pena solucionarlo en Discourse.
Estoy bastante seguro de que me encontré con esto también al intentar restaurar una copia de seguridad y creé la copia de seguridad con “incluir cargas” DESACTIVADO. ¿Hay algo más que me esté perdiendo con la restauración solo de la base de datos?
Soy nuevo en Discourse, así que intentaré averiguar cómo solucionarlo, pero esto parece ser una prioridad mayor si la copia de seguridad/restauración no funciona correctamente para los usuarios que tienen buckets S3 como almacenamiento de cargas.
Aquí están mis archivos de registro del intento de restauración.
Actualización sobre mi situación específica… Todavía tenía archivos en mi /var/discourse/shared/standalone/uploads aunque me había cambiado a S3 para el almacenamiento. Una vez que eliminé el directorio ‘default’ en ese directorio de uploads, volví a crear una copia de seguridad y se creó con éxito una que solo contenía la base de datos (…sql.gz).
Por alguna razón (en mi caso) si hay archivos en ese directorio, ignora la configuración para NO incluir las subidas en la copia de seguridad y las crea de todos modos.
Hazme saber si se necesita más información o aclaración para mi situación. Parece que es quizás un poco diferente a la situación del OP.
De todos modos, pude solucionar el problema y ahora puedo restaurar con éxito.
