Несколько расписаний резервного копирования

Внести вклад Функция
1

Не уверен, стоит ли отвечать здесь или создать новую тему: предложение по функции — отдельные расписания для «включать вложения» и «не включать вложения».

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

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

4 лайка
2

Обычно рекомендуемое действие для этого запроса — создание резервных копий другой базы данных с помощью какого-либо внешнего инструмента.

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

6 лайков
3

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

4

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

  • одного ежедневного резервного копирования достаточно
  • используйте внешние инструменты, такие как скрипты и cron

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

Любой внешний инструмент может справиться с этой задачей, это правда. Но все остальные приложения предлагают приличное резервное копирование нативно, а Discourse — нет.

Мне бы очень хотелось узнать, связана ли причина этого с тем, что:

  • «мы просто не хотим, поэтому никто другой тоже не нуждается в этом»
  • это технически действительно сложно и/или дорого

Ну и всегда есть третий вариант: Marketplace

5

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

Причина в том, что наличие множества резервных копий — это способ заполнить ваш диск, что является одной из самых частых причин падения саморазмещённых сайтов (что, на мой взгляд, относит это к категории «дорого»). Поэтому идея заключается в том, что если у вас достаточно навыков для управления тысячами резервных копий и контроля места на диске, то вы, вероятно, сможете решить эту задачу множеством способов. А если вам нужны ежечасные резервные копии, то они должны быть только базами данных, а не десятками или сотнями копий ваших загруженных файлов.

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

Если у вас всё это уже настроено, то плагин для ежечасных резервных копий только баз данных потребует не более часа-двух работы, или, возможно, 2–10 часов, если вы не умеете создавать плагины и вам нужно разобраться, как настроить ежечасную задачу.

1 лайк
6

Это правда. Сам WordPress не может сделать много. Вот почему существует так много плагинов — плохих и хороших.

Это не так. Платными являются только дополнительные функции, а не само резервное копирование.

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

Вопрос на самом деле простой: сколько контента вы можете потерять.

7

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

4 лайка
8

Есть ли какие-то другие данные, о которых я не знаю? Или вы используете термин данные в более широком смысле, включая все файлы: системные, Docker/Discourse и т.д., загруженные?

Эти файлы можно легко восстановить или с небольшими затратами — за исключением, конечно, загруженных, но для этого у нас есть S3 :wink:

9

Нет, я имел в виду данные базы данных.

1 лайк
10

Тогда он в основном небольшой по размеру, но если говорить о самом форуме, то он самый большой. Но по какой-то причине мы снова вернулись к этому:

Мне действительно интересно узнать, в чём здесь основная проблема — техническая или ментальная. Или это часть бизнес-модели: если резервное копирование станет простым и надёжным, хостинг потеряет один из аргументов для продаж. Хотя я не знаю, используется ли вообще такая стратегия продаж. Я просто пытаюсь понять, почему улучшение резервного копирования является таким важным вопросом, даже если оно запрашивалось ранее.

11

Нет необходимости подозревать, что за этим стоит какая-либо стратегия или зловещий план. Я не думаю, что существует большой интерес к более частому резервному копированию. Если бы он был, кто-то уже написал бы для этого плагин. Это заняло бы всего несколько часов работы. Я не вижу, чтобы Marketplace был переполнен запросами на это.

Думаю, всё сводится к следующему:

  • для небольших форумов вы в любом случае не потеряете много данных, так как за день появляется немного нового, поэтому более частое резервное копирование не стоит затраченных усилий
  • для крупных форумов более частое резервное копирование потребует ресурсов производительности и места для хранения
  • для действительно крупных форумов стоит рассмотреть другие решения (например, репликацию на сервер базы данных с горячей резервной копией)

Не забывайте также, что вероятность того, что вам действительно понадобится резервная копия, крайне мала. За всю историю Communiteq (более 8 лет) нам пришлось восстанавливать резервную копию всего один раз, и то только потому, что мы нетерпеливы и не хотели ждать несколько часов восстановления файловой системы.

*) (исключая восстановление по запросу клиента, когда они просто хотели откатить изменения, в основном на форумах, не являющихся рабочими, а также исключаем наш ежемесячный тест восстановления)

4 лайка
12

Так что, если я ищу здесь, я не нахожу тем, где Discourse по какой-то причине упал, и единственным решением было восстановление из резервной копии?

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

Так что круг замкнулся, и мы вернулись туда, откуда я начал:

И третий вариант. Пока я де-факто провожу тестирование для Discourse здесь и самостоятельно, я не готов платить за такую базовую функциональность.

Ну, мы здесь обсуждаем это без каких-либо комментариев от команды. Снова :rofl:

13

Как вы думаете, сколько будет стоить разработка? В зависимости от цены я готов профинансировать это прямо сейчас, если вы заинтересованы. :dollar:

Этот вопрос уже был рассмотрен CDCK. Просто дайте им немного времени на ответ, вот и всё.

14

Это правильный путь. Пожалуйста, следуйте руководству Запуск Discourse с отдельным сервером PostgreSQL, чтобы развернуть свой собственный экземпляр PostgreSQL и управлять резервным копированием и высокой доступностью так, как вам удобно, если ежедневного резервного копирования недостаточно для ваших задач.

3 лайка
16

Я думаю, что это будет стоить 250–500 долларов, в зависимости от того, насколько настраиваемым оно должно быть и сколько работы потребуется на фронтенде. Хотя я пока не изучал, что именно для этого потребуется. @RGJ, возможно, сделает это дешевле; он часто удивляет меня своей скоростью.

РЕДАКТИРОВАНИЕ: ОХ, эта тема закрыта. Если вы заинтересованы, вы можете связаться со мной или написать в Marketplace.