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

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

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

Книга:

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

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

Данная программа называется Handy Backup, ее разработчиком является компания «Новософт» (сайт программы – www.handybackup.ru). Программа является условно-бесплатной: ее демонстрационную версию можно скачать на сайте разработчика. К скачиванию предлагается дистрибутив объемом около 12,5 Мб.

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

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

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

6.3.1. Функциональные возможности Handy Backup

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

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

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

Программа умеет делать резервное копирование баз данных (в том числе из таблиц SQL, MS Access, Oracle, PostgreSQL, FoxPro, и др.), сохранять электронную почту, данные Lotus Notes, а также создавать резервные копии реестра Windows.

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

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

6.3.2. Структура пользовательского интерфейса

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

Рис. 6.28. Пользовательский интерфейс программы Handy Backup

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

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

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

...

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

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

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

Имя задачи (присваивается пользователем на стадии постановки задачи).

Тип задачи (возможные варианты – Резервное копирование , Восстановление или Синхронизация ).

Время последнего выполнения данной задачи.

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

Индикатор выполнения задачи;

Текущий статус задачи.

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

Ожидание – данный статус присваивается задачам, ожидающим команды на выполнение.

Резервное копирование , Восстановление или Синхронизация – один из этих статусов (в зависимости от типа задачи) присваивается задачам, находящимся в процессе выполнения.

Успех – статус означает, что задача успешно выполнена.

По расписанию – данный статус присваивается задачам, которые ожидают начала исполнения в соответствии с установленным ранее расписанием.

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

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

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

Имя файла или папки.

Текущий статус объекта.

Исходный размер объекта (отметим, что для папок данная информация не показывается).

Размер сохраненного объекта.

Время последнего редактирования файла или папки.

Время последнего сохранения файла или папки.

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

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

При необходимости вы можете убрать из интерфейса окно лога. Управление его отображением осуществляется с помощью команды главного меню Вид? Окно лога? Спрятать/Показать окно лога .

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

6.3.3. Параметры настройки Handy Backup

Как и при работе со многими другими приложениями, перед началом эксплуатации Handy Backup рекомендуется просмотреть и, в случае надобности – изменить параметры настройки программы, чтобы максимально адаптировать ее к специфике использования на данном компьютере. Для перехода в данный режим предназначена команда главного меню Файл? Настройки , вызываемая также нажатием комбинации клавиш Alt+F7 . При активизации данной команды на экране отображается окно, которое показано на рис. 6.29.

Рис. 6.29. Настройка программы, раздел Основные настройки

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

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

Вы можете сделать так, что в контекстное меню операционной системы будет добавлен пункт Handy Backup – для этого нужно в разделе Основные настройки установить флажок Разрешить интеграцию с Windows Explorer .

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

Если в разделе Основные настройки установлен флажок , то по окончании копирования автоматически откроется привод компакт-дисков для извлечения диска. Иногда бывает полезно выполнить проверку результатов копирования на диск: для этого нужно установить флажок Извлечь CD/DVD после резервного копирования . При установленном данном флажке становится еще один параметр – Остановить проверку после первой ошибки . Если он установлен, то при обнаружении первой же ошибки проверка диска будет прекращена. Смысл данного параметра заключается в том, что иногда даже одной ошибки достаточно для того, чтобы запись была признана неудачной.

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

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

Рис. 6.30. Настройка программы, раздел Передача данных

В поле Максимальное время ожидания в сети следует указать, в течение какого времени программа должна ждать получения ответа от сети. Данный параметр выражается в секундах, по умолчанию ему присвоено значение 120 . Если по истечении указанного времени подключение не произошло, то после паузы программа предпримет попытку повторного соединения. Продолжительность этой паузы указывается в поле Задержка между повторными подключениями , а количество попыток подключений – в поле . Если установлен флажок Повторять до успешного завершения , то поле Попыток повторения при сетевых ошибках становится недоступным для редактирования. В этом случае программа будет предпринимать попытки подключения до тех пор, пока какая-то из них не окажется успешной. Программа может информировать вас о ходе протекающих ней процессов по электронной почте. Это очень удобная функциональность: она позволит вам контролировать положение даже при отсутствии непосредственного доступа к данному компьютеру (достаточно иметь доступ к электронному почтовому ящику с любого другого места). Необходимые настройки выполняются в разделе Уведомления по E-mail , содержимое которого показано на рис. 6.31.

Рис. 6.31. Настройка программы, раздел Уведомления по E-mail

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

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

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

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

6.3.4. Резервное копирование образа диска

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

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

Чтобы создать образ жесткого диска, необходимо сформировать соответствующую задачу. Для этого нужно выполнить команду главного меню Файл? Новая задача , которая вызывается также нажатием комбинации клавиш Ctrl+N , либо нажать соответствующую кнопку инструментальной панели. При выполнении любого из указанных действий на экране откроется окно Мастера создания новой задачи, изображенное на рис. 6.32.

Рис. 6.32. Мастер создания новой задачи

Для создания образа жесткого диска нужно на первом этапе создания задачи установить переключатель Выберите тип задачи в положение Задача резервного копирования (это значение выбирается во всех случаях, когда необходимо выполнить резервное копирование, независимо от типа копируемых данных). Для перехода ко второму этапу нужно нажать кнопку Далее . В открывшемся окне следует нажать кнопку Добавить , и в появившемся меню выбрать команду Disk Image (рис. 6.33),

Рис. 6.33. Выбор команды копирования образа диска

В результате содержимое окна примет вид, как показано на рис. 6.34.

Рис. 6.34. Второй этап постановки задачи

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

Рис. 6.35. Третий этап постановки задачи

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

Рис. 6.36. Четвертый этап постановки задачи

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

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

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

Рис. 6.37. Пятый этап постановки задачи

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

Рис. 6.38. Шестой этап постановки задачи

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

Рис. 6.39. Седьмой этап постановки задачи

Здесь необходимо с клавиатуры ввести имя формируемой задачи, под которым она будет отображаться в области задач главного окна программы. После нажатия кнопки Завершить поставленная задача будет добавлена в список задач и начнется ее выполнение, о чем будет свидетельствовать информация в колонке Развитие/Ход событий , а также содержимое лог-файла (рис. 6.40).

Рис. 6.40. Выполнение поставленной задачи

После того как резервное копирование завершено, задаче будет присвоен статус Успех , а в колонке Развитие/Ход событий для нее отобразится значение 100 % (рис. 6.41).

