Cómo hacer una copia de seguridad de Discourse en S3 | Discourse cómo respaldar en S3

Discourse y S3 son grandes amigos, si estás familiarizado con S3, te será de gran ayuda.

Muchos tienen espacio limitado en su hosting virtual y recursos limitados.

Usar S3 para copias de seguridad permite un mejor uso del espacio.

Puedes seguir los siguientes pasos para configurarlo:

Configurar la frecuencia de copia de seguridad

Ve a admin > backup, y configura backup_frequency a 1. Este parámetro indica la frecuencia de las copias de seguridad, por defecto es 7.
1 significa que se realiza una copia de seguridad cada día.
7 significa que se realiza una copia de seguridad cada 7 días.

Para un sitio web de acceso general, si usas S3 para almacenar copias de seguridad, es mejor hacer una copia de seguridad cada día.

Configurar el Bucket y la ruta de copia de seguridad.

Este Bucket puede ser privado y no público. Aquí es importante tener en cuenta que si también usas S3 para almacenar imágenes y archivos adjuntos, ese Bucket debe seleccionarse como público al configurarlo.

Para mayor comodidad, puedes crear otro bucket aquí. Intenta no mezclarlo con el almacenamiento de archivos adjuntos e imágenes.

Te recomendamos que configures un directorio adicional aquí, ya que Discourse creará varias carpetas necesarias dentro de esta carpeta.

Para que tu almacenamiento sea más claro y específico.

Configurar s3_access_key_id y s3_secret_access_key

A continuación, deberás configurar s3_access_key_id y s3_secret_access_key, así como s3_region para los datos de copia de seguridad que almacenes. Estos 3 parámetros son muy importantes, no selecciones la región incorrecta. Si tu copia de seguridad no se sube, la gran mayoría de las veces será un problema de permisos.

Para obtener instrucciones específicas de configuración, consulta: Configuración de subidas de archivos e imágenes a S3 - sysadmin - Discourse Meta

Es importante tener en cuenta que aquí debes otorgar suficientes permisos a tu key ID, de lo contrario, no podrás subir nada.

Configurar la copia de seguridad para almacenamiento S3

Configura el método de copia de seguridad para almacenamiento S3.

En la sección de selección de parámetros, debes cambiar Local a S3.

Probar la copia de seguridad

Una vez que todo esté configurado, puedes probar la copia de seguridad.

Haz clic en el botón de copia de seguridad para probarla. En el menú de copias de seguridad, simplemente haz clic en Backup.


En la interfaz que aparece, se te preguntará si deseas incluir las imágenes y archivos adjuntos subidos.

Generalmente, aquí se selecciona “Yes”. Luego, la interfaz te redirigirá a la interfaz de registro, donde se mostrará la información de la copia de seguridad a través de los registros. Puedes observar si el registro muestra “Finished” para confirmar que la copia de seguridad se ha completado.

Lo más importante es que puedes iniciar sesión en tu cuenta de S3 para confirmar que tienes una copia de seguridad reciente.


Debes prestar atención a la hora, el tamaño y el nombre del archivo para confirmar.


Al configurar copias de seguridad en S3, podemos expandir el espacio de almacenamiento de Discourse, obteniendo casi espacio de copia de seguridad y almacenamiento ilimitados. Para la operación del sitio web, la copia de seguridad automática y la carga son funciones muy prácticas.

Además, tendrás múltiples copias de seguridad almacenadas, lo que te facilitará la restauración a diferentes puntos de copia de seguridad al restaurar el sitio web.

Dado que has separado los archivos de copia de seguridad de Docker, esto es muy útil para tus copias de seguridad diarias. Puede reducir significativamente el uso del espacio de almacenamiento.

También recomendamos almacenar imágenes y archivos adjuntos en S3, lo que te brindará grandes ventajas para la migración y la restauración de copias de seguridad.

Consulta el artículo original en iSharkFly - 飞鲨 para obtener más información.

2 Me gusta

Me gustaría preguntar si al montar copias de seguridad y archivos adjuntos en diferentes S3, ¿se respaldará también el contenido del S3 de los archivos adjuntos? Si no se seleccionan las imágenes y archivos adjuntos subidos, ¿se seguirán mostrando normalmente en el foro cuando se restaure la copia de seguridad utilizando el contenido del S3 de los archivos adjuntos?

Nunca he revisado detenidamente el contenido de las copias de seguridad de Discourse.

Después de revisar nuestras copias de seguridad, me di cuenta de que:

Si tus archivos adjuntos utilizan el almacenamiento en la nube de AWS, incluso si seleccionas Incluir archivos adjuntos en la copia de seguridad al hacer la copia de seguridad,


los archivos adjuntos subidos a AWS tampoco se incluirán en tu archivo de copia de seguridad.

Los archivos adjuntos que quedan son los que están almacenados en tu ordenador local, pero no los que están en AWS.

