Книга: Серверные технологии хранения данных в среде Windows® 2000 Windows® Server 2003

5.2 Проблемы при резервном копировании

5.2 Проблемы при резервном копировании

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

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

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

Невозможность резервного копирования файлов, которые открыты и активно используются приложениями.

Более подробно эти проблемы рассматриваются в разделах 5.2.1–5.2.3.

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

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

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

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

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

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

1. Запрет приложениям доступа к диску в процессе резервного копирования. Блокирование одновременного доступа пользователей к диску во время резервного копирования было достаточно распространенным на раннем этапе использования персональных компьютеров, когда работа в режиме 24x7 не практиковалась. Резервное копирование выполнялось в периоды пониженной нагрузки, например в ночные часы. Теперь этот подход не всегда возможен, и тому есть ряд причин.

Рис. 5.1. Экспоненциальное увеличение количества API для резервного копирования

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

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

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

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

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

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

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

Обратите внимание на уровни драйверов, показанные на рис. 5.2 (подробное описание драйверов Windows, объектов устройств и т.д. приводится в главе 1). Драйверы фильтрации файловой системы размещены над драйвером файловой системы NT (NTFS), который, в свою очередь, расположен над драйвером фильтрации диска. Последний находится над драйвером класса диска, ниже которого находятся и другие драйверы (см. главу 1), однако в данном случае они нас не интересуют. Как только приложение открывает файл, NTFS (в ответ на запрос приложения) отправляет последовательность команд для чтения метаданных (расположение файла на диске) и отправляет запросы на чтение и запись логических блоков, где хранится этот файл.

Рис. 5.2. Драйверы фильтрации Windows NT

Драйвер фильтрации верхнего уровня (он расположен над файловой системой) показан на рис. 5.2. Расположение этого драйвера идеально подходит для перехвата выполняемых над файлами операций и перенаправления вызовов, если это необходимо для решения проблемы резервного копирования открытых файлов. Компания Microsoft предлагает набор Windows Installable File System (IFS), в котором представлена информация, необходимая для написания подобного драйвера фильтрации. Разработчики программ резервного копирования могут решить проблему на более низком уровне; например, уровень образа обычно требует создания драйвера фильтрации нижнего уровня (он находится над драйвером класса диска), что показано на рис. 5.2.

Операции ввода-вывода (см. рис. 5.2) выполняются на уровне файловой системы, что показано стрелкой, обозначенной цифрой 1. Драйвер NTFS управляет отображением данных файла на дисковые блоки; операции ввода-вывода выполняются на уровне дисковых блоков, что показано стрелкой, обозначенной цифрой 2. Компания Microsoft предоставляет драйвер фильтрации diskperf. sys, который входит в набор разработки Windows Driver Development Kit (DDK). Несколько поставщиков систем резервного копирования использовали набор DDK для создания программ, с помощью которых выполняется моментальный снимок данных.

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

Оглавление книги