Передовой опыт защиты БД MS SQL Serverdownload.paragon-software.com/doc/ms_sql_server_experience_ru.pdf · 6.5.1 Резервное копирование и

Paragon Drive BackUp Server

Передовой опыт защиты БД MS SQL Server

Системы резервного копирования данных 2 Решения для корпоративного сектора

© Копирайт 1994-2006 Paragon Software Group. Все права защищены.

Содержание 1 Введение ..........................................................................................4 2 О компании Paragon Software Group...............................................5 3 Концепции резервного копирования данных .................................6 3.1 Целостность данных ........................................................................................ 6 3.2 Копирование на уровне файлов и на уровне томов ...................................... 6 3.3 Оффлайновое и онлайновое резервное копирование .................................. 7 3.4 Снимки томов.................................................................................................... 7 3.5 Копирование-при-записи.................................................................................. 8 3.6 Синхронизация данных .................................................................................... 9 3.7 Период отсутствия записи ............................................................................. 10 4 Обзор технологий онлайнового резервного копирования ...........10 4.1 Описание Paragon HotBackup......................................................................... 10 4.1.1 Концепция HotBackup...................................................................................................11 4.1.2 Как это работает ..........................................................................................................11 4.2 Краткое описание MS VSS .............................................................................. 12 4.2.1 Концепции VSS ............................................................................................................12 4.2.2 Как это работает ..........................................................................................................13 4.2.3 Ограничения MS VSS...................................................................................................13 4.3 Работа Drive Backup в среде MS VSS............................................................. 13 4.3.1 Возможность резервного копирования через VSS ........................................................14 4.3.2 Как это работает ..........................................................................................................14 4.3.3 Работа с VSS-несовместимым программным обеспечением ........................................14 4.4 Онлайновое и оффлайновое резервное копирование ................................ 17 5 Особенности защиты корпоративных данных .............................18 5.1 Производительность ...................................................................................... 18 5.2 Надежность ..................................................................................................... 18 5.3 Резервное копирование данных с помощью DBE ........................................ 19 5.3.1 Рекомендованные типы размещения данных ...............................................................19 5.3.2 Неподдерживаемые типы размещения данных ............................................................20 5.4 Восстановление данных с помощью DBE .................................................... 20 5.5 Опции Hotbackup и VSS .................................................................................. 21 6 Защита данных MS SQL Server ......................................................21 6.1 Архитектура баз данных MS SQL ................................................................... 21 6.1.1 Файлы базы данных MS SQL........................................................................................22 6.1.2 Системные и пользовательские базы данных...............................................................22 6.2 Резервное копирование баз данных MS SQL с помощью DBE.................... 23 6.3 Восстановление баз данных MS SQL с помощью DBE ................................ 24 6.4 Выбор между Hotbackup и VSS ...................................................................... 25 6.5 Примеры использования DBE для онлайнового резервного копирования баз данных MS SQL.................................................................................................... 25 6.5.1 Резервное копирование и восстановление изолированной базы данных ......................25 6.5.2 Восстановление отдельной базы данных из архива с несколькими базами данных ......32



6.5.3 Резервное копирование и восстановление отдельной базы данных распределённой по нескольким томам....................................................................................................................38 7 Приложения ...................................................................................46 7.1 RAID уровни .................................................................................................... 46



1 Введение Обеспечение круглосуточного доступа к данным стало насущной необходимостью многих современных предприятий. Простои в работе корпоративных систем обходятся дорого. Особенно это верно для электронного бизнеса. Между тем, согласно исследованию, проведённому IOUG (Independent Oracle Users Group) в 2005 году данные 70% серверов Oracle были недоступны для пользователей в течение часа и более. За этой цифрой стоят серьёзные убытки, которых в большинстве случаев можно было избежать, поскольку значительная часть этих простоев (около 40%) была связана с запланированными техническими работами. В данной книге речь пойдёт об оптимизации одного из наиболее часто проводимых технических мероприятий, о резервном копировании. Описанные методики учитывают, что система и её данные должны быть максимально доступны для пользователей в течение всей процедуры резервного копирования. Кроме того, в книге представлены методики восстановления информации, предполагающие то же условие минимизации простоев системы.

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

В качестве стороннего программного обеспечения, специально разработанного для задач резервного копирования корпоративных данных, предлагается использовать пакет Paragon Drive Backup Enterprise. Пакет содержит все необходимые инструменты для разработки и автоматизации процедур резервного копирования и восстановления информации. Важной его особенностью является возможность восстановления данных без участия базовой операционной системы, что позволяет полностью восстанавливать не только сами данные, но и всё программное окружение. Высокопроизводительные алгоритмы анализа и обработки данных позволяют оптимизировать выполняемые операции для большинства популярных файловых систем Windows и Linux платформ.

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



2 О компании Paragon Software Group Paragon Software Group - международный холдинг, объединяющий ряд европейских и российских компаний, специализирующихся в области производства программного обеспечения для карманных и персональных компьютеров. Холдинг давно зарекомендовал себя в качестве одного из лидеров рынка благодаря качеству разрабатываемых программных продуктов, удовлетворяющих потребностям практически всех групп пользователей. Среди новейших достижений компании - целый ряд разработок, позволяющих быстро и надежно производить сложные манипуляции с оптическими носителями и жесткими дисками. Большое внимание уделяется развитию систем локализации для карманных компьютеров и смартфонов, а также систем распознавания рукописного текста. Использование продуктов Paragon Software позволяет сделать работу на компьютере более приятной и безопасной.

Контактная информация:

Телефон: (495) 789-63-64 доб.505

Факс: (495) 789-63-64 доб.210

E-mail: [email protected]

mailto:[email protected]



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

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

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

3.2 Копирование на уровне файлов и на уровне томов Существуют два подхода к резервному копированию. Первый из них - резервное копирование на уровне файлов или т.н. пофайловое копирование, ориентированное на сохранение отдельных файлов. Второй – резервное копирование на уровне томов диска или создание образов дисковых томов, ориентирован на сохранение всей файловой системы тома в целом.

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

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



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

• либо они используются некоторыми программами, и в таком случае их называют “открытыми”, “оперативными” или “онлайновыми” данными (online data),

• либо они не используются программами, и в таком случае их называют “автономными” или “оффлайновыми” данными (offline data).

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

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

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

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

Метод получения "снимков" или “мгновенных копий” дисковых томов (snapshot – снимок, мгновенная копия) решает данную проблему. Снимок представляет собой точную копию состояния всего архивируемого тома в некоторый момент времени. При этом копия должна быть получена очень быстро, за тот короткий период, пока приложения не производят запись на диск. Как только снимок сделан, специализированная утилита осуществляет резервное копирование данных с полученного снимка, а приложения продолжают работу с исходным томом. Современные технологии позволяют сократить время необходимое для создания снимка до нескольких секунд.

