Системы автоматизации резервного копирования данных. Резервное копирование. Теория и практика. Краткое изложение. Как обычно приходят к сложным системам

Программные средства резервного копирования .

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

Если требуется выполнить резервное копирование файлов одного пользователя, обычно достаточно использовать стандартные утилиты, такие как Ntbackup в Windows или tar в Unix-системах. С их помощью можно задать метод резервного копирования и определить факт изменения файлов (требующийся при осуществлении выборочного копирования), но их применение в масштабах всего предприятия не представляется целесообразным.

Для небольших компаний часто можно обойтись вовсе без специального ПО. Для резервного копирования с минимальным необходимым функционалом оно поставляется вместе с ОС (это утверждение справедливо как для MS Windows, так и для UNIX), а с СУБД Oracle, например, поставляется усеченная версия Legato Networker.

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

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

Очевидно, что для успешной работы всего комплекса резервного копирования необходима слаженная работа как программных, так и аппаратных средств . Поэтому для систем резервного копирования масштаба предприятия стандартные средства резервного копирования не применяются. Можно выделить несколько важных требований, которым должно удовлетворять программное обеспечение для резервного копирования и восстановления данных для крупных предприятий:
- Построение системы по принципу клиент-сервер . Поскольку любая современная информационная система строится на основе сети, система резервного копирования должна быть также сетевой. Такая система должна обеспечивать: управление резервным копированием во всей сети с выделенных компьютеров; удаленное резервное копирование данных, содержащихся на серверах и рабочих станциях; централизованное использование устройств резервного копирования. В применении к резервному копированию терминология клиент-сервер означает следующее: компонент системы резервного копирования, обеспечивающий управление всеми процессами и устройствами называется сервером, а компонент, отвечающий за сохранение или восстановление конкретных данных, - клиентом. Программный продукт резервного копирования масштаба предприятия должен обеспечивать скоординированную работу всех элементов вычислительной сети - рабочих станций, серверов и устройств резервного копирования - для обеспечения наименьшей загрузки устройств и каналов связи. Для этого применяют следующую организацию программного комплекса: сервер системы, консоль управления (в общем случае устанавливается не на сервере), агенты резервного копирования (программы-клиенты, устанавливаемые на рабочих станциях). Кроме того, такой продукт должен обеспечивать возможность работы с клиентами под управлением различных операционных систем. И, наконец, такие программы должны обеспечивать доступ к файлам пользователей и баз данных, даже если эти файлы открыты и используются системой.
- Мультиплатформенность. Современная информационная сеть является гетерогенной. Соответственно и система резервного копирования должна полноценно функционировать в такой сети, т. е. предполагается, что ее серверная часть будет работать в различных операционных средах и поддерживать клиенты на самых разных аппаратно-программных платформах. Наличие, как минимум, клиентов под разные ОС.
- Автоматизация типовых операций. Процесс резервного копирования неизбежно содержит много циклов различных операций. Система резервного копирования должна выполнять циклические работы в автоматическом режиме и минимизировать число ручных операций. В частности, она должна поддерживать: выполнение резервного копирования по расписанию, ротацию носителей, обслуживание устройств резервного копирования по расписанию. Например, копирование может осуществляться каждый день в определенное время. Другой пример цикла - это процесс перезаписи информации на носителях резервных копий. Если ежедневная резервная копия должна храниться неделю, то по истечении этого срока соответствующий носитель можно использовать заново. Такой процесс последовательной замены носителей резервных копий называется ротацией. К циклическим работам относится и профилактическое обслуживание устройств резервного копирования, например чистка узлов лентопротяжного механизма стримера по истечении определенного срока работы при помощи специальной кассеты. Следует отметить, что автоматизация работ является одним из ключевых факторов снижения затрат на сопровождение системы резервного копирования.
- Поддержка различных режимов резервного копирования. Предположим, что каждый день необходимо создавать резервную копию некоторого набора файлов, например содержащихся в одном каталоге. Как правило, в течение рабочего дня изменения вносятся лишь в отдельные файлы и ежедневное копирование информации, оставшейся неизмененной с момента создания предыдущей резервной копии, является излишним. Исходя из этого, система должна обеспечивать различные режимы резервного копирования, т. е. поддерживать возможность сохранения только той информации, которая была изменена с момента создания предыдущей копии.
- Простота инсталляции, поддержка широкого спектра приводов, быстрое восстановление серверов сети после аварии . Сервер сети может выйти из строя по различным причинам, например из-за аварии системного жесткого диска или вследствие ошибок программного обеспечения, приведших к разрушению системной информации. В этом случае его восстановление требует переустановки ОС, конфигурирования устройств, инсталляции приложений, восстановления файловой системы и учетных записей пользователей. Все эти операции очень трудоемки, и на любом из этапов данного процесса возможно возникновение ошибок. Таким образом, для восстановления сервера необходимо иметь резервную копию всей хранящейся на нем информации, включая системные данные, чтобы как можно быстрее привести его в рабочее состояние.
- Наличие модулей для основных СУБД (MS-SQL, Oracle, DB/2) и бизнес-критических приложений (MS Exchange, SAP R/3 и др.); резервное копирование данных в интерактивном (on-line) режиме. Зачастую информационная система включает в себя различные приложения клиент-сервер, которые должны функционировать круглосуточно. Примером тому являются почтовые системы, системы коллективной работы (например, Lotus Notes) и SQL-серверы. Осуществить резервное копирование баз данных таких систем обычными средствами невозможно, поскольку они все время открыты. Поэтому в них часто встроены собственные средства резервного копирования, но их использование, как правило, не вписывается в общую технологию, принятую в организации. Исходя из этого, система резервного копирования должна обеспечивать сохранение баз данных приложений клиент-сервер в интерактивном режиме.
- Возможность как центрального, так и локального администрирования, развитые средства мониторинга и управления. Для управления процессами резервного копирования и отслеживания их состояния система резервного копирования должна иметь графические средства мониторинга и управления и широкий набор средств оповещения о событиях, наличие функции генерации и рассылки отчетов.
С точки зрения требований, которые были приведены выше корпоративное программное обеспечение для резервного копирования должно превосходить решение для SMB (недорогие решения для сектора малого и среднего бизнеса - Small/Medium Business). Однако оно требует и заметно больших расходов на приобретение, равно как и на обучение. По этой причине, выбирая продукт, следует учитывать поддерживаемые им расширенные и дополнительные функции и технологии. Для небольших реализованных решений, которые по причине новых требований уже не могут более наращиваться, все ведущие производители предлагают программные обновления до продуктов корпоративного класса, и создание резервной копии на диске считаются особенно важными функциями для крупных предприятий, поскольку они значительно улучшают производительность резервного копирования и обеспечивают дополнительные возможности защиты данных.

Популярными решениями для корпоративного сектора являются HP Data Protector, Bakbone NetVault, BrightStor ARCserve Backup (Computer Associates), Legato NetWorker, Veritas NetBackup и некоторые другие. Многие из этих продуктов пользуются заслуженной популярностью и в России. Все они созданы для работы в гетерогенных средах с разнотипными операционными системами и большими объемами данных и удовлетворяют высоким требованиям к производительности, стабильности и готовности. Поэтому поддержка сетей хранения данных - обязательная составная часть этих продуктов. Благодаря мультиплексированию корпоративные решения резервного копирования обеспечивают высокую производительность, поддерживают множество библиотек и дисководов и могут быть адаптированы к специфическим потребностям при помощи агентов баз данных и операционных систем. Рассматриваемый тип программного обеспечения представляет собой набор дополнительных функций, которые либо поставляются с системой хранения данных, либо доступны от независимых производителей. Они обычно включают: создание моментальных снимков тома (snapshots), создание полной рабочей копии тома (snapclone), репликацию данных по расписанию (replication) и зеркалирование данных на уровне тома на удаленное хранилище (synchronous/ asynchronous mirroring).

Производители систем хранения данных (СХД) и программного обеспечения для СХД предлагают несколько концепций решения данной проблемы. Данный функционал может присутствовать в виде микрокода контроллера (Hitachi), в виде дополнительного серверного модуля (appliance) (EMC, HP, IBM), либо на уровне FC коммутатора (Cisco, Troika).

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

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

Поскольку в большинстве случаев программное обеспечение для архивирования зависит от приложения, некоторые компании предлагают специализированные решения для классических почтовых и ERP-систем. К крупным производителям систем для SAP относится компания Open Text (приложения SAP Document Access и SAP Archiving), IBM (DB2 CommonStore for SAP), EMC (Archive Services for SAP), Техносерв АС (Technoserv Content Server) и некоторые другие со своими продуктами для управления контентом и документами, а также архивирования. Интегрированные решения с поддержкой архивирования и управления жизненным циклом информации структурированных и неструктуриро ванных данных различных приложений в будущем станут наиболее рациональным вариантом, поскольку позволяют снизить издержки на администрирование. HP Reference Information Storage System (RISS) уже сегодня поддерживает Microsoft Exchange и Outlook, Lotus Domino и документы в файловых форматах приложений MS Office, Adobe PDF, HTML и проч.

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

