Правильный способ защиты и резервного копирования Discourse на собственном сервере?

Привет,

На собственном сервере какие лучшие способы предотвратить безвозвратную потерю нашего форума? Как правильно и безопасно делать резервные копии наших ценных данных?

В теме, которая была удалена, @falco сказал:

Снимки файловой системы не поддерживаются и могут привести к потере данных.

Кроме того, о функции резервного копирования от Hetzner компания сообщает:

мы рекомендуем выключить ваш сервер, чтобы обеспечить согласованность данных на диске.

Так что, я полагаю, это не совсем рекомендуемое решение… Или всё же?

На моём форуме я использую rclone и синхронизирую мои локальные папки с резервными копиями с папкой в Google Диске.

Если мой сервер выйдет из строя, у меня будут еженедельные резервные копии в Google Диске.
Если мои локальные резервные копии исчезнут и rclone удалит резервные копии в диске после синхронизации моей теперь пустой папки, мои удалённые резервные копии всё ещё будут доступны, так как они останутся в корзине Google Диска.

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

Но действительно ли это так? Есть ли какое-либо другое надёжное решение, которое легко установить?
Касательно rclone: он совместим с множеством систем хранения. Есть ли какие-то лучшие варианты для хранения и синхронизации наших резервных копий?

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

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

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

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

Если вы удалённо синхронизируете /var/discourse/containers и /var/discourse/shared/standalone/backups, всё будет в порядке. Если ваш сервер перестанет работать, вам понадобятся только файл(ы) yml контейнера и самая последняя резервная копия. Я рекомендую делать ежедневные резервные копии. Если вы особенно сообразительны и преданы делу, вы можете настроить процесс очистки на стороне назначения rsync, чтобы сохранять еженедельные, ежемесячные и годовые резервные копии.

Я только что написал это: Best Practices for Backups

Также посмотрите это:

Резервное копирование в Amazon S3, которое выполняется автоматически и встроено в систему.

Мы уже много лет используем rsync, и он отлично работает для нас. Каждый день мы синхронизируем резервные копии с помощью rsync на внешний сервер резервного копирования, который мы контролируем и управляем им. Поэтому, если с дата-центром случится беда, у нас всё будет в сохранности :slight_smile:

Кроме того, размышляя о резервном копировании и безопасности, помните, что информационная безопасность состоит из трёх ключевых областей:

  • доступность
  • целостность
  • конфиденциальность

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

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

Безопасность не бывает универсальной; она зависит от вашей уникальной модели управления рисками. Эта модель также включает три ключевых аспекта:

  • угрозы
  • уязвимости
  • критичность

Именно пересечение этих трёх областей помогает сформировать вашу стратегию резервного копирования и восстановления.

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

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

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

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

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

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

Кстати: мы никогда не доверяем наши резервные копии каким-либо третьим сторонам (никогда) и всегда храним их в безопасном месте под нашим техническим и административным контролем.


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

ОДНАКО, этот же всемирно известный исследователь подводных пещер никогда не делает резервных копий своего настольного компьютера, и часто он выходит в интернет, потому что его ноутбук сломался, и он потерял все свои данные. Он говорит, что ему не важно, потеряет ли он свои презентации PowerPoint… так что это его личная стратегия управления рисками. Он ценит свою жизнь гораздо больше, чем несколько цифровых файлов.

Такова жизнь…


Итак, отвечая на ваш вопрос. Мы работаем на собственном хостинге уже почти 30 лет. Мы всегда храним наши резервные копии на удалённом сервере с помощью rsync и даже sftp на сервере, к которому у нас есть доступ, и за 30 лет работы серверов в интернете у нас никогда не возникало проблем. У меня даже есть дополнительная копия в моей домашней сети на небольшом Mac Mini, который служит устройством для частного хранения. Именно это я считаю «безопасным»… для моей модели управления рисками.

Спасибо за всю эту информацию :+1:t6:

Интересно, почему я даже не упомянул S3 :thinking: возможно, я неосознанно думал о бесплатных методах резервного копирования… Хотя у меня есть подписка на Google Диск :upside_down_face:

Тем не менее, как правильно оценить стоимость S3 для хранения резервных копий Discourse?
Не уверен, как заполнить поля калькулятора:


В моём случае резервные копии (включая загрузки) занимают около 1 ГБ, и я планирую делать ежедневные резервные копии с хранением от 4 до 7 дней, насколько я понимаю.

Ещё один момент, о котором я не говорил: я хочу, чтобы мой соадминистратор также имел доступ к удалённым резервным копиям.
Сейчас на Google Диске я поделился с ним папкой, где хранятся мои резервные копии.
Возможно ли также предоставить доступ к резервным копиям в S3?

Ожидайте ежемесячные расходы в размере 7 ГБ-месяцев (плюс небольшой запас для роста) плюс дополнительная плата за передачу данных каждый раз, когда вам потребуется получить одну из резервных копий.

Отправка или получение резервной копии — это 1 запрос?