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

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

Системы резервного копирования это программно-аппаратные комплексы, предназначенные для:

• проведения регулярного автоматического копирования как системных данных, так и данных, создаваемых пользователями, на специально предназначенные для этого накопители;
• оперативного восстановления данных ( в случае утери или по каким то другим причинам).

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

Большинство систем резервного копирования в качестве внешних носителей поддерживают только накопители на магнитных лентах (устройства с последовательным доступом). Кроме простых программ в UNIX, наподобие dump, cpio, tar, все остальные работают в архитектуре клиент-сервер и состоят из трех типов компонентов:

• сервер системы,
• консоль управления,
• агенты резервного копирования.

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

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

Чтобы не повторять прописные истины, мы не станем подробно разбирать само собой разумеющиеся требования, такие как поддержка всех основных сетевых и клиентских ОС или ведение подробных журналов выполняемых операций и сообщений. Несмотря на самоочевидность такого требования, как надежность работы самой программы резервного копирования, здесь, к сожалению, не все так просто. Если в среде Windows NT и UNIX дела обстоят более или менее гладко, то NetWare может серьезно затруднить выполняемую задачу. Существует аксиома, что чем больше на компьютере выполняется программ, тем он менее устойчив в работе. Это особенно наглядно проявляется в случае NetWare. Следует помнить, что отладка надежной работы программы в NetWare занимает гораздо больше времени, чем в случае Windows NT или UNIX. Среди других очевидных требований можно назвать наличие фильтров для копирования и восстановления данных, возможность задания отличного от первоначального места восстановления данных, использование календаря при запуске процедур и ряд других требований.

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

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

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

Разные системы задействуют различные критерии для определения модификации файла со времени последнего резервного копирования. Самым распространенным способом в среде DOS, Windows и NetWare является использование атрибута Archive. При создании или модифицировании файла данный атрибут автоматически выставляется прикладными программами. При резервном копировании этот атрибут убирается. Поэтому теоретически система резервного копирования может таким образом определить, что файл еще не копировался на ленту. Ряд прикладных программ принудительно убирают этот атрибут при работе с файлами. Таким образом, система резервного копирования будет считать, что у файла есть копия на ленте, хотя это и не так. Это ведет к опасности того, что файлы окажутся вообще без резервных копий. Кроме того, здесь возможна и иная неприятная ситуация. Если файл восстановлен с резервной копии, то он получает атрибут Archive, хотя его копия на ленте уже существует. Вдобавок, ряд прикладных программ при обращении к файлам выставляют этот атрибут, даже если файл не модифицировался.

И при инкрементальном или дифференциальном резервном копировании файлы копируются повторно, в результате длительность процедуры копирования возрастает.

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

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

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

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

Вполне достаточно пару-тройку раз (желательно, не сразу, а через некоторое время) обратиться к файлу. И если он не будет закрыт, то прекратить бесплодные попытки. Разумеется, все такие случаи должны быть зафиксированы в журнале сообщений. Лучшим лекарством от наличия открытых файлов до сих пор остается резервное копирование в ночное время и в выходные дни.

Чтобы система резервного копирования могла работать длительное время в автоматическом режиме (в пределах недельного или месячного цикла), она должна поддерживать автозагрузчики и библиотеки. Неплохо, если система может работать с массивами RAID на магнитных лентах, а также если в ее состав входят антивирусные средства. Важна и встроенная поддержка типовых схем ротации картриджей магнитных лент. Хорошая система должна сама маркировать картриджи, поддерживать штрих-коды, назначать уникальные идентификаторы лент для разных процедур копирования. Желательно, чтобы процедуры резервного копирования/восстановления данных можно было инициализировать как с агента резервного копирования, так и с сервера. Только система, удовлетворяющая подобному перечню требований, может считаться подходящей для сетевой среды.

Требования к восстановлению данных

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