Существуют аппаратные и программные средства, реализующие различные технологии получения снимков. Аппаратные средства (например, технология расщепления зеркала – split mirror) дают возможность практически мгновенно получать копию всего набора данных, не снижая при этом производительности операционной системы. Их можно применять в системах “внешнего” резервного копирования (off host backup – технология, в которой вся вычислительная нагрузка выполняется выделенным сетевым компьютером – сервером резервного копирования, либо специализированным оборудованием). Недостатком аппаратных средств является необходимость применения дорогостоящего специализированного оборудования и наличия избыточного количества дисковых накопителей. Кроме того, после “расщепления зеркала” и копирования данных со снимка приходится выполнять т.н. ресинхронизацию использованного снимка с актуальными данными диска, что требует дополнительного времени и создаёт нагрузку на дисковые накопители.

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



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

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

В Paragon Drive Backup реализована оригинальная технология онлайнового резервного копирования (именуемая Paragon HotBackup). Кроме того, программа поддерживает любые технологии получения снимков системы, участвующие в функционировании сервиса MS VSS.

3.5 Копирование-при-записи Метод копирования-при-записи (Copy-On-Write - COW) преобладает среди программных технологий получения снимков томов. В основе его лежит идея сохранения исходного содержания изменяемых блоков в специальной области памяти до того, как будет непосредственно произведена запись на диск и содержание блока изменится. Такая область памяти называется хранилищем внесённых изменений (difference storage). Метод позволяет поддерживать исходный том диска в актуальном, активном состоянии, сохраняя его исходное содержание в момент получения снимка.

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

1. Некоторый том диска частично используется приложениями. Блоки A, B, C, и D содержат данные. Согласно COW методу с данного тома получают снимок. При получении снимка системы отслеживаются только используемые блоки тома. Первоначально они помечены как "неизменённые".

A B C D

неисп.

неизмен

. неизмен

.

неизмен

. неизмен

.

неисп.

неисп.

A B C D

Исходное содержание тома

Статус блоков

Содержимое хранилища внесённых изменений (пусто) (временно пусто)

Содержимое снимка



2. Некоторое приложение пытается внести изменения в содержание блока B. Перед тем, как эти изменения будут внесены, всё содержимое блока B копируется в хранилище внесённых изменений. Теперь блок помечается как "изменённый". Затем содержание блока B обновляется. Теперь драйвер будет перенаправлять все запросы для блока B к данным, сохраненным в хранилище. Запросы к блокам A, C и D будут направляться непосредственно к копируемому тому.

A B C D

неисп.

неизмен.

неизмен.

неизмен.

неисп.

неисп.

A B C D

B

Актуальное содержание тома

Статус блока B изменён

Содержимое блока B записано в Хранилище


W Приложение переписало блок B

A W C D

неисп.

неизмен.

неизмен.

изменён

!

неизмен.

неисп.

неисп.

A B C D

B неизмен.

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

A W C D

неисп.

неизмен.

неизмен.

неизмен.

неисп.

неисп.

A B C D

B

Актуальное содержание тома

Снимок остаётся прежним

Содержимое Хранилища остаётся прежним


Приложение перезаписало неиспользуемый блок F

A W C D F

неисп.

неизмен.

неизмен.

изменён

!

неизмен.

неисп.

неисп.

A B C D

B неизмен.

F

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



Компанией Microsoft была предпринята серьёзная попытка решить проблему. Среда резервного копирования с получением снимков именуемая Volume Shadow Copy Service (VSS) встроена во все последние версии Windows, а именно в Windows XP, Windows Server 2003 и Windows Vista. Инфраструктура VSS включает в себя механизм оповещения приложений о резервном копировании, взаимообмен соответствующей информации между VSS участниками, а также предусматривает синхронизацию всех программных компонентов вовлеченных в процесс копирования.

Однако, VSS имеет несколько существенных ограничений:

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

отдельном компьютере. Удаленные приложения и системы распределённых данных не могут управляться VSS.

• На сегодняшний день сервис VSS полнофункционально работает только в системе Windows 2003.

3.7 Период отсутствия записи Существует другое частичное решение проблемы синхронизации данных, применимое для программного обеспечения несовместимого с VSS. Это популярное решение основано на парадигме Периода отсутствия записи (Write Inactivity Period - WIP) представленной компанией St.Bernard Software в середине 1990-х.

Предполагается, что в ходе интенсивной обработки информации приложения используют механизм транзакций. Транзакция собирает записи ввода/вывода в компактную группу с целью снижения вероятности фиксирования неполной транзакции при возникновении какого-либо сбоя. Данные в период между транзакциями находятся в целостном состоянии, поэтому именно этот период, когда приложения не производят записи на диск, является наилучшим моментом для получения снимка. Такой период именуется Периодом отсутствия записи (WIP – Write Inactivity Period). Период отсутствия записи может быть использован утилитой резервного копирования для получения снимка тома, если по каким-либо причинам сервис VSS недоступен в системе.

4 Обзор технологий онлайнового резервного копирования

Среди существующих технологий онлайнового резервного копирования данных наибольшую популярность заслужено обрёл метод копирования через получение снимка тома, описанный в главе 2.4. “Снимки томов” и в частности его реализации в виде службы VSS от компании Microsoft. В данной главе подробно рассматривается работа службы VSS, особенности её взаимодействия с программным окружением. Кроме того, представлено описание другой технологии онлайнового резервного копирования, близкой по принципу функционирования к методу копирования через получение снимка тома. Это технология - Paragon HotBackup. В ряде случаев (описанных далее) использование службы VSS затруднено или невозможно. Далеко не все крупные программные продукты поддерживают эту технологию. В таких случаях HotBackup является одной из немногих альтернатив. HotBackup обладает и рядом других достоинств по сравнению с MS VSS, так что администратору предоставляется выбор оптимального инструмента для онлайнового резервного копирования данных. Обе технологии поддерживаются пакетом Paragon Drive Backup Enterprise.

4.1 Описание Paragon HotBackup Paragon HotBackup представляет собой технологию онлайнового резервного копирования для операционных систем семейства Win'NT+. Технология разработана в 2001 и за 2002-2003 годы была интегрирована во все программные решения компании Paragon, так или иначе связанные с резервным копированием. На сегодняшний день HotBackup поддерживает все версии Windows NT4, 2000, XP и 2003 (включая версии x86, IA64 и AMD64).



4.1.1 Концепция HotBackup HotBackup не является технологией получения снимков системы. Однако её концепция близка к тем, что используются в программных средствах их получения. В частности, здесь реализовано отслеживание периодов отсутствия записи (WIP) и метод копирования-при-записи (COW).

Выполняя онлайновое резервное копирование, Drive Backup использует драйвер уровня ядра операционной системы - HOTCORE.SYS для мониторинга и контроля над операциями записи со стороны как приложений, так и самой системы. Драйвер перехватывает запросы ввода/вывода и реализует наиболее критичную по времени часть алгоритма Копирования-при-записи (COW), в то время как утилита Drive Backup обеспечивает функции анализа данных диска и собственно архивирование.

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

