До и После полуночи

Резервное копирование? Опять?
Ага!

Разумеется, любой грамотный АйТи-шник прекрасно знаком с подоплёкой этого вопроса, однако, как оказалось, методология и даже простейшая алгоритмика иногда являются камнем преткновения.

Что странно. Что удивительно.
Давайте разбираться, что нужно сделать "До полуночи", чтобы спать спокойно "После полуночи"...

Эта статья написана по следам прошедшего недавно вебинара.

Основными темами обсуждения являлись вопросы необходимости всегда иметь "на борту" резервные копии данных (далее по тексту, для краткости, – РКД), а так же способы их создания, проверки и восстановления.

Для начала, для “затравки”, вспомним, что платформа InterSystems IRIS обладает мощными и, что самое важное, работоспособными и действенными средствами зеркалирования данных.

Типовая схема синхронного зеркала с дополнительным асинхронным узлом Обеспечения Восстановления после Сбоев (Disaster Recovery) выглядит примерно следующим образом

Более подробно с архитектурой и методиками построения зеркал на инфраструктуре InterSystems можно ознакомиться здесь.

Невольно возникает закономерный вопрос: “А для чего нам тогда нужны резервные копии данных, если они (эти наши супер-пупер важные данные) неоднократно отзеркалированы?”

Отвечаю.

Зеркалирование надёжно защищает вас от “физических” сбоев в вашей инфраструктуре, но ничем не поможет при нарушении логической целостности данных.

То есть базы данных байт-в-байт целостны физически, а сами данные некорректны (или вообще удалены) логически.

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

В этом случае только наличие резервной копии ваших баз данных может помочь вам восстановиться до приемлемого состояния. Но, разумеется, лишь в том случае, когда регламент создания копий чётко согласован и исполняется (об этом ниже).

Я выделю три основные причины, когда РКД вам точно не помешают:

• Ошибки в программном коде (also known as BUGs).
• Непреднамеренные или случайные действия.
• Злоумышления, и человеки, с ними связанные.

Слишком подробно рассматривать это не будем, только очень кратко опишу для полноты картины.

Ошибки в программном коде, они же Баги

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

Непреднамеренные или случайные действия

Никто не идеален.

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

Злоумышления, и человеки, с ними связанные

Здесь уже человеческий фактор на 100%.

Эффективные менеджеры торгуют и спекулируют, зарабатывая на подчас измотанных инженерах, программистах, админах, ...

Знакомая ситуация, не правда ли?

Многие (не все, но выделю тех, кто только и умеет, что собрать гирлянду из проводков USB) ИТ-специалисты переходят в разряд ИТ-пролетариата, которые озлоблены по тем или иным причинам на работодателя, который закономерно увольняет их.

Кто-то из таких разобиженных отпрысков “поколения LEGO” успевает оставить в программном или системном коде свои закладки, бэкдуры или даже неявные ошибки, которые рано или поздно дадут о себе знать.

(Банальное напоминание любому работодателю: проверяйте нанимаемых вами менеджеров и исполнителей на знание хотя бы азов естественных и гуманитарных наук и на психологическую стойкость…).

И лишь регулярно создаваемая резервная копия ваших данных может спасти ситуацию.
Хоть как-то…

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

Обычно выделяются три вида способов резервного копирования:

• Холодный
• Внешний
• Горячий (он же Online)

Я позволю себе объединить Холодный и Внешний способы создания РКД, и в конце этого раздела опишу ещё один способ, который самый правильный, на мой взгляд.

“Грязный” метод создания резервных копий мы рассматривать в этой статье не станем. Полное описание всех способов, их преимуществ и недостатков есть в нашей Документации, пожалуйста, ознакомьтесь.

Итак, приступим.

Холодный или Внешний

Чаще всего этот способ создания копий требует либо полной (в варианте Холодного), либо частичной, но зачастую продолжительной, остановки вашей системы (в случае Внешнего).

Холодный вариант – самый тривиальный. Вы просто останавливаете инстанс IRIS и физически копируете файлы IRIS.DAT и всё остальное, нужное вам, в безопасное место.

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

Внешнее резервное копирование немного интереснее, т. к. подразумевает взаимодействие с прочими (третьесторонними) средствами. Как видно из рисунка-заставки к этому разделу, это могут быть средства, имеющиеся на борту вашей СХД (Системы Хранения Данных), или средства гипервизора системы виртуализации, например, периодическое снятие снапшотов виртуальных машин целиком, либо только виртуальных дисков, или различные средства различных ОС, наподобие VSS от Microsoft (которая, кстати, документирована у нас и неплохо работает).

Также вполне успешно используются специализированные программные продукты, наподобие решений от Veeam, Veritas, и так далее.

При этом стоит помнить, что вызовы методов класса Backup.Gerenal ExternalFreeze() и ExternalThaw() являются обязательными, если вам важна целостность копируемых БД.

Горячий (он же Онлайн)

Самый используемый способ. Но не идеальный, и в нашей документации описаны преимущества и недостатки.

Тем не менее, это – штатный механизм, весь необходимый инструментарий идёт “из коробки” и работает практически безотказно.

Напомню фазы создания “горячей” резервной копии (подробно они рассматриваются в нашем учебном курсе Системного Администрирования):

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

Если у вас по каким-то причинам до сих пор не производится резервное копирование данных, то настоятельно рекомендую начать именно с этого способа.

И будет замечательно, если это будет совмещено с идеями, изложенными в следующем разделе и следующих главах.

Умный

Самый ресурсоёмкий, но и самый правильный способ создания копий данных.

Несмотря на все современные успехи информационных технологий, для работы на критически важном участке пока всегда требуется Человек, причём человек грамотный и ответственный.

Вы можете использовать совершенно любые технологии создания резервных копий, но если у вас нет выработанной, согласованной и внедрённой методологии всего процесса, и, что самое важное – Ответственного Человека, то все усилия, скорее всего, пойдут насмарку…

Я предлагаю свой план из пяти простых и довольно чётко гранулированных шагов для построения системы РКД, который будет применим (опять-таки только по моему мнению) для большинства проектов.

Итак, пошагово:

1. Осознание необходимости регулярного создания РКД.
   К сожалению, такое осознание часто приходит только через боль потерь…
2. Выработка, согласование и подписание регламента создания РКД на уровне проекта/компании/системы.
   Самый важный шаг. На этом же шаге должен быть избран Ответственный за РКД. И он должен принять эту ответственность и подписаться за неё.
3. Тестирование и внедрение системы РКД.
   Технически – это самый простой шаг, однако есть целые залежи “подводных камней”, о которые часто спотыкаются. Об этом пункт 4 и немного детальнее ниже в статье.
4. Обеспечение непрерывного мониторинга и контроля процесса РКД.
   Все сбои в создании РКД должны протоколироваться. Всё должно мониториться. Всё должно управляться. Заканчивается место на СХД – уведомляются все задействованные лица всех причастных подразделений. Не удалось создать РКД – оперативно и с наивысшим приоритетом оповещаются все службы и специалисты. Процессы мониторинга, контроля и оповещения должны быть максимально автоматизированы.
5. Да, вышеизложенное – ещё не всё… Мы добрались лишь до начала, до того, что “До полуночи” – до планирования и внедрения. Что же нас ждёт дальше?

Типизация, Регламент и Проверка РКД.

Взглянем чуть подробнее на принципы разработки и согласования методологии РКД на примере Горячего (Online) способа создания бэкапов.

Условная типизация видов РКД

• Полный бэкап .
  Создаётся полная копия вашей БД. Это означает то, что вы сможете восстановить ваши данные по состоянию на момент завершения создания копии.
• Кумулятивный .
  В РКД записываются только блоки, изменённые с момента создания Полной РКД и должны использоваться в связке с ней.
• Инкрементальный .
  В файл РКД записываются блоки БД, изменившиеся с момента создания РКД любого типа.

Пример регламента РКД

Конечно же, специфика каждого проекта предполагает свои условности и тонкости, но я приведу типичный и всегда рекомендуемый мною регламент:

• Полная РКД раз в неделю (да, как раз “после полуночи”, в ночь с субботы на воскресенье).
• Кумулятивная РКД раз в сутки (и опять-таки, как правило, “после…”).
• Инкрементальная РКД раз в час.

Я ни в коем случае не настаиваю на правильности этой схемы.

Все позиции вы можете гибко варьировать в зависимости от ваших технических мощностей и от реальных (повторюсь, заранее регламентированных и согласованных) требований к сохранности данных.

Что же нас ждёт “…после полуночи”?

Проверка!

Наиважнейший шаг в методике правильного РКД.

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

Чтобы полностью обезопасить себя от потери или искажения данных, необходимо после каждого создания РКД выполнять проверку на целостность.

Обобщая, нужно иметь отдельные серверы или инстансы InterSystems IRIS, на которые, желательно в автоматическом режиме, будут разворачиваться созданные РКД, после чего на них будет выполняться проверка целостности.

Идеальный план создания и восстановления РКД.

С учётом всего вышеизложенного, вам уже будет довольно просто понять схему с картинки.

Следуем регламентированному и согласованному алгоритму:

• Автоматически создаётся РКД того или иного типа.
• Уведомляется Ответственный; статус виден в Мониторинге.
• При необходимости РКД переносится на выделенную архивную СХД (т.к. саму копию желательно создавать на “быстрых дисках”, и только потом переносить её, скажем так, на медленную “ленту”).
• Затем копия переносится на тестовый контур, где производится её развёртывание и проверка логической целостности данных.
• О результатах проверки (особенно в случаях ошибок) уведомляются ответственные лица и предпринимаются необходимые действия.
• В случае инцидента все РКД должны быть готовы и проверены.

И кое-что ещё...

Важно не столько время СОЗДАНИЯ, сколько время ВОССТАНОВЛЕНИЯ.

Но это уже тема для отдельной статьи, если будет заинтересованность.

Ещё немножко картинок

Специально для этой статьи я провёл небольшое исследование, на основании которого получилось нарисовать несколько интересных (и иногда неожиданных) “графиков”.

Общая статистика

Эта статистика, несмотря на разумеющуюся нерепрезентативность моей выборки, меня сильно вдохновила, потому что, как видно, бОльшая часть данных наших пользователей защищена так или иначе, но, с другой стороны, насторожили 13% безответственных граждан…

Кто что использует

Здесь уже сумма больше ста процентов. Почему – понятно: многие используют одновременно несколько инструментов для РКД. Например, Hot Backup плюс нечто внешнее для управления файлами РК. Или же создают свою механику создания копий, иногда “с нуля”, а иногда – наследуясь от имеющихся классов.

Пригождалось ли?

Я не стану комментировать, из картинки всё ясно.

Подводя итоги

Скажу только одно: не пренебрегайте созданием копий ваших данных, и будьте ответственны! Ну или назначайте Ответственных :)

Спасибо!