Некоторые системы начального уровня (в частности, SBACKUP) восстанавливают стертые файлы. Допустим, на томе VOL1 сервера NetWare имелись каталоги DIR1 и DIR2. После полного резервного копирования их содержимое было перенесено на ленту. Далее нужда в этих каталогах исчезла, и они были удалены (заметьте, специально, а не случайно). Обновленную информацию с помощью инкрементального (или дифференциального) копирования поместили на ленту. Но после восстановления с полной резервной и далее инкрементальной копии они вновь появятся на диске. К каким последствиям это может привести? Во-первых, диски оказываются засоренными ненужными файлами, с которыми администратору придется разбираться отдельно. Во-вторых, места для восстановления данных может просто не хватить. И чем реже проводится полное резервное копирование, тем хуже. Если в такой ситуации восстанавливается том SYS, то это запросто может привести к краху всей системы.

Требования к архивированию

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

Лучшим выбором будет циклическая схема ротации всех картриджей в пределах срока архивации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Традиционно в своих решениях для систем резервного копирования компания «Инфосистемы Джет» ориентируется на продукты, предлагаемые компанией Sun (сама компания не производит аппаратные средства для резервного копирования, а предлагает устройства таких производителей, как, например, Quantum или Hewlett-Packard). Это разнообразные устройства, использующие в том числе упомянутые выше популярные технологии, которые обеспечивают быструю, надежную и экономически эффективную защиту данных. Ленточные библиотеки семейства Sun StorEdge позволяют организовывать резервное копирование в серверных комплексах любого масштаба. Примерами таких устройств могут служить:

Sun StorEdge L1000 – ленточная библиотека (рис. 2), предназначенная для резервного копирования в серверных комплексах масштаба рабочей группы или отделения.

Технические характеристики:

• Емкость до 1,05 Тбайт без компрессии.
• До 4 устройств записи.
• Используемая технология – DLT7000.
• Кассеты – тип IV, емкость 35 Гбайт, количество – до 30 штук.

Sun StorEdge L11000 – ленточная библиотека (рис.3), предназначенная для резервного копирования в серверных комплексах масштаба предприятия.

Технические характеристики:

• Емкость до 11,8 Тбайт без компрессии.
• До 16 устройств записи.
• Используемая технология – DLT7000.
• Кассеты – тип IV, емкость 35 Гбайт, количество – до 326 штук.

Новая серия ленточных библиотек на основе технологии DLT7000, объявленная в июле 2000г., включает такие продукты как L20, L40, L60, отличающиеся модульной конструкцией; вместе с ними была объявлена небольшая, предназначенная для систем масштаба рабочей группы, библиотека L9 (рис.4), использующая технологию DLT8000.

Рост объема хранимых данных привел к появлению систем, способных хранить «петабайты» (PB) информации. Это целые комплексы ленточных библиотек. Как одно из «экзотических» свойств некоторых из этих устройств, можно упомянуть возможность передачи кассет из одной библиотеки в другую аппаратными средствами.

Появление сетей хранения данных (Storage Area Networks, SAN) отразилось и на средствах резервного копирования. Наиболее привлекательными в данном случае являются высокая пропускная способность сети (значение этого фактора повышается при централизации хранения данных, росте их объема и разнообразия), ее независимость от локальной сети (стремление уменьшить возможные потери данных заставляет чаще выполнять резервное копирование, увеличивая при этом нагрузку на сеть), возможность размещать узлы на большом расстоянии друг от друга (необходимое условие при защите от таких факторов как пожар и т.п.). Существует возможность разгрузить не только локальную сеть, но и серверы, если передавать данные непосредственно с дисковых массивов на устройства резервного копирования.

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

• Подключение существующих устройств через FC-to-SCSI мост (bridge).
• Разработка устройств с FC-интерфейсом.

Большинство современных решений основаны на использовании FC-to-SCSI мостов (такие решения предлагаются компаниями Compaq, Hewlett-Packard, Sun и др.). Это позволяет подключать к сетям хранения данных большое количество существующих SCSI-устройств. Вместе с тем, в ряде существующих ленточных библиотек предусмотрена возможность установки FC-AL хост-адаптера, позволяющего им подключаться к сети хранения данных непосредственно, без использования устройств типа «мост» (bridge). Правда, их использование тормозится из-за несовершенства устройств, используемых в сетях на основе технологии Fibre Channel.

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