Рис. 6.41. Информация об успешном завершении резервного копирования

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

6.3.5. Восстановление данных из резервной копии

Чтобы восстановить данные из резервной копии, необходимо поставить программе соответствующую задачу. Для этого выполним команду главного меню Файл? Новая задача или нажмем комбинацию клавиш Ctrl+N , затем в открывшемся окне Мастера создания новой задачи (см. рис. 6.32) установим переключатель в положение Задача восстановления данных и нажмем кнопку Далее . В результате окно Мастера примет вид, как показано на рис. 6.42.

Рис. 6.42. Выбор индекс-файла для восстановления

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

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

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

Если для восстановления данных выбран источник на FTP– или SFTP-сервере, то после установки переключателя в положение FTP или SFTP ниже откроются поля для ввода адреса сервера, имени и пароля пользователя и иных необходимых данных.

Рис. 6.43. Выбор пути для восстановления данных

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

...

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

При этом на экране откроется окно, которое показано на рис. 6.44.

Рис. 6.44. Ввод пути для восстановления данных

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

Рис. 6.45. Выбор способа восстановления

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

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

Частичное восстановление – при выборе этого способа будут восстановлены только те объекты, которые претерпели изменения.

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

Рис. 6.46. Настройка расписания для автоматического выполнения задачи

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

...

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

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

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

Рис. 6.47. Ввод имени задачи

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

Рис. 6.48. Процесс восстановления данных

А после того как восстановление завершено, в колонке Развитие/Ход событий для данной задачи отобразится значение 100 % , и ей будет присвоен статус Успех (рис. 6.49).

Рис. 6.49. Успешное завершение восстановления

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

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

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

Глава 5 Технологии резервного копирования и восстановления данных

Резервное копирование – это процесс создания когерентной (непротиворечивой) копии данных. Резервное копирование становится все более важным на фоне значительного увеличения объема данных в компьютерной индустрии. Некоторые исследования показывают, что в ближайшие несколько лет будет создано больше данных, чем за всю историю человечества! Очень интересно сравнить увеличение емкости подсистем хранения данных с более известным ростом плотности транзисторов в электронных компонентах. Закон Мура гласит, что количество транзисторов на единицу площади электронных микросхем удваивается каждые 18 месяцев. Аналитики предполагают, что рост объемов подсистем хранения данных намного обгоняет закон Мура и объемы хранилищ удваиваются значительно быстрее, чем за 18 месяцев.

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

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

В этой главе рассматриваются технические трудности, которые необходимо преодолеть для обеспечения своевременного резервного копирования и восстановления данных. Здесь также приводится классификация методов восстановления и резервного копирования. Кроме того, описываются возможности Windows Server 2003 по созданию «моментальных снимков» (служба теневого копирования томов) и по работе с сетевым протоколом управления данными (Network Data Management Protocol – NDMP), а также видение компании Microsoft относительно управления подсистемами хранения данных, что будет реализовано в следующих версиях Windows.

5.1 Причины резервного копирования й восстановления данных

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

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

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

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

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

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

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

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

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

5.2.1 Время, затрачиваемое на резервное копирование

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

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

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

5.2.2 Увеличение количества программных интерфейсов приложений

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

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

5.2.3 Проблема открытых файлов

Еще одна проблема при выполнении резервного копирования связана с тем, что процесс занимает значительное время. Если устройство записи на магнитную ленту поддерживает запись со скоростью 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.

5.3 Классификация типов резервного копирования

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

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

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

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

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

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).

5.4 Утилита резервного копирования Windows 2000

В составе Windows 2000 поставляется программа резервного копирования, которая на самом деле представляет собой облегченную версию программы VERITAS Backup Exec. Встроенная утилита резервного копирования интегрирована с другими компонентами операционной системы, например с шифрованной файловой системой и интерфейсом управления иерархическим хранилищем. Утилита резервного копирования поддерживает резервное копирование и восстановление EFS в Windows 2000. Более подробная информация представлена в главе 6. Кроме того, утилита поддерживает работу с менеджером RSM – Removable Storage Manager (см. главу 7). Менеджер предоставляет поддержку операций, необходимых для резервного копирования:

инвентаризацию носителей, загруженных в библиотеку ленточных библиотек;

загрузку и извлечение носителей из ленточных библиотек;

предоставление безопасного доступа и обеспечение целостности данных на смонтированном носителе;

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

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

агенты резервного копирования для приложений уровня предприятия, например серверов SQL и IIS;

поддержка резервного копирования открытых файлов;

повышенное быстродействие;

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

поддержка команды Extended Сору и агентов перемещения данных других поставщиков.

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

5.5 Технологии создания моментальных снимков тома

Моментальный снимок (snapshot) – это целостная копия состояния тома в определенный момент времени. Под целостностью в данном случае подразумевается возможность для приложений обработать данные, хранящиеся в снимке; например, сервер Microsoft Exchange воспринимает данные как действительное хранилище Exchange, а сервер Microsoft SQL – как реальную базу данных SQL. Рассматриваемый в этом случае набор данных в дальнейшем будет именоваться логическим томом.

Моментальные снимки набирают популярность и используются по ряду различных причин.

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

Создание образа активных данных, в котором поддерживается поиск.

Создание образа активных данных для тестирования новой версии приложения в «реальном» окружении.

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

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

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

Уровень над файловой системой. Второй способ создания моментального снимка тома в операционных системах семейства Windows Server заключается в создании драйвера фильтрации файловой системы, который размещен над драйвером файловой системы, например NTFS или FAT. Драйвер фильтрации файловой системы дублирует каждый пакет IRP (пакет запроса ввода-вывода), который передается драйверу файловой системы. Этот процесс довольно сложен и не может использовать преимущества технологии моментальных снимков, которая предоставляется аппаратным обеспечением. В качестве примера программ, внедряющих фильтры над NTFS, можно указать Open File Manager компании St. Bernard, Vinca (теперь LEGATO) Open File Manager и Open File Agent компании Cheyenne. Обратите внимание, что не каждая программа поддерживает технологию моментальных снимков.

Рис. 5.7. Моментальные снимки по методу копирования при записи

Уровень непосредственно файловой системы. Переместившись ниже по стеку драйверов, можно реализовать третий способ создания моментальных снимков на уровне файловой системы, такой, как WAFL (Write Anywhere File Layout) и Linux SnapFS. Очевидно, что в данном случае речь не идет о Windows NT. Создание файловой системы – достаточно сложный процесс, а создание технологии моментальных снимков на уровне файловой системы еще больше его усложняет. В результате файловые системы, реализованные в Windows NT, не поддерживают моментальных снимков.

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