Cистема резервного копирования может работать вот так

Чем корпоративный бэкап отличается от домашнего?
Масштаб - инфраструктуры до петабайта. Скорость – тысячи транзакций в секунду, поэтому, например, нужно уметь забирать бэкап из базы данных на лету, не останавливая запись. Зоопарк систем: рабочие машины, мобильные телефоны и планшеты, профили людей в «облаке», копии баз данных CRM/ERP, все это на разных ОС и в тяжелых разветвленных системах.

Ниже я расскажу про решения от IBM, EMC, CommVault, Symantec и то, что они дают как бизнесу в целом, так и IT-отделу. Плюс о некоторых подводных камнях.

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

Начинаем ликбез. Бэкап вообще нужен?

Обычно такой вопрос задают люди, далекие от IT. Правильный вопрос - «какой бэкап нужен»? В начале этого года мне на глаза попадался отчет, что в среднем по миру утеря данных стоит до трети стоимости компании, в США и Европе - до половины. Проще говоря, отсутствие свежего бэкапа может в некоторых случаях означать уход с рынка.

Зачем вообще нужен бэкап?

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

• Во-первых, он защищает данные от утери. Основные причины утери - это сбои оборудования, падение удаленных площадок (например, при пожаре в ЦОДе), изъятие оборудования. Более мелкие случаи - утеря ноутбуков и так далее.
• Также бэкап защищает целостность данных: страхует от ошибок оператора, например. Это вторая по распространенности причина: человек может взять и «запороть» важные данные не той командой.
• В-третьих, в корпоративной среде «горячий» бэкап может понадобиться для быстрого развертывания сервисов при чрезвычайном происшествии, это очень актуально у тех, для кого особенно критична непрерывность IT-процессов, например, у телеком операторов или банков.

Как обычно приходят к сложным системам?

Тут все просто: с ростом компании. Сначала используются простые средства: копирование вручную, затем скриптами по расписанию или настройкой утилиты, после появляется серверное приложение, которое этим управляет. На этой стадии обычно добавляются требования к уровню бэкапа от безопасников или финансового отдела (управляющего рисками компании) - и вот тогда начинается внедрение. Каждая задача классифицируется по важности и оценивается, например, биллинг должен накатываться через 5 минут после аварии на активную дублирующую систему в другом ЦОДе, а данные сотрудников офиса - через 2 часа на заранее подготовленное, но законсервированное оборудование. На этом уровне появляется необходимость плотной интеграции с приложениями, а чуть позже - и с аппаратными массивами для хранения.

Как выглядит интеграция на практике?

Как правило, когда наши специалисты приходят ставить тотальный бэкап, в крупной компании уже есть несколько подсистем резервного копирования. Чаще всего, речь идет об уже настроенных приложениях файлового бэкапа и регулярном снятии отпечатков баз данных (например, о ночном бэкапе базы 1С) и складированию их на отдельное устройство. Бывают, конечно, и феерические случаи. Например, одна розничная сеть вообще не делала бэкап баз о наличии товара на складе - и в случае сбоя отправляла людей делать инвентаризацию.

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

Что самое важное в ПО для резервного копирования?

Давайте рассмотрим главные параметры.

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

Пример архитектуры ПО резервного копирования (CommVault Simpana)

Функции централизованного управления.
Важно управлять всеми операциями. Бэкап крупных систем достаточно сложен, поэтому важно, чтобы администратор точно представлял, что происходит. При разветвленной структуре, например, в крупном ЦОД с сотнями систем, к каждой не «подойдешь» и не посмотришь, есть у нее резервная копия или нет. Тут нужна система, которая может построить отчет, посмотреть, что все данные и приложения копируются или не копируются, на что нужно обратить внимание, известить администратора о каких-то проблемах.

Централизованное управление СРК

У лидеров рынка появляются системы, которые позволяют посмотреть, что и где хранится, какие типы данных, что именно можно оптимизировать и так далее. Можно построить прогноз на год вперед.

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

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

К примеру, системы CommVault или ЕМС поддерживают практически все имеющиеся на корпоративном рынке ОС и коммерческие приложения (в частности, базы данных Oracle, Microsoft, у CommVault есть еще поддержка PostgreSQL и MySQL, Documentum, SAP).

Дедупликация - архитектура
Важна грамотная дедупликация. Хорошая дедупликация в разы снижает требования по цене к дисковым массивам и очень хорошо жмет трафик. Грубо говоря, если первый бэкап пользовательских данных с виртуальных машин был на 10 Gb, то каждый следующий, за день, может быть на 50-60 Mb - из-за разницы между слепками систем. При этом у лидеров рынка резервного копирования (про них ниже) для внешних систем копии видны как отдельные слепки, то есть так, как если бы каждый раз делался тотальный бэкап. Это невероятно ускоряет восстановление.

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

Подсистема дедупликации, по-хорошему, должна удобно масштабироваться. В идеале, линейно с добавлением узлов хранения путем организации некоторого Grid или Cloud. При этом узлы не должны быть отдельными островами со своими наборами данных, а связаны в единое дедупликационное пространство. И совсем хорошо, если эти узлы распараллеливают нагрузку и параллельно ее обрабатывают. Отмечу, что сейчас многие заказчики бросаются меряеть коэффиценты дедупликации при сравнении продуктов. Но это не совсем правильно: современные SATA диски уже по 4ТБ в объеме каждый. Плюс-минус пару дисков и все системы смогут хранить одинаковый объем данных – и лучше докупить один диск в начале, чем при необходимости роста перестраивать всю систему.

Балансировка нагрузки
Еще в таких системах есть функции по обеспечению отказоустойчивости операции и балансировки нагрузки, что важно в больших ЦОДах, когда объемы данных в одной системе могут достигать десятков и сотен Tb. Например, у платформы виртуализации может быть очень большой объем данных и большое количество виртуальных машин. Сама система, в данном случае, должна позволять построить набор серверов, которые будут передавать данные, получать их с платформы и записывать на хранилище, при этом так, чтобы они между собой имели возможность взаимодействовать, а в случае повышения или снижения нагрузки перераспределять ее автоматически. Функция простая и очевидная, но достаточно критичная, потому что влияет на скорость и оперативность создания резервных копий.

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

Физическое хранение

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

Диски и лента + «облако»

Так получается, что ленточные накопители все еще используются. Чаще всего «горячие» данные (скажем, процентов 10 самых важных) хранятся на дисках, откуда их можно быстро получить, а уже второй уровень - на ленте. Это практично и дешево, плюс лента позволяет хранить данные чуть ли не десятилетиями без замены оборудования, они просто вынимаются и кладутся на полку. Частый случай - логи и другие документы банков, которые нужно хранить определенный срок. Система бэкапа умеет выделять такие данные на диске, отчуждать их и архивировать на ленточном накопителе. При этом всегда есть возможность в случае аварии найти эту информацию и восстановить. Записывать, кстати, можно как полные копии, так и дедуплицированные – если необходимо, умная система может собрать все обратно так, как будто последний слепок был полным.

А вот CommVault Simpana умеет еще напрямую складывать копию данных из корпоративного хранилища в «облако» (некоторые наши заказчики так делают с «облаком» КРОК – мы даже проводили сертификацию). Эта дополнительная копия может рассматриваться заказчиком как долговременный архив. Для его хранения не нужно думать об аппаратной части. Еще такая копия может быть использована для аварийного восстановления систем. Например, один из заказчиков делает так: копия всех виртуальных машин отправляется в наше «облако» на хранение. В случае падения основного ЦОДа заказчика, мы можем запустить все эти виртуальные машины на своей инфраструктуре. При этом оплата до запуска идет только за емкость – то есть получается очень экономично.

Прямая работа с пользователями

Если вы не сталкивались с корпоративным бэкапом, то у вас может сложиться впечатление, что обратно данные накатывает только IT-отдел, причем делает это вручную. Но, например, у CommVault это не совсем так.

В этой ситуации пользователь может сам зайти на портал (на картинке ниже) и накатить себе конкретно свои данные, если они были в копии. Обычно на таком портале также есть поисковик по резервным копиям и архивам (в рамках прав пользователя). К этому же архиву можно открыть доступ и сотрудникам информационной безопасности - это в разы уменьшит количество запросов к IT-отделу с вопросами вроде: «А у кого был документ такой-то».

Да, вы правильно поняли. Если пользователь потерял файл, случайно удалил письмо или же захотел найти старую версию документа для сравнения – он просто идет и делает все сам за считанные секунды без лишних сложностей. И даже не звонит и не пишет в IT-отдел.

