Configure automatic backups for Discourse

Documentación Autoalojamiento
,
131

Copias de seguridad automáticas en Backblaze B2

así es como lo he configurado para un sitio hipotético alojado en example.com

  1. crea una cuenta en backblaze (por ahora, no es necesario introducir el pago para <10 GB, que es gratis)
  2. crea un bucket (backblaze > Almacenamiento en la nube B2)
    • nombre: $sitename-discourse-$random rellenado hasta 30 caracteres
      • en este ejemplo: example-discourse-g87he56ht8vg
      • discourse necesita que el nombre del bucket solo contenga letras minúsculas, números y guiones
      • sugiero mantenerlo en 30 caracteres o menos, ya que se muestra bien en la interfaz web de backblaze sin envolver
    • bucket privado
    • habilita el cifrado (SSE-B2)
    • habilita el bloqueo de objetos
  3. crea una clave de aplicación (backblaze > cuenta > claves de aplicación)
    • nombre de clave: example-discourse
    • nombre del bucket (Permitir acceso a Bucket(s)): example-discourse-g87he56ht8vg
    • capacidades: leer y escribir
    • deja en blanco namePrefix y validDurationSeconds
  4. configura los ajustes de B2 de discourse (discourse > administrador > ajustes)
    • backup_location: s3
    • s3_backup_bucket: example-discourse-g87he56ht8vg
    • s3_endpoint: esto se muestra en la página del bucket; asegúrate de anteponer https://
    • s3_access_key_id: (del paso anterior)
    • s3_secret_access_key: (del paso anterior)
      • ¡backblaze solo te muestra la clave una vez (al crearla)!
    • por cierto, también puedes configurar estas como variables de entorno en tu archivo yml del contenedor en su lugar. esto te permitiría restaurar con solo ese archivo y nada más:
env:
  ## Copias de seguridad de Backblaze B2
  # DISCOURSE_BACKUP_LOCATION: 's3' # descomenta para recuperar desde la línea de comandos
  DISCOURSE_S3_ENDPOINT: 'https://....backblazeb2.com'
  DISCOURSE_S3_BACKUP_BUCKET: 'example-discourse-g87he56ht8vg'
  DISCOURSE_S3_ACCESS_KEY_ID: '...'
  DISCOURSE_S3_SECRET_ACCESS_KEY: '...'
  # DISCOURSE_DISABLE_EMAILS: 'non-staff' # descomenta para deshabilitar correos electrónicos durante una restauración de prueba
  ## puedes restaurar sin más datos que este archivo yml del contenedor.
  ## descomenta DISCOURSE_BACKUP_LOCATION arriba, compila el contenedor (./launcher rebuild ...),
  ## y luego ejecuta esto dentro del contenedor (restaurará desde el bucket B2):
  ##   discourse enable_restore
  ##   discourse restore <example-com-...tar.gz> # elige el nombre del archivo de restauración navegando por la interfaz web de B2
  ## recuerda deshabilitar la restauración después
  1. configura la retención de copias de seguridad
    • discourse:
      • backup_frequency: 1 (copias de seguridad diarias en este ejemplo, pero podrías hacerlo semanal)
      • maximum_backups: ignora este ajuste, deja que backblaze se encargue :sunglasses:
      • s3_disable_cleanup: true (Evita la eliminación de copias de seguridad antiguas de S3 cuando hay más copias de seguridad que el máximo permitido)
    • backblaze (ve a la configuración de tu bucket):
      • Bloqueo de objetos (Política de retención predeterminada): 7 días
      • Ajustes del ciclo de vida (personalizado):
        • fileNamePrefix: default/example-com (opcional)
        • daysFromUploadingToHiding: 8 días
          • esto debe ser el bloqueo de objetos + 1
        • daysFromHidingToDeleting: 1 día
          para resumir la retención en este ejemplo:
  • discourse crea copias de seguridad cada 1 día
  • cada archivo de copia de seguridad es inmutable durante 7 días después de cargarlo en B2 (bloqueo de objetos). esto te protege contra accidentes, ransomware, etc.
  • 8 días después de la carga, el bloqueo de objetos de la copia de seguridad expira. como vuelve a ser mutable, una regla del ciclo de vida puede ocultar el archivo de copia de seguridad
  • la siguiente parte de la regla del ciclo de vida elimina cualquier archivo 1 día después de que se oculte

así obtienes copias de seguridad diarias. el tiempo de retención es de una semana durante la cual las copias de seguridad no se pueden eliminar sin importar qué. luego, las copias de seguridad se eliminan 2 días después. así que, en realidad, una copia de seguridad dura unos 9 días.

espero que eso ayude a alguien :slight_smile:

en segunda reflexión, quizás sea mejor dejar que discourse gestione la retención (maximum_backups). de esa manera, tus copias de seguridad no empezarán a caducar automáticamente si discourse está caído. no querrías que un reloj corriera sobre ellas mientras intentas recuperarte. si eligieras esa opción, podrías configurar maximum_backups=8 y s3_disable_cleanup=false en este ejemplo y no usar una política de ciclo de vida en B2. aún así usarías la política de bloqueo de objetos (7 días), sin embargo.

edición: de hecho, creo que todavía necesitas una política de ciclo de vida de B2 porque creo que los archivos solo se ‘ocultan’ y no se eliminan cuando un cliente S2 los elimina. estoy usando la política " Mantener solo la última versión del archivo ", que es equivalente a daysFromHidingToDeleting=1, daysFromUploadingToHiding=null.

supongo que piénsalo y decide qué enfoque es el adecuado para ti.

por cierto, me doy cuenta de que hay algunas idas y venidas en esta publicación. creo que es informativa tal como está, pero si alguien quiere, podría hacer otra publicación un poco más simple con mis recomendaciones reales.

6 Me gusta