4.1.2 Как это работает Драйвер HOTCORE активируется только в ходе выполнения операции онлайнового резервного копирования. В оффлайновом копировании драйвер не принимает никакого участия.

• Drive Backup активирует драйвер HOTCORE в самом начале "физического" резервного копирования.

• HOTCORE ждёт периода отсутствия записи на целевом томе. • Как только такой период зафиксирован, драйвер делает "снимок тома".

В среде HotBackup, "снимок тома" представляет собой карту блоков защищенную от потери исходного содержания алгоритмом Копирования-при-записи (COW). Процесс требует тесного взаимодействия между драйвером и утилитой. В итоге, "защищённая область" снимка включает только используемые блоки с опциональным исключением некоторых файлов (например, PAGEFILE.SYS и HIBERFIL.SYS). Встроенный модуль анализа файловой системы позволяет сократить данный шаг до нескольких секунд.

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

• В случае успешного получения снимка, драйвер выполняет алгоритм COW в отношении "защищенной области".

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

• Если стороннее приложение попытается изменить "защищенный" блок, драйвер записывает его исходное содержание в буфер. Первоначально, блоки хранятся в буфере памяти. Когда он становится почти полным, утилита перемещает блоки во временные файлы (именуемые как "X:\hb_nn.tmp", где X: - логический диск заданный в Настройках).

• Обычно Drive Backup выполняет наиболее быстрое потоковое резервное копирование используемых блоков. Однако, если временные файлы растут слишком быстро и становятся очень большими, утилита приостанавливает потоковый режим и начинает срочное копирование блоков из буфера.

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

• Снимок тома должен быть получен в течение 60 секунд. • Буферизованные данные должны обрабатываться в течение 10 секунд.

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



4.2 Краткое описание MS VSS Volume Shadow Copy Service (VSS) является открытой системной средой, ориентированной на те решения резервного копирования, которые связаны с получением снимков. Среда VSS была разработана компанией Microsoft в тесном сотрудничестве с ведущими поставщиками решений по резервному копированию. На сегодняшний день VSS интегрирован в системы Windows XP, Windows Server 2003 и Windows Vista.

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

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

Есть три типа программного обеспечения (ПО) вовлеченного в работу VSS:

• Поставщики снимков (Providers) – инструменты получения и обслуживания снимков (как аппаратных, так и программных).

• Опросчики (Requestors) – утилиты, запрашивающие теневые копии (обычно это утилиты резервного копирования).

• Агенты записи (Writers) – VSS совместимые приложения, которые держат открытые файлы на томах.

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

VSS writers

VSS requestor VSS

(координатор)

VSS providers

Устройства хранения

DB

SQL сервер

Exchange сервер

Состояние системы

Сам сервис VSS лишь координирует активность поставщиков снимков, агентов записи и опросчиков. Стандартный пакет Windows XP/2003 включает VSS координатор, универсальный программный поставщик



снимков системы (VOLSNAP), несколько агентов записи для системных компонентов и один универсальный агент записи для MS Desktop Engine (MSDEwriter). MSDEwriter обеспечивает интеграцию MS SQL Server 2000 с оболочкой VSS.

4.2.2 Как это работает Исчерпывающее описание VSS можно найти на соответствующих страницах Microsoft TechNet (например, см. тему "How Volume Shadow Copy Service Works",

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/2b0d2457-b7d8-42c3-b6c9-59c145b7765f.mspx ). Ниже приведено лишь краткое описание работы MS VSS:

1. VSS опросчик (утилита резервного копирования) активирует сервис VSS для запуска стандартной процедуры резервного копирования.

2. VSS запрашивает информацию от всех агентов записи. В результате формируется Документ Метаданных Агентов записи (Writers Metadata Document - WMD). Он содержит характерные имена приложений и компонентов, параметры восстановления, список файлов и другую информацию.

3. Опросчик получает документ WMD и принимает решение, что именно будет архивироваться в первую очередь. Он формирует Документ Компонентов Резервного копирования (Backup Components Document - BCD), который задает архивируемые тома, агентов записи и их компоненты, участвующие в процессе. Этот документ направляется в VSS. Опционально, можно выбрать VSS поставщика, который по тем или иным причинам наиболее предпочтителен.

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

5. Затем VSS направляет команду соответствующим VSS поставщикам – сделать снимки выбранных томов.

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

7. В случае успешного завершения описанных выше шагов (в пределах заданного интервала времени), VSS создает теневые копии снимков и предоставляет опросчику соответствующие ссылки.

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

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

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

4.2.3 Ограничения MS VSS MS VSS имеет несколько существенных ограничений:

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

отдельном компьютере. Удаленные приложения и системы распределённых данных не могут управляться VSS.

• На сегодняшний день сервис VSS полнофункционально работает только в системе Windows 2003.

4.3 Работа Drive Backup в среде MS VSS Интегрированные среды управления запоминающими устройствами предоставляют очевидные преимущества и могут существенно упрощать соответствующие процедуры управления дисковой

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/2b0d2457-b7d8-42c3-b6c9



подсистемой. На сегодняшний день Paragon Drive Backup Enterprise адаптирован для работы в интегрированной среде VSS в качестве опросчика.

4.3.1 Возможность резервного копирования через VSS Для выполнения операций резервного копирования через VSS сервисы, выберите в настройках Drive Backup опцию "Microsoft Volume Shadow Copy Service ":

(главное меню:) Общие Ä Настройки… Ä Опции Hot processing Ä Технология Hot processing Ä Microsoft Volume Shadow Copy Service

Заметьте, что сервис MS VSS доступен только в Windows XP, 2003 and Vista. В других операционных системах для онлайнового резервного копирования доступна лишь технология Hotbackup.

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

4.3.2 Как это работает Резервное копирование с использованием VSS выполняется следующим образом:

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