5.6 Служба теневого копирования томов в Windows ХР и Windows Server 2003

В Windows ХР и Windows Server 2003 компания Microsoft реализовала службу теневого копирования. Таким образом, предоставляется инфраструктура, позволяющая создавать целостные копии дисковых томов в заранее определенный момент времени. По юридическим причинам Microsoft решила назвать эту технологию теневым копированием томов (volume shadow copy), что на самом деле не отличается от более популярного термина – моментальные снимки. Служба теневого копирования томов реализована в драйвере, который называется volsnap. sys и находится ниже уровня файловой системы.

Компания Microsoft предоставляет инструментарий разработки программного обеспечения для теневого копирования томов, реализуемый на базе договора о неразглашении. Набор SDK в основном предназначен для представителей трех обширных аудиторий.

Независимые поставщики программного обеспечения, предназначенного для теневого копирования томов, включая Microsoft Exchange, SQL Server, Oracle, SAP, Sybase и др.

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

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

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

Рис. 5.8. Архитектура теневого копирования томов

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

Архитектура теневого копирования томов в Windows ХР и Windows Server 2003 включает в себя четыре типа модулей (рис. 5.8).

Модули записи.

Модули запроса.

Служба теневого копирования томов.

Поставщики.

Эти модули подробно рассматриваются в разделах 5.6.1–5.6.4.

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

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

Модули записи и поставщики должны внедрить отдельного внепроцесс- ного поставщика СОМ, как описано в SDK , для теневого копирования томов. Поставщики обычно реализуются в виде «конечного автомата». Автомат переходит из одного состояния в другое при получении события, сгенерированного службой теневого копирования. Поставщик получит событие (сгенерированное службой теневого копирования), однако тип события зависит от текущего статуса поставщика и от наличия ошибок в работе. Другими словами, поставщик ожидает получения предпочтительного события, которое позволит ему перейти в следующее нормальное состояние. В случае ошибки поставщик получит событие, которое отличается от ожидаемого. Тем не менее такое событие также может быть обработано поставщиком.

Инфраструктура теневого копирования в Windows ХР и Windows Server 2003 предоставляет базовые функции, необходимые для управления подсистемой хранения данных, включая следующие:

определение момента времени, в который должен создаваться моментальный снимок;

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

предоставление. единого API, который может использоваться во время операций резервного копирования и восстановления;

предоставление общей платформы для управления моментальными снимками.

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

5.6.1 Модули записи

Модули записи моментальных снимков представляют собой приложения, которые записывают данные. К модулям записи относятся программы Microsoft Exchange, Microsoft SQL Server 2000, SAP и Oracle. Компания Microsoft и независимые поставщики программного обеспечения разрабатывают системы, поддерживающие запись моментальных снимков. При этом модули записи моментальных снимков должны быть реализованы с помощью набора SDK. В частности, модули записи получают от службы моментальных снимков два события, в результате чего приложения прекращают запись данных на диск, а также отдельное событие, позволяющее продолжить запись (это событие указывает на успешное создание моментального снимка). Существуют и другие события, которые может генерировать служба создания моментальных снимков. Дополнительная информация об этих событиях доступна в наборе SDK. Так как приложения могут определять целостность получаемых данных, операции сохранения должны проводиться достаточно быстро.

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

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

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

Компания Microsoft объявила, что будет предоставлять модули записи для программ SQL Server 2000 и Exchange, а также других компонентов Windows Server. Компания сотрудничает с независимыми поставщиками программного обеспечения для разработки модулей записи к другим приложениям, включая службу каталогов Active Directory.

5.6.2 Модули запроса

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

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

5.6.3 Служба теневого копирования томов

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

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

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

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

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

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

5.6.4 Поставщики

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

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

Одним из примеров поставщика моментальных снимков служит драйвер volsnap. sys, который предоставляется в Windows ХР и ожидается в Windows Server 2003. Этот поставщик использует технологию копирования при записи для создания минимального необходимого набора данных во вторичном хранилище, чтобы воссоздать том с определенной временной точки. При этом должен быть доступен достаточный объем свободного дискового пространства. Поставщик может обрабатывать тома NTFS, FAT32 и тома без файловой системы в Windows Server 2003. Однако поставщик может создавать моментальные снимки, предназначенные только для чтения, и для каждого тома создается только один моментальный снимок. Это ограничение самого поставщика, а не инфраструктуры, на базе которой он создан. Независимые производители программного и аппаратного обеспечения при желании могут предоставлять более широкие возможности.

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

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

Commit Snapshot. С получением этого события поставщик уведомляется о том, что служба моментальных снимков завершит работу через 10 секунд. Таким образом, быстродействие поставщика должно быть достаточно высоким. Более того, пока создание моментального снимка не будет завершено, Windows NT не будет выполнять операции записи на том, для которого создается моментальный снимок. Это значит, что поставщик не должен выполнять операции ввода-вывода с этим томом, а если такая операция выполнена, то она не должна завершаться до тех пор, пока создание моментального снимка не будет завершено или прервано.

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

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

Поставщик должен монтировать моментальный снимок в другом пространстве имен й не в виде отдельного тома. Внимательно рассмотрев архитектуру Windows ХР, можно отметить, что поставщик моментальных снимков от компании Microsoft монтирует их с использованием адреса \Device\HarddiskSnapshotX.

5.6.5 Модификации подсистемы ввода-вывода Windows NT

Хотя модификации подсистемы ввода-вывода Windows NT не обязательно относятся к окружению моментальных снимков, следует обратить внимание, что для создания целостных и надежных моментальных снимков в определенный момент времени требуются значительные доработки файловой системы, стека ввода-вывода и драйверов фильтрации файловой системы. В частности, компания Microsoft добавила два вызова управления вводом: выводом (IOCTL), которые должны быть реализованы во всех файловых системах и драйверах фильтрации файловых систем.

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

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

Некоторые компоненты Windows NT также были модифицированы для вызова указанных IOCTL в соответствующие моменты времени. Хотя компания Microsoft уже модифицировала файловую систему и драйвер фильтрации файловой системы для предоставления соответствующей функции, от драйверов фильтрации независимых производителей^ программного обеспечения ожидается то же самое.

