Комментарии 6
Подскажите, Георгий Гаджиев не у вас сейчас работает? Такое ощущение, что текст вышел из под его пера.
Прочитал. Подумал, что кроме DBA нужен еще специальный backup admin: надежды на мальчиков-зайчиков-энекейщиков при использовании софта подобной сложности просто нет.
Скажите, а что может произойти с кластером из пяти нод в двух разных дата-центрах, что оправдывает сохранение не только данных с SQL (с чем SQL сам справляется заметно лучше всякого софта, при включенной компрессии), а и настроек данного кластера?
Это не сарказм. Я пытаюсь осознать полезность.
P.S. Пример из текста — «Давайте представим, что к нам придёт зловред шифровальщик и начнёт одну за одной класть ноды кластера. Тут у нас уже не получится быстренько восстановить только файлы БД. А ещё бывают неудачные обновления ОС, умирающее железо и т.д.» — не работает в случае бекапа transaction log 1 раз в 10 минут. Пусть себе шифрует, отвалим ноду. Сломано 5 нод — собственно, значит остальная инфраструктура уже лежит, и надо тушить пожар…
Скажите, а что может произойти с кластером из пяти нод в двух разных дата-центрах, что оправдывает сохранение не только данных с SQL (с чем SQL сам справляется заметно лучше всякого софта, при включенной компрессии), а и настроек данного кластера?
Это не сарказм. Я пытаюсь осознать полезность.
P.S. Пример из текста — «Давайте представим, что к нам придёт зловред шифровальщик и начнёт одну за одной класть ноды кластера. Тут у нас уже не получится быстренько восстановить только файлы БД. А ещё бывают неудачные обновления ОС, умирающее железо и т.д.» — не работает в случае бекапа transaction log 1 раз в 10 минут. Пусть себе шифрует, отвалим ноду. Сломано 5 нод — собственно, значит остальная инфраструктура уже лежит, и надо тушить пожар…
Чтобы успеть отвалить одну (да пусть и несколько) ноду в реальной жизни, необходима хорошая скорость реакции мониторинга, отличные аналитические способности людей на местах, невероятная способность к принятию решений у персонала (отключать от боевого кластера ноды, это всё же надо решиться) и физическая близость к консоли управления (как известно, всё ломается, когда админ жуёт обед или сидит на горшке).
Но это лирика, давайте к практике. Пожар потушили, надо как-то поднимать. Если у нас есть бекап самого кластера, мы раскатываем его на железо и запускаем через минимальное время. Приналичии реплик или фич вроде запуска прямо из бекапа (instant vm restore в терминологии veeam), время восстановления получается действительно копеечное.
Если у нас есть только бекап SQL, то мы отдельно раскатываесм систему (предположим, что у нас есть образ со всеми нужными обновлениями), собираем кластер, ставим SQL (предположим, что тоже без мучительных обновлений), восстанавливаем базу и только потом запускаемся.
Но это лирика, давайте к практике. Пожар потушили, надо как-то поднимать. Если у нас есть бекап самого кластера, мы раскатываем его на железо и запускаем через минимальное время. Приналичии реплик или фич вроде запуска прямо из бекапа (instant vm restore в терминологии veeam), время восстановления получается действительно копеечное.
Если у нас есть только бекап SQL, то мы отдельно раскатываесм систему (предположим, что у нас есть образ со всеми нужными обновлениями), собираем кластер, ставим SQL (предположим, что тоже без мучительных обновлений), восстанавливаем базу и только потом запускаемся.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как правильно бекапить SQL Failover кластер