Немного опыта про backup & storage

Всем привет!

Некоторое время назад я окунулся в мир «сурового энтерпрайза», а именно в ту его область что отвечает за хранение и резервное копирование данных. Точнее говоря в нее больше всего. И за этот срок у меня накопилось несколько правил, которых я стараюсь придерживаться при проектировании или обслуживании решений в этой сфере. Какие-то уже отжили свое, с развитием технологий, а какие-то вполне рабочие. И я решил ими поделиться с вами.

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

Особенности местного «сайзинга»


Рано или поздно возникает потребность получить еще сколько-то терабайтов и/или IOPS'ов. И тогда начинается сайзинг. Часто бессмысленный и беспощадный. Потому что крайне редко кто-то закладывает в сайзинг требования RTO которые обычно предъявляются к резервному копированию. Хотя вроде очевидное требование к любому аппаратному комплексу. Т.е. при сайзинге и формировании требований к новому оборудованию почему-то не учитываются требования системы резервного копирования, которая будет экстренно вам на железо что-то восстанавливать. Иногда что-то весьма большое. Вообще какой-то запас по производительности и месту закладывается, но первое же восстановление данных показывает, что его не хватит на тот жизненный цикл, который был определен для этого оборудования.

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

У нас решение на кластере, зачем вам бекап?!


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

Однако потери данных достигаются не только выходом из строя оборудования на одной площадке, и вот это почему-то долго разработчик понимать не хотел. Как следствие первая версия ПО была выпущена на community СУБД, механики резервного копирования которой не позволяли выполнить ни требования RTO/RPO, ни SLA подрядной организации.
Вообще эту фразу про кластер я слышу довольно часто.

Сперва то, потом сё!


Одной из самых больших моих ошибок было рассмотрение объектов резервного копирования как самостоятельных. Вот СУБД, вот ПО. Это бекапим вот так, а это вот так. Сперва одно, потом другое. И в один прекрасный день мы не смогли восстановиться. Точнее смогли, но за несколько дней, которые были потрачены на устранение ошибок в базе. Причем это не я их устранял, за что мне особенно стыдно. Хотя мы использовали штатный механизм создания резервных копий данной СУБД. Уже протестированный на других системах.

С того момента я везде сую свой нос и трясу разработчика/владельца системы на предмет того, как правильно создавать резервные копии и восстанавливать. Например, в одном случае единственным способом создать рабочую резервную копию была полная остановка служб на 5-и серверах, сделать резервную копию и запустить службы.

Dump наше всё?


Часто сталкиваюсь с решениями на таких СУБД как MySQL и PostgreSQL. И еще чаще сталкиваюсь с ситуацией, когда в качестве метода резервного копирования используется банальный dump базы в /tmp, а потом уже на другой носитель. При этом системы, где применяются эти СУБД, достаточно критичные к времени простоя в случае потери данных, и весьма нагруженные. Я уже молчу про объемы.

Почему-то мало кто читает документацию к этим продуктам и не знает, что есть альтернативные способы и решения создания бекапов этих СУБД. MySQL Enterprise Backup для, соответственно, MySQL и pg_basebackup (pg_start_backup, pg_stop_backup) в, соответственно, PostgreSQL. Или же знает, но вылетело из головы. Хотя эти решения и не сильно сложнее, и быстрее. Быстрее сделать резервную копию, быстрее восстановить, быстрее протестировать.
Please do not shoot the pianist.
He is doing his best.
Oscar Fingal O'Flahertie Wills Wilde
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 12

    0
    Ещё добавлю вроде очевидный, но редко используемый совет. Проводите периодическое восстановление из вашего бэкапа и прогоняйте какие-то минимальные тесты, хотя бы руками, чтобы убедиться, что восстановилось как надо. А в идеале ронять продакшн и восстанавливать, хотя на это мало кто решается :)
      0
      Хм, мне всегда казалось, что единственный более менее адекватный вариант резервирования базы данных — это асинхронная реплика. В остальных случаях, в случае физического отказа дисков вы потеряете слишком много данных. Правда это не отменяет регламентного бэкапа на случай логической потери данных (случайно запрос что-то не то сделал). Но тогда восстановление идет уже в ручном режиме тем, кто поддерживает ПО (так как администратор не знает структуры базы и что нужно для ее целостности).
        +2
        Репликация — это всего лишь инструмент для создания двух (или более) запоротых баз данных из одной, с небольшой задержкой в случае асинхронной репликации.
          0
          Репликация помогает при физическом отказе дисков. А отказывают обычно только на одном (если там они не висят на одних и тех же дисках в одной и той же хранилке). Обычная копия нужна как раз, чтобы восстанавливать поврежденные данные. Но тогда обычно идет восстановление не всей базы, а конкретных таблиц.
            +1
            О чём и написано, репликация — вариант обеспечения высокой доступности (как, кластер из статьи), но не
            адекватный вариант резервирования базы данных
            и её восстановления.
            0
            Репликация бывает с снепшотами ;-), например в реализации VMware VSphere
              0
              Главное, что бы эти снепшоты были application consistent. Они не всегда помогают и тогда приходится делать репликацию на уровне приложения/СУБД.
            0
            Тут следует учитывать два момента: асинхронная реплика — это тоже потеря данных, и служба эксплуатации может просто не успеть переключится на реплику. Например, если реплика идет очень часто, раз в 5-15 минут. Но переключение на реплику всегда быстрее и потому ее неплохо иметь так же. Восстановление же, верно, идет в ручном режиме. Резервные копии так же можно делать достаточно часто. Это зависит от метода копирования и конкретной СУБД. Я скорее к тому, что нужно учитывать максимум вариантов сбоя и прорабатывать методы их устранения. Идеально, если разработчик задумается об этом на этапе создания своего продукта. Вполне прекрасно, если это требование будет внесено в ТЗ на разработку.
              0
              Это очень поверхностный подход. А нужен комплексный.
              В зависимости от базы, ее размера, критичности и стоимости данных выбирается свой инструмент. В том числе есть решения класса Continuos Data Protection, которые позволяют синхронно реплицироваться и откатываться на нужный момент времени. Например, Oracle Standby с FlashBack логами.
              Для очень критичных баз обычно делается так: Кластер высокой доступности в одном ЦОД, Standby в другом ЦОД, там отстающий Standby с логами (можно FlashBack).
              Статья про трудности РК
                0
                Не спорю. Но в жизни не так много задач, который требуют такой уровень. Если вы обрабатываете банковские транзакции то конечно. А если считаете лайки на котиков или простенькую учетную систему на 3 пользователя, то нет.
                Но чаще всего достаточно асинхронной реплики и регламентных бэкапов. У меня на практике еще пока ни разу не рушились raid'ы, а из бэкапов нужно было доставать крайне редко и достаточно некритичные данные.
                  0
                  Про лайки с котиками не знаю, такие компании к нам не обращаются. Как я писал, зависит от «базы, ее размера, критичности и стоимости данных».
                  Автор поста писал про «суровый энтерпрайз», не думаю, что это не про котиков.

                  У меня на практике рушились рейды, выходили из строя оба контроллера СХД сразу, люди портили словарь базы, заливали СХД, перегревали ЦОДы, ломались процессоры, системные платы, память. И это происходит достаточно часто, если мы говорим про большие компании.
              0
              dump в /tmp
              отличное решение
              отожрём памяти и свалимся в swap
              как характеризовал один мой знакомый ощущение работы на новом месте
              «любительская хоккейная команда»

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

              Самое читаемое