 |
|
|
|
Резервное копирование. Теория и практика. Краткое изложение. Часть 2
Резервное копирование Какие существуют технологические аспекты резервного копирования? Что из них лучше выбрать в том или ином случае? Этому и посвящен данный материали Файлы vs блоки Резервное копирование данных производится с помощью двух основных технологических направлений:
Технология файлового копирования Как это предполагается из названия, обычно используется при резервировании информации на уровне файлов. Основной плюс данной технологии заключается в возможности гибкого отбора сохраняемых файлов. Например, только один каталог, файлы по шаблону или изменившиеся за определенный период времени. Минусом технологии является довольной долгий процесс копирования. Это связано с необходимостью каждый раз получать доступ к объекту на уровне файловой системы. Также замедление работы может быть связано длительной процедурой поиска и отбора файлов по признакам, указанным в задании резервного копирования. Еще одна неприятная особенность данной технологии – необходимость бороться с блокировкой открытых для записи файлов. Обычно, когда файл открыт для записи, операционная система не дает получить доступ к его содержимому другой программе. В результате, если процесс резервного копирования «натыкается» на такой открытый файл, он в зависимости от настроек, либо останавливается, либо пропускает данный файл. Существуют различные методы обхода данной проблемы, например, повторная попытка получить доступ через некоторый временной интервал или использование службы теневого копирования томов VSS в Windows. Но факт остается фактом – необходимо осуществлять дополнительные действия по преодолению трудностей. Технология блочного копирования Значительно отличается от файловой и на первый взгляд не имеет недостатков. В случае с блочным бэкапом доступ к данным осуществляется посредством специального драйвера с прямым доступом к диску в обход файловой системы. Сам блок представляет собой наименьший адресуемый элемент диска. Такие вот «кирпичики», из которых состоит файловая система. Особенности технологии блочного резервного копирования:
Обычно технологию блочного копирования используют для копирования дисковых разделов целиком, но возможны и исключения. Например, программа Acronis True Image позволяет исключить из процесса резервирования файл подкачки, а также файлы, соответствующие определенному шаблону, например, с разрешением *.bak, *.tmp и т.д. В этом случае система резервного копирования все равно вынуждена обращаться к файловой системе, но не для считывания файлов, а для получения информации о том, какие файлы (а следовательно, блоки, из которых они состоят) следует пропустить. Строго говоря, существует два режима блочного копирования. В одном случае происходит побитовое копирование дискового раздела на другой диск или в файл образа. В этом случае программу абсолютно не интересует ни тип файловой системы, ни занимаемый объем. Естественно, получившийся объем резервной копии будет равен полному объему дискового раздела, включая свободное пространство. При этом процесс протекает довольно медленно. Единственным плюсом в данном случае является возможность копировать любые дисковые разделы с самыми экзотическими файловыми системами, незнакомыми ни для программы резервного копирования, ни для операционной системы, в которой эта программа работает. Также можно сохранять зашифрованные тома (разумеется, без возможности доступа к самим данным). В другом случае программа блочного копирования знает, как обратиться к файловой системе за информацией о свободном (незанятом) пространстве и файлах, подлежащих исключению из конечной копии. В итоге сам процесс проходит значительно быстрее, и конечный объем резервной копии может быть значительно меньше. Но программа должна уметь работать с файловыми системами копируемых разделов. Разумеется, данный метод бесполезен, если раздел зашифрован. Причиной такого ограничения является все то же считывание копируемой информации «в обход» операционной системы, сразу с тома, содержащего необходимые данные. Например, Acronis True Image не может работать с файловой системой при блочном бэкапе разделов, зашифрованных программой Secret Disk. Приходится копировать раздел побитно, один к одному или воспользоваться файловым методом. Технология блочного резервного копирования также позволяет создавать дифференциальные и инкрементные резервные копии, что может значительно сократить объем копий и ускорить процесс резервного копирования. При этом стоит отметить, что на самом деле инкрементные и дифференциальные копии создаются быстрее, так как копируется не каждый измененный файл целиком, а только изменившиеся небольшие блоки (см. рис. 1, 2).
Рисунок 1. Копирование изменений по файловой технологии (измененные файлы копируются целиком)
Рисунок 2. Копирование изменений по блочной технологии (копируются только измененные блоки) Минус у блочного метода в чистом виде только один: недостаточно гибкости при определении объектов резервного копирования. Нельзя указать в задании: «Вот эту директорию мы копируем, а эту нет, а здесь выбираем только несколько файлов». Приходится копировать либо весь раздел целиком (за исключением некоторых файлов), либо воспользоваться услугами «старого доброго» файлового метода. Именно поэтому в последнее время все чаще встречаются программные продукты, сочетающие в себе оба метода. Такая стратегия позволяет использовать плюсы обоих методов. В каких случаях обычно применяют блочное или файловое копирование? Блочный метод хорошо подходит для копирования в целях аварийного восстановления системы, когда необходимо получить полностью работоспособную систему в сжатые сроки. В таких случаях всегда полезно иметь под рукой полный «слепок» файловой системы рабочего сервера, чтобы провести быстрое восстановление. Также данная технология хороша, когда на дисковом томе содержится только информация, подлежащая резервному копированию согласно текущему плану. Таким примером может послужить отдельный раздел файлового сервера, на котором хранятся исключительно рабочие данные пользователей. В этом случае можно сделать имидж всего раздела и быть уверенным, что в него попали все подлежащие копированию файлы. Также блочный бэкап используется при конверсии физических машин в виртуальные. Сначала создается полный образ системы, после чего он разворачивается на базе заранее созданной виртуальной машины. Плюсом данного метода в отличие от стандартных утилит конверсии является независимость от гипервизора. Созданный имидж системы можно развернуть одинаково хорошо в виртуальной среде WMvare ESX/ESXi, Citrix XenServer и т.д. Есть еще одна сфера применения блочного бэкапа: расследование инцидентов, в том числе инициированных службой безопасности. В этом случае очень удобно иметь под рукой образ системы за определенную дату, чтобы была возможность посмотреть, что же на самом деле хранилось на исследуемом томе. В свою очередь, файловое копирование подходит для случаев, когда нужно провести сложный селективный отбор копируемых или невозможна работа специальных драйверов, работающих в обход файловой системы (например, конфликт с другим программным обеспечением). В случае когда необходимо обеспечить быстрое аварийное восстановление, иногда поступают следующим образом: загрузившись с другого носителя, например с CD-диска, однократно создается образ системной партиции и других дисковых разделов, подлежащих быстрому восстановлению в режиме «один к одному», после чего сервер снова возвращается в нормально работающий режим, а файловое резервное копирование используется для сохранения изменений. Конечно, существует очень большая вероятность, что подобную операцию придется повторять, чтобы избежать серьезных расхождений, особенно если система претерпевала изменения. Но в любом случае лучше запланированная остановка на время выполнения резервной копии, нежели не определенный по времени простой по причине серьезного сбоя. Особенно часто такой комбинированный метод используется на период внедрения и апробирования продуктов, технологий других нововведений, когда может потребоваться быстро вернуть систему к первоначальному состоянию. Таким образом при серьезном сбое сначала производится восстановление из раннего образа, а после «накатываются» изменения из файлового бэкапа. Внимание: в случае когда резервному копированию подлежит работающая база данных в режиме «чтение-запись», не подходит ни файловый, ни блочный метод резервного копирования. Это связано с тем, что часть измененных данных, подлежащих записи на диск, может находиться во временной памяти, например, в ОЗУ или файле подкачки. Поэтому необходимо либо использовать встроенные средства данной СУБД для организации безопасной выгрузки данных, например, в отдельный файл, либо специальные программы-агенты, которые умеют работать с базой данных. Такой метод позволяет получить данные напрямую и передать их системе для дальнейшего копирования. Примеры программ, реализующих ту или иную технологию резервного копирования
Continuous backup или резервное копирование без остановки Также носит название «Continuous data protection (CDP)», «real-time backup» и т. д. [5]. Существует не очень точное русское название «Точки мгновенного восстановления». Неточное потому, что вызывает определенную ассоциацию с системой полного восстановления при сбоях, хотя данная технология может применяться и при ведении архива данных, истории изменений и для других задач. Довольно интересная технология, когда резервные копии создаются не по определенному расписанию, а непрерывно, по мере модификации данных в файлах. Когда данные записываются на диск, допустим, при закрытии файла, они одновременно сохраняются на устройстве резервного копирования. Примером такой технологии для среды Windows может служить программа NTI Shadow for ReadyNAS [6], поставляемая бесплатно с устройствами NETGEAR ReadyNAS Pro. Для UNIX-систем хорошую службу может сослужить Box Backup [7]. Различные программы для сontinuous backup могут использовать файловый или блочный метод резервного копирования. В случае применения последнего возможна хорошая экономия дискового пространства на устройстве хранения копий благодаря преимуществам блочного бэкапа, описанным в предыдущем разделе. Очень часто системные администраторы сталкиваются с проблемой, когда нужно восстановить данные пользователя на момент сбоя, приведшего к их потере. Такая «роскошь» кажется недопустимой в случае, когда используются обычные системы резервного копирования, и копия создается, к примеру, раз в день. Но в случае сontinuous backup подобный запрос может быть выполнен, при условии, что до сбоя сохранение изменившихся данных было произведено корректно. Зачем все это нужно, если есть Shadow Copy? В некоторых системах существуют попытки создать некие заменители сontinuous backup, и Shadow Copy в системах Windows тому подтверждение. Но отличие «непрерывного бэкапа» от «теневого копирования» заключается в том, что Shadow Copy создает скрытые резервные экземпляры файлов на том же дисковом томе и по расписанию. Сразу обнаруживается два недостатка: резервная копия хранится на том же массиве, что само по себе весьма опасно и копии создаются не непрерывно, а по расписанию, что не позволяет восстанавливать данные на момент сбоя или на другой произвольный момент времени. Зачем все это нужно, если есть возможность провести репликацию данных на другой сервер? В случае репликации, например, посредством механизма DFS в системах 200x, файлы синхронизируются на определенный момент времени. Это значит, что нельзя восстановить данные в произвольный момент времени, например, несколько дней назад. Нет истории версий. А технология сontinuous backup может решить подобную задачу. С помощью репликации или даже введением в строй зеркального сервера можно решить проблему восстановления после сбоев в ограниченном ряде случаев (см. часть 1 этой статьи [7]). И в этот перечень не входят заражение системы вирусом и человеческий фактор. Последний вопрос, который иногда возникает: «Но VSS и DFS бесплатны, так как входят в поставку Windows Server. Связка VSS плюс DFS тоже работает, зачем тогда «огород городить» с Continuous data protection?» Ну, во-первых, резервные копии данных продуктов создаются по определенному расписанию, что не позволяет восстанавливать данные на момент сбоя при условии (если только запланированное задание не завершилось успешно непосредственно перед позникновением неполадки). Во-вторых, вышеописанная «связка» VSS+DFS работает только в среде MS Windows. При наличии гетерогенных решений для остальных платформ придется внедрять другие методы. При этом все равно придется выделять отдельный сервер (или группу серверов) для зеркалирования... Не проще ли сразу воспользоваться бесплатным Box Backup? Схемы ротации носителей Рассмотрим какие бывают схемы ротации носителей. Разовое копирование Самый простой способ. Решили, что сегодня нужно сделать бэкап – просто берем и делаем. До сих пор по такому графику работает резервное копирование во многих российских компаниях. При данной схеме почти всегда используется полное копирование. Плюсами являются простота реализации и небольшая экономия на носителях. Серьезным минусом является возможная потеря регулярности пополнения архива и актуальности данных. Схема «Отец-сын» Данная схема очень проста. Раз в неделю (декаду или за другой период) выполняется полный бэкап, после чего регулярно (допустим, раз в день) выполняется инкрементный или дифференцированный бэкап. В случае с еженедельным полным бэкапом и инкрементным бэкапом по будням требуется всего 10 носителей (пять еженедельных полных и пять промежуточных) при условии, что на один носитель записывается либо полная, либо промежуточная копия, носители не поступают в архив, а данные сохраняются в течение месяца. Нетрудно догадаться, что под понятием «отец» подразумевается full backup, а «сыном», точнее «сыновьями», являются промежуточные копии (см. рис. 3).
Рисунок 3. Схема «Отец-сын» Схема «Дед, отец, сын» Это несколько более усложненный вариант ранее рассмотренной схемы «Отец-сын». Вводится дополнительный ежемесячный full backup («дед»), который, собственно, и идет в архив. В наиболее распространенной ситуации создаются:
Рисунок 4. Схема «Дед-отец-сын» Для этой схемы ротации при расчете на год понадобится 21 носитель: пять промежуточных по будням, четыре еженедельных (по числу полных недель в месяце) и двенадцать ежемесячных. Соответственно производится маркировка носителей для использования в будние дни, раз в неделю и раз в год в определенный месяц (они, как правило, не перезаписываются и поступают в архив). Другие схемы ротации Существует довольно большое число различных вариантов схем ротации носителей, например, «Ханойская башня», «10 наборов» и т. д. Я не вижу смысла их описывать в рамках данной статьи из-за довольно редких случаев использования, а также отсутствия поддержки этих схем в популярных системах резервного копирования. Но важно понимать, что ни одно «классическое» решение не будет идеально подходить под нужды конкретной IT-структуры. Иногда требуется всего лишь небольшая адаптация, а порой и вовсе приходится создавать собственную схему ротации с нуля, опираясь исключительно на требования бизнеса. Но в любом случае главное – при проведении мероприятий резервного копирования четко следовать выбранной схеме. Это позволит не только сохранить данные для последующего восстановления после сбоя, но и вести регулярную историю версий, своего рода архив жизни компании. *** Мы рассмотрели теоретические и технические аспекты организации резервного копирования. Теперь, будучи во всеоружии, можно приступать к созданию системы резервного копирования. В третьей части будут рассмотрены практические аспекты и наиболее часто встречающиеся ошибки при проектировании и эксплуатации подобных систем.
|
АЛЕКСЕЙ БЕРЕЖНОЙ, системный администратор. Главные направления деятельности: виртуализация и гетерогенные сети. Еще одно увлечение помимо написания статей – популяризация бесплатного ПО
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