• Когда начинается "физическое" резервное копирование, программа получает составной WMD документ от VSS (см. пункт #2 в описании работы VSS).

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

• Drive Backup передает VSS команду использовать принятый по умолчанию порядок вызова VSS поставщиков: аппаратный поставщик - первый (если есть), далее сторонние программные (если есть), последние – универсальный системный поставщик VOLSNAP (есть всегда).

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

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

4.3.3 Работа с VSS-несовместимым программным обеспечением Как упоминалось ранее, есть немало популярных программных продуктов, которые пока не поддерживают VSS. Это часто служит препятствием для использования специализированных средств резервного копирования при защите их данных. Однако некоторые из них обеспечивают функции управления, позволяющие имитировать VSS-совместимое поведение путём быстрой остановки работы приложения перед запуском операции резервного копирования и возобновления нормального функционирования после получения снимков томов. Например: для Oracle, с этой целью необходимо выполнить специальную последовательность PL/SQL команд; для Microsoft Virtual Server, необходимо сформировать запросы к COM интерфейсу и вызвать соответствующие методы, и т.д..

Для поддержки такого рода функциональности, Drive Backup предоставляет возможность обработки заданных пользователем команд в трёх критически-важных моментах процедуры резервного копирования:



1. Непосредственно перед получением снимка; 2. Сразу после получения снимка; 3. По завершению всего процесса резервного копирования.

Командой может быть любая допустимая для Windows интерпретатора команд (CMD.EXE):

• Любая внутренняя команда CMD.EXE • Любой пакетный файл (*.BAT, *.CMD) • Любой исполняемый файл со своим списком аргументов • Сервисы запуска/остановки, паузы/возобновления работы. • Сценарии любого типа поддерживаемого Windows Scripting Host

Чтобы команды были выполнены в один из указанных моментов процедуры копирования, их необходимо задать в программных настройках, на странице "Run during backup options" (“Опции запуска по ходу резервного копирования”):

Drive Backup контролирует коды завершения возвращаемые указанными командами и может прервать операции резервного копирования согласно заданному пользователем условию. Кроме того, программа передаёт командам информацию специфичную для той или иной операции через специальные переменные окружения. Информация может включать текущий статус операции резервного копирования, флаги ошибок, ссылки на используемую технологию онлайнового резервного копирования, список архивируемых томов. Подробное описание опций "Run during backup" доступно в онлайновом справочнике по Drive Backup.

Рекомендуемое использование команд:

1. Команды секции "Execute before taking a snapshot" (“Выполнить перед получением снимка”) должны приостанавливать работу приложения, данные которого необходимо скопировать.

2. Команды секции "Execute after taking a snapshot" (“Выполнить после получения снимка”) должны возобновлять работу приложения, разрешая ему вновь нормально функционировать.

3. Команды в "Execute after finishing the backup" (“Выполнить по завершению резервного копирования”) используются редко. Например, они могут быть направлены на выполнение некоторых



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

В соответствии с функциональной ролью опций "Run during backup", процедура резервного копирования выглядит следующим образом:

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

• Возникновение ошибки (не-нулевой код завершения) приводит к тому, что Drive Backup прерывает всю процедуру резервного копирования.

• В противном случае (нулевой код завершения) Drive Backup делает снимок выбранных томов.

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

• В противном случае (снимок был успешно получен) Drive Backup выполняет вторую команду (возобновляет работу приложения).

• Независимо от результата предыдущего шага, Drive Backup запускает операцию резервного копирования для данных снимка.

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

1-я команда

Получить снимок

Ошибка ?

2-я команда

3-я команда

Резервн. копирование

2-я команда

Конец

да

да

нет

нет

Ошибка ?

Начало

Действия выполняемые командами "Run during backup" могут зависеть от результатов предшествующих шагов процедуры резервного копирования. По этой причине Drive Backup передаёт командам информацию о параметрах копирования, а также о результатах выполнения предшествующих шагов. Эта информация хранится в специальных переменных окружения, которые поддерживаются Drive Backup при каждом выполнении той или иной команды.

Переменные окружения:

Имя Значения PARAGON_VSSACTIVE “YES”, “NO” PARAGON_BACKUPLEVEL “BEFOREBACKUP”, “AFTERSNAPSHOT’, “AFTERBACKUP” PARAGON_BACKUPERROR 0..65536 VOLUME_NAME_LIST Список томов (например, "C:\ D:\ F:\")

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

Пример анализа переменных:

Командой "Execute after taking a snapshot" может быть следующая:

resume_app.bat Фрагмент пакетного файла "resume_app.bat":

..... if %PARAGON_BACKUPERROR%=0 goto NoError net send BackupSupervisor "MyApp backup failed!"



:NoError

net continue MyAppService ..... Пакетный файл направляет пользователю "BackupSupervisor" предупреждение о сбое при выполнении процедуры резервного копирования (на этапе получения снимка).

Пример конвертирования в аргументы команды:

Командной "Execute before taking a snapshot" может быть следующая:

stop_oracle.bat %PARAGON_VSSACTIVE% Фрагмент пакетного файла "stop_oracle.bat":

..... if %1="YES" goto NoError net send BackupSupervisor "VSS is not used in backup!" exit 1

:NoError ..... Пакетный файл направляет пользователю "BackupSupervisor" предупреждение в том случае, если VSS не будет использован для онлайнового резервного копирования (требуется получить синхронный снимок нескольких томов и VSS необходим для операции); ошибка передана через код завершения – и это должно привести к прерыванию процедуры резервного копирования.

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

• “Горячее” резервное копирование (онлайновое), осуществляемое через Hotbackup или VSS, занимает больше времени, чем та же операция выполненная оффлайн.

• Инициирование VSS требует значительного времени и, в общем, не отличается стабильностью при высоком трафике ввода/вывода на целевом томе.

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

• Опции онлайнового резервного копирования (HotBackup и VSS) полностью не решают проблем естественным образом связанных с самой технологией онлайнового резервного копирования.

VSS обеспечивает целостность данных только для VSS-совместимых приложений. Hotbackup тоже не гарантирует стопроцентной целостности данных, а лишь её высокую вероятность. Фактически, он обеспечивает хорошие результаты для любых приложений использующих транзакции (например, сервера SQL, MS Exchange).

Drive Backup обеспечивает некоторую гибкость в выборе между оффлайновым и онлайновым режимами резервного копирования. Пользователь может выбрать три варианта: (a) "всегда выполнять резервное копирование в оффлайновом режиме", (b) "переключаться в онлайновый режим, если том используется" и (c) "всегда выполнять резервное копирование в онлайновом режиме". Отличия между этими вариантами следующее:

a. “Всегда выполнять резервное копирование в оффлайновом режиме”: • Программа не будет делать резервные копии используемых томов. Пользователю будет

предложено произвести перезагрузку для завершения операции в режиме "Startup Bluescreen".



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

b. “Переключаться в онлайновый режим, если том используется”: • Если том используется, программа выполняет онлайновое резервное копирование. В ходе

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

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

c. " Всегда выполнять резервное копирование в онлайновом режиме": • Программа выполняет онлайновое резервное копирование. В ходе операции прочие

приложения могут также получать доступ к тому.

5 Особенности защиты корпоративных данных Защита корпоративных данных требует учёта ряда очевидных условий, вытекающих из повышенных требований к операционной стабильности сервера. Среди таких условий можно назвать обеспечение непрерывного доступа к данным (часто речь идёт о круглосуточном доступе), актуальность данных (востребованность часто меняющейся информации), высокий трафик ввода/вывода на томах с архивируемыми данными, размещение данных на нескольких томах и некоторые другие. В данном разделе рассматриваются решения, в максимальной степени учитывающие эти условия. В качестве инструмента резервного копирования предлагается пакет Paragon Drive Backup Enterprise, специально разработанный для защиты данных корпоративных серверов и представляющий собой эффективное решение для большинства рассматриваемых ситуаций.

5.1 Производительность Есть немало факторов оказывающих влияние на производительность работы серверов. Наиболее существенные из них – доступный объем памяти и производительность дисковой подсистемы. Доступная память влияет на скорость чтения, которая важна для эффективной работы Систем поддержки принятия решений (Decision Support Systems - DSS). Производительность дисковой подсистемы оказывает влияние на скорость чтения / записи. Высокая скорость записи существенна для приложений оперативной обработки транзакций (OLTP приложения).

Наиболее эффективные методы увеличения производительности дисков основаны на использовании RAID массивов. Чередующиеся RAID массивы обеспечивают максимально высокую скорость чтения/записи, которая может в несколько раз превышать производительность отдельного диска.

RAID 0 Чередующийся массив дисков RAID 0+1 Зеркалирование чередующихся сегментов (RAID 1

поверх RAID 0) RAID 3 Чередующийся массив дисков с Изолированным

контролем четности RAID 5 Чередующийся массив дисков с Распределённым

контролем четности RAID 10 Чередование зеркалированных сегментов (RAID 0

поверх RAID 1)

5.2 Надежность Помимо резервного копирования данных обеспечивающего возможность их аварийного восстановления, есть немало способов снизить вероятности возникновения самих сбоев в работе сервера. Аппаратный метод заключается в использовании отказоустойчивых RAID конфигураций (например, RAID-10 или RAID-5).



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

5.3 Резервное копирование данных с помощью DBE Успешное применение пакета Paragon Drive Backup Enterprise для задач резервного копирования зависит от ряда обстоятельств. Так, необходимо учитывать:

• Находятся ли данные сервера на сетевом устройстве? • Распределены ли копируемые данные по нескольким томам? • Следует ли выполнить онлайновое резервное копирование данных, или будет приемлемо

временно приостановить работу сервера (или отдельной базы данных) для оффлайнового резервного копирования?

• Какая операционная система используется на компьютере?

Следующие управляющие факторы могут ограничивать использование Drive Backup для резервного копирования данных:

• Текущая версия Drive Backup не выполняет резервного копирования сетевых устройств. • Текущая версия Drive Backup не содержит каких-либо агентов специально ориентированных на

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

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

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

5.3.1 Рекомендованные типы размещения данных Общие рекомендации:

• Размещайте производственные данные на локальных томах. • Размещайте производственные данные на томах высокопроизводительных RAID массивов. • Размещайте производственные данные на специально выделенных для этого томах (если позволяют

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

Системные рекомендации:



• Технология MS VSS доступна только в Windows XP, 2003 и Vista. • В Windows Server 2003 и Vista устанавливайте Drive Backup, чтобы использовать MS VSS для

онлайнового резервного копирования данных распределенных по нескольким томам. Выберите пункт "Microsoft Volume Shadow Copy" в выпадающем списке "Технология Hot processing " программных настроек. VSS существенно повышает шансы успешного архивирования распределённых баз данных.

• В Windows 2000 и NT 4.0, размещайте все критически важные данные (в базах данных – и файлы данных, и журнал транзакций) на одном томе. Для этих операционных систем доступна только опция Hotbackup. В случае нескольких томов Hotbackup выполняет их асинхронное резервное копирование, так что распределённые базы данных могут быть архивированы в логически нецелостном состоянии.

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

5.3.2 Неподдерживаемые типы размещения данных Текущая версия Drive Backup имеет ряд ограничений на операции резервного копирования данных:

• Данные полностью размещаемые на сетевом диске не могут быть архивированы средствами Drive Backup, т.к. программа не выполняет резервного копирования сетевых дисков.

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

Данные сервера частично размещаемые на сетевом диске могут быть препятствием для корректного восстановления данных всего копируемого тома. Drive Backup не может полностью архивировать такие данные, т.к. их нельзя будет правильно восстановить. Во избежание возможных проблем вызванных неполным восстановлением данных, не стоит применять операции восстановления тома в отношении томов с распределенными данными. Вместо этого к такого рода томам следует применять пофайловое восстановление данных. Используйте утилиту "Image Explorer" или окно "Volume Explorer" для экспорта отдельных файлов из резервных архивов Drive Backup.

• В окружении Windows 2000 и NT 4.0 распределенные данные не могут быть корректно архивированы в онлайновом режиме (в виду синхронизационных ограничений опции Hotbackup). Однако такого рода данные можно успешно архивировать в оффлайн. В случае базы данных отключите её или приостановите её работу перед архивированием томов содержащих распределенные данные.

5.4 Восстановление данных с помощью DBE Текущая версия Drive Backup не использует онлайновых методов восстановления данных. Оффлайновое восстановление – единственный доступный метод. Миграция баз данных при восстановлении также недоступна.

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

Различие между упомянутыми выше способами следующие:

• При восстановлении на уровне тома диска, всё содержимое целевого тома будет возвращено в исходное состояние. Например, если на томе было размещено три базы данных, то при восстановлении на уровне тома все они будут восстановлены в состояние предшествующее снятию резервной копии. Метаданные тома также будут восстановлены и помещены в целостном состоянии на ранее занимаемые ими места.

• Восстановление на уровне тома протекает очень быстро и позволяет восстанавливать тома “с нуля”.

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



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

5.5 Опции Hotbackup и VSS В операционных системах Windows XP, 2003 и Vista Drive Backup предоставляет два варианта онлайнового резервного копирования на базе снимков системы. В Windows 2000 и Windows NT4.0, доступен лишь один - Hotbackup.

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

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

• Для работы в режиме Hotbackup требуется меньше памяти и дисковых ресурсов. Например, последние версии VSS (для Windows XP и 2003) требуют как минимум 300 Мб дискового пространства на каждую создаваемую теневую копию (в момент получения снимка), в то время как Hotbackup будет занимать те же 300 Мб дискового пространства только при очень высокой рабочей загрузке диска.

• Как VSS, так и Hotbackup могут иметь проблемы при получении или сохранении снимков системы в условиях высокого трафика ввода/вывода на архивируемом томе. VSS требует большого объёма свободного дискового пространства для хранения снимка. Hotbackup требует более высокой производительности операции резервного копирования по отношению к нагрузке сервера SQL.

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

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

• Только последние версии VSS достаточно стабильны. В связи с этим рекомендуется устанавливать последний доступный service pack, а также следить за последними поправками к VSS для систем Windows XP/2003.

6 Защита данных MS SQL Server Microsoft SQL Server – универсальный сервер реляционных баз данных, который может масштабироваться от обслуживания небольшой базы данных до системы бизнес приложений решающих критически важные задачи. MS SQL – наиболее популярная на сегодняшний день реляционная база данных на платформе Windows.

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

6.1 Архитектура баз данных MS SQL Понимание отношений между файлами базы данных, томами диска и устройствами хранения информации играет важную роль для оптимального использования средств резервного копирования, в частности пакета Drive Backup Enterprise (DBE).



Существуют два различных типа размещения баз данных MS SQL:

• База данных может быть помещена на RAW раздел. Размещение базы данных на одном разделе обеспечивает некоторый выигрыш в производительности. Но такого рода базы данных не могут наращиваться и по этой причине используются крайне редко. Пакет Drive Backup применяется для резервного копирования баз данных находящихся на одном разделе без каких-либо ограничений.

• База данных может быть помещена в некоторый набор файлов. Это стандартный тип размещения базы данных. Файлы базы могут располагаться на любых локальных томах, а также на сетевых совместно используемых устройствах. Они необязательно помещаются вместе, а могут быть разбросаны по разным томам. Пакет Drive Backup применяется для резервного копирования файл-ориентированных баз данных с небольшими ограничениями.

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

6.1.1 Файлы базы данных MS SQL В пределах структуры MS SQL Server, файлы базы данных обычно, по умолчанию имеют следующие расширения:

• .MDF – "main data file", файл первичных данных. Обязательная часть любой базы данных. Он хранит сами данные и служебную информацию базы данных, включая список файлов составляющих базу.

• .NDF – "next data file", файл(ы) вторичных данных. Опциональная часть базы данных. Используется для расширения базы данных, а иногда для "мульти-потокового" доступа к данным.

• .LDF – "log data file", файл(ы) журнала транзакций. Обязательная часть любой базы данных. Файл содержит информацию необходимую для управления и восстановления транзакций.

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

Например, если Ваша база данных называется "ABC" и размещается в папке "S:\ABC", то она может состоять из следующих файлов: файла первичных данных "S:\ABC\ABC_DATA.MDF", журнала транзакций "S:\ABC\ABC_DATA.LDF" и файлов вторичных данных "S:\ABC\ABC_DATA_1.NDF", "S:\ABC\ABC_DATA_2.NDF".

6.1.2 Системные и пользовательские базы данных В MS SQL Server есть несколько системных баз данных, в которых хранится структурная, административная, сопроводительная и прочая служебная информация по базе:

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

Model Используется как шаблон для вновь создаваемых баз данных, экземпляров сервера. Msdb Используется SQL Server Agent для хранения информации о выполняемых

сопроводительных работах. tempdb Используется для временного хранения информации. Эта база данных пересоздается при

каждом перезапуске сервера SQL.

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



6.2 Резервное копирование баз данных MS SQL с помощью DBE

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

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

Помимо общих системных рекомендаций, также изложенных в разделе 4.3.1., главы 4, необходимо отметить, что только системы MS SQL Server 2000 и 2005 являются VSS-совместимыми. Для более ранних версий SQL серверов, нет заметного различия между опциями Hotbackup и VSS. Технология VSS дает преимущества при получении резервных копий MS SQL Server 2000 и 2005 и повышает шансы успешного архивирования баз данных.

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

• Есть некоторый высокопроизводительный RAID массив предназначенный для размещения производственной базы данных. Например, RAID 10 обеспечивает достаточно высокий уровень и надежности, и производительности.

• Есть некоторое отдельное устройство хранения информации (жесткий диск или другой RAID-массив) предназначенный для размещения системного раздела, бинарных файлов MS SQL Server и базы данных tempdb, а также для хранения образов резервных копий.

• Системный жесткий диск разбит на несколько томов. База данных tempdb отделена от операционной системы и бинарные файлы SQL сервера также размещены на отдельном томе.

• Образы резервных копий хранятся на не-системном томе, возможно, на томе содержащем tempdb.

Жесткий диск

RAID 10

[C:]

[E:]

[X:]

[Y:]

[D:] CD-ROM

MS SQL Server

Windows 2003

master model msdb

tempdb

SALES

Системные базы данных

Логические тома

Производственные базы данных

sales.MDF sales_1.NDF sales.LDF

GOODS goods.MDF goods_1.NDF goods.LDF



6.3 Восстановление баз данных MS SQL с помощью DBE Как упоминалось в главе 4 “Особенности защиты корпоративных данных” (раздел 4.4.), восстановление повреждённой базы данных может быть выполнено двумя способами – как часть процедуры восстановление тома диска и пофайловым восстановлением. В последнем случае есть два варианта. Первый – через восстановление файлов базы данных в места их первоначального расположения с последующим перезапуском сервисов SQL сервера, так что они автоматически подключат восстановленную базу данных. Но при этом SQL сервер будет недоступен для пользователей в течение некоторого времени, требующегося для: остановки всех пользовательских сессий, остановки всех баз данных, сброса данных на диск, остановки и перезапуска сервисов SQL сервера и выполнения так называемой процедуры "мягкого восстановления" для всех подключенных баз данных включая восстанавливаемую.

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

1. Запустите SQL Server Enterprise Manager и выберите требуемую базу данных в древовидном списке: Console Root Ä Microsoft SQL Servers Ä <группа Вашего SQL сервера> Ä <Имя экземпляра SQL сервера> Ä Databases Ä <требуемая база данных> Ä (контекстное меню) Ä All Tasks Ä Detach Database…

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

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

3. Если описанное выше не помогло, попробуйте просмотреть таблицы поврежденной базы данных с тем, чтобы вынудить сервера SQL сменить статус базы данных на "Suspect". Затем перезапустите ещё раз SQL Server Manager.

4. Если все предшествующие шаги не оказали никакого эффекта, остановите работу сервера SQL сервера и перезапустите его.

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

После того как база данных была отключена, можно начать её восстановление из архивного образа. Восстановленную базу данных можно легко вновь подключить к серверу SQL:

Console Root Ä Microsoft SQL Servers Ä <группа Вашего SQL сервера> Ä <Имя экземпляра SQL сервера> Ä Databases Ä (контекстное меню) Ä All Tasks Ä Attach Database…



6.4 Выбор между Hotbackup и VSS В операционных системах Windows XP, 2003 и Vista Drive Backup предоставляет два варианта онлайнового резервного копирования на базе снимков томов - Hotbackup и MS VSS (в Windows 2000 и Windows NT4.0, доступен лишь один – Hotbackup). При выборе опции необходимо учитывать ряд обстоятельств, наиболее общие из которых уже обсуждались в главе 4 “Особенности защиты корпоративных данных” (раздел 4.5). В отношении SQL-сервера следует также отметить, что VSS-совместимыми можно считать только Microsoft SQL Server 2000 и Microsoft SQL Server 2005, более ранние версии серверов – VSS-несовместимы. В связи с этим для более ранних версий Microsoft SQL Server, различия между VSS и Hotbackup опциями онлайнового резервного копирования несущественны.

Ряд проведённых тестов показали общую нестабильность запуска VSS при "стрессовой нагрузке" сервера SQL (например, при длительной нагрузке на уровне более 1-1.5 тысячи редактируемых страниц в секунду). Для решения этой проблемы необходимо либо использовать опцию Hotbackup, либо уменьшить активную часть журнала транзакций.

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

Упомянутый эффект различия периодов восстановления является общим для всех не-VSS технологий получения снимков системы. Для уменьшения эффекта запустите управляющую консоль сервера SQL и задайте некоторое положительное значение для Интервала восстановления (Recovery Interval):

<экземпляр сервера SQL > Ä Properties Ä Database Settings Ä Recovery Interval (min).

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

6.5 Примеры использования DBE для онлайнового резервного копирования баз данных MS SQL

Настоящая глава показывает, как можно использовать Paragon Drive Backup для онлайнового резервного копирования баз данных MS SQL, а также при восстановлении данных в случае повреждения базы.

6.5.1 Резервное копирование и восстановление изолированной базы данных

Условия: производственная база данных (с названием "test") размещена на отдельном томе [F:]. Все файлы базы данных (основной файл - test_Data.MDF, журнал транзакций - test_log.LDF и вторичный файл - test_fg1.NDF) размещены на томе F:. На практике такое расположение базы данных реализуется только в случае малых баз данных или в условиях очень ограниченного бюджета.

Задача: выполнить резервное копирование, а затем восстановление базы данных "test".

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

1. Проверьте параметры базы данных, чтобы убедиться, что все файлы базы расположены на одном томе. Для этого откройте консоль SQL Server Manager, найдите соответствующий экземпляр сервера SQL и откройте категорию "Databases". Найдите соответствующее имя базы данных в списке (в нашем



примере, это база "test"). Просмотрите параметры этой базы. Месторасположение файлов определено в закладках "Data files" и "Transaction Log" диалога “Properties”:

Более исчерпывающую информацию по всем файлам базы данных можно получить из таблицы "sysfiles". Раскройте список узла соответствующего выбранной базе данных, кликните на категории "Tables". Затем перейдите на правую панель и найдите в списке таблицу "sysfiles". Кликните правой кнопкой мыши на таблице и выберите в контекстном меню пункт "Open table" à "Return all rows". После этого будет отображено содержание таблицы "sysfiles". Здесь можно просмотреть имена файлов, их текущий размер (выраженный в 8KB-страницах) и другую информацию для каждого файла базы данных:



2. Запустите Drive Backup, откройте диалог “Settings” (menu: "File" à "Settings…"). Перейдите к странице "Hot processing options", включите опцию онлайнового резервного копирования, а затем выберите используемую технологию для резервного копирования: Paragon Hotbackup или Microsoft Volume Shadow Copy:

3. Запустите Мастер резервного копирования для настройки параметров операции (независимо от того будет ли это задача запланированная для регулярного выполнения или задача "одного запуска"). На странице "What to back up", выберите для резервного копирования том F:



4. Программа создаст резервный образ тома F:

5. Теперь предположим, что база данных "test" повреждена (в нашем примере, было искажено содержание файла test_Data.MDF, что вызвало повреждение системной информации). Сервер SQL больше не может подключать и использовать базу данных "test". Недоступны и параметры базы данных:



6. Необходимо отключить базу данных от сервера SQL, восстановить её из резервного архива, а затем вновь подключить к серверу SQL. Для отключения базы данных "test", кликните правой кнопкой мыши на имени базы в списке и выберите пункт "All tasks" à "Detach database…" в контекстном меню:

7. Предположим, что на томе F: нет ни других баз данных, ни их файлов, а есть только база данных "test", которую необходимо восстановить. Запустим Drive Backup и восстановим весь том F: из соответствующего архива. Для этого запустим Мастер восстановления и выберем соответствующий файл архива (.PBF):



8. Выберем в архиве сохраненный том:

9. Выберем на диске том, на который будут восстанавливаться данные:



10. Drive Backup восстановит данные тома:

11. Подключим ещё раз базу данных "test" к серверу SQL. Для этого, запустите SQL Server Manager, найдите соответствующий экземпляр сервера SQL, выберите пункт "Databases" и откройте для него выпадающее меню. В этом меню выберите пункт "Attach database". Программа отобразит диалоговое окно "Attach database". Нажмите кнопку "…" и найдите файл .MDF восстановленной базы данных (test_Data.MDF в нашем примере):

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

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



12. Проверьте следующее окно и убедитесь, что все файлы восстановленной базы данных имеют корректные ссылки. Все файлы базы данных должны быть помечены зелёными “галочками”, это показывает, что сервер SQL нашел все файлы базы данных в их ожидаемом месторасположении. В данном примере, все файлы базы данных должны быть расположены в одной директории "F:\test":

13. Сервер SQL подключает базу данных и обновляет её статус. Она вновь становится работоспособной:

6.5.2 Восстановление отдельной базы данных из архива с несколькими базами данных

Условия: три производственные базы ("test1", "test2", "test3") размещены на отдельном томе [E:]. Том E: содержит все их файлы.

Задача: выполнить резервное копирование базы данных "test2". Восстановить базу данных "test2" без какого-либо влияния на работу остальных баз данных.

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



1. Итак, том E: содержит три базы данных (test1, test2, test3). В SQL Server Manager можно ознакомится с параметрами баз данных. Открыв таблицы "sysfiles" для всех баз данных, можно сразу увидеть значения параметров:

2. Резервное копирование всего тома E: следует производить в режиме онлайн. Для этой задачи можно использовать любую из опций онлайнового резервного копирования (HotBackup или MS VSS):

Производительность:

• Виртуальная машина: P4 1.5 GHz, 512 MB RAM • операционная система: Windows Server 2003, Domain Controller • виртуальный диск (max производительность): 35 Mб/сек • ср. производительность архивирования: 26Mб/сек, что превышает >90Гб/час

(~74% от максимальной производительности) (это 12× скорость архивирования через SQL server API)

• конечная скорость сжатия (уровень "Best"): ~ 1:6 (526Мб архива против 3.1Гб исходных данных)



3. База данных "test2" повреждена (в нашем примере, искажено содержимое файла test2_Data.MDF, что вызвало повреждение системной информации). Сервер SQL больше не может подключать и использовать базу данных "test". Недоступны и параметры базы данных:



4. Необходимо отключить базу данных от сервера SQL, восстановить её из резервного архива, а затем вновь подключить к серверу SQL Server. Для отключения базы данных "test2", кликните правой кнопкой мыши на имени базы в списке и выберите пункт "All tasks" à "Detach database…" в контекстном меню:

5. Нет необходимости восстанавливать весь том E: из резервного архива, т.к. это повлечёт за собой

откат всех трёх баз данных, включая неповреждённые "test1" и "test3"! Во избежание этой проблемы, следует восстановить базу данных "test2" в пофайловом режиме. Необходимо открыть резервный архив в Image Explorer, а затем “вручную” скопировать файлы в места их исходного расположения. Запустите Image Explorer и найдите файл резервного архива для тома E:. Откройте архив двойным кликом на соответствующем PBF-файле. Image Explorer отобразит содержимое архива.



6. Теперь необходимо извлечь файлы базы данных из архива. В нашем примере, вся база данных "test2" размещается в отдельной директории (E:\test2). Так что вся директория "test2" может быть экспортирована из архива. Откройте контекстное меню для директории сохраненной в архиве, а затем выберете пункт "Export".

7. Теперь выберите родительскую директорию, куда следует поместить директорию "test2". В нашем примере база данных первоначально располагалась в директории E:\test2. Поэтому в качестве целевой необходимо выбрать директорию "E:\" (для восстановления базы данных в место её первоначального расположения).



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

8. Image Explorer извлекает выбранные файлы из резервного архива:

9. Подключим ещё раз базу данных "test2" к серверу SQL. Для этого, запустите SQL Server Manager, найдите соответствующий экземпляр сервера SQL, выберите пункт "Databases" и откройте для него выпадающее меню. В этом меню выберите пункт "Attach database". Программа отобразит диалоговое окно "Attach database". Нажмите кнопку "…" и найдите файл .MDF восстановленной базы данных (test2_Data.MDF в нашем примере):



В большинстве случаев сервер SQL не блокирует повреждённые базы данных. Поэтому нет необходимости отключать базу данных перед её восстановлением. Но, это может потребоваться позже, для процедуры повторного подключения базы данных. Шаг 4 можно выполнить непосредственно перед этим шагом.

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

10. Теперь база данных вновь работоспособна

6.5.3 Резервное копирование и восстановление отдельной базы данных распределённой по нескольким томам

Условия: производственная база "Test" размещена на нескольких томах и сконфигурирована в соответствии с рекомендациями Microsoft по повышению производительности баз данных. Файлы журнала транзакций помещены на отдельном томе (L:). Файлы данных объединены в две файловые группы ("PRIMARY" и "SECOND"). Файловая группа "SECOND" активна и включает все производственные таблицы; она состоит из двух файлов базы данных, размещённых на различных томах. База данных "tempdb" изолирована от производственных баз данных. В итоге все упомянутые тома размещены на разных жестких дисках:



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

Задача: выполнить резервное копирование и восстановить базы данных "Test".

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

1. Ознакомьтесь с параметрами базы данных в SQL Server Manager для получения информации о месторасположении её файлов: раскройте список соответствующий базе данных "Test", выберите таблицу "sysfiles" в правой панели. Затем кликните правой кнопкой мыши на таблице и выберите пункт "Open table" à "Return all rows" в контекстном меню.



В данном примере, база данных "Test" расположена на трёх томах (D:, F: и L:).

2. Запустите Drive Backup, откройте диалог “Settings” (главное меню: "File" à "Settings…"). Перейдите к странице "Hot processing options", включите режим онлайнового резервного копирования и выберите в качестве технологии резервного копирования - "Microsoft Volume Shadow Copy":

3. Запустите Мастер резервного копирования для настройки операции (независимо от того будет ли это задача запланированная для регулярного выполнения или задача "одного запуска"). На странице "What to back up", выберите для резервного копирования тома D:, F: и L:



4. Программа создаст резервную копию трёх томов

5. Теперь предположим, что база данных "test" была повреждена. Сервер SQL не может подключить или использовать базу данных "test". Недоступны и параметры базы данных:



6. Отключите повреждённую базу данных "Test" от сервера SQL: кликните правой кнопкой мыши на базе данных "test" в списке и выберите пункт "All tasks" à "Detach database…" открывшегося контекстного меню.

7. Предположим, что никаких других баз данных и файлов на томах D:, F: и L: не существует, за исключением файлов базы "Test", которую необходимо восстановить. При этих условиях можно применить метод восстановления данных на уровне тома. Запустите Drive Backup, запустите Мастер восстановления и выберите ранее созданный резервный архив томов D:, F: и L:.



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



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

10. По завершению настройки параметров операции, программа приступает к физическому выполнению операции восстановления.



11. Подключите повторно базу данных "Test" к серверу SQL. Запустите SQL Server Manager и выберите: Console Root Ä Microsoft SQL Servers Ä <группа SQL сервера> Ä <Имя экземпляра сервера> Ä Databases Ä (контекстное меню) Ä All Tasks Ä Attach Database…

Программа отобразит диалоговое окно "Attach database". Нажмите кнопку "…" и найдите .MDF файл восстановленной базы данных (в нашем примере, это файл "Test_Data.MDF").

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



7 Приложения 7.1 RAID уровни Использование RAID массивов – наиболее эффективный способ повысить производительность и обеспечить аппаратный уровень отказоустойчивости дисковой подсистемы. Чередующиеся RAID массивы обеспечивают максимальную скорость чтения/записи, которая может многократно превышать производительность отдельного диска.

RAID уровень Краткое описание Число дисков Коэффициент

размера Коэффициент

производительности

Отказоустойчивос

ть 0 Чередующийся массив дисков N ≥ 2 × N × N Нет



1 Зеркалированный массив дисков M ≥ 2 × 1 × 1 Да

0+1 Зеркалирование чередующихся сегментов (RAID 1 поверх RAID 0)

M•N ≥ 4 M ≥ 2, N ≥ 2 × N × N Да

3 Чередующийся массив дисков с изолированным контролем четности

N+1 ≥ 3 × N × N (для чтения) × 1 (для записи) Да

5 Чередующийся массив дисков с распределённым контролем четности

N+1 ≥ 3 × N × N (для чтения) × 1 (для записи)

Да

10 Чередование зеркалированных сегментов (RAID 0 поверх RAID 1)

N•M ≥ 4 N ≥ 2, M ≥ 2

× N × N Да

RAID 0

A C E G

B D F H

RAID 1 RAID 3

A C E G

B D F H

⊕ ⊕ ⊕ ⊕

RAID 5

A

G

D ⊕

B

H

⊕ E

⊕

⊕

C F

RAID 0+1

A C E G

B D F H

A C E G

B D F H

A C E G

A C E G

B D F H

B D F H H

G F E D C B A

H G F E D C B A

RAID 1+0

H G F E D C B A

H G F E D C B A

H G F E D C B A

H G F E D C B A

H G F E D C B A

H G F E D C B A

G ⊕ H E ⊕ F C ⊕ D A ⊕ B

Parity

Более подробное описание различных RAID уровней можно найти в Интернет.

Documents

Передовой опыт защиты БД MS SQL Serverdownload.paragon-software.com/doc/ms_sql_server_experience_ru.pdf · 6.5.1 Резервное копирование и