Отдельно стоит сказать про поиск . Все неструктурированные данные (файлы, почта, объекты SharePoint и т.п.) которые попадают в систему, хорошо бы проиндексировать и организовать поисковик. Simpana это умеет. С одной стороны пользователи через консоль самообслуживания могут найти любой объект сами по ключевым словам. С другой стороны, служба безопасности может проводить целенаправленные мероприятия по анализу всей этой информации, в том числе для поиска внутренних угроз. Ну и система может устанавливать сроки хранения данных в зависимости от содержимого этих данных.

Как быстро все можно накатить обратно?

Предположим, у нас есть сложная система с базой данных Oracle в качестве хранилища. Данные физически «размазаны» по нескольким серверам в одном ЦОД. Используется CommVault.

• Первый случай - пользователь взял и удалил данные со своей рабочей станции. Восстанавливает либо он сам, либо администратор: заходит в интерфейс, выбирает участок. Все остальное делает система. Пользователь видит красивый веб-интерфейс, администратор может работать с ним же или с консолью.
• Теперь у нас падает почтовый сервер Exchange. Сценарий все еще достаточно простой: опять же, либо сам пользователь, либо администратор определяет, какие данные необходимо восстановить, подключается, заходит в систему, открывает консоль восстановления, выбирает область, жмет кнопку «восстановить».
• Теперь у нас пропадают данные из базы нашего большого коммерческого приложения за сегодня. Например, все транзакции по купле-продаже. В этом случае бэкап-система будет стучаться к механизму RMAN, который есть в Oracle (это своего рода API по восстановлению данных). Но поскольку у нас уже все интегрировано, то администратор также только выбирает, что именно надо восстановить. Дальше уже сам RMAN вместе с бэкап-системой решает, что конкретно делать: восстанавливать целиком базу или какой-то TableSpace, т.е. отдельную таблицу, и так далее.
• А теперь у нас ночью взрывается ЦОД. В этом случае администратор выбирает другой ЦОД и накатывает на «чистое» оборудование последнюю копию. Система сама собирает ему наиболее свежий полный слепок из дедуплицированных данных и отдает нужную информацию каждой подсистеме и приложению. Обычные пользователи, скорее всего, даже не замечают произошедшего. Может быть и так, что в другом ЦОДе частично данные уже есть, среплицированы или просто восстанавливаются по расписанию, тогда все еще проще и восстановление происходит уже даже не на чистую систему.

Развитие систем от версии к версии

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

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

Недавно появились клиенты для iOS и Android для управления копиями своей рабочей станции: удобно, если кто-то уезжает в командировку и забывает презентацию, например. Или когда в дороге ломается ноутбук. Здесь тоже не нужно будить админа в два ночи: пользователь может сделать все сам.

Вендоры

По отчету Gartner - среди лидеров, с которыми мы активно работаем, в частности, IBM, Symantec, ЕМС и CommVault.

Квадрат Gartner: лидеры сверху-справа, нишевые игроки снизу-слева.

IBM Tivoli Storage Manager (TSM) - довольно гибкий продукт в плане настройки и организации схемы резервного копирования на предприятии. Совмещая различные компоненты TSM, заказчик получает возможность выстраивать нужный функционал под свои задачи. Но, зачастую, для этого требуется больше времени на проектирование и внедрение. TSM часто используется в составе комплексных решений на базе оборудования и ПО от IBM.

EMC . Являясь компанией производящей не только ПО, но и оборудование, нацелена, прежде всего, на интеграцию всех своих решений. Поэтому если инфраструктура в большей мере построена на СХД Clariion, VNX, data domain, стоит посмотреть на продукты по резервному копированию от EMC, которые позволят обеспечить однородную структуру системы. Кстати, и продукт EMC Avamar тоже является программно-аппаратным решением.

Symantec представлен на рынке резервного копирования своим флагманским продуктом NetBackup, ориентированным на enterprise-сегмент, и более «легковесным» BackupExec, традиционно используемым в средах, построенных в основном на продуктах Microsoft. NetBackup славится поддержкой большого спектра операционных систем, СУБД и бизнес-приложений, развернутых в том числе в виртуальном окружении. А также умеет использовать продвинутые возможности современных СХД. NetBackup является хорошим выбором для среды с большой долей UNIX-систем. С недавнего времени продукты от Symantec поставляются не только как ПО, но и как ПАК, что ускоряет их развертывание и настройку.

CommVault . Пожалуй, самым важным является то, что это целостный продукт, который закрывает практически все потенциальные потребности заказчиков. Это унифицированная платформа, объединяющая в себе функционал копирования, архивирования и доступа к данным. Плюс традиционно хорошая интеграция с платформами виртуализации, дедупликация и интеграция с облачными хранилищами. Ну и как говорилось выше, очень сильно разгружает IT-отдел за счет грамотной политики прав доступа пользователей к элементам архива. По опыту ряда внедрений, CommVault будет хорошим выбором при наличии большого количества разнородного ПО и оборудования. В гомогенных средах на базе *unix возможно стоит думать о других продуктах, но в гетерогенных – она сразу позволяет избавиться от хаоса и всегда быть спокойным за то, что бэкап есть, он свежий, и быстро накатится обратно, если что. А это, как вы наверняка знаете, весьма бережет нервы.

В целом, надо смотреть, конечно, по месту. Если у вас есть вопросы, что выбрать под вашу инфраструктуру, пишите на [email protected], поможем оценить все аспекты и предупредить о возможных подводных камнях.

АЛЕКСЕЙ БЕРЕЖНОЙ, системный администратор. Главные направления деятельности: виртуализация и гетерогенные сети. Еще одно увлечение помимо написания статей – популяризация бесплатного ПО

Резервное копирование
Теория и практика. Краткое изложение

Чтобы организовать систему резервного копирования наиболее эффективно, нужно выстроить настоящую стратегию сохранения и восстановления информации

Резервное копирование (или, как его еще называют, бэкап – от английского слова «backup») является важным процессом в жизни любой ИТ-структуры. Это парашют для спасения в случае непредвиденной катастрофы. В то же время резервное копирование используется для создания своего рода исторического архива бизнес-деятельности компании на протяжении определенного периода ее жизни. Работать без бэкапа – все равно, что жить под открытым небом – погода может испортиться в любой момент, а спрятаться негде. Но как его правильно организовать, чтобы не потерять важных данных и не потратить на это фантастические суммы?

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

В данной статье речь пойдет как раз об обратном: основное внимание уделено общим понятиям, а технические средства будут затронуты только в качестве примеров. Это позволит абстрагироваться от аппаратного и программного обеспечения и ответить на два главных вопроса: «Зачем мы это делаем?», «Можем ли мы это делать быстрее, дешевле и надежнее?».

Цели и задачи резервного копирования

В процессе организации резервного копирования ставятся две основные задачи: восстановление инфраструктуры при сбоях (Disaster Recovery) и ведение архива данных в целях последующего обеспечения доступа к информации за прошлые периоды.

Классическим примером резервной копии для Disaster Recovery является образ системной партиции сервера, созданный программой Acronis True Image.

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

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

• Период хранения данных. У архивных копий он достаточно длительный. В некоторых случаях регламентируется не только требованиями бизнеса, но и законодательно. У копий для аварийного восстановления он сравнительно небольшой. Обычно создают одну или две (при повышенных требованиях к надежности) резервные копии для Disaster Recovery c максимальным интервалом в сутки-двое, после чего они перезаписываются свежими. В особо критичных случаях возможно и более частое обновление резервной копии для аварийного восстановления, например, раз в несколько часов.
• Быстрота доступа к данным. Скорость доступа к длительно хранящемуся архиву в большинстве случаев не критична. Обычно необходимость «поднять данные за период» возникает в момент сверки документов, возврата к предыдущей версии и т.д., то есть не в аварийном режиме. Другое дело – аварийное восстановление, когда необходимые данные и работоспособность сервисов должны быть возвращены в кратчайшие сроки. В этом случае скорость доступа к резервной копии является крайне важным показателем.
• Состав копируемой информации. В архивной копии обычно содержатся только пользовательские и бизнес-данные за указанный период. В копии, предназначенной для аварийного восстановления, помимо этих данных, содержатся либо образы систем, либо копии настроек операционной системы и прикладного программного обеспечения, а также другой информации, необходимой для восстановления.

Иногда возможно совмещение этих задач. Например, годовой набор ежемесячных полных «снимков» файлового сервера, плюс изменения, сделанные в течении недели. В качестве инструмента для создания такой резервной копии подойдет True Image.

Самое главное – четко понимать, для чего делается резервирование. Приведу пример: вышел из строя критичный SQL-сервер по причине отказа дискового массива. На складе есть подходящее аппаратное обеспечение, поэтому решение проблемы состояло только в восстановлении программного обеспечения и данных. Руководство компании обращается с понятным вопросом: «Когда заработает?» – и неприятно удивляется, узнав, что на восстановление уйдет целых четыре часа. Дело в том, что на протяжении всего срока службы сервера регулярно осуществлялось резервное копирование исключительно баз данных без учета необходимости восстановить сам сервер со всеми настройками, включая программное обеспечение самой СУБД. Попросту говоря, наши герои сохраняли только базы данных, а про систему забыли.

