В этой статье мы постараемся кратко рассказать об опыте внедрения системы резервного копирования Symantec NetBackup.
Для повышения защищенности внутрикорпоративных систем от потери информации и уменьшения производственных затрат на восстановление в случае сбоев заказчик принял решение о внедрении системы резервного копирования на базе NetBackup 7.6. Описание процесса выбора заказчиком конкретного решения мы оставляем за рамками данной статьи.
В итоге были определены основные параметры решения:
а также сформулированы цели проекта, достижение которых считалось необходимым.
В ходе подготовки к проекту было проведено обследование существующей инфраструктуры, что позволило составить представление о всех системах, подлежащих резервному копированию, определить требования к объемам хранилищ резервных копий и пропускной способности сетей передачи данных, а также создать необходимые схемы.
Так как внедрение системы проводилось преимущественно в удаленном режиме, наличие схем и описаний, составленных на этапе обследования, упростило решение большого числа вопросов, возникавших в ходе работ.
Инфраструктура заказчика, с одной стороны, относительно проста, так как в ней существует четкое разделение функций между серверами, а, с другой стороны, ее гетерогенность и насыщенность разнообразными системами потребовали разработки большого количества разнообразных политик резервного копирования. При этом была поставлена задача выполнять резервное копирование всех систем, используя только один мастер-сервер и один медиа-сервер.
В перечень подлежащих резервному копированию систем входит около 40 серверов (как физических, так и виртуальных) с суммарным объемом хранимых данных порядка 60 ТБ.
Большая часть серверов, виртуализация, дисковые системы и ленточные библиотеки расположены на первой площадке заказчика. Отдельные аппаратные серверы – на второй (в пределах одного города). Площадки соединены между собой сетью GbE. Внутри первой площадки существуют две фабрики сети хранения данных, к которым подключены ресурсы хранения и различные серверы.
Конечно, в целях обеспечения сохранности данных при различных серьезных происшествиях (пожарах, затоплениях и т.п.), рабочие данные и резервные копии лучше размещать на разных площадках, но в данном случае имеющиеся ресурсы заказчика не позволяли реализовать такую схему, и эта задача не ставилась в рамках проекта.
В состав решения входят:
Обе ленточные библиотеки, дисковые массивы и медиа-сервер имеют подключение к двум изолированным фабрикам SAN, построенным на коммутаторах Brocade, с пропускной способностью до 8 Гбит/с. Также к SAN подключены хосты виртуализации с гипервизорами VMware ESXi. Это позволило в дальнейшем использовать режим резервного копирования виртуальных машин по SAN и существенно разгрузить сеть GbE.
Корректная настройка SAN является одним из ключевых факторов, влияющих на стабильность работы решения в целом. Ошибки в зоновой конфигурации SAN или в физическом транспорте сети (на портах, линках к серверам и хранилищам, в межкоммутаторных связях и т.п.), перегрузки при пиковом трафике, нехватка кредитов приема-передачи и другие не всегда явные проблемы могут приводить, на первый взгляд, к непонятной или беспричинной недоступности ресурсов, внезапному их пропаданию при малейших изменениях и т.п. Кроме конфигурирования самой сети хранения данных на этом этапе проводится настройка публикации ресурсов на системах хранения: как на дисковых массивах, так и на библиотеках.
Иногда бывает так, что специалисты заказчика не особо следят за работой SAN, так как для них эта часть работы не является повседневной. Как говорится, один раз настроили и забыли, пока работает – не трогаем. А при подготовке сети к запуску системы резервного копирования изменений в ее конфигурации и настройках систем хранения производится много. Поэтому детальное изучение конфигурации SAN до начала изменений в сети является очень важным этапом.
На дисковых массивах были выделены LUN’ы для хранения резервных копий: LUN размером 6 ТБ для дедуплицированных данных и LUN размером чуть менее 2 ТБ для хранения данных, которые проще сжимать, чем дедуплицировать, например, к таким видам данных относятся логи транзакций БД. Оба дисковых тома подключены к медиа-серверу, на котором средствами ОС Windows Server они были размечены как базовые тома GPT.
Для целей резервного копирования сразу имеет смысл размечать дисковые ресурсы в GPT, так как предел MBR в 2 ТБ достаточно легко достигается в ходе эксплуатации и появляется необходимость увеличивать объем хранилища выше этой величины. При этом компонент PDDO в NetBackup, о котором будет рассказано далее, имеет ограничение: на медиа-сервере с его помощью можно использовать только один логический диск для хранения дедуплицированных данных. Поэтому, чтобы в будущем не создавать множество LUN’ов по 2 ТБ и не объединять их в Spanned Volume средствами управления динамическими томами, гораздо проще сразу разметить нужный LUN в GPT.
Здесь, конечно, нужно учитывать, будет ли доступен необходимый для резервного копирования объем в пределах одного LUN’а с одного массива. Если дисковое пространство будет «нарезано» различными кусками с нескольких массивов, то управление дисковым пространством на медиа-сервере может усложниться. Особенно, учитывая, что при использовании резервного копирования виртуальных машин по SAN медиа-сервер должен иметь доступ еще и ко всем томам VMFS.
В связи с ограниченной пропускной способностью сетевых интерфейсов медиа-сервера и высокой плотностью задач резервного копирования, выполняемых в ночное время, система изначально рассчитана на использование следующих методик, значительно ускоряющих процесс создания резервных копий:
Резервное копирование по SAN применяется в рамках решения для создания копий виртуальных машин, размещенных на платформе VMware vSphere. Если кратко, смысл этой методики заключается в том, что при создании резервной копии данные с хоста виртуализации передаются на медиа-сервер не по сети Ethernet, а по SAN, что в случае применения сети GbE очень сильно ее разгружает (для сетей 10GbE это, очевидно, уже не так актуально). При этом медиа-сервер напрямую по протоколу SCSI (завернутому в трафик FC) взаимодействует с дисковым хранилищем, на котором размещены LUN’ы с виртуальными машинами. В этом случае должны быть созданы соответствующие зоны в SAN от медиа-сервера до дисковых массивов, содержащих LUN’ы с виртуальными машинами, а также эти LUN’ы должны быть презентованы медиа-серверу средствами дисковых массивов.
Дедупликация в NetBackup реализована средствами либо Media Server Deduplication Pool (MSDP), либо PureDisk Deduplication Option (PDDO), либо Open Storage Technology (OST). Все три варианта требуют особого лицензирования и не входят в базовую поставку NetBackup. Первые две опции позволяют создавать специальные типы хранилищ на медиа-сервере (Media Server Deduplication Pool и PureDisk Deduplication Pool, соответственно). Третья опция позволяет подключать внешние OST-совместимые дисковые хранилища сторонних производителей.
Дедупликация в NetBackup может производиться как на медиа-сервере, так и на клиенте. По очевидным причинам сетевой трафик будет значительно снижен, в случае если используется дедупликация на клиенте. Обратной стороной медали здесь является рост нагрузки на ЦП клиента, что может быть неприемлемо для высоконагруженных систем. Теоретически, эффективность дедупликации может достигать 100% (в случае, если данные вообще не изменялись в промежутке между отдельными задачами резервного копирования). В реальности эффективность дедупликации изменяется во всем диапазоне значений от 0 до 100% и зависит от количества произведенных изменений в данных. На иллюстрации ниже в колонке Deduplication Rate видна высокая эффективность дедупликации БД SAP при выполнении резервного копирования на пул PDDO.
При использовании дедупликации на клиенте наблюдается закономерное уменьшение времени, необходимого на резервное копирование данных (если ЦП клиента нормально справляется с этой задачей). Например, первое полное резервное копирование в объеме 1 ТБ может занять условно 5 часов, а второе при том же объеме данных, может выполниться и за 1 час и меньше, если изменения в копируемых файлах были невелики. Это нужно учитывать при планировании окон резервного копирования.
Сжатие на клиенте также снижает сетевой трафик и нагружает ЦП клиента. При этом сжатие (как и шифрование) сильно изменяет содержимое передаваемых на медиа-сервер файлов, что приводит к резкому падению эффективности дедупликации. Поэтому при использовании дедупликации опции сжатия и шифрования в политике резервного копирования должны быть отключены.
Для сохранения эффективности дедупликации и сжатия NetBackup по умолчанию самостоятельно на медиа-сервере сжимает (но не шифрует) дедуплицированные данные, т.е., сначала данные дедуплицируются, а только затем сжимаются. Это регулируется через конфигурационный файл pd.conf, параметры которого подробно расписаны в руководстве «Symantec NetBackup Deduplication Guide» в разделе «MSDP pd.conf file parameters».
В случае, если данные часто и сильно меняются (например, журналы логов транзакций БД), их сжатие может оказаться более эффективным, чем дедупликация. В таком случае сжатые данные нужно записывать на хранилища типов BasicDisk или AdvancedDisk, не поддерживающие дедупликацию.
NetBackup Accelerator – это технология, позволяющая, как следует из названия, ускорить создание резервных копий. Выполняется это за счет обнаружения на клиенте блоков данных, резервные копии которых уже были созданы ранее, причем данные не менялись с момента создания предыдущей резервной копии, и она еще доступна в хранилищах NetBackup.
В отличие от известного файлового атрибута «Архивный» в Windows (или резервного копирования с учетом даты изменения файла) этот метод позволяет передавать не измененные файлы целиком, а только измененные блоки в этих файлах, что максимально экономит полосу пропускания между клиентом и медиа-сервером и существенно сокращает время на создание резервной копии. При этом на лету выполняется синтез новой резервной копии из старых (не изменившихся) и новых (изменившихся) блоков данных.
NetBackup Accelerator совместим только со следующими видами политик резервного копирования:
Применение Accelerator возможно только с дисковыми хранилищами MSDP, PureDisk и OST. Работа с BasicDisk и AdvancedDisk не поддерживается. Для работы Accelerator’a необходима лицензия Data Protection Optimization Option для NetBackup.
В случае политики Standard работа Accelerator’a не зависит от ОС, он на стороне клиента ведет свой журнал изменений в файлах. При использовании политики MS-Windows необходимо использовать журнал файловой системы NTFS или ReFS, что включается опцией Use Change Journal. Для этих двух политик логика работы Accelerator’a такова:
Работа Accelerator’a в рамках политики VMware в целом такая же, но для ведения журнала используется опция VMware Changed Block Tracking (CBT), которая может требовать отдельной настройки на системе виртуализации. Кроме того, при отдельных событиях (холодный рестарт виртуальной машины, сбой питания хоста и т.п.) журнал изменений в VMware может сбрасываться, что при следующем бэкапе приведет к созданию полной резервной копии без учета изменений в файлах и закономерно скажется на времени создания бэкапа. Кроме того, при создании полной резервной копии виртуальной машины и включенном Accelerator’e поддерживается гранулярное восстановление данных MS Exchange, MS SQL и MS Sharepoint из VMDK-файла ВМ.
Кроме Accelerator’a в NetBackup имеется еще одна опция, позволяющая выполнять резервное копирование только измененных блоков данных. Она называется «Блочное инкрементальное резервное копирование» (Block-level Incremental Backup, BLIB) и предназначена для работы с БД Oracle. BLIB – это технология, позволяющая передавать с клиента на медиа-сервер только те блоки файлов БД Oracle, которые помечены как измененные. В NetBackup применение ее возможно только при размещении БД на томах с файловой системой VxFS, созданных с помощью Symantec Storage Foundation.
В данном проекте, несмотря на наличие БД Oracle в составе решений SAP, метод BLIB не применялся в силу отсутствия у заказчика продукта Storage Foundation. Все остальные методы ускорения создания резервных копий были успешно применены и позволили уложиться в весьма небольшие окна резервного копирования, заданные заказчиком.
Перечень классов ресурсов, подлежащих регулярному резервному копированию включал следующее:
Для каждого класса ресурса создается одна или несколько политик резервного копирования, на основе которых NetBackup формирует задачи резервного копирования и расписание их запуска.
Задачи резервного копирования в NetBackup представляют собой пересечение четырех типов параметров, которые можно описать следующими словами:
Параметры, определяющие место назначения резервной копии (хранилище, группа томов), могут определяться в атрибутах политики, но на практике этот метод используется редко, так как место назначения резервной копии зависит от расписания.
При этом, если атрибуты политики задаются единым набором на одну политику, то перечни расписаний, клиентов и ресурсов могут включать в себя множество значений.
В зависимости от класса политики, задаваемой на закладке Attributes, другие параметры могут менять свой смысл.
Например, если для политики Standard на закладке Selections перечисляется список резервируемых ресурсов по абсолютным путям в файловой системе клиента, то для задач резервного копирования SAP или Oracle этот список содержит перечень скриптов, которые запускаются клиентом NetBackup, и из них уже ведется управление процессом резервного копирования. Такой подход позволяет достичь максимальной гибкости в организации процесса резервного копирования, что особенно важно для работы с большими БД.
В зависимости от типа политики резервного копирования также выбираются различные дополнительные опции, которые как оптимизируют процесс бэкапа (как Accelerator), так и могут обеспечивать особые возможности в процессе восстановления данных из резервной копии. Например, гранулярное восстановление (Granular Recovery) позволяет восстановить отдельные письма из бэкапа MS Exchange или отдельные файлы из БД Share Point.
На закладке Attributes также можно указать место для хранения резервных копий (Policy Storage), хотя практика работы показывает, что задавать место хранения на уровне всей политики удобно далеко не всегда. Больше возможностей предоставляет определение мест хранения на уровне политик жизненного цикла хранения (Storage Lifecycle Policy, SLP). Это специальные объекты, объединяющие в себе информацию о месте хранения, сроке хранения, порядке дублирования бэкапов, а также о распределении носителей (файлов на диске или лент) по пулам.
Использование SLP позволяет гибко задавать правила хранения бэкапов в пределах одной политики NetBackup, так как SLP можно указывать для каждого расписания задач в отдельности.
Расписания выполнения задач указываются на отдельной вкладке Schedules и позволяют определить в пределах одной политики порядок запуска задач с учетом общей политики резервного копирования организации. Обычно, отдельные расписания задаются для ежегодных, ежемесячных, еженедельных, ежедневных задач, а также для задач, выполняемых множество раз в течение одних суток (например, задачи резервного копирования логов транзакций БД).
Особенностью резервного копирования задач БД является то, что для каждого вида бэкапа необходимо создавать пару задач:
На закладке Clients перечисляется список клиентов, резервное копирование данных с которых производится в рамках данной политики. Клиентов может быть достаточно много, но ко всем им будут применяться одни и те же правила.
То же относится и к перечню копируемых ресурсов. Net Backup на каждом из перечисленных клиентов будет пытаться найти все ресурсы, перечисленные на закладке Backup Selections, и если какой-то отдельный ресурс из списка будет найден, то Net Backup произведет его резервное копирование в соответствии с политикой.
В большинстве случаев для восстановления данных необходимо воспользоваться программой «Backup, Archive and Restore», входящей в инсталляцию NetBackup. Она позволяет задать перечень ресурсов, подлежащих восстановлению с учетом требуемой даты, список ресурсов, место назначения (тут можно переопределить место назначения данных, указав другой путь или другой сервер), а также правила восстановления в исключительных ситуациях (например, указать, перезаписывать ли файлы, если они уже есть в точке восстановления).
Для Windows можно указать в дереве восстановления файлы, каталоги, состояние системы в целом, ключи реестра и т.п.
Комбинаций вариантов по восстановлению данных из резервных копий в NetBackup очень много, больше, чем способов резервного копирования. Рамки данной статьи не позволяют детально их раскрыть. Все они максимально подробно документированы в официальных инструкциях Symantec и обращение к этим инструкциям в процессе работы с Net Backup всегда является полезным, так как охватить одному человеку все возможности этого продукта достаточно тяжело. Но можно уверенно сказать, что если проектирование и настройка системы резервного копирования были выполнены грамотно, то восстановление данных в случае реальных проблем, связанных с их повреждением или потерей – это дело техники.
Автор: Андрей Хлебников, Softline
Для повышения защищенности внутрикорпоративных систем от потери информации и уменьшения производственных затрат на восстановление в случае сбоев заказчик принял решение о внедрении системы резервного копирования на базе NetBackup 7.6. Описание процесса выбора заказчиком конкретного решения мы оставляем за рамками данной статьи.
В итоге были определены основные параметры решения:
- перечень информационных систем, подлежащих резервному копированию;
- окна резервного копирования;
- доступные серверные ресурсы;
- ресурсы систем хранения и сетей передачи данных,
а также сформулированы цели проекта, достижение которых считалось необходимым.
В ходе подготовки к проекту было проведено обследование существующей инфраструктуры, что позволило составить представление о всех системах, подлежащих резервному копированию, определить требования к объемам хранилищ резервных копий и пропускной способности сетей передачи данных, а также создать необходимые схемы.
Так как внедрение системы проводилось преимущественно в удаленном режиме, наличие схем и описаний, составленных на этапе обследования, упростило решение большого числа вопросов, возникавших в ходе работ.
Описание инфраструктуры заказчика
Инфраструктура заказчика, с одной стороны, относительно проста, так как в ней существует четкое разделение функций между серверами, а, с другой стороны, ее гетерогенность и насыщенность разнообразными системами потребовали разработки большого количества разнообразных политик резервного копирования. При этом была поставлена задача выполнять резервное копирование всех систем, используя только один мастер-сервер и один медиа-сервер.
В перечень подлежащих резервному копированию систем входит около 40 серверов (как физических, так и виртуальных) с суммарным объемом хранимых данных порядка 60 ТБ.
Большая часть серверов, виртуализация, дисковые системы и ленточные библиотеки расположены на первой площадке заказчика. Отдельные аппаратные серверы – на второй (в пределах одного города). Площадки соединены между собой сетью GbE. Внутри первой площадки существуют две фабрики сети хранения данных, к которым подключены ресурсы хранения и различные серверы.
Конечно, в целях обеспечения сохранности данных при различных серьезных происшествиях (пожарах, затоплениях и т.п.), рабочие данные и резервные копии лучше размещать на разных площадках, но в данном случае имеющиеся ресурсы заказчика не позволяли реализовать такую схему, и эта задача не ставилась в рамках проекта.
Описание архитектуры решения
В состав решения входят:
- 1 мастер-сервер NetBackup (на нем же установлены модуль контроля доступа NBAC и средство мониторинга OpsCenter);
- 1 медиа-сервер NetBackup;
- Несколько LUN’ов с дисковых массивов, предназначенных для хранения резервных копий;
- 2 ленточные библиотеки (3 ленточных привода в сумме).
Обе ленточные библиотеки, дисковые массивы и медиа-сервер имеют подключение к двум изолированным фабрикам SAN, построенным на коммутаторах Brocade, с пропускной способностью до 8 Гбит/с. Также к SAN подключены хосты виртуализации с гипервизорами VMware ESXi. Это позволило в дальнейшем использовать режим резервного копирования виртуальных машин по SAN и существенно разгрузить сеть GbE.
Корректная настройка SAN является одним из ключевых факторов, влияющих на стабильность работы решения в целом. Ошибки в зоновой конфигурации SAN или в физическом транспорте сети (на портах, линках к серверам и хранилищам, в межкоммутаторных связях и т.п.), перегрузки при пиковом трафике, нехватка кредитов приема-передачи и другие не всегда явные проблемы могут приводить, на первый взгляд, к непонятной или беспричинной недоступности ресурсов, внезапному их пропаданию при малейших изменениях и т.п. Кроме конфигурирования самой сети хранения данных на этом этапе проводится настройка публикации ресурсов на системах хранения: как на дисковых массивах, так и на библиотеках.
Иногда бывает так, что специалисты заказчика не особо следят за работой SAN, так как для них эта часть работы не является повседневной. Как говорится, один раз настроили и забыли, пока работает – не трогаем. А при подготовке сети к запуску системы резервного копирования изменений в ее конфигурации и настройках систем хранения производится много. Поэтому детальное изучение конфигурации SAN до начала изменений в сети является очень важным этапом.
На дисковых массивах были выделены LUN’ы для хранения резервных копий: LUN размером 6 ТБ для дедуплицированных данных и LUN размером чуть менее 2 ТБ для хранения данных, которые проще сжимать, чем дедуплицировать, например, к таким видам данных относятся логи транзакций БД. Оба дисковых тома подключены к медиа-серверу, на котором средствами ОС Windows Server они были размечены как базовые тома GPT.
Для целей резервного копирования сразу имеет смысл размечать дисковые ресурсы в GPT, так как предел MBR в 2 ТБ достаточно легко достигается в ходе эксплуатации и появляется необходимость увеличивать объем хранилища выше этой величины. При этом компонент PDDO в NetBackup, о котором будет рассказано далее, имеет ограничение: на медиа-сервере с его помощью можно использовать только один логический диск для хранения дедуплицированных данных. Поэтому, чтобы в будущем не создавать множество LUN’ов по 2 ТБ и не объединять их в Spanned Volume средствами управления динамическими томами, гораздо проще сразу разметить нужный LUN в GPT.
Здесь, конечно, нужно учитывать, будет ли доступен необходимый для резервного копирования объем в пределах одного LUN’а с одного массива. Если дисковое пространство будет «нарезано» различными кусками с нескольких массивов, то управление дисковым пространством на медиа-сервере может усложниться. Особенно, учитывая, что при использовании резервного копирования виртуальных машин по SAN медиа-сервер должен иметь доступ еще и ко всем томам VMFS.
Особенности реализации решения
В связи с ограниченной пропускной способностью сетевых интерфейсов медиа-сервера и высокой плотностью задач резервного копирования, выполняемых в ночное время, система изначально рассчитана на использование следующих методик, значительно ускоряющих процесс создания резервных копий:
- резервное копирование по SAN;
- дедупликация на клиенте;
- сжатие на клиенте;
- ускорение создания резервных копий (Accelerator).
Резервное копирование по SAN применяется в рамках решения для создания копий виртуальных машин, размещенных на платформе VMware vSphere. Если кратко, смысл этой методики заключается в том, что при создании резервной копии данные с хоста виртуализации передаются на медиа-сервер не по сети Ethernet, а по SAN, что в случае применения сети GbE очень сильно ее разгружает (для сетей 10GbE это, очевидно, уже не так актуально). При этом медиа-сервер напрямую по протоколу SCSI (завернутому в трафик FC) взаимодействует с дисковым хранилищем, на котором размещены LUN’ы с виртуальными машинами. В этом случае должны быть созданы соответствующие зоны в SAN от медиа-сервера до дисковых массивов, содержащих LUN’ы с виртуальными машинами, а также эти LUN’ы должны быть презентованы медиа-серверу средствами дисковых массивов.
Дедупликация в NetBackup реализована средствами либо Media Server Deduplication Pool (MSDP), либо PureDisk Deduplication Option (PDDO), либо Open Storage Technology (OST). Все три варианта требуют особого лицензирования и не входят в базовую поставку NetBackup. Первые две опции позволяют создавать специальные типы хранилищ на медиа-сервере (Media Server Deduplication Pool и PureDisk Deduplication Pool, соответственно). Третья опция позволяет подключать внешние OST-совместимые дисковые хранилища сторонних производителей.
Дедупликация в NetBackup может производиться как на медиа-сервере, так и на клиенте. По очевидным причинам сетевой трафик будет значительно снижен, в случае если используется дедупликация на клиенте. Обратной стороной медали здесь является рост нагрузки на ЦП клиента, что может быть неприемлемо для высоконагруженных систем. Теоретически, эффективность дедупликации может достигать 100% (в случае, если данные вообще не изменялись в промежутке между отдельными задачами резервного копирования). В реальности эффективность дедупликации изменяется во всем диапазоне значений от 0 до 100% и зависит от количества произведенных изменений в данных. На иллюстрации ниже в колонке Deduplication Rate видна высокая эффективность дедупликации БД SAP при выполнении резервного копирования на пул PDDO.
При использовании дедупликации на клиенте наблюдается закономерное уменьшение времени, необходимого на резервное копирование данных (если ЦП клиента нормально справляется с этой задачей). Например, первое полное резервное копирование в объеме 1 ТБ может занять условно 5 часов, а второе при том же объеме данных, может выполниться и за 1 час и меньше, если изменения в копируемых файлах были невелики. Это нужно учитывать при планировании окон резервного копирования.
Сжатие на клиенте также снижает сетевой трафик и нагружает ЦП клиента. При этом сжатие (как и шифрование) сильно изменяет содержимое передаваемых на медиа-сервер файлов, что приводит к резкому падению эффективности дедупликации. Поэтому при использовании дедупликации опции сжатия и шифрования в политике резервного копирования должны быть отключены.
Для сохранения эффективности дедупликации и сжатия NetBackup по умолчанию самостоятельно на медиа-сервере сжимает (но не шифрует) дедуплицированные данные, т.е., сначала данные дедуплицируются, а только затем сжимаются. Это регулируется через конфигурационный файл pd.conf, параметры которого подробно расписаны в руководстве «Symantec NetBackup Deduplication Guide» в разделе «MSDP pd.conf file parameters».
В случае, если данные часто и сильно меняются (например, журналы логов транзакций БД), их сжатие может оказаться более эффективным, чем дедупликация. В таком случае сжатые данные нужно записывать на хранилища типов BasicDisk или AdvancedDisk, не поддерживающие дедупликацию.
NetBackup Accelerator – это технология, позволяющая, как следует из названия, ускорить создание резервных копий. Выполняется это за счет обнаружения на клиенте блоков данных, резервные копии которых уже были созданы ранее, причем данные не менялись с момента создания предыдущей резервной копии, и она еще доступна в хранилищах NetBackup.
В отличие от известного файлового атрибута «Архивный» в Windows (или резервного копирования с учетом даты изменения файла) этот метод позволяет передавать не измененные файлы целиком, а только измененные блоки в этих файлах, что максимально экономит полосу пропускания между клиентом и медиа-сервером и существенно сокращает время на создание резервной копии. При этом на лету выполняется синтез новой резервной копии из старых (не изменившихся) и новых (изменившихся) блоков данных.
NetBackup Accelerator совместим только со следующими видами политик резервного копирования:
- Standard (файловые ресурсы на любых серверах);
- MS-Windows (те же файловые ресурсы на системах MS Windows);
- VMware (виртуальные машины VMware).
Применение Accelerator возможно только с дисковыми хранилищами MSDP, PureDisk и OST. Работа с BasicDisk и AdvancedDisk не поддерживается. Для работы Accelerator’a необходима лицензия Data Protection Optimization Option для NetBackup.
В случае политики Standard работа Accelerator’a не зависит от ОС, он на стороне клиента ведет свой журнал изменений в файлах. При использовании политики MS-Windows необходимо использовать журнал файловой системы NTFS или ReFS, что включается опцией Use Change Journal. Для этих двух политик логика работы Accelerator’a такова:
- если резервное копирование ресурсов с данного клиента еще не выполнялось, то NetBackup делает обычную полную копию и создает журнал изменений;
- при следующем бэкапе NetBackup определяет, какие блоки в файлах изменились, и отправляет на медиа-сервер поток данных, содержащий измененные блоки и ссылки на неизменные блоки из предыдущего бэкапа;
- медиа-сервер реконструирует полный бэкап на основе полученной информации от клиента.
Работа Accelerator’a в рамках политики VMware в целом такая же, но для ведения журнала используется опция VMware Changed Block Tracking (CBT), которая может требовать отдельной настройки на системе виртуализации. Кроме того, при отдельных событиях (холодный рестарт виртуальной машины, сбой питания хоста и т.п.) журнал изменений в VMware может сбрасываться, что при следующем бэкапе приведет к созданию полной резервной копии без учета изменений в файлах и закономерно скажется на времени создания бэкапа. Кроме того, при создании полной резервной копии виртуальной машины и включенном Accelerator’e поддерживается гранулярное восстановление данных MS Exchange, MS SQL и MS Sharepoint из VMDK-файла ВМ.
Кроме Accelerator’a в NetBackup имеется еще одна опция, позволяющая выполнять резервное копирование только измененных блоков данных. Она называется «Блочное инкрементальное резервное копирование» (Block-level Incremental Backup, BLIB) и предназначена для работы с БД Oracle. BLIB – это технология, позволяющая передавать с клиента на медиа-сервер только те блоки файлов БД Oracle, которые помечены как измененные. В NetBackup применение ее возможно только при размещении БД на томах с файловой системой VxFS, созданных с помощью Symantec Storage Foundation.
В данном проекте, несмотря на наличие БД Oracle в составе решений SAP, метод BLIB не применялся в силу отсутствия у заказчика продукта Storage Foundation. Все остальные методы ускорения создания резервных копий были успешно применены и позволили уложиться в весьма небольшие окна резервного копирования, заданные заказчиком.
Методики резервного копирования
Перечень классов ресурсов, подлежащих регулярному резервному копированию включал следующее:
- файловые ресурсы на серверах Windows и Linux;
- службы каталогов Actve Directory;
- виртуальные машины VMware;
- физические машины;
- базы данных SAP/Oracle;
- базы данных MS SQL;
- портал SharePoint.
Для каждого класса ресурса создается одна или несколько политик резервного копирования, на основе которых NetBackup формирует задачи резервного копирования и расписание их запуска.
Задачи резервного копирования в NetBackup представляют собой пересечение четырех типов параметров, которые можно описать следующими словами:
- как копировать (атрибуты политики, Attributes);
- когда копировать (расписания задач, Schedules);
- откуда копировать (клиенты резервного копирования, Clients);
- что копировать (перечень копируемых ресурсов, Selections).
Параметры, определяющие место назначения резервной копии (хранилище, группа томов), могут определяться в атрибутах политики, но на практике этот метод используется редко, так как место назначения резервной копии зависит от расписания.
При этом, если атрибуты политики задаются единым набором на одну политику, то перечни расписаний, клиентов и ресурсов могут включать в себя множество значений.
В зависимости от класса политики, задаваемой на закладке Attributes, другие параметры могут менять свой смысл.
Например, если для политики Standard на закладке Selections перечисляется список резервируемых ресурсов по абсолютным путям в файловой системе клиента, то для задач резервного копирования SAP или Oracle этот список содержит перечень скриптов, которые запускаются клиентом NetBackup, и из них уже ведется управление процессом резервного копирования. Такой подход позволяет достичь максимальной гибкости в организации процесса резервного копирования, что особенно важно для работы с большими БД.
В зависимости от типа политики резервного копирования также выбираются различные дополнительные опции, которые как оптимизируют процесс бэкапа (как Accelerator), так и могут обеспечивать особые возможности в процессе восстановления данных из резервной копии. Например, гранулярное восстановление (Granular Recovery) позволяет восстановить отдельные письма из бэкапа MS Exchange или отдельные файлы из БД Share Point.
На закладке Attributes также можно указать место для хранения резервных копий (Policy Storage), хотя практика работы показывает, что задавать место хранения на уровне всей политики удобно далеко не всегда. Больше возможностей предоставляет определение мест хранения на уровне политик жизненного цикла хранения (Storage Lifecycle Policy, SLP). Это специальные объекты, объединяющие в себе информацию о месте хранения, сроке хранения, порядке дублирования бэкапов, а также о распределении носителей (файлов на диске или лент) по пулам.
Использование SLP позволяет гибко задавать правила хранения бэкапов в пределах одной политики NetBackup, так как SLP можно указывать для каждого расписания задач в отдельности.
Расписания выполнения задач указываются на отдельной вкладке Schedules и позволяют определить в пределах одной политики порядок запуска задач с учетом общей политики резервного копирования организации. Обычно, отдельные расписания задаются для ежегодных, ежемесячных, еженедельных, ежедневных задач, а также для задач, выполняемых множество раз в течение одних суток (например, задачи резервного копирования логов транзакций БД).
Особенностью резервного копирования задач БД является то, что для каждого вида бэкапа необходимо создавать пару задач:
- обычную (Full, Differential и т.п.), которая является, по сути, триггером, инициирующим запуск скрипта резервного копирования;
- задачу бэкапа приложения (Application), выполняющую прием данных от инструментов резервного копирования, расположенных на клиенте, запуск которых был произведен скриптом. В случае бэкапа БД именно в этой задаче указывается SLP.
На закладке Clients перечисляется список клиентов, резервное копирование данных с которых производится в рамках данной политики. Клиентов может быть достаточно много, но ко всем им будут применяться одни и те же правила.
То же относится и к перечню копируемых ресурсов. Net Backup на каждом из перечисленных клиентов будет пытаться найти все ресурсы, перечисленные на закладке Backup Selections, и если какой-то отдельный ресурс из списка будет найден, то Net Backup произведет его резервное копирование в соответствии с политикой.
Восстановление данных из резервной копии
В большинстве случаев для восстановления данных необходимо воспользоваться программой «Backup, Archive and Restore», входящей в инсталляцию NetBackup. Она позволяет задать перечень ресурсов, подлежащих восстановлению с учетом требуемой даты, список ресурсов, место назначения (тут можно переопределить место назначения данных, указав другой путь или другой сервер), а также правила восстановления в исключительных ситуациях (например, указать, перезаписывать ли файлы, если они уже есть в точке восстановления).
Для Windows можно указать в дереве восстановления файлы, каталоги, состояние системы в целом, ключи реестра и т.п.
Комбинаций вариантов по восстановлению данных из резервных копий в NetBackup очень много, больше, чем способов резервного копирования. Рамки данной статьи не позволяют детально их раскрыть. Все они максимально подробно документированы в официальных инструкциях Symantec и обращение к этим инструкциям в процессе работы с Net Backup всегда является полезным, так как охватить одному человеку все возможности этого продукта достаточно тяжело. Но можно уверенно сказать, что если проектирование и настройка системы резервного копирования были выполнены грамотно, то восстановление данных в случае реальных проблем, связанных с их повреждением или потерей – это дело техники.
Автор: Андрей Хлебников, Softline
