Сегодня я хочу затронуть вопрос о некоторых важных принципах процедуры резервного копирования и восстановления после сбоев. В частности будут рассмотрены такие вопросы как:
- Взаимосвязь процедур обновлений продуктивной системы и процесса ее резервного копирования
- Тестирование восстановления из резервных копий
- Взаимодействие бэкап-процесса с элементами сетевой инфраструктуры продуктивной сети
- Документирование процедуры восстановления после сбоев
Резервное копирование
Проводите резервное копирование ПЕРЕД обновлением системы
Перед установкой обновлений приложений и операционной системы, переходом на новые версии программного обеспечения, модернизацией оборудования и проведением других значительных изменений в системе, целесообразно выполнить резервное копирование, так как, если обновление пройдет не успешно и система войдет в некорректное состояние, то у администратора будет возможность откатить изменения и вернуться к стабильному состоянию с наименьшими потерями для бизнеса (с точки зрения RPO).
Предположим следующий сценарий:
- Плановый бэкап проходит в ночь со вторника на среду
- До среды система используется в режиме «как обычно»
- Вечером в среду система обновляется (устанавливается новая версия системного программного обеспечения). В виду того, что перед установкой release notes были прочитаны не достаточной внимательно, система входит в нестабильное состояние.
- Система переустановлена с потерей данных на момент своего состояния во вторник
- В четверг пользователи вынуждены пересоздать все данные, созданные за среду
Хотя этот пример может показаться несколько утрированным, тем не менее, законы Мэрфи действуют в полной мере и в информационных технологиях. Поэтому все же не стоит пренебрегать созданием «лишней» инкрементальной резервной копии перед обновлением системы. Если же компания не может себе позволить «терять время» на «профилактическое» резервной копирование, то стоит задуматься над применением отказоустойчивого кластера, автоматических аппаратных снапшотов СХД, или других способов обеспечения постоянной доступности системы без ущерба для надежности ее данных.
Проводите ПОЛНОЕ резервное копирование сразу после существенного обновления системы
Пример:
- Полная резервная копия создается по пятницам, в остальные дни создаются инкрементальные копии
- В среду было произведено обновление сервера базы данных до новой версии, которое сопровождалось обновлением некоторых общих системных файлов, относящихся к операционной системе
- В ночь на четверг была, как обычно, получена инкрементальная резервная копия
- В четверг утром произошел критический сбой, потребовавший восстановления системы
- Изучив характер сбоя, администратор понимает, что повреждены только системные файлы и для восстановления функционирования системы достаточно было бы восстановить только множество системных фалов (system state), используя последнюю полную резервную копию. Однако, если сделать только это, то обновленная версия сервера базы данных перестанет работать, так как ей требуются более новые версии системных файлов (например, последняя версия .NET Framework), которые были установлены вместе с ним. Это приводит к необходимости продолжать процесс восстановления, просматривая необходимые инкрементальные копии, которые содержат изменения в system state. Это ведет, в конечном счете, к увеличению трудоемкости процесса восстановления и увеличению времени RTO, вплоть до нарушения SLA.
Общую рекомендацию можно сформулировать следующим образом: если кумулятивный объем инкрементальных резервных копий превосходит объем полной резервной копии, рационально сделать внеплановую полную резервную копию.
Проводите полное резервное копирование СРАЗУ после восстановления системы
По сути, это разновидность предыдущего пункта. Восстановление системы после сбоя — трудоемкий процесс, часто требующий значительного времени (за счет необходимости применения инкрементальных резервных копий, различных патчей, не вошедших в резервные копии и т.п.). В ряде случаев пользователи сразу приступают к работе в системе, как только ее базовая функциональность восстановлена и тем самым начинают менять ее состояние. Кроме того, нельзя исключать повторного сбоя через короткий промежуток времени после первого. Поэтому разумно сразу после восстановления зафиксировать в полной резервной копии новое актуальной состояние системы.
«Не гонитесь за двумя зайцами» или «Модернизация — зло»
Не стоит совмещать процесс восстановления системы после сбоев и процесс ее модернизации. Несмотря на то, что это может показаться очевидным, дефицит времени на технологические процедуры во время непрерывного производственного функционирования системы, а также нежелание вносить (даже необходимые) изменения в «то, что и так нормально работает», может вызвать желание использовать момент вынужденного простоя системы во время сбоя для того, чтобы выполнить модернизацию, так сказать «за одно».
Рассмотрим несколько примеров, что из этого может получиться:
- Система удачно восстановлена после сбоя, но администратор принимает решение сразу установить самые последние обновления на систему, чтобы потом не прерывать работу пользователей для этих целей. Однако один из патчей некорректно устанавливается, и система рушится. В результате систему опять приходится восстанавливать с нуля.
- Произошел критический сбой сервера приложения версии X.1. Система не была затронута сбоем. Администратор решил в процессе восстановления установить новую версию X.2 с установочного диска и восстановить из резервной копии данные приложения и дополнительные программные модули, реализующие специфичную бизнес логику. Однако после восстановления данных и модулей выяснилось, что они не совместимы с новой версией X.2 из-за небольших изменений в логике работы некоторых программных функций и в спецификациях некоторых программных интерфейсов. В результате сервер приложений пришлось восстанавливать сервер приложений версии X.1.
- Произошел критический сбой операционной системы версии X. Пользователь не нашел установочный диск версии X (так как эта версия была установлена 3 года назад) и установил версию X+1. У администратора возникла проблема с учетом лицензий, кроме того, одно используемое для работы бизнес приложение оказалось не совместимо с новой версией операционной системы. Систему пришлось переустанавливать.
Как следствие можно рекомендовать установление политики по процедуре восстановления после сбоев, в рамках которой никакие действия по модернизации не будут рассматриваться как допустимые. Целью процедуры восстановления является исключительно восстановление работоспособности исходной системы за минимальное время (RTO). Мероприятия по модернизации системы должны проводится отдельно в специально запланированное время, и сопровождаться процедурами предварительного тестирования обновлений, запланированных для установки.
Обо всем понемногу
Читайте документацию ПЕРЕД тем как настроить резервное копирование
В процедуре резервного копирования и восстановления приложений могут быть различные нюансы, которые необходимо учесть и которые не всегда очевидны. Эти нюансы обычно можно узнать только из документации приложения, однако, как это часто бывает, документация не прочитывается своевременно (или не прочитывается вовсе).
Пример «нюансов» такого рода:
- В процессе резервного копирования не сохраняются различные пароли и информация о лицензии. А это означает, что при восстановлении не удастся получить работоспособное приложение или операционную систему, а план восстановления после сбоев в части декларированного RTO окажется сорванным.
- Системная конфигурация приложения должна сохраняться по специальной процедуре, отдельной от процедуры бэкапа самих данных
- Процедура бэкапа открытых на запись файлов является специальным образом оговоренной в документации (требуется заранее включить определенные настройки в конфигурации приложения).
Процесс восстановления должен производится администраторами
Восстановление системы в компании в общем случае может проводиться администраторами сети, специалистами HelpDesk, и самими пользователями. Последний вариант я рассматривать не буду как характерный лишь для маленьких компаний или для ИТ отрасли. Что же касается специалистов HelpDesk, то обычно они могут решить часто встречающиеся проблемы базового уровня, в том числе восстановление отдельных файлов. Но, если говорить о восстановление системы в целом, то лучше поручить такую задачу человеку с административными полномочиями:
- Восстановление может затрагивать задачу включения рабочей станции в домен, а на это нужны полномочия администратора домена
- Восстановление системы с нуля может потребовать решения проблем (например, с драйверами для RAID), выходящими за рамки компетенции персонала HelpDesk. Кроме того, более высокая квалификация администраторов позволяет им правильнее приоритизировать выдаваемые системой ошибки, возникающие при восстановлении, откладывая на более поздний срок решение проблем, непосредственно не мешающих задаче скорейшего восстановления работы продуктивной сети.
- Могут возникнуть иные проблемы, требующие административных полномочий (пароли на сетевые ресурсы, недоступность сети в целом, проблемы активации из-за настроек корпоративного файервола и т.д.)
Тестирование восстановления должно проводиться регулярно
Само наличие резервных копий еще не означает, что восстановление пройдет без проблем. Во-первых данные могут быть неверно сохранены, во-вторых, данные при хранении могут со временем исказиться, или при восстановлении вдруг выяснится, что в резервной копии были сохранены не все необходимые данные. Подробнее об этом было уже написано в посте: Тестирование восстановления из резервных копий.
Учитывайте зависимости от инфраструктурных компонентов сети
Предположим, что сбой произошел на DNS сервере. После запуска процедуры восстановления оказалось, что используемый продукт резервного копирования использует DNS в рамках работы с собственной инфраструктурой (например, соединяется с репозиторием резервных копий, используя FQDN имя сервера). В результате получается «циркулярная зависимость», не позволяющая автоматически выполнить восстановление после сбоя. Аналогичная ситуация может наблюдаться с контролером домена (но здесь спасает то, что контролеров домена обычно в компании несколько).
Таких циркулярных зависимостей следует стараться избегать. Выявлять их позволяет тестирование восстановления резервных копий в изолированную от продуктивной сети песочницу, например, с помощью технологии Veeam SureBackup.
Документирование процедур стадии восстановления
Аккуратно документируйте процедуру восстановления после сбоев
Нужно избегать двух вещей:
- Не нужно полагаться целиком и полностью на продукт резервного копирования (в том смысле, что он «если что — восстановит все сам — установил и забыл»). Всегда могут быть такие параметры конфигурации системы (например, статус активации операционной системы, информация о лицензии, или сохраненные учетные записи с паролями к сетевым ресурсам), которые не будут сохранены в резервной копии, или будут приложением намеренно (в рамках защиты от копирования) признаны недействительными при восстановлении (например статус активации). Практически это означает, что всегда нужно иметь под рукой документ по финальному восстановлению работоспособности приложений на случай, если продукт резервного копирования не сможет восстановить все полностью автоматически.
- Не нужно полагаться на предположение, что любой продукт резервного копирования будет полностью совместим с любой инфраструктурой в мире. Нужно проверить, что продукт совместим с имеющейся аппаратурой и нормально работает в условиях функционирования специфических режимов (например, при выполнении LUN rebinding на SAN или при перестроении тома на RAID-5 массиве). Особые случае поведения продукта и методов обеспечения совместимости подлежат документированию.
Примеры рекомендуемой к созданию документации для случая восстановления после сбоя:
- Регулярный автоматизированный дамп конфигурационных настроек, выполняемый, например, с помощью программных продуктов, позволяющих осуществлять версионный контроль настроек и/или контролировать их целостность. Управление версиями конфигураций приложений в принципе является полезным дополнением к системе резервного копирования, так как в ряде случаев позволяет снизить RTO. В отличие от продуктов резервного копирования, продукты контроля версий конфигураций, позволяют не просто сохранить любое изменение в настройках, но (1) согласовывать такие изменения (2) помечать некое устойчивое состояние конфигурации специальными тэгами.
- Лицензионные ключи, которые могут потребоваться для повторного ввода после того, как приложения будут восстановленф
- Пароли, которые будут нужны на случай восстановления системы, должны быть записаны на листе восстановления в бумажном или электронном виде и храниться в месте ограниченного доступа, в соответствии с политиками безопасности. Это нужно, как минимум, для случая, когда восстановление системы будет производиться другим администратором (например, если первый администратор в отпуске).
- Перечисленная выше информация для восстановления должна, в свою очередь, подлежать резервному копированию, в том числе, при необходимости, с копированием в другой офис компании. Эта информация быть максимально надежно защищена от возможного действия вирусов и шпионского программного обеспечения во всех точках хранения.
Что тестировать в рамках проверки процедуры восстановления после сбоев?
Для того, чтобы инструкции, применяемые в процессе восстановления после сбоев, были максимально корректны, нужно проводить «учебные восстановления». В процессе проведения тестирования процесса восстановления нужно обратить внимание по крайней мере на такие вопросы как:
- В случае полного разрушения сайта, будут ли резервные копии содержать всю информацию, необходимую для его восстановления?
- Как будет проходить процесс восстановления, если главный системный администратор будет недоступен (скажем, будет находится в заграничном отпуске)?
- Что произойдет, если окажется поврежденным носитель информации (лента/диск), на котором размещена резервная копия, наиболее подходящая для использования в процессе восстановления?
- Что будет в случае т.н. «вторичного сбоя»? То есть, в случае, когда после успешного завершения процесса восстановления, окажется, что восстановленная система не работает?
- Укладывается ли время, затраченное на процесс восстановления, в оговоренный SLA? Знают ли вовлеченные в процесс люди о существовании SLA и его параметрах, и принимают ли его во внимание в своей работе?
- Как скажется на процесс восстановления отказ инфраструктурных компонентов продуктивной сети (почтовый сервер, сервер мгновенных сообщений, DNS, контролер домена и т.д.)
- Качество документации: cможет ли нетренированный администратор восстановить продуктивную систему, следуя письменным инструкциям?
- Скорость реакции компании, если причиной разрушения информации стал вирус (любого типа). Специфичность этой угрозы в том, что вирус может исказить данные и приложения, не нарушив при этом их доступность,- в результате чего системы обеспечения отказоустойчивости не зафиксируют сбой, кроме того, настроенные механизмы репликации изменений данных автоматически разнесут эти искажения по остальным репликационным партнерам (или узлам кластера/геокластера).
- Зависит ли процесс восстановления от специфичной аппаратуры (которая может выйти из строя в момент восстановления)?
- Можно ли провести процесс восстановления полностью удаленно?
- Что будет, если будет нарушена работа канала, связывающего бэкап-сайты компании?
Разумеется при составлении списка угроз работоспособности продуктивной системы, нужно учитывать также вероятность возникновения этих угроз, и сравнивать с потенциальным ущербом от простоя системы в каждом случае.
Общий вывод
Планирование и тестирование резервного копирования и восстановления является важнейшим фактором, позволяющим минимизировать RTO и выполнить условия SLA. Наличие в продукте резервного копирования функционала в части автоматизации тестирования восстановления из резервных копий является крайне важным.
Дополнительно о тестировании резервных копий и о патентованной технологии Veeam SureBackup, можно почитать здесь:
- Описание на сайте Veeam: Технология Veeam vPower для VMware
- Вебинар: Modern Data Protection for Virtualised Environment
- Пост "SureBackup – автоматическая проверка возможности восстановления данных из резервной копии"
- Пост "Тестирование восстановления данных из резервных копий"
Автор: sysmetic
