Как правильно создавать резервные копии критически важных данных

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

1. Введение
2. Зачем бэкапить данные?
3. Как выбрать хранилище?
4. Слабые места при построении и эксплуатации системы резервного копирования
5. Алгоритм построения системы резервного копирования
6. Выводы

Введение

Для каждой компании данные — это наиболее ценный актив, потеря которого может произойти по множеству причин. Например, это могут быть человеческий фактор (случайное или намеренное удаление), шифрование вирусами-вымогателями, поломки жёстких дисков, стихийные бедствия, аварии на площадке организации (ЦОД) или же недоступность площадки целиком, в том числе если она находится в другой стране. При этом сами данные могут быть где угодно: «в облаках» или «на земле». Их месторасположение не гарантирует защиты от случайного удаления или ото всех возможных факторов их потери.

Зачем бэкапить данные?

Если не делать резервное копирование или делать его несвоевременно, то основной риск заключается в полной потере данных или их недоступности для сотрудников на неопределённый срок. Так, если говорить о данных, размещённых в облаке, то поставщики облачных решений предоставляют функциональность ПО и гарантируют работоспособность и безопасность платформы, но не самих данных (за редкими исключениями). Следовательно, любая информация может быть случайно или намеренно удалена. Также стоит учитывать, что некоторые провайдеры предоставляют ограниченный срок хранения данных, поэтому рекомендуется заранее проверять соответствующую политику поставщика облачных решений.

Даже если компания пользуется услугами облачного провайдера, ей всё равно необходимо самостоятельно проводить резервное копирование. Один из вариантов — сервис BaaS (Backup-as-a-Service). В некоторых случаях такое решение может иметь ограниченную функциональность — резервное копирование только в облако того же провайдера, который эту услугу предоставляет, или же с недостаточной гранулярностью резервной копии.

В любом случае, даже при использовании услуги BaaS рекомендуется параллельно делать резервное копирование и на локальной площадке (ЦОД) для прямого и оперативного доступа к копиям защищаемых данных. Локальный бэкап — это гарантия сохранности данных от физического отказа оборудования и более оперативное их восстановление.

Как выбрать хранилище?

«3-2-1» — модель резервного копирования, которая объясняет преимущества трёх копий данных или приложений. Две копии расположены локально, на одной площадке, но на разных носителях, а третья — отдельно ото двух предыдущих, например, в облаке. Соответственно, если с первым хранилищем что-то произошло, то данные остаются в соседней стойке в ЦОДе. Если же потерян доступ к ЦОДу целиком, то остаётся резервная копия в облаке. При таком сценарии можно говорить о гарантированной сохранности критически важных данных.

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

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

Хранение данных при бэкапе в облако на территории РФ обеспечивает защиту от отказа целой площадки. Так, сегодня есть риск недоступности ЦОДа целиком, в том числе расположенного в другой стране. Именно поэтому важно, чтобы резервные копии располагались отдельно от иностранной площадки. При выборе провайдера облачных услуг важно, чтобы он не только соблюдал соглашение об уровне предоставляемых услуг, но и был партнёром, заинтересованным в результате.

Слабые места при построении и эксплуатации системы резервного копирования

Есть два основополагающих показателя резервного копирования: RTO (Recovery Time Objective) и RPO (Recovery Point Objective), которые необходимо учитывать в регламенте и построении системы резервного копирования. Показатель RPO характеризует максимальное время, данные за которое компания готова потерять. Это означает, что в случае происшествия будут утеряны данные наработанные не позже выбранного периода. Соответственно, именно с такой частотой производится бэкап. Второй показатель — RTO, время, на которое данные или иная информационная система окажутся недоступны. Так, после происшествия данным, приложению, виртуальной машине необходимо восстановление. RTO — это время на такой процесс. В зависимости от категории данных по степени их важности для бизнеса и от стоимости их восстановления, будь то виртуальная машина, приложение или массив данных, параметры RTO и RPO рассчитываются индивидуально в разрезе каждого сервиса.

Наиболее часто допускаемая ошибка при эксплуатации системы резервного копирования — несвоевременное обновление её регламентов и задач. Так, по мере развития ИТ-инфраструктуры компании растёт количество внутренних сервисов, данных, приложений и т. д. Но не всегда меняются регламенты резервного копирования, которые были написаны единожды энное количество лет назад. Например, нет обновления информации по ключевым показателям, учитывающим развитие ИТ-инфраструктуры. В этом случае возникают риски потери данных или недопустимого времени простоя критической информационной системы.

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

Алгоритм построения системы резервного копирования

1. Аналитика. На данном этапе рекомендуется провести анализ текущей инфраструктуры, а также определить, какие сервисы необходимо бэкапить. Желательно также выстроить зависимости для информационных систем, которые будут подлежать резервному копированию. Далее — установить требования к RTO и RPO, оценить окно бэкапа (время, за которое будет производиться резервное копирование).
2. Оформление результатов. На данном этапе уже должны быть полная аналитика по каждой информационной системе (ИС) и требования к ней. Оптимально, если результаты оформлены в виде таблицы. На их основе разрабатывается стратегия резервного копирования.
3. Выбор вендора, на решении которого будет строиться система резервного копирования. После формирования полной картины ИС, подлежащих резервному копированию, рекомендуется определить функциональность будущей системы. Она должна соответствовать требованиям, сформированным на предыдущих этапах, и разработанной стратегии.
4. Определение требований к аппаратному обеспечению. После описания стратегии формируются требования к аппаратной части: СХД, ленточным библиотекам, серверам и другим элементам инфраструктуры. Они формируются на основе составленного списка информационных систем, подлежащих бэкапу, времени и места хранения, а также количества резервных копий и их типа.
5. Развёртывание системы резервного копирования. Когда все элементы включены в инфраструктуру, установлено программное обеспечение системы бэкапа, созданы политики и задания, начинаются само резервное копирование и устранение выявленных неполадок при наличии таковых. Этот этап должен убедить компанию в работоспособности процессов резервного копирования, их верной настройке и соответствии регламенту, после чего понадобится распространить разработанную политику на все объекты, подлежащие бэкапу. Не стоит забывать, что по мере роста инфраструктуры система резервного копирования также должна пропорционально расти.

Выводы

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

При построении системы резервного копирования стоит учитывать два показателя: RTO и RPO, которые рассчитываются индивидуально в зависимости от категории данных по их важности для бизнеса и от стоимости их восстановления. Также рекомендуется не забывать о своевременном обновлении регламентов и тестировании системы.

Алгоритм построения системы резервного копирования состоит из пяти пунктов: анализ инфраструктуры, оформление результатов аудита, выбор вендора, формирование требований к аппаратному обеспечению и собственно развёртывание системы.