Приведу другой пример. Молодой специалист на протяжении всего периода своей работы создавал посредством программы ntbackup одну-единственную копию файлового сервера под управлением Windows Server 2003, включая данные и System State в общую папку другого компьютера. По причине дефицита дискового пространства эта копия постоянно перезаписывалась. Через некоторое время его попросили восстановить предыдущий вариант многостраничного отчета, который был поврежден при сохранении. Понятное дело, что, не имея архивной истории с выключенным Shadow Copy , он не смог выполнить этот запрос.

На заметку Shadow Copy , дословно – «теневая копия». Обеспечивает создание мгновенных копий файловой системы таким образом, что дальнейшие изменения оригинала никак не оказывают на них влияния. С помощью данной функции возможно создавать несколько скрытых копий файла за определенный период времени, а также на лету резервные копии файлов, открытых для записи. За работу Shadow Copy отвечает служба Volume Copy Shadow Service. System State , дословно – «состояние системы». Копирование System State создает резервные копии критических компонентов операционных систем семейства Windows. Это позволяет восстановить инсталлированную ранее систему после разрушения. При копировании System State происходит сохранение реестра, загрузочных и других важных для системы файлов, в том числе для восстановления Active Directory, Certificate Service database, COM+Class Registration database, SYSVOL-директории. В ОС семейства UNIX непрямым аналогом копирования System State является сохранение содержимого каталогов /etc, /usr/local/etc и других необходимых для восстановления состояния системы файлов.

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

При небольших объемах данных и не очень сложной ИТ-инфраструктуре можно попытаться совместить обе эти задачи в одной, например, делать ежедневное полное копирование всех дисковых разделов и баз данных. Но все же лучше различать две цели и подбирать под каждую из них правильное средство. Соответственно под каждую задачу используется свой инструмент, хотя есть и универсальные решения, как тот же пакет Acronis True Image или программа ntbackup

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

При реализации задачи аварийного восстановления можно использовать разные стратегии.

В одних случаях необходимо прямое восстановление системы на «голое железо» (bare metal). Это можно выполнить, к примеру, с помощью программы Acronis True Image в комплекте с модулем Universal Restore. В этом случае конфигурацию сервера удается вернуть в строй за очень короткий срок. Например, раздел с операционной системой в 20 Гб вполне реально поднять из резервной копии за восемь минут (при условии, что архивная копия доступна по сети 1 Гб/с).

В другом варианте целесообразнее просто «вернуть» настройки на только что проинсталлированную систему, как, например, копирование в UNIX-подобных системах конфигурационных файлов из папки /etc и других (в Windows этому приблизительно соответствует копирование и восстановление System State). Конечно, при таком подходе сервер введется в работу не ранее, чем будет проинсталлирована операционная система и восстановлены необходимые установки, что займет гораздо более длительный срок. Но в любом случае решение, каким быть Disaster Recovery, проистекает из потребностей бизнеса и ресурсных ограничений.

Принципиальное отличие резервного копирования от систем избыточного резервирования

Это еще один интересный вопрос, который хотелось бы затронуть. Под системами избыточного резервирования оборудования подразумевается внесение некоторой избыточности в аппаратное обеспечение с целью сохранения работоспособности в случае внезапного выхода из строя одного из компонентов. Прекрасный пример в данном случае – RAID-массив (Redundant Array of Independent Disks). В случае отказа одного диска можно избежать потери информации и безопасно произвести замену, сохранив данные за счет специфичной организации самого дискового массива (подробнее о RAID читайте в ).

Мне доводилось слышать фразу: «У нас очень надежное оборудование, везде стоят RAID-массивы, поэтому резервные копии нам не нужны». Да, конечно, тот же самый RAID-массив убережет данные от разрушения при выходе из строя одного жесткого диска. Но вот от повреждения данных компьютерным вирусом или от неумелых действий пользователя это не спасет. Не спасет RAID и при крахе файловой системы в результате несанкционированной перезагрузки.

Кстати Важность отличия резервного копирования от систем избыточного резервирования следует оценивать еще при составлении плана копирования данных, касается ли это организации или домашних компьютеров. Спросите себя, зачем вы делаете копии. Если речь идет о резервном копировании, то подразумевается сохранение данных при случайном (умышленном) действии. Избыточное резервирование дает возможность сохранить данные, в том числе и резервные копии, при выходе оборудования из строя. Сейчас на рынке появилось множество недорогих устройств, обеспечивающих надежное резервирование с помощью RAID-массивов или облачных технологий (например, Amazon S3). Рекомендуется использовать одновременно оба вида резервирования информации. Андрей Васильев, генеральный директор компании Qnap Россия

Приведу один пример. Бывают случаи, когда события развиваются по следующему сценарию: при выходе диска из строя происходит восстановление данных за счет механизма избыточности, в частности, с помощью сохраненных контрольных сумм. При этом наблюдается значительное снижение быстродействия, сервер подвисает, управление практически потеряно. Системный администратор, не видя другого выхода, перезагружает сервер холодным перезапуском (попросту говоря, нажимает на «RESET»). В результате такой перегрузки «по живому» возникают ошибки файловой системы. Самое лучшее, чего можно ожидать в этом случае, – длительная работа программы проверки диска в целях восстановления целостности файловой системы. В худшем варианте придется попрощаться с файловой системой и озадачиться вопросом, откуда, как и в какие сроки можно восстановить данные и работоспособность сервера.

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

Единственное, что может выступить в качестве неполноценной замены резервного копирования для Disaster Recovery, – наличие зеркального резервного сервера с постоянным реплицированием данных с основного сервера на резервный (по принципу Primary  Standby). В этом случае при выходе из строя основного сервера его задачи будут подхвачены резервным, и даже не придется переносить данные. Но такая система является довольно дорогостоящей и трудоемкой при организации. Не забываем еще про необходимость постоянной репликации.

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

И уж, конечно, никакая система избыточного резервирования не решит задачу ведения архива данных в течение определенного периода.

Понятие «окно бэкапа»

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

Выход при решении этих вышеописанных проблем напрашивается сам собой: перенести запуск процесса создания копий на неактивный период времени, когда взаимное влияние резервного копирования и других работающих систем будет минимально. Этот временной период называется «окно бэкапа». Например, для организации, работающей по формуле 8х5 (пять восьмичасовых рабочих дней в неделю), таким «окном» обычно являются выходные дни и ночные часы.

Для систем, работающих по формуле 24х7 (всю неделю круглосуточно), в качестве такого периода используется время минимальной активности, когда нет высокой нагрузки на серверы.

Виды резервного копирования

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

Полное резервное копирование (или Full backup)

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

Инкрементное копирование

В отличие от полного резервного копирования в этом случае копируются не все данные (файлы, сектора и т.д.), а только те, что были изменены с момента последнего копирования. Для выяснения времени копирования могут применяться различные методы, например, в системах под управлением операционных систем семейства Windows используется соответствующий атрибут файла (архивный бит), который устанавливается, когда файл был изменен, и сбрасывается программой резервного копирования. В других системах может использоваться дата изменения файла. Понятно, что схема с применением данного вида резервного копирования будет неполноценной, если время от времени не проводить полное резервное копирование. При полном восстановлении системы нужно провести восстановление из последней копии, созданной Full backup, а потом поочередно «накатить» данные из инкрементных копий в порядке их создания.

Для чего используется этот вид копирования? В случае создания архивных копий он необходим, чтобы сократить расходуемые объемы на устройствах хранения информации (например, сократить число используемых ленточных носителей). Также это позволит минимизировать время выполнения заданий резервного копирования, что может быть крайне важно в условиях, когда приходится работать в плотном графике 24х7 или прокачивать большие объемы информации.

У инкрементного копирования есть один нюанс, который нужно знать. Поэтапное восстановление возвращает и нужные удаленные файлы за период восстановления. Приведу пример. Допустим, по выходным дням выполняется полное копирование, а по будням инкрементное. Пользователь в понедельник создал файл, во вторник его изменил, в среду переименовал, в четверг удалил. Так вот при последовательном поэтапном восстановлении данных за недельный период мы получим два файла: со старым именем за вторник до переименования, и с новым именем, созданным в среду. Это произошло потому, что в разных инкрементных копиях хранились разные версии одного и того же файла, и в итоге будут восстановлены все варианты. Поэтому при последовательном восстановлении данных из архива «как есть» имеет смысл резервировать больше дискового пространства, чтобы смогли поместиться в том числе и удаленные файлы.

Дифференциальное резервное копирование