В разделе 5.8 рассматривается промышленный стандарт NDMP (Network Data Management Protocol – сетевой протокол управления данными). Но перед обсуждением этой темы следует рассмотреть взаимосвязь между службой теневого копирования томов Windows ХР/Windows Server 2003 и протоколом NDMP. Служба теневого копирования используется для клонирования данных, которые необходимо скопировать на резервный носитель, в то время как NDMP применяется для переноса данных с клонированного образа на магнитную ленту или другой резервный носитель.

5.7 Устройства NAS под управлением Windows и моментальные снимки

Компания Microsoft предоставляет версию Windows NT, которую иногда называют Embedded NT (встроенная NT), однако обычно она известна как Server Appliance Kit, или SAK. Эта система основана на ядре Windows 2000, которая не содержит службы теневого копирования томов. Для производителей аппаратного обеспечения, использующих SAK при разработке устройств NAS, компания Microsoft лицензировала технологию создания моментальных снимков и добавила ее в SAK. В последнем случае для создания моментальных снимков используется технология PSM (Persistent Storage Management) от компании Columbia Data Products. В этом разделе приводится краткое описание архитектуры и функций PSM.

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

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

5.8 Протокол NDMP

В основе протокола NDMP лежит инициатива компаний Network Appliance и Intelliguard (теперь подразделение компании LEGATO). Он предназначался для предоставления дополнительных возможностей приложениям резервного копирования и восстановления данных, а именно:

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

Рис. 5.9. Архитектура Persistent Storage Manager

стандартизированные способы связи между модулями;

возможность разделить перенос данных и команд на отдельные каналы или даже сети;

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

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

Протокол NDMP может использоваться в различных сетевых средах, например Ethernet, Gigabit Ethernet, Fibre Channel. Главным условием является использование IP (Internet Protocol) в качестве транспортного протокола. Сервер NDMP и агенты используют протокол IP, а сервер NDMP выдает необходимые команды SCSI блочного уровня.

Протокол NDMP ориентирован на устройства NAS и определяет метод резервного копирования и восстановления данных с устройства, например

системы NAS, на которой сложно установить агент резервного копирования. При отсутствии NDMP данные копируются с общего диска по протоколам CIFS и NFS.

Протокол NDMP имеет ряд преимуществ.

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

Интерфейсы стандартизированы и позволяют использовать Plug and Play для модулей разных производителей.

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

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

5.8.1 Архитектура NDMP

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

агент перемещения данных;

службы NDMP;

сеансы NDMP.

Рассмотрим эти компоненты подробнее.

5.8.1.1 Агент перемещения данных

Агент перемещения данных (data mover agent – DMA) представляет собой основное приложение резервного копирования. Он устанавливает сеансы NDMP с поставщиком услуг NDMP (рассматривается далее) и управляет последовательностью действий, необходимых для настройки операции резервного копирования или восстановления. Кроме того, иногда агент перемещения данных называетсяклиентом NDMP.

5.8.1.2 Службы NDMP

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

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

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

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

5.8.1.3 Сеансы NDMP

Службы NDMP взаимодействуют друг с другом с помощью интерфейсов NDMP. В результате устанавливается сеанс NDMP, который называется управляющим сеансом , если используется для получения управления над операцией резервного копирования или восстановления, либо сеансом данных , если используется для передачи файловой системы или данных тома (включая метаданные). Между каждой службой NDMP и агентом перемещения данных существует только один сеанс. Сеансы управления всегда создаются на основе протокола TCP/IP; потоки данных могут передаваться по протоколу TCP/IP или по сетям хранения данных. Даже несмотря на возможность передачи данных по сетям хранения данных, использование протокола TCP/IP для сеансов управления требует наличия локальной сети. Потоки данных могут проходить между агентом перемещения данных и службой NDMP или непосредственно между двумя службами NDMP.

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

На рис. 5.11 представлена концептуальная реализация протокола NDMP в Windows NT. Агент перемещения данных NDMP устанавливает два сеанса управления NDMP, по одному с каждым сервером NDMP. Данные передаются непосредственно между двумя серверами NDMP, а не «перетаскиваются» с одного сервера NDMP к агенту перемещения данных NDMP и оттуда к другому серверу NDMP.

Рис. 5.10. Архитектура NDMP

Рис. 5.11. Концептуальная реализация NDMP в Windows NT

5.9 Сложности практической реализации

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

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

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

5.10 Резюме

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

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

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

Созданный моментальный снимок можно использовать для резервного копирования данных. Чтобы выполнить резервирование, можно воспользоваться стандартным протоколом, например NDMP.

Примечания:

Для тех читателей, кто незнаком с термином СОМ, стоит упомянуть, что это чрезвычайно важная архитектура Windows, позволяющая создавать программы в виде взаимодействующих друг с другом объектов. Объекты СОМ можно написать с помощью различных языков программирования, в том числе С, С++ и Visual Basic. Два объекта СОМ могут быть расположены на одной локальной системе или одновременно выполняться на двух удаленных системах. Два объекта могут выполняться в контексте одного процесса (в локальной системе) или же в двух отдельных процессах. В последнем случае предоставляются специальные механизмы для обеспечения взаимодействия этих объектов. Таким образом, внепроцессиый поставщик - это поставщик, реализованный в виде объекта СОМ и выполняемый в отдельном контексте процесса.

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

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

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

Бэкап программа для Windows

Handy Backup – надежная программа для резервного копирования и восстановления данных для компьютерах, работающих под Windows, известная своим простым и удобным интерфейсом и огромным количеством функций. Чтобы создать копию или восстановить данные, нужно просто создать новую "задачу" (с помощью пошагового Мастера создания задач). Handy Backup поможет вам создать резервные копии следующих данных:

• Файлы и папки

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

• Популярные утилиты и приложения

Программа может выполнять автоматический поиск и бэкап многих популярных приложений, включая Outlook, Skype, Adobe Photoshop и др.

• Образ диска

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

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

• Поддержка всех версий систем Windows

В программе реализована возможность работы в различных версиях Windows, в том числе, можно выполнять резервное копирование и восстановление Windows 8 .

• Базы данных

Программа может копировать ODBC совместимые базы данных, а также имеет специальные плагины для точного копирования баз DB2, Oracle, MS SQL, MySQL и др.

• MS Exchange и данные почты

Приложение способно выполнять резервное копирование и восстановление данных MS Exchange Server, без остановки работы сервера. А также создавать автоматический бэкап почты с серверов Яндекс.Почты, Mail, Gmail, Yahoo Mail и др.

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

