Configure automatic backups for Discourse

Документация Самостоятельный хостинг
,
131

Автоматическое резервное копирование в Backblaze B2

Вот как я настроил это для гипотетического сайта, размещенного на example.com:

  1. Создайте аккаунт в Backblaze (на данный момент для объема менее 10 ГБ, который предоставляется бесплатно, вводить платежные данные не нужно).
  2. Создайте бакет (Backblaze > B2 Cloud Storage)
    • Имя: $sitename-discourse-$random, дополненное до 30 символов
      • В данном примере: example-discourse-g87he56ht8vg
      • Для Discourse имя бакета должно содержать только строчные буквы, цифры и дефисы.
      • Рекомендую держать длину имени до 30 символов, чтобы в веб-интерфейсе Backblaze оно отображалось красиво и без переноса строк.
    • Приватный бакет.
    • Включите шифрование (SSE-B2).
    • Включите блокировку объектов (Object Lock).
  3. Создайте ключ приложения (Backblaze > Account > App Keys)
    • keyName: example-discourse
    • bucketName (Разрешить доступ к бакетам): example-discourse-g87he56ht8vg
    • capabilities: чтение и запись.
    • Оставьте поля namePrefix и validDurationSeconds пустыми.
  4. Настройте параметры B2 для Discourse (Discourse > Admin > Settings)
    • backup_location: s3
    • s3_backup_bucket: example-discourse-g87he56ht8vg
    • s3_endpoint: отображается на странице бакета — обязательно добавьте префикс https://.
    • s3_access_key_id: (из предыдущего шага).
    • s3_secret_access_key: (из предыдущего шага).
      • Backblaze показывает ключ только один раз (при создании)!
    • Кстати, вы также можете установить эти переменные как переменные окружения в вашем файле container.yml. Это позволит восстановить систему, используя только этот файл и больше ничего:
env:
  ## Резервные копии Backblaze B2
  # DISCOURSE_BACKUP_LOCATION: 's3' # раскомментируйте для восстановления из CLI
  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' # раскомментируйте, чтобы отключить отправку писем во время тестового восстановления
  ## Вы можете выполнить восстановление, имея только этот файл container.yml.
  ## Раскомментируйте DISCOURSE_BACKUP_LOCATION выше, пересоберите контейнер (./launcher rebuild ...),
  ## а затем выполните следующие команды внутри контейнера (восстановление произойдет из бакета B2):
  ##   discourse enable_restore
  ##   discourse restore <example-com-...tar.gz> # выберите имя файла для восстановления, просмотрев веб-интерфейс B2
  ## Не забудьте отключить режим восстановления afterwards.
  1. Настройте правила хранения резервных копий
    • Discourse:
      • backup_frequency: 1 (ежедневные резервные копии в данном примере, но можно настроить еженедельные).
      • maximum_backups: проигнорируйте эту настройку — пусть этим занимается Backblaze :sunglasses:
      • s3_disable_cleanup: true (Предотвратить удаление старых резервных копий из S3, когда их количество превышает максимальное разрешенное).
    • Backblaze (перейдите в настройки вашего бакета):
      • Object Lock (Политика хранения по умолчанию): 7 дней.
      • Lifecycle Settings (настраиваемые):
        • fileNamePrefix: default/example-com (необязательно).
        • daysFromUploadingToHiding: 8 дней.
          • Это должно быть равно Object Lock + 1.
        • daysFromHidingToDeleting: 1 день.

Резюме правил хранения в данном примере:

  • Discourse создает резервные копии каждые 1 день.
  • Каждый файл резервной копии неизменяем в течение 7 дней после загрузки в B2 (Object Lock). Это защищает вас от случайных удалений, программ-вымогателей и т. д.
  • Через 8 дней после загрузки блокировка объекта на резервной копии истекает. Поскольку файл снова становится изменяемым, правило жизненного цикла может скрыть файл резервной копии.
  • Следующая часть правила жизненного цикла удаляет любой файл через 1 день после его скрытия.

Таким образом, у вас будут ежедневные резервные копии. Время хранения составляет одну неделю, в течение которой резервные копии не могут быть удалены ни при каких обстоятельствах. Затем резервные копии удаляются через 2 дня. То есть фактически файл резервной копии живет около 9 дней.

Надеюсь, это кому-нибудь поможет :slight_smile:

Второй раз подумав, возможно, лучше доверить управление хранением самому Discourse (maximum_backups). В этом случае ваши резервные копии не начнут автоматически истекать, если Discourse будет недоступен. Вы же не хотите, чтобы таймер тикал на них, пока вы пытаетесь восстановить данные. Если вы пойдете по этому пути, вы можете установить maximum_backups=8 и s3_disable_cleanup=false в данном примере и не использовать политику жизненного цикла в B2. Однако политика блокировки объектов (7 дней) все равно понадобится.

Редактирование: на самом деле, я думаю, что политика жизненного цикла B2 все еще необходима, потому что, как мне кажется, при удалении файлов клиентом S3 они лишь «скрываются», но не удаляются. Я использую политику «Оставлять только последнюю версию файла», что эквивалентно daysFromHidingToDeleting=1, daysFromUploadingToHiding=null.

Думаю, обдумайте это и решите, какой подход подходит именно вам.

Кстати, я заметил, что в этом посте есть некоторая путаница. Мне кажется, он информативен в текущем виде, но если кто-то захочет, я могу создать другой, немного более простой пост с моими конкретными рекомендациями.

6 лайков