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.


Схема роботи 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 (поки що немає підтримки 6.x SPOS)
  • 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, щоб та підключалася до джерела даних
  • Якщо розділ не був раніше забэкаплен, будуть виконана базова передача даних (тобто — передавання блоків даних з джерела на отримувач)
  • Якщо розділ раніше був забэкаплен, тоді будуть передані лише змінені дані з часу останньої передачі. Тут застосовується механізм чексум базується на SHA-1 і чексум БД щоб передати стільки змінені дані на отримувач. Для кожного такого розділу, всі резервні копії (за винятком першого) — инкрементальные.
  • Коли передача для всіх клієнтів завершена, виконується спепшот на віддаленому сховищі і цей Snapshot реєструється як основна копія даних для програми, яка відповідає snap копії на основній системі. Після чого софт, який виконав Snapshot на основній системі, видаляє Snapshot по завершенні завдання, як тільки передача даних закінчитися успішно.


Зауваження щодо помилок у тексті та пропозиції прошу направляти в ЛС.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.