Зачем нужно Android?

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

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

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

Компьютер в помощь

Самый распространенный метод сохранения данных Android - Windows, точнее, создание на компьютере. Все, что нужно, это скачать дополнительную утилиту и немного подготовить телефон. Заходим в "Настройки\Функции для разработчиков". Отмечаем галочкой пункт

Если версии "Андроид" прошивки 4.2 и выше, заходим в раздел "Ситема\О телефоне" и нажимаем 7-10 раз по номеру сборки. После чего возвращаемся в "Функции для разработчиков" и выставляем отладку. Далее скачиваем и устанавливаем программу, после чего подключаем гаджет к компьютеру.

Mobogenie

Во время установки этой утилиты антивирусная программа может поднять тревогу, поэтому защиту стоит временно отключить. Это никак не навредит компьютеру, просто антивирус опознает Mobogenie как шпионскую программу. Также устанавливаем Mobogenie на Android с Play Market. Подключаем гаджет к ПК и запускаем на нем Mobogenie. Нажимаем "Функции" и выбираем "Подключить к ПК"

Теперь запускаем утилиту на компьютере. В верхнем меню заходим в раздел "Телефон", где в списке находим "Резервное копирование". Выбираем путь, куда будут сохранены данные Android - Windows.

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

MyPhoneExplorer

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

Скачиваем и устанавливаем. Подключаем гаджет к ПК по USB (отладка по USB включена). Запускаем программу. Нажимаем на верхней панели "Файл\Подключить\телефон с ОС Android". Метод выбираем "USB-кабель". Когда подключится, нажимаем на раздел "Разное\Создать резервную копию".

Далее следует выбрать путь, куда будут сохранены данные. После чего откроется окно, в котором нужно будет отметить файлы и приложения. Выбираем нужные или просто ставим галочку в названии раздела. Нажимаем "Создать". Резервное копирование данных Android выполнено.

На карту памяти

Резервное копирование Android можно сделать и без помощи компьютера, сохранив важные данные на флешку. Для этого необходимо прибегнуть к помощи специальных приложений, которые находятся в Play Market. Но кроме этого, нужно будет получить root-права. Сделать это можно как через компьютер, так и с помощью специальных приложений. Проще всего обратиться за помощью к китайской утилите VRoot.

Не стоит пугаться, что там всё на китайском, все нужные для рутирования кнопки на английском, кроме того, программа интуитивно понятна. Если ничего не получилось, не стоит отчаиваться, так как подобных утилит довольно много, например Unlock Root или Framaroot. Получив права суперадминистратора, можно начинать создавать резервную копию.

ROM Manager

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

Восстановить информацию также не составит труда. Нажимаем "Резервные копии" и выбираем точку восстановления.

Titanium Backup PRO

Устанавливаем приложение, запускаем. Переходим в раздел "Резервные копии". Здесь можно увидеть уже созданные точки восстановления Android, обзор приложений и компонентов операционной системы. Нажимаем на кнопку с изображением листа с галочкой справа сверху. В списке выбираем, что нужно сохранить: пользовательское ПО, системные данные или все вместе. Так как нам необходимо сохранить всё, нажимаем "Сделать резервную копию всего пользовательского ПО и системных данных". А узнать, куда сохраняется вся информация, можно в настройках приложения.

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

Специализированные утилиты для смартфонов

К таким относятся те, которые поставляются только для телефонов одной марки или даже серии. Например, Samsung Kies, Sony PC Companion и другие. В них не только содержатся драйверы для нужного устройства, но также есть возможность сделать резервный перенос данных с гаджета на ПК и восстановить устройство.

Для Samsung Kies делаем следующее:

• Запускаем утилиту и подключаем гаджет к ПК.
• Когда модель определится, переходим в раздел "Резервное копирование\восстановление".
• Отмечаем нужные пункты (или просто нажимаем "Отметить всё") и нажимаем "Резервное копирование".

Восстановление данных происходит точно так же.

Для Sony PC Companion:

• Запускаем утилиту, подключаемся.
• Нажимаем Пуск в разделе Xperia Transfer.
• Отмечаем точкой "Резервная копия Xperia на моем компьютере" и кликаем на "Пуск".

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

Сохранение контактов

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

Заходим в телефонную книгу, нажимаем "Опции" (часто с правой стороны кнопка и 4 горизонтальных полоски). Нажимаем "Экспорт", или "Резервная копия". Выбираем "Карта памяти". Путь, куда будут сохранены контакты, указывается при сохранении. Скорее всего, это будет папка System на карте памяти.

• сбросить на компьютер и загрузить в облако;
• отправить на другой телефон посредством электронной почты;
• передать по Bluetooth;
• загрузить в аккаунт "Гугл" в раздел "Контакты".

Кроме этого, контакты можно сохранить на SIM-карте. Алгоритм сохранения тот же, только экспорт будет производиться на симку. Импортировать их можно будет только, вставив симку в другое устройство. В отличие от micro-SD, на SIM имеется всего 200 ячеек для номеров телефонов.

Облако Google

Для этого необходимо иметь аккаунт в системе "Гугл". Скорее всего, он есть, так как без него невозможно зайти в Play Market. Если его нет, нужно перейти на google.com и зарегистрироваться.

Заходим в "Настройки\Учетные записи и синхронизация", где нужно синхронизировать учетную запись "Гугл" на Android. Ставим галочки на всём, что нужно синхронизировать. Возвращаемся на шаг назад и переходим в раздел "Резервное копирование и восстановление". Отмечаем пункт и "Автовосстановление". Нажимаем "Резервная учетная запись", "Добавить".

Зачем сохранять информацию с SD-карты

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

• Подключить телефон со вставленной SD-картой к компьютеру по USB.
• Вытащить флешку из гаджета и подключить к ПК с помощью кардридера. Особенно просто это будет сделать на ноутбуке, так как в нем предусмотрен этот разъем. Важно правильно отключить карту в гаджете, так как неправильное извлечение может привести к поломке карты памяти (такое случается нечасто, но бывали случаи). Заходим в Android: "Настройка\\ Память\\ Отключить SD-карту".
• По Wi-Fi. Для этого потребуется приложение FTP Server, которое превратит устройство в FTP-сервер. Запускаем приложение, нажимаем на красную кнопку посреди экрана. Она станет зеленой, а чуть ниже появится IP-адрес, который нужно ввести в адресную строку в "Мой компьютер".

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

