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

Поддержка
1

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

Резервное копирование базы данных

  • Discourse выполняет одно ежедневное резервное копирование базы данных.
  • Дополнительно выполняется ежедневное резервное копирование базы данных через cron (+12 часов относительно резервной копии, созданной через интерфейс).
  • Резервные копии хранятся в бакете S3 (в другом дата-центре).

Основные файлы

Следующие файлы резервируются дважды в день в бакет S3 (в другом дата-центре):

  • discourse/containers/app.yml
  • discourse/shared/standalone/uploads/
  • discourse/shared/standalone/backups/
  • discourse/shared/standalone/ssl/
  • discourse/shared/standalone/letsencrypt/

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

S3: Загрузки

  • Ежедневная резервная копия загрузок хранится в бакете S3 в другом дата-центре.

Резервное копирование сервера

  • Еженедельное резервное копирование всего сервера — хранится 4 еженедельные копии.
  • Один раз в год одна из еженедельных копий сохраняется как основная резервная копия в удаленном месте.

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

Что я упустил?

2

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

Мне уже дважды говорили, что это не проблема, но никто так и не объяснил, почему. Поэтому я делаю резервную копию базы данных каждые 6 часов — мой форум не слишком активен, поэтому я могу позволить себе такой риск. Для сравнения: мой интернет-магазин делает резервную копию каждые 4 минуты.

3

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

4

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

docker exec app bash -c "discourse backup"

Если данные действительно критически важны, вы можете настроить сервер репликации PostgreSQL и обеспечить выполнение каждой транзакции на втором сервере.

5

У меня есть такая задача в crontab:

docker exec app discourse backup --sql-only

Это собственная команда CLI Discourse для создания резервной копии, и мне подсказали, что docker exec app выполняет её извне контейнера (app — это имя контейнера, разумеется).

Поскольку я настроил S3, который попадает в тот же бакет, что и «обычные» резервные копии.

Есть одна небольшая проблема… очень скоро появится бесчисленное количество резервных копий. Не знаю, стоит ли мне делать дамп SQL иначе, перемещать его с помощью aws-cli, а затем удалять всё, что старше определённого периода. Или делать то же самое на VPS.

Но это самый простой способ получить дамп SQL.

6

Я предполагаю, что это активирует внутреннюю процедуру резервного копирования Discourse, поэтому все уведомления остаются на месте.

Вы отключаете планирование резервного копирования через интерфейс и управляете всем через cron? Или вы настраиваете одну задачу через интерфейс, а дополнительные — через cron?

7

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

8

Спасибо @Jagster и @pfaffman за помощь в настройке дополнительной базы данных через cron. Это снижает потенциальную потерю данных в моём системе до 12 часов в худшем случае.