Комментарии 15
Если нужно сделать резервную копию данных, более конфиденциальных, чем фотки и видео из отпуска, едва ли стоит копировать их в облачное хранилище, принадлежащее другой компании. Может получиться так, что вы по тем или иным причинам потеряете доступ к облаку или ваши данные будут скомпрометированы.
В хороших средствах для бэкапа существует шифрование перед загрузкой в облако.
В хороших средствах для бэкапа существует шифрование перед загрузкой в облако.
Да, это снимает часть проблем. Но остается довольно высокая стоимость по сравнению с обычными выделенными серверами и отсутствие контроля за происходящим. Все же я предпочитаю хранить важные данные на собственных ресурсах.
Тут другой вопрос - если мы так боимся провайдера облака, то почему не боимся провайдера сервера?
Повторюсь:
По возможности стараюсь контролировать все сам. В этом смысле черный ящик облака дает меньше возможностей по сравнению с собственными серверами.
Не нашел в своем случае никаких преимуществ хранения бекапов в облаке, за что стоило бы платить больше. Особенно с учетом платного трафика, а для бекапов это десятки ТБайт в сутки.
Для защиты от проблем с провайдерами и датацентрами храню бекапы в трех независимых местах, одно из которых постоянно в офлайне.
Конечно, если компания ориентирована на аутсорсинг или в других случаях, для нее может быть удобно использовать в качестве одного из этих мест хранения бекапов и облака. Тут все индивидуально.
А вот ответ ChatGPT на ваш вопрос:
"Это действительно хороший вопрос. Оба типа провайдеров - провайдеры облака и провайдеры серверов - имеют доступ к вашим данным и информации. Однако, существует несколько различий, которые могут влиять на выбор провайдера.
Провайдеры облака обычно имеют большее количество клиентов и могут иметь больше ресурсов, чем провайдеры серверов, что может увеличивать риск взлома или кражи данных. Однако, провайдеры облака также имеют более строгие меры безопасности и контроля доступа, что может уменьшать риск.
С другой стороны, провайдеры серверов могут иметь больше контроля и возможностей для настройки безопасности, чем провайдеры облака, но меньше ресурсов для защиты данных и безопасности.
В итоге, выбор зависит от индивидуальных потребностей и предпочтений компании или организации. Важно учитывать факторы, такие как степень контроля, удобство, стоимость и меры безопасности, прежде чем принимать решение о выборе провайдера. Важно также выбрать провайдера, который может предоставить необходимые гарантии безопасности и конфиденциальности данных."
Интересно - а есть ли интернет магазины или другие клиенты - которым нужна практически синхронная репликация базы данных например или каких то других данных. Как поступаете в этом случае.
Интересно - а есть ли интернет магазины или другие клиенты - которым нужна практически синхронная репликация базы данных например или каких то других данных. Как поступаете в этом случае.
У нас есть такие магазины. Настраиваем репликацию MariaDB master-slave и файлов через Rsync, переключаем IP при аварии с помощью keepalived. Там еще нужно настраивать бекапы основного и резервного сервера, а также мониторинг.
Подробнее можно почитать здесь: https://habr.com/ru/post/709650/
Есть еще вариант использования отказоустойчивых облаков, но это сильно дороже.
Вот еще инструкция от ChatGPT:
Here is a high-level overview of how to set up this configuration:
Install MariaDB on both the primary and backup servers.
Configure the primary MariaDB server as the master, by setting up appropriate user accounts, granting replication privileges, and enabling binary logging.
Configure the backup server as the slave, by connecting to the primary server and specifying it as the master.
Set up Rsync to replicate files between the primary and backup servers.
Install and configure Keepalived to monitor the primary server and switch the IP address in case of failure.
Set up a backup solution to take regular backups of both the primary and backup servers.
Implement monitoring to ensure that the replication and backups are working as expected, and to receive notifications in case of any failures.
It's important to note that this is a general overview and the exact steps and configuration details may vary depending on your specific requirements and infrastructure. It's recommended to follow MariaDB's official documentation or seek assistance from a qualified system administrator or consultant to properly set up this configuration.
А как в такой ситуации происходит переключение обратно на master-сервер? Получается, что slave накопил какие-то изменения пока master был в отключке, и надо как-то засинкать данные обратно на master. Как это делается?
Тут два варианта.
По первому варианту:
анализируются причины выхода из строя мастер-сервера, при необходимости выполняется ремонт, замена, переустановка ПО и т.д.;
выбирается время, когда количество посетителей на сайте минимально;
блокируется доступ посетителей, менеджеров и пакетных заданий для изменений базы данных;
запускается бекап базы данных и файлов на резервном сервере, эти бекапы переносятся на мастер-сервер и восстанавливаются там;
на резервном сервере перезапускается keepalived, и при правильной настройке виртуальный IP переходит от резервного сервера на мастер;
заново настраивается репликация базы данных и файлов на резервном сервере и выполняются все необходимые проверки
Есть еще разные тонкости, которые зависят от архитектуры сайта.
По второму варианту бекапный сервер превращается в мастер, а восстановленный мастер становится бекапом.
В любом случае будет недоступность базы данных на запись во время ее бекапа и переноса на другой сервер, к сожалению. При этом витрина будет работать, а оформление заказов - нет.
Спасибо.
which в скриптах лишнее.
Если ОС "знает" где лежит тот или иной исполняемый файл, то он и без which отработает. Если нет, то и which не поможет. Лишние строки.
Кстати, which - устарел, вместо него command -v нынче. На shellcheck было.
Для по-файлового бэкапа гляньте на kopia.
> Устройства My Book World Edition II и DNS-345 для хранения данных в офисе или дома
Не надо. Это привязка к вендору и в теперешней ситуации это может быть проблемой в случае выхода из строя. Надо универсально и без привязки - это omv или truenas.
Это привязка к вендору
Первое из этих устройств используется как хранилище с FTP-доступом, тут можно использовать любое другое. Можно и Truenas поставить, да.
Что касается DNS-345, то его можно заменить чем угодно, лишь бы там работал доступ по SSH и скрипты Perl. Нам Truenas там был не нужен. Подойдет любой компьютер или сервер с достаточным количеством дисков и ОС Linux.
Раз вы выбрали то, то что выбрали, значит на то были причины.
Я лишь предложил универсальный вариант без привязки к вендору.
Да, спасибо, особенно за Kopia, посмотрю на досуге.
Когда покупали DNS-345, то потратили меншье 10 тр., при этом он не слишком сильно шумит (дома на ночь включать), и можно поставить 4 диска. Правда для получения доступа через SSH пришлось кое-что пропатчить, но это было нетрудно.
А My Book World Edition II я просто купил в магазине, потому что там был RAID из двух дисков)
В догонку.
Если оч-оч захочется синолоджи не на железе от синолоджи )
https://xpenology.com/forum/topic/66980-dsm-7x-proxmox-backup-template/
Еще раз про бэкапы