Хабрахабр

[Из песочницы] Немного опыта про 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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть