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

Резервное копирование? Снова? Ага! Конечно, любой грамотный IT-специалист прекрасно знает подоплеку этого вопроса, однако, как оказывается, методология и даже самые простые алгоритмы иногда являются камнем преткновения.

Что странно.

Это потрясающе.

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

вебинар .

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

Для начала, в качестве «затравки», вспомним, что платформа InterSystems IRIS обладает мощными, а главное эффективными и действенными инструменты зеркального отображения данных .

Типичная схема синхронного зеркала с дополнительным асинхронным узлом Disaster Recovery выглядит примерно так:



Подробнее об архитектуре и методах построения зеркал вы можете узнать на инфраструктуре InterSystems. Здесь .

Невольно возникает логичный вопрос: «Зачем нам тогда резервные копии данных, если они (эти супер-пупер важные наши данные) многократно зеркалируютсяЭ» Я отвечаю.

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

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

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

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

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

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

• Ошибки в программном коде (также известные как BUG).

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

• Злоба и люди, связанные с ней.

Ошибки в программном коде, также известные как ошибки

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

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

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

Не стоит также сбрасывать со счетов фактор усталости наших уважаемых Админов.

Злоба и люди, с ней связанные

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

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

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

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

) .

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

Хоть как-то.

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

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

В этой статье мы не будем рассматривать «грязный» метод создания резервных копий.

Полное описание всех методов, их преимуществ и недостатков находится в наша документация , пожалуйста прочти.

Итак, давайте начнем.

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

Холодный вариант – самый тривиальный.

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

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

Внешнее резервное копирование немного интереснее, поскольку предполагает взаимодействие с другими (сторонними) инструментами.

Как видно из заставки к этому разделу, это могут быть инструменты, имеющиеся на борту вашей системы хранения данных (Data Storage System), или инструменты гипервизора системы виртуализации, например, периодически делающие снимки целых виртуальных машин.

, или только виртуальные диски, или различные средства различных ОС типа ВСС от Microsoft (что, кстати, задокументировано у нас и это хорошо работает).

Специализированные программные продукты, такие как решения от Veeam , Веритас , и так далее.

Стоит помнить, что вызовы методов класс Backup.Общий Внешняя заморозка() И ВнешняяОттаивание() необходимы, если вам важна целостность копируемых баз данных.

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

Однако это стандартный механизм; все необходимые инструменты выходят из коробки и работают практически безупречно.

Напомню этапы создания «горячей» резервной копии (они подробно рассмотрены в нашем обучающем курсе).

Системное администрирование ):

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

  • Соответствующий бит в растровом изображении установлен.

  • Все блоки базы данных копируются.

• Второй и N-й проходы.
  • Копируются все блоки, изменившиеся при предыдущем проходе через базу данных.

• Последний проход.
  • Демон записи ненадолго делает паузу во время последнего прохода.

    Пользователи этого не чувствуют.

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

Умный

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

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

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

Итак, шаг за шагом:

1. Осознание необходимости регулярного создания рабочей документации.

   К сожалению, такое осознание зачастую приходит только через боль утраты.

2. Разработка, согласование и подписание регламентов создания рабочей документации на уровне проекта/компании/системы.

   Самый важный шаг.

   На этом же этапе должны быть избраны Ответственный для РКД.

   И он должен принять эту ответственность и подписать ее.

3. Тестирование и внедрение системы конструкторской документации.

   Технически это самый простой шаг, но здесь есть целые залежи «подводных камней», о которые люди часто спотыкаются.

   Об этом говорится в пункте 4 и немного подробнее ниже в статье.

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

   Все должно контролироваться.

   Все должно быть управляемо.

   Место в СХД заканчивается - оповещаются все задействованные лица всех задействованных отделов.

   Не удалось создать рабочую документацию - все службы и специалисты оповещаются оперативно и в приоритетном порядке.

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

5. Да, вышеперечисленное - это еще не все.

   Мы добрались только до начала, до того, что "До полуночи" - до планирования и реализации.

   Что нас ждет дальше?

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

Условная типизация видов конструкторской документации

• Полное резервное копирование.

  Будет создана полная копия вашей базы данных.

  Это означает, что вы сможете восстановить свои данные до состояния на момент завершения резервного копирования.

• Накопительный.

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

• Инкрементальный.

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

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

• Полное РКД раз в неделю (да-да, сразу «после полуночи», в ночь с субботы на воскресенье).

• Накопительная РКД один раз в день (и повторно, как правило, «после…»).

• Инкрементное УЗО один раз в час.

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

Что нас ждет «.

после полуночи»?

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

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

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

проверка целостности .

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

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

• Рабочая документация того или иного типа создается автоматически.

• Ответственное лицо уведомляется; Статус виден в Мониторинге.

• При необходимости РКД переносится на выделенную архивную систему хранения (поскольку саму копию целесообразно создавать на «быстрых дисках», а уже потом переносить ее, так сказать, на медленную «ленту»).

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

• Ответственные лица оповещаются о результатах проверки (особенно в случаях ошибок) и предпринимаются необходимые действия.

• В случае происшествия все процедуры контроля должны быть готовы и проверены.

Не столько время имеет значение ТВОРЕНИЯ который сейчас час РЕСТАВРАЦИЯ .

Но это тема для отдельной статьи, если есть интерес.

Еще несколько фотографий

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

Кто чем пользуется

Понятно почему: многие люди используют несколько инструментов для РКД одновременно.

Например, Hot Backup плюс что-то внешнее для управления файлами RK. Либо создают свою механику создания копий, иногда «с нуля», а иногда путем наследования от существующих классов.

Было ли это полезно?

Подведение итогов

• Обзор Видеоплееров Для Интернета

  19 Oct, 24

• Взлом Сайта: Простые Советы По Безопасности

  19 Oct, 24

• Eff Объясняет, Почему Перестал Принимать Биткойны

  19 Oct, 24

• Всегда Представляйте Свою Работу

  19 Oct, 24

• Приглашаем Вас На Zeronights 2021

  19 Oct, 24

• Почему Google Покупает Движок Gips Voip?

  19 Oct, 24

• Модернизация Android С Помощью Kotlin

  19 Oct, 24

• Firefox 3 + Документы Google

  19 Oct, 24

• Я Знаю, Что Ты Знаешь, Что Я Знаю, Что Ты Знаешь...

  19 Oct, 24

• Eslint-Scope V3.7.2 Крадет Токены Npm

  19 Oct, 24