Отличается от инкрементного тем, что копируются данные с последнего момента выполнения Full backup. Данные при этом помещаются в архив «нарастающим итогом». В системах семейства Windows этот эффект достигается тем, что архивный бит при дифференциальном копировании не сбрасывается, поэтому измененные данные попадают в архивную копию, пока полное копирование не обнулит архивные биты.

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

Но дифференциальное копирование значительно проигрывает инкрементному в экономии требуемого пространства. Так как в каждой новой копии хранятся данные из предыдущих, суммарный объем зарезервированных данных может быть сопоставим с полным копированием. И, конечно, при планировании расписания (и расчетах, поместится ли процесс бэкапа во временное «окно») нужно учитывать время на создание последней, самой «толстой», дифференциальной копии.

Топология резервного копирования

Рассмотрим какие бывают схемы резервного копирования.

Децентрализованная схема

Ядром этой схемы является некий общий сетевой ресурс (см. рис. 1). Например, общая папка или FTP-сервер. Необходим и набор программ для резервного копирования, время от времени выгружающих информацию с серверов и рабочих станций, а также других объектов сети (например, конфигурационные файлы с маршрутизаторов) на этот ресурс. Данные программы установлены на каждом сервере и работают независимо друг от друга. Несомненным плюсом является простота реализации этой схемы и ее дешевизна. В качестве программ копирования подойдут штатные средства, встроенные в операционную систему, или программное обеспечение, такое как СУБД. Например, это может быть программа ntbackup для семейства Windows, программа tar для UNIX-like операционных систем или набор скриптов, содержащих встроенные команды SQL-сервера для выгрузки баз данных в файлы резервных копий. Еще одним плюсом является возможность использования различных программ и систем, лишь бы все они могли получить доступ к целевому ресурсу для хранения резервных копий.

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

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

Централизованное резервное копирование

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

Именно по такому принципу работает большинство популярных систем резервного копирования, таких как Symantec Backup Exec, CA Bright Store ARCServe Backup, Bacula и другие (см. рис. 2).

Помимо различных агентов для большинства операционных систем существуют разработки для резервного копирования популярных баз данных и корпоративных систем, например, для MS SQL Server, MS Exchange, Oracle Database и так далее.

Для совсем небольших компаний в некоторых случаях можно попробовать упрощенный вариант централизованной схемы резервного копирования без применения программ-агентов (см. рис. 3). Также эта схема может быть задействована, если не реализован специальный агент для используемого ПО резервного копирования. Вместо этого серверный модуль будет использовать уже существующие службы и сервисы. Например, «выгребать» данные из скрытых общих папок на Windows-серверах или копировать файлы по протоколу SSH c серверов под управлением UNIX-систем. Данная схема имеет весьма существенные ограничения, связанные с проблемами сохранения файлов, открытых для записи. В результате подобных действий открытые файлы будут либо пропущены и не попадут в резервную копию, либо скопированы с ошибками. Существуют различные методы обхода данной проблемы, например, повторный запуск задания с целью скопировать только ранее открытые файлы, но нет ни одного надежного. Поэтому такая схема подходит для применения только в определенных ситуациях. Например, в небольших организациях, работающих в режиме 5х8, с дисциплинированными сотрудниками, которые сохраняют изменения и закрывают файлы перед уходом домой. Для организации такой усеченной централизованной схемы, работающей исключительно в среде Windows, неплохо подходит ntbackup. При необходимости использовать подобную схему в гетерогенных средах или исключительно среди UNIX-компьютеров я рекомендую посмотреть в сторону Backup PC (см. ).

Рисунок 4. Смешанная схема резервного копирования

Что такое off-site?

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

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

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

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

Мы разобрали основные моменты при организации резервного копирования. В следующей части будут рассмотрены методические рекомендации и приведены практические примеры для создания эффективной системы резервного копирования.

1. Описание резервного копирования в системе Windows, в том числе System State – http://www.datamills.com/Tutorials/systemstate/tutorial.htm .
2. Описание Shadow Copy – http://ru.wikipedia.org/wiki/Shadow_Copy .
3. Официальный сайт Acronis – http://www.acronis.ru/enterprise/products .
4. Описание ntbackup – http://en.wikipedia.org/wiki/NTBackup .
5. Бережной А. Оптимизируем работу MS SQL Server. //Системный администратор, №1, 2008 г. – С. 14-22 ().
6. Бережной А. Организуем систему резервного копирования для малого и среднего офиса. //Системный администратор, №6, 2009 г. – С. 14-23 ().
7. Маркелов А. Linux на страже Windows. Обзор и установка системы резервного копирования BackupPC. //Системный администратор, №9, 2004 г. – С. 2-6 ().
8. Описание VPN – http://ru.wikipedia.org/wiki/VPN .
9. Дедупликация данных – http://en.wikipedia.org/wiki/Data_deduplication .

Вконтакте

Средства для резервного копирования информации можно разделить на несколько категорий:
- Для домашнего/офисного применения (резервирование важных документов, фотографий и пр. на NAS либо в облако);
- Для средних и крупных (offline) предприятий (резервирование важных документов, отчетности, баз данных и пр. как на серверах так и на рабочих станциях сотрудников);
- Для малых веб-проектов (резервирование файлов и баз данных с хостинговой площадки либо VPS/VDS на удаленный хост (или наоборот));
- Для крупных веб-проектов с распределенной архитектурой (почти то же самое, что и на offline-предприятиях только с учетом работы в глобальной сети, а не локальной, и как правило с использование open source средств).

С программными продуктами для дома и офиса все достаточно просто есть масса решений как открытых так и проприетарных, от cmd/bash скриптов до решений известных производителей ПО.
В enterprise секторе все достаточно скучно есть масса программных продуктов которые давно и успешно работают на многих предприятиях, в крупных банках и пр, рекламировать никого не будем . Многие из этих продуктов хорошо упростили жизнь системных администраторов, за достаточно «скромные деньги» по меркам некоторых предприятий.
В данной статье более подробно рассмотрим open source решения для резервного копирования веб-проектов разного масштаба, а также проведем тест на скорость резервирования файлов.
Статья будет полезна веб-мастерам, небольшим веб-студиям, ну и возможно даже бывалый админ найдет здесь что-то полезное.

Что нужно для резервирования небольшого сайта или блога, или нескольких сайтов, например с VPS-ки на которой дискового пространства впритык?
Напрашивается резервирование на удаленный хост. Т.е. чтобы сэкономить драгоценное место на вашем хостинге или VPS, вы можете подключаться, например со своего домашнего/офисного компьютера (возможно у вас есть NAS), по протоколам ftp или sftp, вручную или по расписанию забирать файлики и бережно складывать их каком-то надежном месте. Сойдет любой клиент ftp или sftp, хороший вариант rsync.

С Rsync выглядит это примерно так:
rsync -avzPch [email protected]:/path/to/copy /path/to/local/storage

И это вроде бы неплохо, но что если нужно хранить несколько версий бекапов БД? Или по каким-то причинам понадобилось делать инкрементальные копии, а еще бы неплохо и шифрование добавить. Можно немножко посидеть и сделать хороший велосипед скрипт под свои нужды (например наш rsync-backup), либо взять что-то из готовых утилит.

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

Duplicity консольная утилита для резервного копирования с достаточно широкими возможностями.
Существует несколько графических оболочек для Duplicity - Deja-dup для среды Gnome и test-drive для KDE. Также существует консольная обертка duply.

Duplicity производит бекап в зашифрованные тома в tar-формате локально или на удаленный хост. Делать инкрементальные записи файлов позволяет библиотека librsync, для компрессии используется gzip и gpg делает шифрование.
Конфигурационного файла нет. Автоматизировать процесс резервирования придется самому.

Примеры использования:

Резервирование локальной папки на удаленный хост
duplicity /usr scp://host.net/target_dir
Резервирование с удаленного хоста в локальную папку
duplicity sftp://[email protected]/var/www /home/backup/var/www
Восстановление
duplicity restore /home/backup/var/www sftp://[email protected]/var/www

Про rsnapshot также не мало сказано на Хабре, и . А еще хорошая статья. Rsnapshot в целом, хороший инструмент для создания инкрементальных бекапов (снапшотов). Написан на perl, использует rsync для копирования файлов. Достаточно быстрый (быстрее rdiff-backup) и неплохо экономит место на диске за счет жестких ссылок. Умеет делать pre и post-backup операции, не умеет (без костылей) шифровать и делать бекап на удаленный хост. Файлы хранятся в первозданном виде - легко восстанавливать. Достаточно удобно организовано конфигурирование. Поддерживает несколько временных уровней резервирования (дневной, недельный, месячный). Есть достаточно активное сообщество.

После того как вы пропишете в конфиге необходимые строки (что бекапить и куда), можно запустить бекап:
rsnapshot -v hourly
По умолчанию будет храниться несколько ежечасных и дневных снапшотов. От прочих утилит Rsnapshot отличается тем что он из коробки автоматизирован (актуально для Debian/Ubuntu), т.е. в крон пропишутся необходимые строки, а в конфиге прописано резервирование каталогов "/home", "/etc", "/usr/local"

