SnapProtect for Open Systems

В продолжение темы о ПО SnapProtect: Архитектура резервного копирования на системах NetApp FAS, хочу осветить функционал SnapProtect for Open Systems. Начиная с релиза SnapProtect 10.0 Service Pack 4, NetApp теперь поддерживает резервные копии с direct-attached и «сторонних» хранилищ на Data ONTAP 7-Mode SnapVault системы.

«SnapProtect for Open Systems» или коротко (SPOS), выполняет блочную инкрементальную репликацию поддерждивая ОС Windows, Linux и Solaris, а также такие приложения как Microsoft Exchange Server, Microsoft SQL Server и Oracle Database.


Cхема работы SPOS

Принципиальное отличие такой схемы от стандартного подхода NetApp к резервному копированию, заключается в том, что Snapshot'ы снимаются не на уровне хранилища (Hardware Assistant), а на уровне файловой системы (или файлового менеджера типа LVM) ОС самого хоста.


Для использования функции SPOS следующие компоненты должны быть установлены на хосте-источнике с Windows или UNIX:

• MediaAgent: На всех хостах
• Windows: VSS software provider
• UNIX: Qsnap Driver or Linux LVM или Veritas VxvM
• Лицензия SnapVault на хранилище (куда будут размещаться резервные копии)

Есть также несколько важных моментов при внедрении SPOS версии 10.0 SP 4:

• Поддерживаются системы 7-Mode Data ONTAP версии 7.3.x и более новые
• Пока что нет поддержки резервных копий SPOS на Clustered ONTAP
• Поддерживается только вместе с OnCommand Unified Manager 5.2 (пока что нет поддержки SPOS в OCUM 6.x)
• DB2 DPF и MySQL приложения не поддерживаются в SPOS
• Не поддерживается 7-Mode vFiler (MultiStore) в качестве получателя, кроме vFiler0
• Raw партиции на UNIX не поддерживаются
• Нет поддержки для кластерных приложений или кластерных файловых систем
• Резервное копирование для Exchange Database Availability Groups (DAG) не поддерживается
• Не поддерживаются Oracle RAC и ASM
• Не поддерживается файловая система ZFS (Oracle Linux / Soraris)

Процесс выполнения такого резервного копирования выглядит так:

• Создаётся софтверный Snapshot на источнике данных, используя «родной движок», такой как VSS или Qsnap/LVM
• Раздел добавляется в OnCommand Unified Manager Dataset (соответствует разделу праймари системы) к политике хранения и далее к ней прикрепляется клиент с которого будет выполняться резервное копирование.
• OnCommand Unified Manager выполняет все операции по планированию резервного копирования, и по ним отправляет команды удалённой системе FAS, чтобы та подключалась к источнику данных и начала копирование данных. Копирование выполняется по тенологии «Pool», т.е. не клиент сливает данные на систему резервного копирования, а система резервного копировани затягивает данные с клиента.
• Если раздел ранее не был забэкаплен, будет выполнена базовая передача данных (т.е. — передача блоков данных с источника на получатель)
• Если раздел ранее был забэкаплен, тогда будут переданы только изменённые данные со времни последней передачи. Здесь применяется механизм чексум базирующийся на SHA-1 и чексум БД чтобы передать столько изменённые данные на получатель. Для каждого такого раздела, все резервные копии (за исключением первого) — инкрементальные.
• Когда передача для всех клиентов завершена, выполняется Snapshot на удалённом хранилище и этот Snapshot регистрируется как основная копия данных для приложения, которая соответствует snap копии на основной системе. После чего софт, выполнивший Snapshot на основной системе, удаляет Snapshot по завершении задания, как только передача данных закончиться успешно.
• Восстановление данных «целеком» выполняется на прямую, а «пофайловое» восстановление происходит через медиа агент. К медиа агенту подключается клонированный снепшот и агент копирует все необходимые данные.

Замечания по ошибкам в тексте и предложения прошу направлять в ЛС.