Заключение

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

)-редактор журнала SQL Server Pro, соучредитель компаний Mount Vernon Data Systems и Six Sigma Uptime.

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

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

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

Частота резервирования базы данных зависит от того, как долго она будет восстанавливаться из резервной копии. Чем чаще выполняется резервирование базы данных, тем меньше времени займет восстановление. График резервирования и восстановления можно настроить индивидуально для каждой базы данных. Тип резервирования зависит еще от объема базы данных и количества транзакций, выполняемых за единицу времени. Основными типами резервирования являются полное, журнальное и инкрементальное. Более подробные сведения о режимах восстановления приведены во врезке «Модели восстановления баз данных», команды по резервированию SQL Server описаны во врезке «Стандартные команды для резервирования».

Полное резервирование

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

Больше всего полное резервирование подходит для «небольших» баз данных – назовем так базы данных, резервирование которых может быть завершено за отведенное для этого время. Когда SQL Server осуществляет полное резервирование базы данных, сначала выполняется сохранение на диск всех экстентов (экстент представляет собой восемь идущих последовательно страниц, размер каждой составляет 8 Кбайт). Затем SQL Server резервирует журнал транзакций, чтобы все изменения базы данных, которые могли произойти за время резервирования, также были сохранены в файле полной резервной копии.

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

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

Для выполнения полного резервирования базы данных выполните следующий код:

BACKUP DATABASE AdventureWorks TO DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.bak’WITH INIT, NAME = ‘AdventureWorks Full Db backup’, DESCRIPTION = ‘AdventureWorks Full Database Backup

Параметр DISK определяет целевой файл резервной копии. Вы можете выполнять резервирование на диск или на ленту (в данном случае – на диск). Перед началом резервирования убедитесь, что папка для хранения резервной копии существует. В большинстве случаев резервирование на диск происходит значительно быстрее, чем на ленту, но стоимость дисковой памяти существенно выше. Для обеспечения дополнительного уровня защиты можно выполнять резервирование на диск, а затем сохранять резервную копию на ленту. Параметр WITH INIT указывает, что файл резервной копии должен быть перезаписан. Этот метод подходит в том случае, если резервирование Windows выполняется после каждого резервирования базы данных. NAME – имя резервной копии, до 128 символов. Если имя не указать, поле имени останется пустым. DESCRIPTION – более полное и подробное описание, которое может помочь, например, через длительный промежуток времени выяснить, что это за резервная копия и зачем она была создана.

Для полного восстановления базы данных выполните следующую команду:

RESTORE DATABASE AdventureWorks FROM DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.BAK’ WITH RECOVERY, REPLACE

WITH RECOVERY предписывает SQL Server отменить все незавершенные транзакции, которые могли быть в журнале транзакций, и оставить базу в рабочем состоянии. REPLACE означает перезапись любого существующего файла с тем же именем. Более подробно об этом рассказано во врезке «Замена базы данных».

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

BACKUP LOG AdventureWorks WITH TRUNCATE_ONLY

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

Полное резервирование с сохранением журнала

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

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

Если не указано обратное, после завершения резервирования журнала неактивные записи в нем «удаляются» (в действительности они помечаются для перезаписи). При запуске команды BACKUP LOG вы можете добавить параметры NO_TRUNCATE или COPY_ONLY, чтобы при резервировании записи в журнале не изменялись. Но мы не рекомендуем использовать эти параметры, если только вы не знаете наверняка, для чего это может понадобиться.

SQL Server 2005 имеется режим резервирования копии заключительного фрагмента журнала (tail-log backup), то есть резервирование после краха базы данных в том случае, если журнал транзакций не был испорчен. В этом режиме осуществляется резервирование последних транзакций, выполненных с момента последнего резервирования журнала. Более подробно об этом режиме рассказано во врезке «Что такое резервные копии заключительного фрагмента журнала».

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

Если в базе данных массовые обновления носят регулярный характер, возможно, имеет смысл использовать модель восстановления с неполным протоколированием (bulk logged recovery). Поскольку отдельные записи, включенные в массовую операцию в этом случае не журналируются, этот подход сокращает накладные расходы на ведение журнала SQL Server. Хотя вы можете получить заметное увеличение производительности при выполнении массовых операций, вы рискуете потерять данные при восстановлении, если исходные данные для повторного выполнения массовых операций окажутся в момент восстановления недоступны. При применении простой модели восстановления резервирование журнала также невозможно, так как в этом случае происходит обрезание журнала до контрольной точки.

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

BACKUP DATABASE AdventureWorks TO DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.bak’ WITH INIT, NAME = ‘AdventureWorks Full Db backup’, DESCRIPTION = ‘AdventureWorks Full Database Backup’

А затем следует выполнить резервирование журнала с помощью команды:

BACKUP LOG AdventureWorks TO DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_TlogBkup.bak’ WITH NOINIT, NAME = ‘AdventureWorks Translog backup’, DESCRIPTION = ‘AdventureWorks Transaction Log Backup’, NOFORMAT

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

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

1. Если база данных в состоянии онлайн, ограничьте доступ к ней, переключив режим доступа (в окне свойств) на RESTRICTED_USER. Таким образом доступ к базе данных будет разрешен только членам группы базы данных db_owner и членам групп сервера dbcreator и sysadmin.
2. Исправьте ошибку, вызвавшую крушение базы данных.
3. Если возможно, примените все сохраненные в резервных копиях журналы транзакций с параметром NORECOVERY.

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

BACKUP LOG AdventureWorks TO DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_TaillogBkup.bak’ WITH NORECOVER

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

RESTORE DATABASE AdventureWorks FROM DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.bak’ WITH NORECOVERY

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

RESTORE LOG AdventureWorks FROM DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_TlogBkup.bak’ WITH NORECOVERY

Наконец, выполните восстановление заключительного фрагмента с параметром RECOVERY:

RESTORE LOG AdventureWorks FROM DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_TaillogBkup.bak’ WITH RECOVERY

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

Полное плюс разностное резервирование

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

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

Рисунок 3. Расписание заданий на разностное резервирование

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

BACKUP DATABASE AdventureWorks TO DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_DiffDbBkup.bak’ WITH INIT, DIFFERENTIAL, NAME = ‘AdventureWorks Diff Db backup’, DESCRIPTION = ‘AdventureWorks Differential Database Backup’

Чтобы восстановить базу данных из разностной резервной копии, выполните следующие шаги.

