Спецпроекты

На страницу обзора
Что надо знать о резервном копировании баз данных

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

Рынок СУБД и рынок средств резервного копирования баз данных

Рынок систем управления базами данных растет двузначными темпами. В 2018 г., по данным Gartner, он увеличился на 18,4% и составил $46 млрд, в 2019-м рост был практически идентичным — 18,2%, до $54 млрд. Главным стимулом служат облачные предложения «база данных как сервис» (dbPaaS) — на них приходится две трети общего роста. Но и традиционные сегменты, такие как реляционные базы данных, растут уверенными темпами — на 15,2%.

Вокруг баз данных сформировался рынок сопутствующих продуктов и услуг — проектирование, тестирование, инсталляция, сопровождение… По данным The Business Research Company в 2019 г. его объем составил $78,7 млрд, Reportlinker дает вдвое большую оценку — 149,2 млрд долларов. Аналитики этого исследовательского агентства прогнозируют его незначительное снижение на 1% в 2020 г. из-за пандемии, но уже в следующем году ожидают роста на 12%.

На фоне этих цифр объем всего рынка резервного копирования выглядит более чем скромно — всего $2,2 млрд в 2020 г. по прогнозу industryresearch.biz. Другие аналитики приводят более весомые цифры — $4,5 млрд (Reportlinker) и $11, 8 млрд (ResearchAndMarkets.com). При таком разбросе оценок последние два аналитических агентства дают на удивление схожий прогноз темпов роста — 9,9% в год.

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

Резервные копии каких данных делает ваша организация?

Источник: TechTarger Research, 2019

На рынке имеется множество решений для резервного копирования баз данных. Некоторые из них предназначены для конкретных типов СУБД, другие способны резервировать базы данных нескольких типов, многие поставщики СУБД предлагают собственные средства для их копирования. Правильное понимание особенностей структурированных данных и тенденций развития рынка является ключом к выбору средств резервирования.

При этом, как прогнозируют в Gartner, в 2022 г. 40% компаний заменят свое программное обеспечение для резервного копирования, которое было установлено ранее 2018 г., на более новое. К этому их вынуждает не только рост объемов данных, но и появление новых типов данных, приложений и моделей развертывания.

Особенности резервного копирования баз данных

Структурированные данные требуют особого подхода к резервированию, отмечает эксперт в области резервного копирования Кертис Престон. Данные в «рабочей» БД постоянно обновляются, поэтому файлы, где они хранятся, нельзя просто скопировать как любые другие файлы. Далее, большинство СУБД ведут журнал, куда записывают транзакции. После сбоя эти записи могут быть использованы для восстановления данных на конкретный момент времени. Таким образом, типичный процесс восстановления данных при сбое начинается с восстановления файлов данных из последней копии с последующим воспроизведением последних транзакций по журналу.

Понимание того, как сделать резервную копию, начинается с понимания того, для какой базы данных требуется ее создать. IDC выделяет 4 основных типа СУБД: системы управления реляционными базами данных, нереляционными, динамическими и сеткой распределенных данных (grid). Всего же насчитывается более десятка различных моделей баз данных: реляционная (наиболее известная), «ключ-значение», временные ряды, документная, графовая, поисковых систем, c широкими столбцами, объектно-ориентированная, многозначная, нативная XML, навигационная, событийная и ряд других, менее распространенных.

Все больше поставщиков СУБД предлагают системы управления базами данных, которые способны работать в нескольких режимах (так называемые «мультимодальные базы данных).

Знать, что резервировать

Для правильного резервирования базы данных необходимо знать, где хранятся файлы данных, используются ли простые или сложные транзакции и где находятся журналы транзакций. Кроме того, для распределенной базы данных важно представлять, как осуществляется секционирование — находятся ли все секции на одном хосте или распределены между несколькими. В последнем случае база данных является скорее всего «согласованной в конечном счете» (то есть согласование достигается не моментально, а через некоторое время).

Одинаковое представление новых и измененных данных для всех пользователей обеспечивается двумя разными способами, называемых моделями согласованности. Строгая согласованность гарантирует, что все пользователи одновременно видят одни и те же данные. Большинство реляционных СУБД следуют этой модели. Слабая согласованность (или «согласованность в конечном счете») гарантирует, что все пользователи будут видеть один и тот же атрибут, но лишь по истечении некоторого времени. Показательным примером может служить система доменных имен интернет (DNS). В базе данных, которая хранит доменные адреса, информация заменяется довольно долго, по мере того, как истекает время жизни имеющихся записей. Процесс может занять до 72 часов.

Если база данных распределена по сотне узлов, то получение ее согласованного снимка будет непростой задачей, как и восстановление. Слабо согласованная база данных реплицируется между многими узлами, так что она, на первый взгляд, не нуждается в резервном копировании. Однако, это не так: репликация защищает от выхода из строя узла, но не человеческой ошибки.

Виды резервного копирования

Время восстановления имеет критическое значение для сохранения непрерывности бизнеса при сбое. Сама процедура восстановления может занимать значительное время, а данные с момента последнего резервирования могут оказаться утерянными, если журналы транзакций не сохраняются. Целевая точка восстановления (Recovery Point Objective, RPO), т.е. период, за который утеряны данные, в таком случае часто превышает 24 часа. Для критически важных данных это неприемлемо. Поэтому одной из тенденций 2020 года Garner называет мгновенное восстановление баз данных.

Длительность восстановления и RPO зависят от применяемого вида резервного копирования:

Полное. Все данные, файлы и таблицы базы данных полностью копируются на ленту или диск. Полная копия базы данных позволяет обеспечить восстановление всех ваших бизнес-данных. Однако процесс полного резервного копирования отнимает много времени.

Инкрементальное. Если длительный простой СУБД невозможен, применяется инкрементальное резервирование. При этом подходе копируются только данные, которые были изменены с момента последнего резервирования. Этот вид резервирования выполняется быстрее и сокращает общее время простоя.

Дифференциальное. Это гибрид инкрементального и полного резервирования. При дифференциальном резервировании копируются только измененные данные. Однако, в отличие от инкрементного метода изменения сравниваются с предыдущей полной резервной копией, а не с инкрементами.

Само резервирование выполняется обычно в одном из двух режимов:

Холодное. В этом режиме база данных находится офлайн. Это наиболее безопасный способ резервирования, поскольку позволяет избежать риска копирования данных в процессе обновления. Однако он ведет к простоям, поскольку во время резервного копирования пользователи не могут получить доступ к базе данных.

Горячее. Это основной сценарий резервирования баз данных, позволяющий избежать простоев — база данных остается доступной для пользователей. Однако существует риск, что результирующая копия может не соответствовать финальному состоянию данных, если в процессе резервирования в них будут вноситься изменения.

Полное восстановление базы данных «с нуля» может привести к серьезным задержкам в работе. Чтобы сократить время, необходимое для восстановления данных и систем, резервное копирование базы данных следует выполнять на регулярной основе.

Дмитрий Ганьжа