Rdiff-backup очень похож на Rsnapshot, но в отличии от него написан на Python и использует библиотеку librsync для передачи данных. Умеет копировать файлы на удаленный хост, чем кстати мы довольно успешно пользовались и кое где еще пользуемся. Также можно делать бекап с удаленного хоста, но предварительно нужно установить там Rdiff-backup. Хранит информацию об изменениях файлов (дельты) в сжатом виде, хорошо для больших файлов, позволяет экономить место на диске даже по сравнению с rsnapshot.
Метаданные (права, даты, владелец) хранятся в отдельных файлах.
Запуск бекапа производится из консоли:
rdiff-backup remote.host::/home/web/sites/ /home/backup/rdiff/
Наличие конфигурационного файла не предполагается. Автоматизировать придется самому.

Obnam - открытое клиент-серверное приложение для резервного копирования, код программы написан на языке Python для передачи данных используется протокол SSH. Может эксплуатироваться в двух видах:
- Push резервирование с локального хоста на удаленный сервер на котором работает демон Obnam.
- Pull демон сам забирает файлы с удаленных хостов по протоколу ssh. В этом случае клиент Obnam не нужен.
Умеет делать снапшоты, дедупликацию и шифрование GnuPG. Резервные копии файлов хранятся в томах. Метаданные хранятся в отдельных файлах. Восстановление производится через консоль.

Небольшая выдержка из описания на Opennet (http://www.opennet.ru/opennews/art.shtml?num=39323):
«Предлагаемый в Obnam подход к резервному копированию нацелен на достижение трёх целей: обеспечение высокой эффективности хранения, простоты использования и безопасности. Эффективность хранения достигается благодаря размещению резервных копий в специальном репозитории, данные в котором хранятся в оптимальном представлении с использованием дедупликации. В одном репозитории могут храниться бэкапы разных клиентов и серверов. При этом объединение дубликатов осуществляется для всех хранимых бэкапов, независимо от их типа, времени создания и источника резервной копии. Для проверки целостности репозитория и его восстановления после сбоя предоставляется специальный вариант утилиты fsck.

Если на группе серверов используется одинаковая операционная система, то в репозитории будет сохранена только одна копия повторяющихся файлов, что позволяет существенно сэкономить дисковое пространство при организации резервного копирования большого числа типовых систем, например, виртуальных окружений. Репозиторий для хранения резервных копий может быть размещён как на локальном диске, так и на внешних серверах (для создания сервера для хранения резервных копий не требуется установка дополнительных программ, достаточно доступа по SFTP). Возможен доступ к резервным копиям через монтирование виртуального раздела при помощи специально подготовленного FUSE-модуля.»

Все это хорошо, НО для копирования на удаленный хост используется scp со всеми вытекающими.

Bacula - кроссплатформенное клиент-серверное программное обеспечение, позволяющее управлять резервным копированием, восстановлением, и проверкой данных по сети для компьютеров и операционных систем различных типов. На данный момент Bacula можно использовать практически на любых unix-подобных системах (Linux (включая zSeries), NetBSD, FreeBSD, OpenBSD, Solaris, HP-UX, Tru64, IRIX, Mac OS X) и на Microsoft Windows.

Bacula также может выполняться полностью на единственном компьютере или, распределённо, на нескольких, и может записывать резервные копии на различные типы носителей, включая ленты, ленточные библиотеки (autochangers/libraries) и диски.

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

К Bacula имеются GUI и веб-интерфейсы (Almir, Webmin) различной степени сложности.

Некоторое время назад мне пришлось сильно и безрезультатно повозится с Almir чтобы запустить его на Debian Wheezy.

Bacula это надежная проверенная временем система резервного копирования в том числе хорошо зарекомендовавшая себя на многих крупных предприятиях. От Obnam принципиально Bacula отличается схемой работы. В случае варианта клиент-сервер Bacula будет являться 100% централизованной системой. Также необходимо наличие клиентского приложения на хосте который нужно бекапить. На сервере работают одновременно три демона SD, FD. DIR - Storage Daemon, File Daemon и Director соответственно. Нетрудно догадаться кто за что отвечает.

Резервные копии файлов Bacula хранит в томах. Метаданные хранятся в БД (SQLite, MySQL, PostgreSQL) Восстановление производится с помощью консольной утилиты либо посредством графической оболочки. Процесс восстановления через консоль, прямо скажем, не самый удобный.

Цифры
Я решил проверить скорость резервирования небольшой папки (626M) с несколькими сайтами на WP.
Для этого я даже не поленился развернуть и настроить весь этот софт. :)
Тест состоит из двух частей:
1. Участники Duplicity, Rsync, Rsnapshot, Rdiff-Backup. Копируем с удаленного сервера на домашний компьютер, при этом поскольку Rsnapshot не умеет делать remote-бекап, то он и Rdiff-backup (для сравнения) будут работать домашней машине, т.е. будут тянуть (pull) с файлы с сервера, а остальные наоборот, будут толкать (push) на домашнюю машину.
Все утилиты запускались с минимально необходимыми опциями.

Rsync
rsync -az /home/web/sites/ home.host:/home/backup/rsync
Full backup
Время выполнения:
real 4m23.179s user 0m31.963s sys 0m2.165s
Incremental
Время выполнения
real 0m4.963s user 0m0.437s sys 0m0.562s
Занимаемое место:
626M /home/backup/duplicity/

Duplicity
duplicity full /home/web/sites/ rsync://home.host//home/backup/duplicity
Full backup
Время выполнения:
real 5m52.179s user 0m46.963s sys 0m4.165s
Incremental
Время выполнения
real 0m49.883s user 0m5.637s sys 0m0.562s
Занимаемое место:
450M /home/backup/duplicity/

Rsnapshot
rsnapshot -v hourly
Full backup
Время выполнения:
real 4m23.192s user 0m32.892s sys 0m2.185s
Incremental
Время выполнения
real 0m5.266s user 0m0.423s sys 0m0.656s
Занимаемое место:
626M /home/tmp/backup/rsnap/

Rdiff-backup
rdiff-backup remote.host::/home/web/sites/ /home/backup/rdiff/
Full backup
Время выполнения:
real 7m26.315s user 0m14.341s sys 0m3.661s
Incremental
Время выполнения
real 0m25.344s user 0m5.441s sys 0m0.060s
Занимаемое место:
638M /home/backup/rsnap/

Результаты достаточно предсказуемы. Самый быстрый оказался Rsync, практически такой же результат у Rsnapshot. Duplicity немного медленней но меньше занимает места на диске. Rdiff-backup ожидаемо хуже.

2. Теперь интересное. Проверим как работают Obnam и Bacula. Оба решения достаточно универсальны плюс имеют некоторые сходства. Посмотрим кто шустрее.
Obnam
Первый раз я запустил копирование с удаленного хоста на свой домашний, ждать пришлось долго:

Full backup
Backed up 23919 files, uploaded 489.7 MiB in 1h42m16s at 81.7 KiB/s average speed
Время выполнения:
real 102m16.469s user 1m23.161s sys 0m10.428s
obnam backup --repository sftp://home.host/home/backup/obnam/ /home/web/sites/
Incremental
Backed up 23919 files, uploaded 0.0 B in 3m8s at 0.0 B/s average speed
Время выполнения
real 3m8.230s user 0m4.593s sys 0m0.389s
Занимаемое место:
544M /home/tmp/backup/rsnap/
Не очень хороший результат как мне кажется, хотя понятный.
Попробуем второй раз, но уже на соседний сервер по гигабитной сети и добавим компрессию.

Full backup
Backed up 23919 files, uploaded 489.7 MiB in 2m15s at 3.6 MiB/s average speed
Время выполнения:
real 2m15.251s user 0m55.235s sys 0m6.299s
obnam backup --compress-with=deflate --repository sftp://remote.host/home/backup/obnam/ /home/web/sites/
Incremental
Backed up 23919 files, uploaded 0.0 B in 8s at 0.0 B/s average speed
Время выполнения
real 0m7.823s user 0m4.053s sys 0m0.253s
Занимаемое место:
434M /home/tmp/backup/rsnap/
Так побыстрее и размер бекапа поменьше. Шифрование я не стал пробовать, может быть позже, если будет время.

Bacula
Для Bacula я подготовил полноценный клиент-сервер вариант. Клиент и сервер в одной гигабитной сети.
Задание я запустил в фоновом режиме и пошел пить чай. Когда вернулся обнаружил, что уже все готово, а в логе следующее:
... Scheduled time: 23-Apr-2014 22:14:18 Start time: 23-Apr-2014 22:14:21 End time: 23-Apr-2014 22:14:34 Elapsed time: 13 secs Priority: 10 FD Files Written: 23,919 SD Files Written: 23,919 FD Bytes Written: 591,680,895 (591.6 MB) SD Bytes Written: 596,120,517 (596.1 MB) Rate: 45513.9 KB/s ...
Я даже немного удивился. Все сделалось за 13 секунд, следующий запуск прошел за одну секунду.

