Configurar copias de seguridad automáticas para Discourse

[Discourse]

Esta guía explica cómo configurar las copias de seguridad automáticas para Discourse, incluidas las opciones de almacenamiento en servidores locales y almacenamiento compatible con S3.

Aprende a configurar las copias de seguridad automáticas para tu plataforma Discourse.

Esta guía cubre la configuración de copias de seguridad automáticas, su almacenamiento en servidores locales o almacenamiento compatible con S3, y la gestión de opciones de retención de almacenamiento como Amazon Glacier.

Configuración de copias de seguridad automáticas

1. Navega a la configuración de /admin.
2. Selecciona la sección Backup (Copia de seguridad).
3. Establece backup_frequency al intervalo deseado en días. El valor predeterminado es 7 (semanal). Establécelo en 1 para copias de seguridad diarias, o 0 para desactivar las copias de seguridad automáticas. El máximo es 30.

backup_frequency100%75%50%

Configuración adicional de copias de seguridad

• backup_time_of_day — la hora del día (UTC) en que se ejecutan las copias de seguridad. Predeterminado: 3:30.
• backup_with_uploads — incluye las cargas (uploads) en las copias de seguridad programadas. Predeterminado: habilitado. Deshabilitar esto solo hará una copia de seguridad de la base de datos.
• maximum_backups — el número máximo de copias de seguridad a conservar. Las copias de seguridad más antiguas se eliminan automáticamente. Predeterminado: 5.
• remove_older_backups — elimina las copias de seguridad más antiguas que el número de días especificado. Deja en blanco para deshabilitar.

Almacenar copias de seguridad en el servidor local

Por defecto, las copias de seguridad se almacenan en tu servidor local. Para instancias autohospedadas, accédelas en /var/discourse/shared/standalone/backups/default.

Almacenar copias de seguridad en almacenamiento compatible con S3

Usando el panel de administración

1. Crea un bucket S3.
2. Establece s3_backup_bucket en el panel de administración.

• Sigue los pasos en configurar las cargas (uploads) a S3.

3. Configura s3_access_key_id, s3_secret_access_key y s3_region.
4. Establece backup_location a “S3”.

ADVERTENCIA

Almacenar copias de seguridad y cargas (uploads) regulares en el mismo bucket y carpeta ya no es compatible y no funcionará.

La ruta s3_backup_bucket debe usarse solo para copias de seguridad. Si necesitas usar un bucket que contenga otros archivos, asegúrate de proporcionar un prefijo al configurar la opción s3_backup_bucket (ejemplo: my-awesome-bucket/backups) y asegúrate de que los archivos con ese prefijo sean privados.

A partir de ahora, todas las copias de seguridad se subirán a S3 y no se almacenarán localmente. El almacenamiento local solo se utilizará para archivos temporales durante las copias de seguridad y restauraciones.

Ve a la pestaña Backups en el panel de administración para explorar las copias de seguridad; puedes descargarlas en cualquier momento para realizar una copia de seguridad manual fuera del sitio.

Usando variables de entorno en app.yml

También puedes configurar las copias de seguridad de S3 utilizando variables de entorno en app.yml. Para más información, consulta Configurar un proveedor de almacenamiento de objetos compatible con S3 para las cargas (uploads)

Ten en cuenta que el artículo anterior cubre la configuración de S3 en app.yml tanto para copias de seguridad como para cargas de archivos/imágenes. Si solo deseas utilizar S3 para copias de seguridad (y no para cargas de archivos/imágenes), puedes omitir los siguientes parámetros de tu configuración de app.yml:

• DISCOURSE_USE_S3
• DISCOURSE_S3_CDN_URL
• DISCOURSE_S3_BUCKET

Tampoco necesitas configurar el paso after_assets_precompile en este caso, ni configurar una CDN.

Asegúrate de incluir todos los demás parámetros que son necesarios para tu proveedor de almacenamiento, como se menciona en el artículo. Aquí hay un ejemplo de configuración que solo activa S3 para copias de seguridad (para Scaleway S3):

