Бэкап-методичка: как устроено современное резервирование данных

Организация процесса резервного копирования и восстановления – одна из главных задач ИТ-специалистов любой компании. Как устроены системы резервного копирования, и какие сценарии их использования оптимально подходят для бизнеса любого размера – в материале Тимура Бадретдинова, руководителя направления инфраструктурных решений и услуг компании «Системный софт».

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

Резервирование данных компании сегодня можно осуществлять разными средствами, в том числе с помощью инструментов, встроенных в популярные программные-продукты Microsoft: Windows Server и SQL Server. Такой путь не потребует серьезных финансовых вливаний, но на настройку и обслуживание будет тратиться очень много времени ИТ-администратора. Его главная проблема в том, что в случае сбоя восстановление займет непредсказуемое количество времени, поскольку ручные операции - это всегда долго: поиск информации, проверка на безопасность, сравнение файлов. Поэтому сегодня ИТ-специалисты сходятся в понимании того, что система резервного копирования (СРК) в современной ИТ-архитектуре должна быть исполнена исключительно в формате отдельного продукта.

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

Выход? Использовать облачные сервисы российских или международных провайдеров для хранения и восстановления из бэкапов.

Starter pack

Первый вариант резервного копирования в облаке – соответствие  модели «3-2-1», где последняя цифра – это копия, которая вынесена за пределы локальной инфраструктуры компании в облако. Стандартно – во внешний ЦОД, где данные компании хранятся отдельно от основной ИТ-инфраструктуры. И если происходит сбой и локальные бэкапы оказываются недоступны, всегда есть возможность  восстановиться из «третьих» копий. Либо с минимальными потерями данных, либо полностью их избежать.

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

Современные системы резервного копирования позволяют легко и недорого реализовывать указанный выше вариант. Проблемы возникнут, если у компании ПО для резервного копирования 3-5-летней давности, которое не поддерживает определенные протоколы или расширения, но это поправимо.

Своя СРК в публичном облаке

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

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

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

В отличие от первого варианта, здесь имеется определенная предсказуемость по срокам восстановления, а также возможность менять место установки СРК-софта: если не устраивает один провайдер облаков, то всегда можно перенести свою систему и данные к другому.

BaaS-комплекс

Третья модель, которая становится популярной в малом бизнесе – это Backup-as-a-Service – BaaS. В этом варианте арендуются не виртуальные мощности под развертывание сервиса и хранение данных, а комплексное решение, включая программное обеспечение СРК. Клиент указывает провайдеру объем данных для хранения, примерное количество виртуальных машин, физических серверов и рабочих станций, если они необходимы. В сочетании с исходящим трафиком эта комбинация обсчитывается в виде определенного алгоритма биллинга с помесячной оплатой пост-фактум (pay as you go). Стоимость услуги для клиента в месяц с учетом такой подписки существенно падает. Получаете качественное решение на отказоустойчивой ИТ-инфраструктуре с возможностью полного восстановления в любой момент.

Главное преимущество этого варианта — не нужно покупать лицензии на ПО СРК. Это классическая конверсия CapEx в OpEx. При этом есть нюанс: технически все устроено так, что BaaS-провайдер является глобальным администратором всех программных и аппаратных ресурсов, но за настройку функционала системы - что и как часто бэкапить - отвечает ИТ-специалист заказчика. Поэтому если вы хотите полностью отдать управление СРК в руки провайдера, вам нужно будет за это платить как за дополнительную услугу.

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

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

DRaaS как будущее

И четвертый вариант: так называемые DRaaS-сервисы – Disaster-recovery-as-a-service или катастрофоустойчивость как услуга.

В чем отличие DRaaS от предыдущих вариантов? Кроме наличия у клиента ПО СРК в собственности в публичном облаке, либо в аренде там же, у компании обязательно должны быть либо полноценно синхронизированные, либо преднастроенные для быстрого запуска виртуальные машины с теми данными, которые нужно восстановить. При этом в случае отключения света в офисе ваша СРК, размещенная в ЦОДе провайдера, будет продолжать работать, и вы сможете восстановиться на каких-либо ресурсах, соблюдая RTO.

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

Основной смысл DRaaS в том, чтобы выдерживать высоко-критичные показатели RTO и RPO, когда требуется либо мгновенное восстановление после сбоя основной площадки, либо данные или непрерывность работы приложения нельзя терять даже на мгновение. Такие требования к работе сегодня предъявляют финансовые организации: банки, страховые компании, биржевые площадки, биллинговые системы. Сегодня к этому очень чувствителен ритейл, интернет-магазины, транспортная и энергетическая сфера.

В DRaaS биллинг складывается из традиционных компонентов: объем используемого хранилища, количество виртуальных машин и исходящего трафика. Дублирующая облачная инфраструктура уже запущена, в нее с определенной периодичностью добавляются данные из основной системы. В момент сбоя идет автоматическое (либо ручное) переключение на эту вторую площадку. Переключение обычно делает либо система управления виртуализацией, либо отдельный софт — программа-оркестратор.

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

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

Смысл такого решения? В любой необходимый момент «спящие» ВМ можно быстро включить и запустить работу корпоративных сервисов компании, подгрузив в них все необходимые данные. Создается сценарий действий на случай аварийной ситуации с установленными показателями RTO, который отрабатывается в день X и время Y.

Важные детали

При продумывании бэкап-стратегии нужно помнить несколько принципиальных моментов:  

• Катастрофоустойчивость как способность поддерживать стопроцентную непрерывность работы ИТ-систем  – это минимум 2 площадки, разнесенные не менее чем на 90-100 километров. Если, условно, метеорит попадает в ЦОД с вашими бэкапами, вторая площадка продолжит работать. Позволить себе построить собственную вторую площадку могут лишь крупнейшие коммерческие компании и госкорпорации. СМБ-компании логично выбирают облачную модель DRaaS.

•  Приоритет vendor agnostic-решениям. Проблема привязки СРК-софта только к определенным производителям «железа» остается, такие вопросы необходимо уточнять как в случае развертывания решения локально, так и у провайдера ЦОД на случай масштабирования и т.д.

• Существует опция расширения локальных ресурсов через виртуализацию в публичном облаке – решения класса «гибридное облако». Они позволяют объединять управление виртуальными машинами on premise с виртуальными машинами в облаке провайдера через единую консоль. Если происходит сбой, можно настроить алгоритм восстановления так, чтобы необходимые ресурсы из облака могли автоматически запуститься.

• План резервного копирования и восстановления в каждой компании сильно будет зависеть от списка критичных сервисов и требованиям к RTO и RPO. Для РФ характерно использование 1С с базами данных Microsoft SQL Server, и недоступность этих систем может оказаться фатальной для бизнеса.

Например, если ПО СРК установлена внутри ИТ-инфраструктуры компании и бэкапы хранятся там же, то в случае успешной атаки вируса-шифровальщика восстанавливаться будет некуда и нечем. Но и удалять все приложения для перезапуска с нуля также чревато: потеря данных 1С приведет к проблемам с налоговой и таким штрафам, что проще будет закрыть бизнес.