Аналитики из компании GartnerGroup считают, что продолжится тенденция к централизации обработки и хранения данных, это приведет к необходимости повышения производительности и надежности используемых систем. Кроме того, продолжающийся экспоненциальный рост объема данных явится серьезным испытанием для сетей передачи данных и систем ввода/вывода. Внедрение сетей хранения данных, интеллектуальных серверов хранения данных, а также новых средств удаленной репликации данных в оперативном режиме позволит уменьшить остроту прогнозируемых проблем. Необходимость резервного копирования привела к большому разнообразию средств его выполнения. Это относится как к аппаратным, так и к программным средствам. Действительно, существует множество форматов записи, моделей кассет, устройств записи, роботизированных библиотек; кроме того, существуют как простейшие (в том числе поставляемые в составе операционных систем) средства управления копированием, так и самостоятельные системы, позволяющие управлять операциями по защите данных в масштабах большой фирмы с глобально распределенными филиалами; существуют также средства, встраиваемые в прикладные продукты, например, в системы управления базами данных.

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

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

Компания «Инфосистемы Джет» предпочитает использовать в своих решениях средства управления резервным копированием от таких известных производителей программного обеспечения, как фирмы VERITAS и Legato.

Рассмотрим эти средства более подробно.

Legato Networker

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

В соответствии с архитектурой клиент/сервер ПО Networker состоит из двух основных компонентов – серверной и клиентской частей.

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

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

Для снижения сетевого трафика во время проведения резервного копирования и снижения нагрузки на сервер СРК, ПО Networker позволяет вводить в состав СРК специальные серверы – storage node. Storage node представляет собой сервер, к которому подключаются несколько архивационных накопителей. Storage node обеспечивает резервное копирование заданных администратором клиентов на свои накопители, при этом информация (индексы) о скопированных данных записывается на центральный сервер СРК, что обеспечивает централизованное управление всей СРК.

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

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

Функциональные возможности СРК LegatoNetworker

Networker поддерживает более 40 операционных систем, что позволяет создать единую СРК, обеспечивающую защиту всех серверов и

станций предприятия. Поддерживаемые операционные системы: Windows-NT (на платформах Intel и Alpha), Windows-95, Windows-98, Windows for Workgroup, DOS, Net Ware, OS/2, OC/2 Warp, MacOC, Solaris, SunOC, HP-UX, IBM-AIX, Digital UNIX, SGI ARIX, SCO UNIX, UNIX Ware и другие.

Networker обеспечивает резервное копирование системных данных: для UNIX -ACLs и скрытые системные файлы, для Windows NT – системные файлы, name spaces, local, remote registries, для NetWare – bindery, NDS, name spaces.

Проведение резервного копирования СУБД , приложений и файлов в «горячем режиме». Networker обеспечивает с помощью опционального модуля BusinesSuite Module резервное копирование СУБД и приложений в «горячем режиме» – без прерывания работы приложений и пользователей. Поддерживаемые на сегодня приложения: MS SQL Server, MS Exchenge, Oracle, Informix, DB2, Lotus Notes, Sybase, SAP R3 on Oracle. Для остальных приложений и файлов (на серверах Windows-NT и NetWare) также возможно проведение резервного копирования в «горячем режиме» – с помощью опционального модуля Open File Manager.

Networker поддерживает наиболее широкий список накопителей для проведения резервного копирования, по сравнению с другими СРК. Поддерживаются ленточные накопители и ленточные библиотеки форматов QIC/Travan, 8mm, DAT, DLT,а также оптические накопители и накопители различных производителей. Кроме того, поддерживаются наиболее высокоскоростные ленточные библиотеки – Storage Tek Redwood, Ampex, DST, IBM 3590 Magstar.

Модульная наращиваемая архитектура.

Архитектура ПО Networker позволяет по мере расширения сети и изменений требований к СРК увеличивать число серверов СРК, клиентов, storage nodes, добавлять архивационные устройства, а также модули, поддерживающие HSM, ведение архива, «горячего архивирования» СУБД приложений и файлов и другие – без снижения производительности СРК.

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

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

