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

07 ноября 2014 г. | Стивен Бигалоу | Категория: Обсуждаем статью

Раньше вся информация создавалась – и защищалась – равным образом. В современном дата-центре постоянно меняющиеся ряды виртуальных машин (ВМ) и номеров логических устройств (LUN) требуют новых инструментов резервного копирования.

Информация – это кровь современного бизнеса. Если ее не защищать, вы потеряете не только информацию, но также деньги и репутацию.

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

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

Потеряны, но не забыты

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

Вы можете потерять данные и тогда, когда приложение переносится на новый сервер без соответствующего обновления инструмента резервного копирования. Инструмент все еще считает, что нагрузка осталась на старом сервере, и продолжает выполнять соответствующую программу резервирования на нем. Большинство инструментов, впрочем, сообщают об ошибке, когда IT-персонал забывает изменить конфигурацию, и за вами остается принять срочные меры для исправления ситуации.

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

Заплутавшие в облаке

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

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

Концепция разделения рабочих нагрузок на уровни усугубляет проблему потери данных. Традиционно IT-специалисты применяли одинаковую стратегию резервного копирования данных ко всем приложениям и директориям равным образом. А теперь IT-планировщики начали варьировать ресурсы защиты данных в зависимости от важности конкретной рабочей нагрузки. Критически важные нагрузки, например, копируются часто, в то время как неприоритетные ВМ требуют копирования лишь время от времени. Такая разбивка по приоритетам с одной стороны, оптимизирует эффективность резервирования и использование места, однако вместе с тем это усложняет график копирования, тем самым провоцируя упущения.

Предотвратить и преодолеть потерю данных

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

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

Некоторые инструменты переводят защиту данных в автоматически режим на этапе создания LUN или ВМ. Они также могут реагировать на миграцию рабочей нагрузки без прямого административного вмешательства. Автоматизация особенно благотворно скажется в средах, которые поддерживают функции самостоятельной работы конечных пользователей и иных видов самообслуживания.

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

Стефан Биглоу (Stephen J.Bigelow),
редактор отдела технологий портала  http://searchdatacenter.techtarget.com