Привет всем, нужна ваша помощь. Я новичок в этом деле, настраиваю своё сообщество на сервере. У меня есть вопросы по резервному копированию: как настроить его на три раза в день? И насколько безопасно такое резервное копирование? Если с моим сервером что-то случится, смогу ли я перенести всё моё сообщество со всеми настройками на другой сервер?
Вы не можете этого сделать (если не прибегать к сложным пользовательским скриптам).
Да, при условии, что вы храните его в другом месте (например, в S3).
Понимаю, считаю, что делать всего одну резервную копию в день — это рискованно. Если сообщество очень активное, есть риск потери данных, так как ближайшая резервная копия может быть сделана только через 24 часа. Возвращаясь к теме: подскажите, при добавлении бакета S3 файлы резервных копий загружаются напрямую в S3 или также сохраняются на машине, где размещён сервис?
Сначала они сохраняются на компьютере, а затем загружаются (и удаляются с компьютера).
Понимаю, в моём случае это решение не работает, оно будет небезопасным.
В чём опасность S3?
Если вы по какой-то причине не доверяете ему, можно использовать локальное хранилище и синхронизировать файлы в другое место с помощью rsync. Но это будет менее безопасно, чем S3.
Касательно уязвимости, о которой я говорю, речь идёт не об S3, а о самой логике процесса: минимальный интервал резервного копирования составляет 1 день, однако при анализе этого периода до следующего копирования на сервере или с самим файлом может возникнуть проблема или нештатная ситуация. Поэтому, если речь идёт о очень активном сообществе, возможна потеря части данных.
Если вы не можете позволить себе риск такой потери данных, вам следует инвестировать в настройку базы данных с репликацией на другого хостинг-провайдера или в другую зону доступности. Однако такие решения имеют свою цену.
При управлении рисками риск возникновения проблемы определяется как вероятность её появления, умноженная на масштаб последствий. Чтобы снизить риск, можно либо уменьшить вероятность катастрофы, либо смягчить её последствия.
Более частое создание резервных копий — это мера, снижающая масштаб последствий. Также можно рассмотреть возможность уменьшения вероятности — например, выбрав более надёжного хостинг-провайдера.
За последние 10 лет, в течение которых мы с Communiteq размещали множество форумов на платформе Discourse, у нас никогда не возникало ситуации, в которой мы пожалели бы о том, что не делали более частые резервные копии.
Я новичок в Discourse, поэтому я не очень хорошо понял то, что вы сказали.
Он говорит, что за десять лет управления сотнями форумов он ни разу не пожалел, что у него нет более частых резервных копий.
Если ваши данные очень ценны, вы можете настроить PostgreSQL на репликацию на другой сервер, чтобы иметь возможность переключиться на горячую резервную копию и потерять очень мало данных или ничего. Вы можете найти информацию в Google по запросу “репликация postgres”. Я предполагаю, что настройка займёт у вас день или два, а ещё несколько дней уйдёт на то, чтобы убедиться, что вы действительно понимаете, как переключаться на резервный сервер.
Также можно настроить задачу cron, которая будет выполнять резервное копирование каждые десять минут и сохранять эти копии в S3.
Однако рекомендация заключается в том, чтобы найти что-то другое, о чём стоит беспокоиться.
Понял, хорошо, я посмотрю, что лучше сделать
Я просто не могу понять, почему так много людей выступает против более частого резервного копирования базы данных. Что стоит за этим? Пожалуйста, объясните мне, почему в Discourse ограничение в 24 часа не является угрозой, тогда как в других системах это проблема. Мой WordPress/WooCommerce делает резервные копии базы данных каждые 5 минут, и это практически бесплатно.
С самого начала цифровой эпохи существуют две универсальные истины:
- резервные копии часто оказываются слишком старыми
- создание резервных копий должно быть автоматическим, поскольку полагаться на человека — это гарантированный способ забыть об этом
Я тоже не понимаю, как они не видят рисков в резервном копировании, которое выполняется каждые 24 часа: за этот период может произойти значительная потеря конфиденциальной информации.
Если вы хотите создавать резервные копии чаще, вы можете написать cron-скрипт для этого или создать плагин, который будет делать это чаще. Если вы планируете делать резервные копии чаще, убедитесь, что загрузки хранятся в S3, так как копирование всех файлов загрузок при каждой резервной копии обходится дорого.
Сайт Cdck/discourse.org, насколько я знаю, создаёт резервные копии дважды в день. Они делают это с помощью внешнего скрипта.
Если вы не хотите разбираться в управлении резервными копиями PostgreSQL, вы можете обратиться в канал Marketplace с указанием бюджета и уточнить, предпочитаете ли вы, чтобы плагин создавал резервные копии, или вам нужна помощь в написании скриптов для резервного копирования базы данных PostgreSQL или самого Discourse.
Это, однако, не встроенная функция WordPress, верно? Это плагин, правильно?
Но суть в том, что создание более частых резервных копий, вероятно, излишне, по крайней мере, судя по опыту некоторых людей, которые управляли множеством форумов Discourse на протяжении многих лет.
Но мы здесь говорим о базе данных. Резервное копирование загруженных файлов в S3 каждые несколько минут — это просто глупо.
Тем не менее, я бы хотел услышать, почему это такой большой вопрос.
У Automattic вообще нет встроенного решения. Однако есть множество причин, по которым нет необходимости создавать такой функционал. Вся экосистема отличается, и Discourse как среда полностью лишена такого разнообразия. Всё здесь строго ориентировано на B2B, я это понимаю, и нет ни необходимости, ни желания разрабатывать решение для клиентов такого же уровня, как WordPress и его плагины.
Мне просто нужно знать, какова реальная причина, почему этот вопрос настолько сложный.
Я не против этого. Я просто не думаю, что мне это нужно, и мне это никогда не было нужно.
Создать плагин, который это делает, было бы не очень сложно и не потребовало бы много работы. Однако никто его не создал. Это, вероятно, признак того, что это не так важно для многих 
Да, настоящий тест любого требования — это либо то, что CDCK его подхватит, либо кто-то опубликует сообщение в Marketplace с осмысленным бюджетом.