Итого
С помощью rsnapshot вы можете легко решить задачу резевного копирования файлов и БД (c дополнительным скриптом) вашего VPS на ваш домашний компьютер/ноутбук/NAS. Также неплохо rsnapshot справится с небольшим парком серверов 10-25 хостов (можно и больше конечно, зависит от вашего желания). Rdiff будет хорош для бекапа больших файлов (Видео-контент, базы данных и пр.)
Duplicity поможет не только сохранить ваши данные в целости но защитить их в случае кражи (к сожалению от себя самого защититься нельзя, будьте внимательны и осторожны, храните ключи в надежном и недоступном никому постороннему месте).
Bacula - open source промышленный стандарт, поможет держать в сохранности данные большого парка компьютеров и серверов любого предприятия.
Obnam интересный инструмент имеющих ряд полезных достоинств, но я пожалуй рекомендовать никому не буду.
Если же, вас все таки, по каким-то причинам, не устраивает ни одно из этих решений, не стесняйтесь изобретать свои велосипеды. Это может стать полезным как для вас лично, так и для многих людей.

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

Книга:

Разделы на этой странице:

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

на базе архитектуры;

на основе функциональных возможностей;

на базе сетевой инфраструктуры.

Рассмотрим каждый тип классификации подробнее.

5.3.1 Классификация резервного копирования на базе архитектуры

Один из типов классификации резервного копирования основан на архитектуре. Резервное копирование зависит от объектов, к которым оно применяется, и от того, насколько приложение резервного копирования поддерживает подобные объекты. Доступные архитектурные типы резервного копирования описаны в разделах 5.3.1.1–5.3.1.3.

5.3.1.1 Резервное копирование на уровне дисковых образов и логических блоков

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

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

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

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

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

5.3.1.2 Резервное копирование на уровне файлов

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

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

Еще один недостаток связан с безопасностью. Эта проблема возникает вне зависимости от метода создания резервной копии (на уровне образа или файла) и заключается в том, что резервное копирование выполняется на правах учетной записи администратора или оператора резервного копирования, а не пользователя. Это единственный способ восстановить файлы различных пользователей в ходе одной операции восстановления. Необходимым условием является корректная настройка метаданных файлов, например списков управления доступом и данных о владельцах файлов. Решение проблемы требует поддержки со стороны API файловой и операционной систем, что необходимо для настройки метаданных при восстановлении данных из резервной копии. Кроме того, приложение резервного копирования и восстановления должно корректно использовать предоставленные возможности.

5.3.1.3 Резервное копирование на уровне приложения

В этом случае резервное копирование и восстановление данных выполняется на уровне приложения, например Microsoft SQL Server или Microsoft Exchange.. Резервное копирование проводится с помощью API, предоставленного приложением. В данном случае резервная копия состоит из набора файлов и объектов, которые формируют состояние системы на определенный момент времени. Основная проблема заключается в том, что операции резервного копирования и восстановления тесно связаны с приложением. Если с выходом нового приложения изменится API или функции уже существующего API, администратору придется переходить к новой версии программы резервирования.

Приложения используют чистый диск без файловой системы или записывают на него огромный файл, в котором размещены собственные метаданные приложения. В качестве примера подобного приложения можно указать Microsoft Exchange. В Windows ХР и Windows Server 2003 поддерживаются важные функции NTFS, благодаря которым возможно восстановление таких файлов. Файл восстанавливаемся логическими блоками и в конце маркируется новой функцией Win32 API, которая называется SetFileValidData.

5.3.2 Классификация резервного копирования на базе функциональных возможностей

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

5.3.2.1 Полное резервное копирование

При полном резервном копировании (full backup) полный набор файлов или объектов, а также связанные с ними метаданные копируются на носитель резервной копии. Преимущество состоит в том, что используется только один набор носителей для восстановления в случае отказа в работе системы. Недостаток заключается во времени копирования, так как копируются все данные. Полное резервное копирование часто выполняется на уровне дискового образа или на уровне блоков.

5.3.2.2 Дифференциальное резервное копирование

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

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

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

5.3.2.3 Инкрементное резервное копирование

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

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

5.3.3 Классификация резервного копирования на основе сетевой инфраструктуры

Один из способов классификации резервного копирования основан на сетевой топологии и ее влиянии на выбор наилучшего метода резервирования подключенных узлов. Типы резервного копирования, зависящие от сетевой инфраструктуры (резервирование DAS, NAS, SAN, не зависящее от локальной сети и от сервера) рассматриваются в разделах 5.3.3.1–5.3.3.4.

5.3.3.1 Резервирование DAS

Эта старейшая разновидность резервного копирования возникла- во времена, когда устройства хранения подключались непосредственно к серверу. Несмотря на развитие сетевых устройств хранения, резервирование DAS остается достаточно популярным для копирования данных, размещенных на серверах Windows. Схема резервирования DAS представлена на рис. 5.3. / Преимуществом резервирования DAS является простота его использования. Приложение на сервере считывает данные с соответствующего дйсково- го тома и записывает их на магнитную ленту. Однако резервирование DAS имеет ряд недостатков.

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

Высокая общая стоимость владения (ТСО), так как для резервного копирования с помощью нескольких накопителей на магнитной ленте требуется иметь в штате несколько администраторов.

Хранение нескольких лент может привести к путанице.

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

Рис. 5.3. Резервирование DAS

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

5.3.3.2 Резервирование NAS

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

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

Резервированию NAS свойственны некоторые недостатки.

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

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

Рис. 5.4. Схема резервирования NAS

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

5.3.3.3 Резервирование SAN

Развитие сетей хранения данных привело к появлению новых концепций резервного копирования. Новые возможности основаны та том, что сеть хранения данных может обеспечить достаточную пропускную способность между любыми двумя устройствами и, в зависимости от топологии, способна предоставить одновременную связь с малыми задержками между несколькими парами устройств. С другой стороны, использование топологии кольца Fibre Channel с количеством устройств больше 30 не дает возможности создавать несколько соединений с высокой пропускной способностью и малыми задержками, так как общая пропускная способность кольца будет совместно разделена между всеми подключенными устройствами.

На рис. 5.5 представлена архитектура типичного приложения SAN для резервного копирования. Обратите внимание на мост Fibre Channel. Большинство накопителей на магнитной ленте не поддерживают интерфейс Fibre Channel (они используют параллельный интерфейс SCSI), поэтому для подключения таких устройств понадобится мост. На рис. 5.5 серверы Windows NT подключены одновременно к локальной сети и к сети хранения данных.

Топология резервного копирования (см. рис. 5.5) имеет ряд преимуществ.

Накопитель на магнитной ленте может находиться довольно далеко от сервера, данные которого резервируются. Такие накопители обычно оснащены интерфейсом SCSI, хотя в последнее время всё чаще появляются накопители с интерфейсом Fibre Channel. Это означает, что их можно подключать только к одной шине SCSI, в результате чего усложняется совместное использование накопителя несколькими серверами. Сети хранения данных на основе Fibre Channel благодаря поддержке различных устройств позволяют успешно решать проблемы совместного использования. Обратите внимание: при этом все равно требуется метод, обеспечивающий корректный доступ к накопителю на магнитной ленте с использованием соответствующих разрешений. Примеры подобных методов представлены ниже.

Рис. 5.5. Резервное копирование средствами сети хр&нения данных

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

Следующий метод – использование таких команд интерфейса SCSI, как Reserve и Release.

Метод подключения накопителя на магнитной ленте к серверу позволяет получить совместный доступ к устройству посредством специального программного обеспечения сервера. Совместное использование накопителя на магнитной ленте является весьма привлекательным решением, поскольку накопители – довольно дорогие устройства. К описанным накопителям относится, например, устройство Tivoli от компании IBM.

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

Резервное копирование без локальной сети позволяет более эффективно использовать ресурсы с помощью совместного использования накопителей на магнитной ленте.

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

Наконец, операции резервного копирования и восстановления завершаются значительно быстрее, так как сети хранения данных обеспечивают более высокую скорость передачи данных.

5.3.3.4 Резервирование, не зависящее от сервера

Такое резервное копирование иногда называют резервным копированием без сервера или даже сторонним копированием. Обратите внимание, что резервное копирование, не зависящее от сервера, обычно представляет собой резервирование, не зависящее от локальной сети, что избавляет от необходимости перемещать данные с определенного узла. Идея такого способа резервного копирования состоит в применении команды SCSI Extended Copy.