DISCOURSE_S3_REGION: nl-ams
DISCOURSE_S3_ENDPOINT: https://s3.nl-ams.scw.cloud
DISCOURSE_S3_ACCESS_KEY_ID: my_access_key
DISCOURSE_S3_SECRET_ACCESS_KEY: my_secret_access_key
DISCOURSE_S3_BACKUP_BUCKET: my_bucket/my_folder
DISCOURSE_BACKUP_LOCATION: s3

Archivado a almacenamiento con menor coste

Ten en cuenta que en AWS S3, también puedes habilitar una regla del ciclo de vida para mover automáticamente a un bucket Glacier para mantener bajos los costes de tus copias de seguridad de S3. Otros proveedores de almacenamiento a menudo tienen una oferta similar.

[olivermark83 (Oliver Mark)]

You are able to Archive Backups from your S3 Bucket to Glacier.
It is cheaper, but an Restore attemps more Time.

This Site will Help you to reduce Backup costs.:

Archiving Amazon S3 Data to Amazon Glacier | Amazon Web Services

[Frez (FOSS dev/hacker)]

@codinghorror

Note that you can also enable an automatic move to Glacier bucket lifecycle rule to keep your S3 backup costs low.

Setting this up can be rather confusing. Here’s a simple guide to help you out.

• Log into your Discourse admin panel
• Configure daily backups
• Set maximum backups to 7
• Log into your Amazon Web Services account
• Go in the S3 Dashboard
• Open the bucket containing the backups
• Click on the properties tab
• Activate versioning
• Open the Lifecycle menu
• Add a rule for the whole bucket
• Set current version to expire after 15 days
• Set previous version to
• Archive to Glacier after 1 days
• expire after 91 days
• Save and logout

How it works

Versioning will keep backups automaticly deleted by Discourse. One day after beeing deleted it will be moved to the Glacier storage. After 91 days it will be delete from the Glacier storage.

Warning

Amazon charge you for item stored in Glacier for 90 days even if you delete them before. Make sure your Glacier Lyfecicle keep your file at least 90 days.

[MarcP]

I may have missed this, but how to I make sure a bucket for backups is private the proper way? Setting up file and image uploads to S3 doesn’t seem to be described here.

[Alex_P]

@Frez

Set current version to expire after 15 days

Looks like there is no such option anymore.

UPD: ah, now it’s split into 2 steps of this wizard.

So I guess it should be like this:

[jorymorrison]

¿Funciona correctamente la funcionalidad de copia de seguridad de S3 sin una clave de acceso y un secreto de IAM si se utilizan roles de AWS asignados a la instancia y se ha habilitado s3 use iam profile en el menú de settings?

Edición: ¡La respuesta es SÍ! Solo asegúrate de que la región esté configurada correctamente.

[nathank (Nathan Kershaw)]

@misterjtc

Estoy un poco confundido sobre cómo usar esta guía para configurar las copias de seguridad también.

Hice lo que pensé que tenía sentido, pero me he perdido un poco por el camino y ahora estoy recibiendo el mensaje «Error al acceder al almacenamiento de copias de seguridad: Acceso denegado».

Yo también tuve este problema, el cual se resolvió agregando unas líneas al documento de política:

"Resource": [
        "arn:aws:s3:::your-uploads-bucket",
        "arn:aws:s3:::your-uploads-bucket/*",
        "arn:aws:s3:::your-backups-bucket",
        "arn:aws:s3:::your-backups-bucket/*"
      ]

¿Debería esto agregarse al OP (que no es un wiki)? ¿O quizás en el OP de Set up file and image uploads to S3?

[pfaffman (Jay Pfaffman)]

@codinghorror

¿Así que te gustaría hacer copias de seguridad automáticas de todos tus datos de Discourse todos los días?

¿Hay alguna buena razón para que las copias de seguridad diarias no sean la configuración predeterminada?

Correcciones necesarias para el OP

Agregar algo sobre mover las copias de seguridad de S3 a Glacier.
Eliminar el contenido de S3 y enlazar a Configure an S3 compatible object storage provider for uploads

