В День Конца Света уместно вспомнить какой должна быть политика резервного копирования и восстановления данных после сбоев и катастроф.
Когда происходят значительные катаклизмы, подобные урагану Sandy и наводнению в Нью-Йорке, компании вспоминают про свою «страховку»: была ли резервная копия, не утеряна ли она вместе с оригинальными данными, можно ли из нее восстановить приложения и данные, была ли покрыта процессом резервного копирования вся продуктивная система или только ее часть, и сколько времени займет восстановление?
Ответы на эти вопросы могут быть разными в зависимости от того как компания изначально относилась к своей «страховке»: хорошо ли был продуман и профинансирован проект по защите данных, был ли процесс резервного копирования вписан в комплексный план обеспечения непрерывности бизнеса или же был «осколком» неполной мозаики.
Некоторые компании не уделяют достаточного внимания моделированию угроз для данных и приложений в своей инфраструктуре, не тестируют резервные копии, не проверяют возможность восстановить систему с соблюдением SLA на время восстановления (RTO).
Зачастую компании малого и среднего бизнеса (SMB) не имеют достаточно надежного плана по обеспечению отказоустойчивости своих систем., Одни считают это слишком сложным и затратным для себя. У других просто «нет времени», чтобы думать о надежности хранения своих данных. Третьи верят, что ничего плохого с данными случиться не может.
И даже, если в компании оказывается установлен продукт резервного копирования, зачастую никто не тестирует резервные копии, чтобы проверить, можно ли выполнить восстановление системы из них, если произойдет сбой.
Сейчас на рынке присутствует большое количество решений для резервного копирования с различной функциональностью и ценой, и проблема SMB-компаний заключается в том, чтобы выработать для себя рациональную стратегию защиты данных и найти продукт, который был бы простым, производительным и разумным по цене. Необходимость где-то разместить данные репозитория резервных копий добавляет еще и проблему выбора подходящих аппаратных систем хранения данных.
Так что же можно посоветовать при разработке стратегии резервного копирования?
Резервное копирование Диск-Диск, с поблочным копированием изменений
Обычно операция резервного копирования Диск-Диск (D2D) выполняется быстрее, а операция восстановления данных — значительно быстрее, чем операция Диск-Лента. Резервное копирование на уровне блоков работает намного быстрее, чем на уровне файлов, так как изменения отслеживаются на уровне порций данных значительно меньшего размера. В результате сокращается окно резервного копирования. Если компании требуется соответствовать каким-либо законодательным требованиям, в силу которых требуется долговременное хранение, разумно комбинировать подходы Диск-Диск (D2D) и Диск-Лента (D2T) и использовать конфигурацию Диск-Диск-Лента (D2D2T), выполняя хранение резервных копий в пределах (скажем) 30 дней на дисковом хранилище, а долговременное хранение — на ленте (так как удельная стоимость хранения на ленте не имеет себе равных до сих пор, несмотря на снижение удельной стоимости хранения на дисковых хранилищах данных). Дополнительно о преимуществах этого подхода можно почитать в этом и в этом посте.
Дедупликация резервных копий
Дедупликация — это процесс исключения повторяющихся блоков из данных резервных копий. В среде виртуализации дедупликация оказывается особенно эффективной потому, что многие виртуальные машины создаются по одному шаблону и содержат идентичный набор программного обеспечения. Подробнее о дедупликации резервных копий можно почитать здесь.
Если используете виртуализацию — используйте специализированные бэкап-продукты
Есть «старые» бэкап-продукты, созданные еще для бэкапа физических машин. Они устанавливают специальные программы-агенты внутрь машин, и осуществляют копирование данных, находясь внутри, делая это, обычно, на уровне файлов соответствующей операционной системы. Есть «новые» продукты, созданные специально для систем виртуализации, и использующие новые технологические возможности виртуальных сред. Они не требуют агентов, меньше нагружают сервер виртуализации и работают на значительно быстрее за счет иcпользования новых технологий, таких как vStorage API. Подробнее об преимуществах использования специализированных бэкап-продуктов можно почитать здесь.
Репликация, или бэкап-по-расписанию с минимальным периодом
Как долго новые или модифицированные данные продуктивной системы могут быть не зарезервированы? Этот период времени называется RPO. И современные продукты резервного копирования достигли хорошего прогресса в деле минимизации RPO, доходящего до 15 минут. Применение же репликации вообще позволяет получить режим, близкий к постоянному непрерывному резервированию данных (near-CDP).
Резервное копирование по принципу «копировать все, за исключением...»
Стратегия копирования только выборочных данных пользователя «ничего не копировать, за исключением явно включенных объектов» может привести к тому, что важные данные пользователя будут зарезервированы не полностью. Например, это может произойти тогда, когда пользователь попросил включить в план резервного копирования свой рабочий каталог, а потом создал другие рабочие каталоги вне поддерева первого каталога. Тоже самое может произойти, когда пользователь установит новую программу, которая будет сохранять рабочие файлы пользователя в каталог, который не был сконфигурирован как подлежащий резервному копированию. Или в новой версии программы поменяется каталог хранения рабочих файлов пользователя на такое расположение, которое, опять же, не бэкапится…
Быстрое восстановление данных
Сбои возникают не только в силу причин катастроф или сбоев электропитания и оборудования. До трети случаев приходится на человеческие ошибки (например случайное удаление файла). По этой причине часто необходимо восстанавливать не весь сервер или сегмент сети целиком, а только индивидуальный файл или объект приложения. Нужно использовать бэкап-продукты, поддерживающие гранулярное восстановление данных. Это значительно сокращает время восстановления и упрощает весь процесс для администратора. Подробнее о гранулярном восстановлении можно посмотреть здесь.
Внеофисное хранение резервных копий
Резервные копии данных разумно хранить отдельно (и, по возможности, как можно дальше) от оригинальных данных, так как существует вероятность, что событие, приведшее к сбою, может уничтожить как оригинальные данные так и их копии. Существует два наиболее распространенных варианта клонирования резервной копии, полученной после копирования Диск-Диск:
- хранение дополнительных копий на лентах (которые можно отвезти в другой офис, или в банковскую ячейку) — эта схема называется D2D2T и наиболее распространена в настоящий момент,
- дублирование копий в облако (Cloud), например, в Amazon.
Кроме того, можно пойти по пути создания сайта горячего восстановления — то есть создания клона инфраструктуры в другом офисе и постоянно реплицировать данные и конфигурации приложений между офисами. В случае сбоя, пользователи переключаются на резервный сайт.
Виртуализация критичных приложений (или их резервных кластерных узлов)
Здесь хотелось бы просто отметить, что применение виртуализации само по себе позволяет облегчить процесс восстановления после сбоев, поскольку она изолирует виртуальные машины от конкретного оборудования. Виртуальная машина может быть запущена на сервере виртуализации с любым оборудованием, не обязательно совпадающим с тем, на котором она исполнялась до сбоя. Многие системы виртуализации имеют функциональные возможности по перемещению виртуальной машины между хостами, в случае сбоя, а также функционал отказоустойчивости и кластеризации.
Тестирование резервных копий
Следует регулярно проводить тестирование восстановления данных, а не простое тестирование целостности резервных копий. То есть проверять работоспособность восстановленных систем и наличие в них корректных данных, а не просто проверять контрольные суммы блоков данных файлов резервных копий. В случае, когда продуктивная сеть находится в виртуальной среде, продукты резервного копирования, созданные специально для виртуальной среды, позволяют сделать процесс проверки данных автоматизированным и прозрачным для администратора, так как они позволяют создавать виртуальные тестовые лаборатории-«песочницы», изолированные от продуктивной сети. Подробнее об этом можно посмотреть в этом посте. О технологии SureBackup можно почитать здесь.
Информационная безопасность резервных копий
Исходные данные обычно защищены правами доступа. После переноса этих данных в резервные копии нужно гарантировать, что к ним будет получен только авторизованный доступ. Вариантов несколько: например, можно зашифровать резервные копии, можно сделать их недоступными для не авторизованных сетевых пользователей, или вообще исключить доступ к ним сетевой доступ из сегмента сети, где работают обычные пользователи сети (администраторы могут подключаться из другого сегмента сети).
Почему в случае применения виртуализации резервное копирование на уровне хоста снижает риски информационной безопасности можно посмотреть в этом посте.
***
Дополнительные материалы по стратегии резервного копирования в виртуальной среде
:
- Сайт Backup Academy (англ. яз)
- Экспертная статья о резервном копировании сетей с сотнями виртуальных машин
- Статья «Резервное копирование и восстановление для Microsoft Hyper-V»
- Статья о резервном копировании виртуальных машин в сетях с NAS (англ. яз)
Автор: sysmetic