Se puede ver por el tamaño de la copia de seguridad de nuestro sitio web que, si se incluyeran los archivos adjuntos, el tamaño de la copia de seguridad no sería de solo 80 MB.


Esto indica que la copia de seguridad solo contiene la base de datos y los archivos adjuntos locales.

Al abrir este archivo de descarga, verás que solo hay 2 carpetas: una es dump, que es el archivo de volcado de la base de datos PGSQL.


La otra es la carpeta de subida, que solo contiene los archivos adjuntos que subiste localmente y que no se almacenaron en AWS. Para nosotros, esta carpeta es muy pequeña, con pocos archivos.

Esto se debe a que subimos todos los archivos adjuntos a AWS poco después de que la comunidad comenzara a funcionar.


La imagen de arriba muestra el contenido del archivo de volcado de PGSQL, y puedes ver la versión de PGSQL con la que se ejecuta el contenedor de la base de datos de Discourse en el archivo de volcado.

Si deseas ver la base de datos localmente, este archivo de volcado se puede importar directamente a tu contenedor local.

Problema de recuperación de AWS

Si utilizas archivos adjuntos de AWS pero no utilizas la CDN de AWS, el contenido del cuerpo principal serán las rutas de archivo absolutas en tu AWS.

En el archivo MD del tema, se presenta de la siguiente manera:


Sin embargo, una vez que el contenido se publica, el código HTML real es reemplazado por Discourse con la dirección absoluta de tu CDN.


Por lo tanto, basándonos en la respuesta anterior, si no seleccionas la opción de hacer copia de seguridad de los archivos adjuntos al hacer la copia de seguridad, el contenido de los archivos adjuntos no se verá afectado al restaurar.

Excepciones

De hecho, los archivos adjuntos también se ven afectados, principalmente debido al cambio de dominio.

Tuvimos un cambio de dominio en el pasado, pero el contenido de los archivos adjuntos estaba intacto, solo que el cuerpo principal no podía enlazarlos, e incluso reconstruir el HTML no podía enlazarlos.

En este caso, puede ser un poco complicado y es posible que necesites modificarlo directamente en la base de datos.

Mientras no cambies de dominio arbitrariamente, esto generalmente no será un problema.

Para una discusión más detallada, visita: Discourse 备份和恢复中有关附件的问题 - Discourse - iSharkFly

Solo quería preguntar sobre otra cuestión. No estoy usando Amazon S3, sino R2 de Cloudflare, y ya he realizado copias de seguridad en R2 con éxito. Puedo ver los archivos en Cloudflare, pero no se muestran en la copia de seguridad del backend de Discourse. ¿Podría alguien decirme cuál es el problema?


Haz una copia de seguridad manual una vez más y revisa el registro de copias de seguridad.

Esto se debe probablemente a un error en la parte de la API de Discourse que comprueba el estado después de almacenar la copia de seguridad en R2.

Comprueba si el contenido del registro está completo.

Esta es la captura de pantalla que se acaba de generar, parece que todo se muestra normal, además, creé la API con el máximo permiso en R2.

Ejecuté mi proceso de copia de seguridad, y parece que nuestros registros son los mismos.

[2024-07-26 11:56:00] pg_dump: executing SEQUENCE SET category_custom_fields_id_seq
[2024-07-26 11:56:00] Finalizing backup...
[2024-07-26 11:56:00] Creating archive: isharkfly-2024-07-26-115540-v20240723030506.tar.gz
[2024-07-26 11:56:00] Making sure archive does not already exist...
[2024-07-26 11:56:00] Creating empty archive...
[2024-07-26 11:56:00] Archiving data dump...
[2024-07-26 11:56:00] Archiving uploads...
[2024-07-26 11:56:00] Skipping uploads stored on S3.
[2024-07-26 11:56:00] Removing tmp '/var/www/discourse/tmp/backups/default/2024-07-26-115540' directory...
[2024-07-26 11:56:00] Gzipping archive, this may take a while...
[2024-07-26 11:56:05] Uploading archive...
[2024-07-26 11:56:09] Executing the after_create_hook for the backup...
[2024-07-26 11:56:09] Deleting old backups...
[2024-07-26 11:56:10] Cleaning stuff up...
[2024-07-26 11:56:10] Removing archive from local storage...
[2024-07-26 11:56:10] Removing '.tar' leftovers...
[2024-07-26 11:56:10] Marking backup as finished...
[2024-07-26 11:56:10] Refreshing disk stats...
[2024-07-26 11:56:10] Notifying 'honeymoose' of the end of the backup...
[2024-07-26 11:56:18] Finished!

A continuación, veamos si el problema está en los registros de la tabla de copia de seguridad de la base de datos.

¿Tú también usas R2? ¿Se muestra correctamente?

Uso AWS.

Esto debería ser fácil de configurar.