1. Если база данных в состоянии онлайн, ограничьте к ней доступ, переключив режим доступа (в окне свойств) на RESTRICTED_USER. Тем самым доступ к базе данных будет разрешен только членам группы базы данных db_owner и членам групп сервера dbcreator и sysadmin.
2. Выполните резервирование заключительного фрагмента журнала.
3. Исправьте ошибку, вызвавшую сбой базы данных.
4. Выполните восстановление полной резервной копии с параметром NORECOVERY.
5. Выполните восстановление последней имеющейся разностной резервной копии с параметром NORECOVERY.
6. Выполните восстановление резервной копии заключительного фрагмента журнала с параметром RECOVERY.

Для восстановления разностной резервной копии (выполняется после восстановления полной копии) введите команду:

RESTORE DATABASE AdventureWorks FROM DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_DiffDbBkup.bak’WITH NORECOVERY

Затем восстановите заключительный фрагмент журнала с параметром RECOVERY, с помощью приведенной ранее команды.

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

Комбинирование стратегией

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

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

Альтернативные стратегии резервирования

Резервирование в SQL Server не сводится только к полному, разностному и журналу транзакций. Более сложные стратегии, включающие резервирование файлов или групп файлов, стратегию частичного резервирования и резервирование только путем копирования.

Доступ к базе данных во время выполнения резервирования и восстановления

Резервирование базы SQL Server является онлайн-процессом, все хранящиеся в SQL Server данные во время операции резервирования доступны. Операции изменения базы данных, предложения INSERT, UPDATE и DELETE доступны точно так же, как выборка данных (SELECT). Во время резервирования нельзя изменять структуру базы данных или файловую структуру – предложения ALTER DATABASE, ADD FILE или SHRINKFILE во время резервирования выполняться не могут. Если для базы данных включен режим автоматического запуска уменьшения файла базы данных (auto-shrink), возможен конфликт во время выполнения резервирования. Так, если в процессе выполнения резервирования запустится автоматическое уменьшение файла базы, то обе операции могут завершиться отказом. Та операция, которая стартует раньше, установит блокировку файла, а следующей операции придется ожидать снятия блокировки. Если первая операция снимет блокировку, то начнется выполнение второй. Если же произойдет тайм-аут блокировки первой операции, вторая операция завершится отказом. Такой подход может показаться неправильным с точки зрения исполнения второй операции, которая вынуждена ожидать отказа, и только после него выдаст отказ. Но если учесть, что работа второй операции зависит от успеха первой, если при выполнении первой операции произошел отказ, выполнение второй не имеет смысла. Для предотвращения такой проблемы следует отключать автоматическое уменьшение файла базы данных перед выполнением резервирования.

