Разве одного резервного копирования в день не слишком рискованно? Если с сервером что-то случится, а последнее копирование было вчера, что мне делать? Пользователи, зарегистрированные между вчера и сегодня, разве они больше не зарегистрированы? Я думаю, что лучше делать резервные копии чаще, возможно, каждый час. Но в таком случае, нужно ли переводить сайт в режим только для чтения перед созданием резервной копии? Заранее спасибо!
+1 за это, снова. Discourse — единственная динамическая система, в которой можно автоматизировать резервное копирование базы данных только один раз в день.
Я не ожидаю, что это изменится в ядре в ближайшее время. У меня были разговоры о том, чтобы изменить настройку по умолчанию на более частую, чем раз в неделю, но этого не произойдет.
Я думаю, что было бы хорошо иметь плагин, который добавит настройку сайта для создания резервных копий только базы данных через определенное количество часов (нет смысла хранить тысячи копий несжимаемых загрузок во всех этих полных резервных копиях). Если вам это интересно, напишите мне в личные сообщения или задайте вопрос на маркетплейсе.
Если вам требуется более надежное аварийное восстановление, рекомендую следовать руководству Запуск Discourse с отдельным сервером PostgreSQL и развертывать PostgreSQL самостоятельно. Это позволит вам настроить именно ту высокую доступность, которая вам нужна, например, реплики с синхронизацией в реальном времени, восстановление на определённый момент времени и более частое резервное копирование.
Могу ли я узнать причину этой политики: это техническое ограничение или вопрос класса обслуживания? Интервал в 24 часа между резервными копиями — довольно критичная проблема для форумов с высокой посещаемостью. Или это услуга, доступная только платным клиентам?
Снижает ли скорость работа Discourse с отдельным сервером PostgreSQL, если он находится на другом сервере?
Конечно, это одно из решений. Однако среди приложений такое встречается довольно редко. В мире PHP/MySQL резервное копирование базы данных с помощью cron было бы очень простым, но, опять же, в том мире каждое приложение может делать это самостоятельно — с плагинами или без них.
Да, я немного больше, чем просто средний конечный пользователь ;), но у меня очень поверхностное понимание того, как работают Docker, Rails и подобные технологии. Для меня ситуация, когда выполнение обычных задач оказывается почти невозможной миссией, действительно трудно понять. Конечно, возможно, это связано с моими ограничениями, но я не единственный, кто задаётся этим вопросом.
Что ж. Я понял: в ближайшем или среднесрочном будущем удобного способа резервного копирования баз данных у нас не появится.
Вы также можете настроить резервное копирование PostgreSQL с помощью cron. Здесь нет никаких отличий.
Нет, это не влияет на скорость каким-либо значимым образом. Каждая размещаемая нами инстанция Discourse, как эта здесь, использует базу данных на выделенном сервере.
Я задам вам всего два вопроса, чтобы лучше понять ситуацию.
- База данных — это единственное, что нужно для восстановления всего, верно? Резервная копия, которая создается ежедневно через настройки, касается только базы данных?
- Должен ли форум находиться в режиме только для чтения при создании резервной копии базы данных? Или это можно сделать без каких-либо проблем в любое время?
Заранее большое спасибо!
Настройки хранятся в базе данных.
Технически вам также следует делать резервную копию папки uploads и определения сайта в файле app.yml. Однако обычно это решается путем размещения app.yml в системе контроля версий, а папки uploads — в объектном хранилище.
Режим только для чтения не требуется.
Итак, предположим, что база данных находится на отдельном сервере, и я делаю её резервные копии каждый час. Если я также делаю резервную копию файлов через настройки в панели администратора, будут включены только файлы, включая app.yml и папку uploads, но не база данных, верно? @Falco
Резервная копия будет включать базу данных и загруженные файлы (если они не хранятся в S3). Файл app.yml не включается в резервную копию, так как Discourse не может его прочитать.
Рекомендация для большинства пользователей: хранить резервные копии в S3, а файл app.yml — в надёжном месте, откуда его можно быстро получить в случае чрезвычайной ситуации. Тогда вы сможете создать новый контейнер с помощью app.yml и восстановить данные через командную строку. Однако, если у вас есть технические навыки для резервного копирования и восстановления PostgreSQL с помощью другого инструмента, а изображения уже хранятся в S3 (или вы используете другой способ их резервного копирования), вы можете просто пересоздать контейнер, и всё снова будет работать.
Или, возможно, вы хотите настроить несколько постоянно синхронизируемых серверов PostgreSQL и автоматически переключаться на резервный в случае сбоя основного.
Существует множество способов обеспечить более частое резервное копирование, чем предлагает Discourse. Если вам нужны более частые копии, вам придётся реализовать их самостоятельно.
Ещё один момент здесь — это риски и обслуживание: если вы используете готовое ежедневное решение, оно, скорее всего, будет более надёжным и устойчивым как решение для резервного копирования, чем если вы настроите его самостоятельно. Что, если что-то пойдёт не так с вашим собственным решением, и вы обнаружите это только тогда, когда будет уже слишком поздно? По крайней мере, в случае со стандартным решением его ежедневно тестируют сотни сайтов.
Учитывая, что за 4 года работы с несколькими сайтами у меня ни разу не было случаев повреждения данных, риск того, что резервное копирование вообще понадобится, также невелик…
Возможно, другие смогут упомянуть более серьёзные риски, но, вероятно, самый большой риск — это проблемы из-за заполнения диска на сервере? Поэтому стоит следить за свободным местом? Настроить оповещение?
Итак, насколько я понимаю, лучший способ — держать всё отдельно.
Основной сервер для запуска Discourse. Затем отдельный сервер для PostgreSQL и S3 (или любого другого сервиса объектного хранилища) для загрузок.
Мне кажется, что файл app.yml меняется нечасто, поэтому его достаточно сохранить один раз. Или, в крайнем случае, несколько раз в месяц.
Это позволяет делать резервные копии ваших файлов, причём более упорядоченным образом.
В таком случае решение не внедрять несколько ежедневных резервных копий в ядро кажется мне вполне логичным. С другой стороны, те, у кого сложные потребности, наверняка сами настроят подобную конфигурацию. В итоге вам просто нужно будет переустановить систему (при этом app.yml должен быть сохранён где-то отдельно), а затем подключить её к базе данных и к S3 для загрузок. Резервные копии хранятся на этих двух серверах отдельно, поэтому для меня это легко управляется. Я считаю это очень разумным решением.
Спасибо всем за разъяснения.
Здесь есть ещё одна тема: Configure automatic backups for Discourse - #113 by Tris20
@pfaffman дал там несколько рекомендаций со ссылками. Это привело меня к использованию командной строки для планирования более частых резервных копий, что для меня является вполне разумным решением:
Обратите внимание, что с этим решением вы можете объединить всё в скрипт на Python, чтобы также планировать копию файла YAML и т. д. в то же время.