В этой статье мы расскажем о внедрении резервного копирования в организации и подводных камнях, о которых стоит подумать на этапе планирования решения.
Сразу отметим, что, несмотря на обилие универсальных решений на рынке (как платных, так и Open Source), выбор следует делать только после определения стратегии резервного копирования. Не стоит изобретать велосипед и пытаться придумать что-то уникальное — все стратегии давно созданы и опубликованы в Интернете крупнейшими компаниями в сегменте ИТ-сервисов и консалтинговых услуг. После того как стратегия выбрана и зафиксирована документально, можно уделить внимание деталям, в том числе аппаратному и программному обеспечению.
Определить содержимое
Резервное копирование всегда выполняется с одной простой целью: дать возможность корректно функционировать ИТ-инфраструктуре компании в ситуациях, когда произошла полная или частичная потеря данных. Причины потери при этом могут быть любыми – от воздействия вредоносных программ до выхода из строя накопителей информации. Чтобы понять, какие данные потерять критично, а какие нет, следует определить список сервисов, которые напрямую влияют на бизнес. Среди них, например, сайт компании с формой заказа, база данных, биллинг и пр. Другие же системы, такие как корпоративный мессенджер или обучающий портал, безусловно, важны, но в экстренном случае ими можно будет пренебречь. После формирования списка критичных сервисов следует для каждого из них определить, где хранятся те или иные данные и в каком виде.
«Всё есть файл», — гласит известная концепция в Unix-системах. Скопировать файл в надежное место изначально не кажется сложной задачей, ведь вариантов множество: от выделенных серверов до облачных хранилищ. Проблемы начинаются, когда приходит осознание, что копирование — растянутый во времени процесс, который редко происходит мгновенно. А это означает, что во время копирования файл нельзя изменять, иначе в бэкапе окажутся неполные или неточные данные. Соответственно, пока идет копирование, у пользователей не должно быть возможности менять данные, что в большинстве случаев равноценно простою.
Для успешного решения задачи стоит задуматься об использовании штатных возможностей приложений, управляющих данными. Например, если необходим бэкап базы данных MySQL без остановки, можно проделать небольшой фокус: на отдельном сервере или виртуальной машине создается точная копия оригинальной базы данных при помощи механизма репликации. Реплика будет немного отставать от оригинала, но это не станет критичным. Созданная таким образом полная копия базы данных не должна обслуживать запросы пользователей и может быть в любой момент заблокирована для выполнения копирования. Пользователи же в этот момент продолжат работать с основным сервером и ничего не заметят, а разблокированная реплика спокойно догонит оригинал и будет готова к выполнению новой резервной копии.
Что интересно, такой подход не только позволяет выполнять резервное копирование на лету, без остановки сервиса, но и повышает его доступность: ведь если основной сервер прекратит работу, то системный администратор сможет спокойно перевести нагрузку на реплику, и обслуживание пользователей продолжится.
Где и сколько хранить
Теперь задумаемся, где именно хранить резервные копии данных. Разумеется, это должно быть надежное место, соответствующее выбранной стратегии. Наибольшую популярность получила стратегия 3-2-1, содержащая три простых правила:
Создавать три резервные копии каждого объекта.
Хранить эти копии минимум в двух разных форматах.
Минимум одна копия должна размещаться в удаленном хранилище.
Таким образом, для каждого гигабайта данных на сервере следует предусмотреть 3 Гбайта места для хранения, и тогда риск потери данных будет минимальным при адекватных затратах. Многие IaaS-провайдеры используют эту стратегию в своих продуктах и сразу предлагают хранилище с тройной репликацией на разных физических серверах, нередко еще и географически разнесенных.
Данные — это ценнейший ресурс, но часто бывают ситуации, когда необходимо обеспечить хранение резервных копий с высокой надежностью, но уложиться в ограниченный бюджет. Выход только один: уменьшать количество хранимых данных. Здесь немаловажную роль будет играть функциональность программного обеспечения, и в первую очередь, конечно же, поддержка различных алгоритмов сжатия данных без потерь. А во вторую — задействование различных методов создания резервных копий, среди них:
Полный – при котором создается точная копия всех данных.
Инкрементальный – когда вначале создается полная копия, а каждый последующий бэкап сохраняет дельту от предыдущего.
Дифференциальный – когда вначале создается полная копия, а каждый последующий бэкап сохраняет дельту от полной копии.
Эти варианты можно сочетать между собой, тем самым балансируя между объемом данных, хранение которых придется оплачивать, и потенциальным риском их потери. В любом случае следует помнить, что восстановление данных — это, как и копирование, не мгновенный процесс, поэтому выбор метода должен быть оправданным.
Допустим, вы выбрали инкрементальный бэкап. В таком случае, чтобы восстановить данные после полной потери, придется не только развернуть полную копию всех данных, но еще и пройти по всей цепочке, применяя каждый раз дельты от последнего бэкапа. Если в процессе произойдет сбой, то полученные данные не будут консистентными. Поэтому длину цепочки следует максимально ограничивать, исходя из запланированного бюджета.
В случае дифференциального бэкапа данные будут занимать больше места, чем при инкрементальном подходе, однако длина цепочки будет фиксированной: одна полная копия плюс одна дельта. Это значительно уменьшает шанс нарушения целостности восстанавливаемых данных. Полная копия в данном сценарии наиболее надежна, ведь восстановить требуется только ее — данные будут сразу готовы к использованию. Вопрос целостности на этом уровне не представляет какого-либо риска. Иногда целесообразно делать условные «срезы», к примеру полную копию за месяц/квартал/год.
Теперь посмотрим, сколько же времени нам нужно хранить эти данные. При выборе места хранения стоит помнить простой факт: данных с каждым днем будет все больше, а значит, вопрос масштабирования должен быть решен еще на этапе выбора стратегии. Легко ли вам будет добавить дисковое пространство для хранения, когда существующее пространство закончится? Если ответ «да», это хороший знак – потом не придется решать проблемы с переносом данных.
Стоит ли хранить все резервные копии бессрочно? В идеальном мире – да, особенно если самих данных не очень много. Если же бюджет не позволяет, то старайтесь сохранять данные хотя бы за последний год. Этого срока вполне хватит любому сотруднику, чтобы обнаружить недостаток какого-либо файла/директории и запросить их восстановление. Тут все зависит от того, сколько ресурсов готова потратить компания.
Учебная и боевая тревога
С главным определились: есть стратегия, место для хранения резервных копий и даже возможности масштабирования. Но есть и важный нюанс: любой бэкап бесполезен без тестирования на работоспособность, а в критической ситуации права на ошибку не будет. Так что следует взять за правило тестировать если не все, то хотя бы существенную часть бэкапов. В наш прекрасный век повсеместного использования виртуализации создать тестовый стенд для проверки резервных копий не составит труда.
Далее обратим внимание на документацию. Даже грамотно выстроенная система может дать сбой и в самый ответственный момент отказать. Системные администраторы в этом случае должны иметь возможность воспользоваться заранее составленными документами, где четко прописано, как действовать в случае критической ситуации. Наиболее важным будет BCP (Business Continuity Plan), где детально прописаны действия по восстановлению бизнес-процессов. Вместе с ним рука об руку идет DRP (Disaster Recovery Plan) – заранее определенный порядок действий в случае конкретной аварийной ситуации. В одном BCP может содержаться целая «пачка» DRP, но не наоборот, что логично: именно бизнес-процессы требуют непрерывности, а каждый конкретный DRP позволяет ее достичь.
«Учебная тревога» с развертыванием бэкапов хороша тем, что позволяет добавить конкретики в составленную документацию и выявить узкие места ИТ-инфраструктуры. К примеру, если в процессе восстановления между источником резервной копии и целевой машиной будет медленный канал связи, то восстановление больших объемов данных в разумные сроки будет невозможным. В связи с этим целесообразно запланировать и провести апгрейд сетевой составляющей.
Организация процесса резервного копирования потребует много времени и средств, причем в итоге бэкапы могут и не понадобиться, поскольку современная ИТ-инфраструктура практически на каждом уровне несет в себе средства обеспечения отказоустойчивости. На уровне физического хранения данных это организация дисковых массивов с заданным уровнем надежности, на уровне файловой системы — поддержка журналирования и/или контроля четности данных, что позволяет блюсти их целостность.
Но все это не будет иметь ровным счетом никакого значения, к примеру, при атаке инфраструктуры вирусом, подобным WannaCry. Так, 12 мая 2017 года запомнилось многим системным администраторам и владельцам компаний: в тот день около 500 тыс. компьютеров и серверов в 200 странах мира прекратили обслуживать пользователей, заблокировав работу множества организаций и вызвав коллапс на критических объектах инфраструктуры. На восстановление нормальной деятельности у некоторых крупных компаний ушло несколько недель. В целом ситуация продемонстрировала, насколько важно резервное копирование и что средства на построение подобной системы были потрачены не зря.
Чем бэкапить
Вот мы и добрались до момента, когда пора решить, чем делать резервные копии. Здесь есть два существенно разных подхода. Первый основан на приобретении проприетарных приложений, способных выполнять необходимые операции резервного копирования на используемых в инфраструктуре операционных системах. У этого подхода есть как ряд важных преимуществ (скорость развертывания и настройки, предсказуемое поведение, наличие технической поддержки), так и ряд недостатков (высокие первоначальные затраты, невозможность доработки под конкретную инфраструктуру, архитектурные ограничения).
Второй подход основывается на использовании программного обеспечения с открытым исходным кодом и также имеет плюсы и минусы. С одной стороны, несет в себе нулевые затраты на приобретение ПО и широкие возможности доработки под конкретную инфраструктуру. Но с другой — решение проблем и доработка ПО требуют квалифицированного персонала, имеющего обширный опыт взаимодействия с такими приложениями. Помимо доработки ПО, вероятнее всего, потребуется серьезная доработка документации и создание инструкций по использованию в конкретных ситуациях.
Разумеется, можно отдать все эти серьезные задачи на аутсорс, но подобное решение будет нести в себе множество рисков, начиная от утечек конфиденциальной информации и заканчивая саботажем в случае возникновения спорных ситуаций. Таким образом, можно сделать однозначный вывод: создание качественной системы резервного копирования — исключительно важная задача, требующая к себе самого пристального внимания.