В большинстве случаев восстановление базы SQL Server является автономной операцией, во время которой доступ пользователей к базе невозможен. При использовании SQL Server 2005 Enterprise Edition с моделью полного восстановления частичное восстановление и восстановление неосновных групп файлов по умолчанию являются онлайн-операциями. Части базы данных, которые не должны восстанавливаться, например группы файлов с доступом только для записи, могут быть доступны пользователям на всем протяжении выполнения операции восстановления. Группы файлов для чтения/записи доступны, если они не были переведены в автономное состояние для восстановления. Эта возможность очень полезна для больших баз данных, работающих в режиме 24x7x365. Дополнительную информацию можно найти в документации SQL Server 2005 BOL, «Performing Online Restores» (http://msdn.microsoft.com/ru-ru/library/ms188671.aspx), а также во врезке «Почему восстановление базы данных не может выполняться онлайн».

Подведем итоги

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

Кто может выполнять резервирование?

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

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

Модели восстановления баз данных

Настройка модели восстановления определяет, какая часть данных может быть восстановлена в случае краха базы данных. Для каждой базы данных можно установить собственную модель восстановления в зависимости от того, какую потерю данных вы готовы допустить. Чтобы установить модель восстановления базы данных с помощью SQL Server Management Studio (SSMS), щелкните правой кнопкой нужную базу данных, откройте окно свойств Properties, перейдите на страницу Options и выберите нужную модель резервирования из выпадающего списка.

Существует три типа моделей восстановления: полное, простое и с неполным журналированием (full, simple, и bulk-logged). Полная модель восстановления наиболее использует все возможности журнала транзакций и позволяет восстановить базу данных с высокой степенью точности на заданный момент времени. Все операции, такие как транзакции данных, структурные изменения базы данных, операционные инструкции типа завершения транзакции или отмена, большие объекты и массовые операции, сохраняются в журнале. Журнал транзакций пополняется до тех пор, пока не будет выполнено резервирование журнала транзакций.

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

Модель восстановления с неполным журналированием занимает промежуточное положение между «крайними» моделями полного и простого восстановления. Хотя название bulk-logged может навести на мысль о журналировании массовых операций, в действительности они сохраняются в журнале лишь частично. Во время массовых операций, которые часто заключаются в добавлении большого числа записей за короткий промежуток времени, SQL Server устанавливает на каждом затронутом обновлением экстенте базы данных битовый флажок, но на самом деле вставленные записи не добавляются в файл журнала. Во время последующего резервирования журнала транзакций SQL Server проверяет этот флажок и записывает в резервную копию журнала транзакций сами экстенты базы данных, которые были изменены массовой операцией в добавление к обычным записям о вставке и удалении. Таким образом, резервная копия журнала в модели восстановления с неполным журналированием содержит результаты выполнения массовых операций, а не действительно выполненные отдельные транзакции.

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

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

Стандартные команды для резервирования

В SQL Server 2005 и SQL Server 2000 имеются две команды для выполнения, в сущности, одного и того же действия – DUMP и BACKUP (то есть DUMP DATABASE или BACKUP DATABASE и DUMP LOG или BACKUP LOG). Команда DUMP сохранилась со времен SQL Server 6.5, когда резервирование базы данных означало просто копирование базы данных в состоянии на момент перед началом операции резервирования. При этом изменения в базе данных, которые могли произойти после начала резервирования, не попадали в резервную копию.

Начиная с версии 7 SQL Server может выполнять настоящее «динамическое» резервирование, а это означает, что изменения, внесенные после начала процесса резервирования, записываются в журнал транзакций и сохраняются в файле резервной копии. Таким образом, резервная копия представляет собой «снимок» базы данных на момент завершения операции резервирования. Команда DUMP сохраняется для обратной совместимости, но Microsoft не рекомендует ее использовать в новых разрабатываемых системах. Когда-нибудь эта команда будет исключена, и разработчикам придется избавиться от нее в тех фрагментах программного кода, где она еще используется.

Тем, кто всегда тщательно следил за резервированием баз данных SQL Server и стремился изучать нововведения SQL Server 2005, следует продолжать внимательно следить за резервными копиями: в SQL Server 2005 нет привычной команды DBCC REPAIR. «Заменой» для этой команды служит DROP DATABASE.

Замена базы данных

При восстановлении базы данных на новом сервере используйте параметр REPLACE, который отключает обычные проверки безопасности и позволяет перезаписывать существующие базы данных, даже если их имя отличается от имени восстанавливаемой базы. Например, предположим, что была сделана резервная копия базы данных D, расположенной на сервере A. Эта резервная копия должна быть восстановлена на сервере B. Сначала на сервере B следует создать пустую промежуточную базу, при этом имя и размер базы не имеют никакого значения. Далее, надо восстановить базу D с параметром REPLACE на сервере B поверх только что созданной промежуточной базы. Если же восстановление должно быть произведено обратно на сервер A, на прежнее место, параметр REPLACE указывать не требуется. По умолчанию операция восстановления базы данных выполняет встроенные проверки безопасности, например если в нормальной ситуации нельзя выполнить восстановление базы поверх другой существующей базы данных. Аналогично, запрещено восстановление базы данных, зарезервированной в режиме полного резервирования или резервирования с журналированием массовых операций, если отсутствует резервная копия заключительного фрагмента журнала.

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

Что такое резервные копии заключительного фрагмента журнала

Резервирование заключительного фрагмента журнала – новый режим резервирования в SQL Server 2005. В этом режиме в резервную копию дописываются записи журнала транзакций, которые добавлялись с момента последнего резервирования файла журнала. Когда вы пытаетесь восстановить базу данных на момент отказа, перед началом восстановления выполните резервирование заключительного фрагмента. Резервирование последнего не нужно делать в том случае, если вы собираетесь восстановить базу данных по состоянию на момент до последнего резервирования журнала транзакций, или переносите базу данных с одного экземпляра сервера на другой, либо перезаписываете базу данных. Возможна ситуация, когда журнал транзакций поврежден – в этом случае выполнить резервирование заключительного фрагмента невозможно, и восстановление придется выполнять без него.

Как восстановить базу данных по состоянию на заданный момент времени

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

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

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

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

При восстановлении базы данных по состоянию на некоторый момент времени выполните полное резервирование с установкой NORECOVERY, как показано ниже:

RESTORE DATABASE AdventureWorks FROM DISK = "E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.bak" WITH NORECOVERY

Затем примените все резервные копии журналов с установкой RECOVERY и указанием даты и времени требуемой точки во времени в каждом предложении RESTORE LOG:

RESTORE LOG AdventureWorks FROM DISK = "E:\SQLdata\BACKUPS\AdventureWorks_TlogBkup.bak" WITH RECOVERY, STOPAT = ‘ Dec 10, 2007 8:10 PM’

Резервирование файлов/групп файлов

Эта стратегия резервирования подходит только в том случае, если база данных состоит из нескольких файлов или групп файлов. Если размеры базы или требования к производительности делают полное резервирование базы данных невозможным и если необходимо быстрое восстановление в случае отказа, стоит принять во внимание стратегии резервирования файлов/групп файлов.
Эта стратегия может использоваться для SQL Server 2005 или SQL Server 2000, при этом при выполнении каждой операции требуется указать, какие файлы, группы файлов или комбинации будут резервироваться. При этом следует выполнить полное резервирование базы данных вскоре после создания, после чего выполнять регулярное резервирование файлов или групп файлов. Если для конкретной базы данных необходимо задействовать простую модель восстановления, все доступные для чтения/записи файлы и группы файлов должны резервироваться одновременно. Для минимизации потерь данных при восстановлении выбирайте модель полного восстановления или модель восстановления с неполным протоколированием, при этом необходимо включить в стратегию резервирование журнала транзакций.
Восстановление базы все равно означает ограничение доступа к базе данных, но на меньшее время, чем при полном восстановлении базы данных. Во время восстановления доступ ограничивается только к группам файлов, восстанавливаемым в данный момент.
В худшем случае, если требуется восстановление всей базы данных и вы используете модель полного восстановления, потребуются все резервные копии журналов транзакций с момента создания базы данных. Кроме того, если необходимо восстановление базы на определенный момент времени, потребуется полный набор резервных копий журналов транзакций.

Частичное восстановление

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

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

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

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

Восстановление после частичного резервирования все равно подразумевает ограничение доступа к базе данных, но на меньший интервал времени, чем при полном восстановлении базы данных – и только для первичной группы файлов, групп для чтения/записи и групп только для чтения, которые были частью резервирования. Более подробную информацию можно найти в документации SQL Server 2005 Books Online «Частичные резервные копии» http://msdn.microsoft.com/ru-ru/library/ms191539.aspx.

Резервные копии состояния

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

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

Стратегию резервирования состояния нельзя использовать в качестве базы для разностного резервирования, так как при создании копии состояния не обновляется карта разностей (differential bitmap), используемая для определения, какие экстенты следует копировать, а какие оставить. В действительности, процедура разностного копирования не учитывает сделанные копии состояния, поэтому такие копии не могут участвовать в процессе разностного восстановления.

При резервировании журнала транзакций состояния базы данных журнал транзакций не обрезается, в отличие от обычного резервирования. Резервирование состояния также не оказывает влияния на цепочку журналов, которая используется для полного резервирования с журналом восстановления. Резервные копии состояния вообще не включаются в список резервных копий журналов при восстановлении. Более подробные сведения можно найти в документации SQL Server 2005 BOL «Резервные копии состояния» по адресу http://msdn.microsoft.com/ru-ru/library/ms191495.aspx.

Почему восстановление базы данных не может выполняться онлайн

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

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

На этой стадии в базе данных обычно содержатся незавершенные транзакции, и база данных не может использоваться для доступа. Далее для SQL Server 2005 Standard Edition наступает фаза последней отмены, в ходе которой выполняется отмена всех незавершенных транзакций. После завершения этой фазы база данных полностью восстановлена и готова к работе. Редакция Enterprise Edition работает немного по другому – база данных готова к использованию сразу после повторения изменений, не дожидаясь фазы отмены незавершенных транзакций.

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