Андрей Комиссаренко
Инженер по облачным технологиям, Linxdatacenter
29.06.2021

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

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

Андрей Комиссаренко,

инженер по облачным технологиям, Linxdatacenter

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

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

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

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

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

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

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

Базовые правила: «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 для резервирования критически важных ИТ-систем.

News and publications

You may also be interested in

How can we help you?
Request Demo Access
client:

BEST, money transfer and payments operator

business challenge

The customer faced a technical issue with a persistent BGP session flag with Linxdatacenter hardware. We examined the problem and found out that one of customer’s hosts was under a DDoS attack.

Because of the distributed nature of the attack, traffic couldn’t be filtered effectively, and disconnecting the host from the external network wasn’t an option. The attack stopped after changes in the server configuration, but resumed the day after. A 5.5 Gbps attack overloaded the junctions with internet providers, affecting other Linx Cloud users. To mitigate the effects of the attack, we employed a dedicated DDoS protection service.

Solution

To ensure the continuous availability of resources hosted in Linx Cloud, we rerouted all the customer’s traffic through StormWall Anti-DDoS system. The attack was stopped within half an hour. To prevent future cyberattacks, we organized all connections to the customer’s resources through the StormWall network.

Thank you for your inquiry, we will get back to you shortly!