В основе резервного копирования, не зависящего от сервера, лежит инициатива ассоциации SNIA, которая была реализована в командах SCSI Extended Сору, утвержденных комитетом INCITS, а точнее, техническим подкомитетом Т10 (документ ANSI INCITS.351:2001, SCSI Primary Commands-2). Обратите внимание: в стандарте SCSI уже описывалась поддержка команд копирования, однако ранее для использования команд требовалось подключение всех устройств SCSI к одной шине (с тех пор команда Сору считается устаревшей; более подробная информация представлена на Web-узле http: //www.110. org). Команда Extended Copy добавляет такие дополнительные возможности, как использование источника и пункта назначения данных через различные шины SCSI. При этом в полной мере сохраняется адресация, поддерживаемая синтаксисом команды.

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

Рис. 5.6. Резервное копирование, не зависящее от сервера

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

Принцип резервного копирования, не зависящего от сервера, демонстрируется на рис. 5.6. Для упрощения схемы на рисунке показано минимальное количество компонентов, необходимых для иллюстрации резервного копирования. На практике сети хранения данных имеют более сложную структуру. На рис. 5.6 показан сервер под управлением Windows, подключенный к коммутатору Fibre Channel с помощью адаптера шины Fibre Channel. Кроме того, используется маршрутизатор Fibre Channel-K-SCSI, к которому подключается накопитель на магнитной ленте с интерфейсом SCSI и дисковые устройства. Дисковые и ленточные устройства не обязательно должны подключаться к одному маршрутизатору.

Приложение сервера резервного копирования на сервере Windows находит агента перемещения данных на маршрутизаторе с помощью технологии Plug and Play. Приложение резервного копирования определяет дополнительную информацию о резервировании (идентификатор дискового устройства, начальный логический блок, объем копируемых данных и т.д.). Программное обеспечение сервера резервирования изначально передает последовательность команд накопителю на магнитной ленте для резервирования устройства и монтирования необходимого носителя. Далее программное обеспечение сервера резервного копирования передает команду Extended Сору агенту перемещения данных, который выполняется на маршрутизаторе. Агент координирует перенос необходимых данных. По завершении копирования агент возвращает сервисную информацию программе резервирования, выполняемой на сервере Windows.

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

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

Точка назначения данных обычно представляет собой накопитель на магнитной ленте, на который записываются данные. В качестве устройства может выступать диск, если резервное копирование выполняется на диск, а не на ленту. Ленточные устройства обычно подключены к порту связной архитектуры, чтобы избежать повреждения данных, передаваемых на ленту, в случае отказа других частей сети хранения данных. Например, если накопитель на магнитной ленте подключен к кольцу Fibre Channel с разделением доступа, ошибка в работе другого устройства или подключение/отключение устройства от кольца может привести к остановке записи данных и повторной инициализации кольца, что нарушит целостность данных, записываемых на ленту.

Агент перемещения данных обычно встраивается в маршрутизатор с помощью прошивки, так как он должен обрабатывать команду SCSI Extended Сору, которая отправляется маршрутизатору в виде пакета Fibre Channel. Коммутаторы и концентраторы, обрабатывающие только заголовок кадра Fibre Channel, не совсем подходят для поддержки работы агента перемещения данных, однако в будущем это может измениться.

Агент перемещения данных активизируется после получения инструкций от сервера резервного копирования. Большинство накопителей на магнитной ленте, подключенных к SAN, представляют собой устройства SCSI. Поэтому требуется наличие маршрутизатора, который поддерживает преобразование пакетов между интерфейсами Fibre Channel и SCSI. На данный момент все чаще появляются накопители на магнитной ленте с интерфейсом Fibre Channel, а некоторые компании, например Exabyte, предоставляют прошивки для подобных накопителей, добавляющие функции агента перемещения данных. Кроме того, базовые библиотеки накопителей на магнитной ленте с интерфейсом Fibre Channel обычно имеют встроенные маршрутизаторы Fibre Channel-SCSI, что позволяет библиотеке использовать собственный агент перемещения данных. Обратите внимание, что агент может быть реализован в программном обеспечении младшей рабочей станции или даже сервера. Компании Crossroads, Pathlight (теперь ADIC) и Chaparral предоставляют маршрутизаторы со встроенными в прошивку агентами перемещения данных. Сеть хранения данных может иметь несколько агентов от нескольких производителей, что не мешает агентам сосуществовать в одной сети.

Конечно, для того чтобы агент перемещения данных можно было использовать, его нужно найти (с помощью команды SCSI Report LUNs) и обеспечить должную адресацию (посредством имени WWN) с сервера резервного копирования. Кроме того, агент может проводить два резервных копирования одновременно. Например, один сеанс копирования может проводиться на географически удаленный зеркальный ресурс, однако для этого сервер резервирования должен передать две команды.

Сервер резервного копирования отвечает за все команды и управление операциями. Перечислим еще раз все основные обязанности сервера резервирования.

Программное обеспечение сервера обеспечивает доступность накопителя на магнитной ленте, применяя соответствующие команды SCSI Reserve и Release.

Монтирование носителя для резервного копирования.

Определение точного адреса источника данных и размещения данных в логических блоках, а также объема данных для резервирования.

Получив всю необходимую информацию, сервер отправляет команду Extended Сору агенту перемещения данных. Затем агент отправляет последовательность команд Read источнику данных и записывает информацию в точке назначения.

Компании Computer Associates, CommVault, LEGATO и VERITAS предоставляют программы для резервирования, не зависящего от сервера. Поставщики маршрутизаторов с функциями резервного копирования, не зависящего от сервера, постоянно сотрудничают с компаниями – разработчиками программного обеспечения, чтобы сделать возможной совместимость своих продуктов. Дело в том, что для поддержки базовых команд SCSI Extended Copy производителями применяются различные команды.

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

5.3.3.5 Семейство операционных систем Windows Server и резервное копирование, не зависящее от сервера

В многочисленных рекламных материалах и маркетинговой литературе утверждается, что конкретный метод внедрения технологии резервного копирования, не зависящего от"сервера, совместим с Windows 2000. Рассмотрим эту концепцию более подробно. Далее описывается каждый из четырех компонентов, формирующих резервирование, не зависящее от сервера: источник данных, точка назначения данных, программное обеспечение сервера резервирования и агент перемещения данных.

В большинстве случаев агент перемещения данных, работающий вне сервера Windows NT, не может адресовать данные, хранящиеся на сервере Windows NT. Адаптеры шины, подключенные к серверу Windows NT, обычно работают, как инициаторы и не отвечают на команды Report LUNs. Если сервер Windows NT использует устройство хранения за пределами сервера, например массив RAID, подключенный к коммутатору Fibre Channel, то это устройство будет доступно агенту перемещения. Поэтому вместо утверждений о том, что устройство хранения, используемое Windows NT, не может быть источником данных для резервирования, не зависящего от сервера, следует уточнить, что источником данных не может быть устройство хранения, которое является внутренним для сервера Windows NT.

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

Выполнение программы резервирования на компьютере под управлением Windows представляет собой неплохой вариант. Адаптер шины, подключенный к серверу Windows, может выдать последовательность команд Report LUNs каждому устройству (LUN 0), которое будет обнаружено. Затем программа резервирования просматривает все видимые устройства и логические единицы, после чего выясняет, какие из них могут выступать в роли агента стороннего копирования. Некоторые программы сообщают о дополнительных LUN, которые необходимы при выдаче команд Extended Сору. Множество программ резервирования, которые используют дополнительные LUN, проходят через процесс обнаружения устройств для проверки функций агента перемещения данных.

Промежуточный интерфейс SCSI (IOCTL) в Windows NT может использоваться для передачи команды Extended Сору агенту перемещения данных (команда передается с сервера резервного копирования под управлением Windows NT). Операционная система Windows NT не имеет встроенной поддержки агентов перемещения; технология Plug dnd Play позволяет обнаружить агент, но для регистрации последнего в системном реестре необходимы дополнительные драйверы.

Остается последний вопрос: можно ли запустить программное обеспечение агента перемещения данных на сервере или рабочей станции под управлением Windows NT? Одним из преимуществ такого решения является то, что агент перемещения сможет адресовать устройства хранения, «видимые» для сервера Windows, а также получать к ним доступ. Но сервер резервного копирования, размещенный вне Windows NT, не сможет обнаружить устройства хранения, подключенные к компьютеру с агентом перемещения данных. Агент должен иметь возможность работать в качестве инициатора и целевого устройства для команд SCSI. Поскольку адаптер шины, подключенный к компьютеру под управлением Windows NT, редко выполняет роль целевого устройства, команда Extended Сору может не дойти до агента перемещения данных.

Обратите внимание: в Windows NT для выдачи команд SCSI приложения используют промежуточный интерфейс (DeviceloControl с параметром IoControlCode, равным IOCTOL_SCSI_PASS__THROUGH или IOCTL_SCSI_PASS_ THROUGH_DIRECT).