VERITAS NetBackup

Продукт VERITAS NetBackup очень близок по функциональности и по списку поддерживаемых устройств продукту Legato Networker. Вместе с тем изначально оба эти продукта были ориентированы на предприятия разного уровня. NetBackup – на крупные, с удаленными филиалами, а Networker – на средние (у которых либо нет филиалов, либо нет необходимости в управлении комплексом серверов резервного копирования), а также на комплексы масштаба рабочей группы. В дальнейшем Networker приобрел средства управления копированием в распределенных филиалах, а фирма VERITAS создала варианты ПО NetBackup для средних и малых предприятий, а также для мобильных пользователей.

Продукт VERITAS NetBackup может управлять группами серверов резервного копирования (т.е. серверами, имеющими в своем составе устройства резервного копирования и способные выполнять как копирование локальных данных, так и данных с удаленных клиентов, по сети, рис.5) и разнообразными устройствами (в том числе встроенными и внешними устройствами записи на ленту, роботизированными ленточными библиотеками и автозагрузчиками, дисками и дисковыми массивами). Для него разработаны модули, обеспечивающие взаимодействие с клиентами на разных платформах (UNIX, PC и др.) и со всеми основными системами управления базами данных (Oracle, Informix, Sybase и др.)

К основным особенностям продуктов такого класса как Networker и NetBackup можно отнести:

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

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

Сжатие и шифрование информации.

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

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

Instant Image

Компания Sun Microsystems продолжает развитие серии программных продуктов, предназначенных для решения отдельных задач, связанных с защитой информации. Так, например, разработан продукт Instant Image, позволяющий создавать фиксированные на определенный момент времени копии файловых систем (snapshot), немедленное восстановление данных, тестирование, разработку и работу класса Data Warehouse параллельно текущим операциям, не оказывая влияние на их круглосуточное проведение.

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

До появления программного обеспечения Sun StorEdge Instant Image, например, основные приложения предприятия должны были быть остановлены на несколько часов на время проведения рутинной процедуры архивации данных.

Программное обеспечение Sun StorEdge Instant Image улучшает производительность и повышает уровень доступности приложений, предоставляя имеющий точную дату образ данных. Этот образ данных оказывается доступным для последующей обработки одновременно с функционированием всей системы обработки данных. Этот имеющий точную дату образ данных может быть размещен на той же подсистеме хранения данных, что и сами данные, или на любой другой подсистеме, подключенной к серверу Sun Enterprise, на котором работает программное обеспечение Sun StorEdge Instant Image. Отличия между основными данными и их имеющим точную дату образом затем отслеживается программным обеспечением, для того, чтобы обеспечить возможность мгновенного обновления, или ресинхронизации данных, без необходимости выполнять длительные операции по копированию с диска на диск.

Как ожидается, программное обеспечение Sun StorEdge Instant Image станет одним из первых интеллектуальных продуктов для управления системами хранения данных, который будет совместим с платформой Jiro. Jiro – среда разработки систем управления, основанная на Java-технологии. Спецификация, разработка которой началась в декабре 1998 года, сейчас поддерживается более чем 30 производителями программного и аппаратного обеспечения для систем хранения данных. Платформа Jiro легко взаимодействует с другими платформами и позволяет автоматизировать управление службами дополнительных устройств и приложений в сети, таким образом давая разработчикам возможность сосредоточиться на функциональности, а не на взаимодействии с другими платформами.

Программное обеспечение Sun StorEdge Instant Image уже доступно у прямых и непрямых партнеров компании. Программное обеспечение поддерживается широким спектром серверов Sun Enterprise и систем хранения данных Sun StorEdge.