[codinghorror (Jeff Atwood)]

@pfaffman

¿Hay alguna buena razón para que las copias de seguridad diarias no sean la opción predeterminada?

Sería excesivo y costoso. ¿La misma razón por la que no recomendamos cambiar el aceite de tu coche cada 500 millas?

[pfaffman (Jay Pfaffman)]

@codinghorror

Sería excesivo y costoso.

¿Haces copias de seguridad de tus servidores una vez a la semana?

Creo que tu analogía del cambio de aceite cada 500 millas sería una buena respuesta para “¿por qué no mantener 30 copias de seguridad?”, pero no me parece que tenga sentido aquí.

¿No crees que, si vas a tener 5 copias de seguridad, la mayoría de la gente preferiría que se hicieran cada día, de modo que, si tienen que restaurar una copia, no pierdan más de un día? La única vez que recuerdo que una copia de seguridad antigua fuera útil fue cuando las imágenes desaparecieron de tombstone.

Si tienen tan poco espacio en disco que no pueden almacenar 5 copias de seguridad, parecería mejor enterarse de ello en 5 días, cuando todavía recuerdan lo que hicieron, en lugar de esperar de 4 a 5 semanas.

[codinghorror (Jeff Atwood)]

@pfaffman

¿Haces copias de seguridad de tus servidores una vez por semana?

Sí, eso es correcto, para mis servidores autohospedados.

Si prefieres configuraciones diferentes, siéntete libre de editarlas desde los valores predeterminados. ¿Qué te impide hacerlo?

[pfaffman (Jay Pfaffman)]

@codinghorror

Sí, eso es correcto, para mis servidores autohospedados.

¡Vaya, pues!

@codinghorror

¿Qué te impide hacerlo?

Estoy limpiando temas como este. ¡Si los valores predeterminados hubieran cambiado, no sería necesario!

Estoy convencido de que los valores predeterminados no cambiarán, así que seguiré adelante. :wink

[codinghorror (Jeff Atwood)]

Una vez a la semana es un buen punto de partida y una opción predeterminada sólida.

[Discoursecurious]

@nathank

@misterjtc

Estoy un poco confundido sobre cómo usar esta guía para configurar las copias de seguridad también.

Hice lo que pensé que tenía sentido, pero me he perdido un poco por el camino y ahora estoy obteniendo «Failed to access backup storage: Access Denied».

Yo también tuve este problema, el cual se resolvió agregando un par de líneas al documento de política:

"Resource": [
        "arn:aws:s3:::your-uploads-bucket",
        "arn:aws:s3:::your-uploads-bucket/*",
        "arn:aws:s3:::your-backups-bucket",
        "arn:aws:s3:::your-backups-bucket/*"
      ]

¿Debería esto agregarse al OP (que no es un wiki)? ¿O quizás en el OP de Configuración de cargas de archivos e imágenes a S3?

¡Yo tuve exactamente el mismo problema!

¡Sugiero agregar una nota al respecto en la publicación inicial también!"}

[jessicah (Jessica Hamilton)]

Sería genial si esto pudiera usarse para subir a un proveedor compatible con S3 diferente, como ejecutar MinIO.

[pfaffman (Jay Pfaffman)]

Si deseas usar MinIO, consulta Uso de almacenamiento de objetos para cargas (S3 y clones). Si necesitas servicios distintos para copias de seguridad y activos, no tendrás suerte (aunque existen formas de configurar desencadenadores para copiar datos de un bucket a otro).

[jessicah (Jessica Hamilton)]

No, solo quiero que se usen para copias de seguridad, para que se envíen automáticamente a otra máquina de mi red.

[pfaffman (Jay Pfaffman)]

Entonces, la guía que enlací es lo que estás buscando.

[Tris20 (Tristan)]

¿Es posible tener una frecuencia mayor que una vez al día? Preferiría no hacer suposiciones y establecer la frecuencia de copia de seguridad como un número de punto flotante.

[pfaffman (Jay Pfaffman)]

Si deseas copias de seguridad más frecuentes, tendrás que realizarlas externamente.