🇨🇳 Как сделать резервную копию Discourse в S3 | Как сделать резервную копию Discourse в S3

Discourse и S3 — отличные партнёры. Если вы уже знакомы с S3, это значительно упростит вам задачу.

У многих виртуальных хостингов пространство и ресурсы ограничены.

Использование S3 для резервного копирования позволяет эффективнее использовать доступное место.

Вы можете настроить это, следуя приведённым ниже шагам:

Настройка частоты резервного копирования

Перейдите в раздел Admin > Backup и установите параметр backup_frequency равным 1. Этот параметр определяет частоту резервного копирования; по умолчанию он равен 7.
Значение 1 означает ежедневное резервное копирование.
Значение 7 означает резервное копирование раз в 7 дней.

Для обычных веб-сайтов, использующих S3 для хранения резервных копий, рекомендуется выполнять резервное копирование ежедневно.

Настройка имени бакета и пути для резервных копий

Этот бакет может быть приватным и не публичным. Обратите внимание: если вы также используете S3 для хранения изображений и вложений, то бакет для них при настройке должен быть выбран как public.

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

Также советуем указать дополнительный путь к директории, поскольку Discourse создаст в этой папке несколько необходимых подпапок.

Это поможет сделать структуру вашего хранилища более понятной и организованной.

Настройка параметров s3_access_key_id и s3_secret_access_key

Далее необходимо настроить параметры для хранения резервных копий: s3_access_key_id, s3_secret_access_key и s3_region. Эти три параметра крайне важны; регион нельзя выбрать неправильно. Если резервные копии не загружаются, в большинстве случаев проблема связана с правами доступа.

Подробную инструкцию по настройке см. в статье: Настройка загрузки файлов и изображений в S3 — sysadmin — Discourse Meta.

Обратите внимание: для вашего ключа доступа (Key ID) должны быть предоставлены соответствующие права, иначе загрузка не будет возможна.

Настройка резервного копирования через S3

Установите метод резервного копирования на использование хранилища S3.

В разделе выбора параметров измените локальное хранилище (Local) на хранилище S3.

Тестирование резервного копирования

После завершения всех настроек можно выполнить тестовое резервное копирование.

Нажмите кнопку «Backup» для запуска тестового копирования. В меню резервного копирования просто выберите «Backup».

В появившемся окне вас спросят, включать ли загруженные изображения и вложения.

Обычно рекомендуется выбрать «Да». После этого откроется окно журнала, где будет отображаться информация о процессе резервного копирования. Вы можете проверить, завершено ли копирование, по наличию записи «Finished» в логах.

Кроме того, важно зайти в свой аккаунт S3 и убедиться, что там появилась последняя резервная копия.

Проверьте время создания, размер и имя файла, чтобы убедиться в успешном завершении.

Настройка резервного копирования через S3 позволяет расширить возможности хранения Discourse, обеспечивая практически неограниченное пространство для резервных копий. Для администраторов сайтов автоматическое резервное копирование и загрузка — крайне полезные функции.

Кроме того, наличие нескольких версий резервных копий позволяет восстанавливать сайт на разных временных точках.

Поскольку файлы резервных копий отделены от Docker-контейнера, это значительно упрощает повседневное резервное копирование и существенно экономит место на диске.

Также мы рекомендуем хранить изображения и вложения на S3 — это даст значительные преимущества при миграции, восстановлении и резервном копировании.

Для получения дополнительной информации ознакомьтесь с оригинальной статьёй: iSharkFly - 飞鲨.

2 лайка

Хотелось бы уточнить: если резервное копирование и вложения смонтированы на разные S3-хранилища, будет ли при создании резервной копии также сохранено содержимое S3, где хранятся вложения? Если не выбрать опцию включения загруженных изображений и вложений, смогут ли вложения, хранящиеся в S3, корректно отображаться на форуме после восстановления резервной копии?

Я не изучал детально резервные копии для Discourse.

После проверки наших резервных копий я выяснил следующее:

Если ваши вложения хранятся в облачном хранилище AWS, то даже при выборе опции Включать вложения в резервную копию


вложения, загруженные в AWS, не будут включены в файл резервной копии.

В резервную копию попадут только те вложения, которые хранятся на вашем локальном компьютере, но отсутствуют в AWS.

Это видно по размеру резервной копии нашего сайта: если бы вложения были включены, размер не мог бы составлять всего около 80 МБ.


Это означает, что данная резервная копия содержит только базу данных и локальные вложения.

При открытии загруженного файла вы увидите только две папки: одна — dump, это файл дампа базы данных PostgreSQL.


Вторая папка — uploads, содержащая только те вложения, которые были загружены локально и не хранятся в AWS. Для нас эта папка очень мала и содержит всего несколько файлов.

Это связано с тем, что вскоре после запуска сообщества мы перенесли все вложения в AWS.


На изображении выше показано содержимое файла дампа PostgreSQL. Из него можно увидеть версию PostgreSQL, на которой работает контейнер базы данных Discourse.

Если вы захотите просмотреть базу данных локально, этот файл дампа можно напрямую импортировать в ваш локальный контейнер.

Восстановление через AWS

Если вы используете вложения AWS, но не используете CDN AWS, то в тексте будут указаны абсолютные пути к вашим файлам в AWS.

В файлах тем в формате Markdown это выглядит следующим образом:


Однако после публикации контента Discourse заменяет этот код на абсолютные адреса вашего CDN в HTML.


Таким образом, исходя из вышеизложенного, если при создании резервной копии не выбрано включение вложений, то при восстановлении содержимое вложений не пострадает.

Исключения

Однако вложения всё же могут пострадать, в основном из-за смены доменного имени.

Ранее у нас была смена домена: сами вложения сохранились, но ссылки в тексте перестали работать, и даже перестройка HTML не помогла восстановить связь.

В таком случае потребуется больше усилий, возможно, даже прямое изменение записей в базе данных.

Если вы не меняете доменное имя произвольно, эта проблема обычно не возникает.

Более подробное обсуждение доступно по ссылке: Discourse 备份和恢复中有关附件的问题 - Discourse - iSharkFly

Хочу顺便 задать ещё один вопрос: я не использовал Amazon S3, а выбрал R2 от Cloudflare. Резервное копирование в R2 прошло успешно, файлы видны в панели управления Cloudflare, но в административной панели Discourse они не отображаются. Подскажите, в чём может быть проблема?


Сделайте еще одну ручную резервную копию и просмотрите журнал резервного копирования.

Скорее всего, это связано с ошибкой в части API Discourse, отвечающей за проверку состояния после вызова R2 для резервного копирования.

Проверьте, полностью ли содержимое журнала выше.

Это только что сделанный скриншот, похоже, всё отображается нормально. Кроме того, в R2 я создал API с наивысшими правами доступа.

Запустил свой процесс резервного копирования, похоже, наши логи идентичны.

[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!

Теперь посмотрим, не в записях таблицы резервной копии базы данных ли проблема.

Вы тоже используете R2? У вас всё отображается корректно?

Я использую AWS.

Это должно быть довольно легко настроить.