Rambler's Top100
Статьи
Андрей КОМИССАРЕНКО  29 июня 2021

«Делай бэкап!»: правила резервирования данных

Вопросы хранения информации вряд ли возглавляют список приоритетов топ-менеджмента компании. Тем не менее они играют критически важную роль для существования и развития компании. 

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

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

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

Бэкап как привычка

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

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

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

Базовые правила: «2 лучше, чем 1» и «3-2-1»

Не думайте, что одной копии на внешнем HD, сетевом файловом NAS-хранилище или даже в облачном ресурсе будет достаточно. Сбои возможны всегда и везде, и происходят они в самый неподходящий момент. 

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

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

Надежнее всего соблюдать известное правило «3-2-1»: для обеспечения надежного хранения данных необходимо иметь как минимум три резервные копии, которые должны быть сохранены в двух различных физических форматах хранения, причем одна из копий должна быть передана на хранение в другую локацию.

Тестируйте резервные копии

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

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

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

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

Используйте правильные технологии для конкретных задач

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

В одном случае быстрее настроить бэкап виртуальной машины целиком, чем отдельного приложения; в другом – настроить бэкап базы данных, используя ПО, способное взаимодействовать с СУБД. 

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

Если внутри ВМ работает трудно настраиваемое приложение, будет удобнее выполнять бэкап такой ВМ целиком, чтобы в случае необходимости быстро восстановить сервис. Также в этом случае важно проверять, что восстановленная ВМ работает корректно.

Disaster Recovery как гарантия 100%  

Если вы задумывались о плане аварийного восстановления (Disaster Recovery), то все они в современном исполнении предусматривают копирование и хранение данных за пределами компании – в другом офисе или в облаке сервис-провайдера.

Один из вариантов – Disaster Recovery as a Service (DRaaS), или аварийное восстановление ИТ-систем как услуга. Он заключается в создании копии физических или виртуальных серверов на сторонней площадке, предоставляемой провайдером сервиса, для минимизации потерь бизнеса в случае отказа инфраструктуры при техногенной катастрофе или стихийном бедствии. 

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

Современные DRaaS-решения могут предложить полную репликацию сложного и масштабного ИТ-сервиса в течение 15 минут. Для бизнеса это может иметь неоценимое значение, перекрывающее все организационные и финансовые затраты на развертывание решения. 

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

Типичные ошибки бэкапа

Чаще всего при резервировании данных допускаются следующие ошибки и просчеты: 
  1. Чрезмерно сложная логика периодичности выполнения и/или длительности хранения бэкапов. Часто в подобных случаях используется ручное вмешательство в работу ПО. Сотрудники пытаются вручную реализовать функционал, который по той или иной причине недоступен в ПО, что приводит к непредсказуемым результатам.
  2. Неразумная экономия на оборудовании. Компания хранит важный бэкап на недорогих «дисковых полках», но однажды хранилище дает сбой, и данные теряются. Еще хуже, если бэкапы хранятся в той же системе, что и продуктивная среда.
  3. Неоптимальный выбор способа резервного копирования, когда настройка бэкапа становится слишком долгой и/или трудной. Например, иногда проще бэкапить ВМ целиком, чем тщательно отбирать файлы внутри каждой отдельной ВМ.
  4. Слишком длинная цепочка инкрементальных бэкапов, что повышает вероятность потери данных, если какое-то «звено» в середине окажется поврежденным.
  5. Отсутствие проверки бэкапов. Мало сделать бэкап, нужно проверить, как он работает. Иногда стоит потратить время на ручную проверку, чтобы точно знать на будущее, что и как придется сделать для качественного восстановления.
  6. Дисбаланс между объемом хранимых данных и скоростью восстановления. Например, можно записать очень много бэкапов ВМ на системе с функцией дедупликации (deduplication appliance, например, Dell EMC Data Domain), но скорость восстановления из нее будет невысокой. Быстро достать ВМ для восстановления из такого бэкапа не получится. 
К сожалению, не всегда ошибки бэкапа можно исправить. Если потерян единственный бэкап, и продуктивная система из-за этого невосстановима – у компании большие проблемы.

Как правило, производители ПО для бэкапа объясняют ключевые моменты даже в руководстве пользователя. Стоит воспользоваться этими пояснениями, чтобы предотвратить фатальные ошибки.

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

Основные рекомендации:
  • Используйте руководство к вашему ПО для резервного копирования и не пренебрегайте правилами «2 лучше, чем 1» и «3-2-1».
  • Проверяйте работоспособность бэкапов.
  • Не создавайте сложных схем резервного копирования, в которых сами же можете запутаться. А если все-таки их создаете, то тщательно документируйте все шаги.
  • Проверяйте работоспособность компонентов системы резервного копирования, вовремя устанавливайте обновления.
  • Не пренебрегайте услугами поддержки, простое на вид ПО для бэкапа может оказаться довольно сложным.
  • Используйте DRaaS для резервирования критически важных ИТ-систем. 
Андрей Комиссаренко, инженер по облачным технологиям, Linxdatacenter
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!