Если вы размещаете Discourse самостоятельно, обязательно делайте резервные копии на сторонних серверах на случай катастрофических проблем с вашим сервером. Представьте, что ваш провайдер серверов внезапно обанкротился без предупреждения или вы случайно удалили /var/discourse, полностью стерев вашу установку.
Минимально необходимое
Убедитесь, что резервное копирование включено.
Рекомендуемые настройки сайта:
enable backups: включено (по умолчанию включено)backup frequency: Какой объем данных вы готовы потерять? (По умолчанию: 7 дней). @pfaffman рекомендует один деньbackup time of day: В какое время ваш форум должен быть доступен только для чтения во время создания резервной копии?backup with uploads: Включено, если только ваши загрузки не хранятся в другом месте или не резервируются иным способом. (По умолчанию: включено)maxiumum backups: Насколько вы параноидальны? Сколько места на диске у вас есть? (По умолчанию: 5)
Это позволит восстановить данные из последней резервной копии в случае повреждения базы данных, но не защитит вас, если ваш сервер Discourse перестанет существовать.
Удаленные резервные копии
Для восстановления вашего сайта на новом сервере вам как минимум понадобится резервная копия, создаваемая Discourse. Настройка нового сервера пройдет гораздо проще, если у вас есть контейнер(ы) в /var/discourse//containers.
Конкретный способ организации удаленных резервных копий выходит за рамки данного документа, но один из методов — использование инструмента вроде rsync для копирования данных на удаленный сервер. Существует множество руководств по этому вопросу; выберите то, которое вам подходит.
Файл(ы) /var/discourse/containers меняются редко, поэтому ручное резервное копирование только при внесении изменений не составит большого труда. Обычно они содержат настройки SMTP и плагины, которые относительно легко восстановить по памяти, но в экстренной ситуации этого делать не хочется. В таком случае вы сможете запустить систему заново с отсутствующими несколькими плагинами и неработающей почтой, а остальное донастроить, пока сайт работает с ограничениями.
Резервное копирование в S3
Самый удобный способ хранения удаленных резервных копий — загрузка их в S3, как описано по адресу Set up file and image uploads to S3. Если вы сделаете это и сохраните настройки S3 в месте, где сможете их найти (или в файле app.yml), вы сможете восстановить свой сайт непосредственно из S3 после настройки нового сервера.
Возможно внедрение настроек в файл app.yml. Если вы добавите что-то вроде следующего в раздел env файла app.yml, эти настройки исчезнут из веб-интерфейса, и вы сможете Restore a backup from the command line восстановить резервную копию из командной строки без необходимости создания учетной записи администратора и входа в систему.
DISCOURSE_S3_ACCESS_KEY_ID: 'key'
DISCOURSE_S3_SECRET_ACCESS_KEY: 'secret'
DISCOURSE_BACKUP_LOCATION: 's3'
DISCOURSE_ENABLE_S3_UPLOADS: true
DISCOURSE_S3_BACKUP_BUCKET: 'my-backup-bucket'
DISCOURSE_S3_REGION: 'us-west-1'
Если у вас также есть загрузки в S3 и вы доверяете стабильности вашего провайдера S3, вы можете настроить Discourse на резервное копирование только базы данных (см. настройку выше). Это избавит вас от хранения нескольких копий всех ваших загрузок. Если вы выберете этот вариант, обязательно выполните тестовое восстановление, чтобы убедиться, что все ваши загрузки действительно находятся в S3.
Практика ведет к совершенству
Хотя наличие копии только самой последней резервной копии является минимальным требованием для восстановления в кризисной ситуации, если вы хотите быть действительно уверенными в работоспособности ваших резервных копий, вы должны хотя бы один раз, а лучше периодически, тестировать их. Запустите новый сервер и проверьте, сможете ли вы восстановить данные из резервной копии.