Аналогичные по назначению средства есть и у других производителей программного обеспечения для систем хранения и резервного копирования данных. В качестве примера можно привести snapshot, разные варианты которого реализованы в файловой системе фирмы VERITAS и в ее же продукте Volume Manager. Такие продукты позволяют создавать множественные корректные копии файловых систем и специальный кэш, куда будут записываться изменения, без остановки процессов обработки данных. То есть данные будут постоянно доступными даже в процессе выполнения резервного копирования (основная файловая система копируется, а изменения записываются в специальный кэш, после окончания копирования изменения переносятся в основную файловую систему).

VERITAS NetBackup Shared Storage Option

Фирма VERITAS совместно с фирмой Sun предложили решение (VERITAS NetBackup Shared Storage Option), которое позволяет в сети хранения данных динамически разделять устройства резервного копирования между множеством серверов, работающих под управлением ОС UNIX или Windows NT. При этом может автоматически выполняться распределение нагрузки между устройствами резервного копирования (ленточными или дисковыми). Этот программный продукт обеспечивает полную разгрузку локальной сети от передачи данных при резервном копировании (или восстановлении потерянных данных). Увеличение производительности устройств резервного копирования способствует сокращению интервалов времени, выделяемых для выполнения копирования, а увеличение количества этих устройств позволяет обслуживать большее количество запросов на копирование/восстановление в единицу времени. Это решение может служить основой для систем, в которых передача копируемых данных будет выполняться без участия управляющего сервера, что, в свою очередь, позволит снизить общую стоимость владения системой.

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

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

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

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

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

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

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

Такой протокол был разработан и в последнее время находит все большее распространение. Появились версии популярных систем резервного копирования (например, Legato Networker и VERITAS NetBackup) и аппаратура, поддерживающие его.

Протокол NDMP

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

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

В спецификации протокола NDMP используются следующие термины:

NDMP-клиент – приложение, которое управляет NDMP-сервером

NDMP-хост – хост, на котором работает NDMP-сервер

NDMP-сервер – процесс на NDMP-хосте, которым управляют при помощи протокола NDMP, для каждого соединения с NDMP-хостом существует свой NDMP-сервер

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

В простейшем случае NDMP-клиент копирует данные с NDMP-хоста на присоединенное к нему устройство.

Возможно одновременное копирование на несколько устройств, подключенных к NDMPхосту, при этом на NDMP-хосте будут существовать несколько NDMP-серверов.

При работе с ленточной библиотекой для управления роботизированными устройствами на NDMP-хосте запускается отдельный NDMPсервер.

Имеется возможность выполнять копирование данных с NDMP-хоста, не имеющего своих устройств копирования, на NDMP-хост, оснащенный такими устройствами, через TCP/IP соединение.

Поддерживается копирование с ленты на ленту и с диска на диск между двумя NDMP-серверами.

NDMP-сервер предоставляет два сервиса: сервер данных и ленточный сервер.

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

Ленточный сервер читает поток NDMPданных и записывает его на ленту, либо читает данные с ленты и генерирует поток NDMP-данных, в зависимости от того, выполняется копирование или восстановление данных. В задачу ленточного сервера не входит обеспечение различных форматов копирования (например, dump или tar), но входит управление ленточными устройствами.

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

Перспективы развития

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

Ряд компаний продолжают разработку новых технологий записи на магнитную ленту, которые позволят существенно увеличить как объем хранимых данных, так и пропускную способность подсистемы резервного копирования. Примерами могут служить технология SuperDLT (SDLT), разрабатываемая компанией Quantum и технология LTO, поддерживаемая компаниями Hewlett-Packard, IBM, Seagate и рядом других производителей. О реальных характеристиках устройств, использующих эти технологии, можно будет говорить позднее, возможно, в 2001 году.

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

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

Кроме того, эти продукты должны поддерживать работу в сетях хранения данных (SAN).

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

Существуют разнообразные программные реализации этой технологии (Sun Instant Image, VERITAS Volume Manager, Flash Backup), существенно различающиеся используемыми в них средствами и, как следствие, возможностями.

Иногда говорят об аппаратных реализациях идеи snapshot, но реально они представляют собой варианты технологии зеркалирования (EMC Symmetrix, HP XP).

Компания VERITAS собирается поддерживать все перечисленные варианты.

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

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