Резервное копирование SAP HANA
Дальше — отдельный сценарий: резервное копирование баз SAP HANA. Он вынесен отдельно потому, что HANA устроена не так, как привычные дисковые СУБД, и копируется тоже иначе.
Почему для SAP HANA отдельный порядок
SAP HANA — in-memory СУБД. Рабочий набор данных находится в оперативной памяти, а диск используется как слой персистентности: тома данных и тома журналов. Периодически СУБД сбрасывает изменённые страницы памяти на тома данных, а журнал изменений пишется непрерывно.
Отсюда два следствия.
Копия виртуальной машины проблему не решает. Она захватит слой персистентности в произвольный момент, но восстановление базы выполняется механизмами самой HANA — из точек сохранения и журналов. Копия дисков без участия СУБД не даёт гарантии, что база поднимется.
Копированием управляет сама HANA. У неё есть штатный интерфейс для внешних систем резервного копирования — Backint. Через него СУБД сама инициирует и контролирует процесс, вплоть до числа параллельных потоков, а агент принимает данные и складывает их в хранилище.
Поэтому агент ставится на сам сервер SAP HANA, а не рядом, и настройка идёт в определённой последовательности: сначала агент, затем права, затем инстанс, и только потом задание.
Если вы выбираете между агентским резервным копированием и копией машины целиком, посмотрите сравнение подходов. Для SAP HANA агентский вариант — не предпочтение, а требование архитектуры.
Что резервируется
| Объект | Зачем |
|---|---|
| Данные | Полная копия содержимого базы на момент выполнения задания |
| Журналы | Изменения между копиями данных; позволяют восстановиться на момент времени, а не только на момент снятия копии |
Без копирования журналов восстановление возможно только на состояние последней копии данных. Всё, что произошло после неё, будет потеряно.
Что потребуется до начала
Доступ к серверу SAP HANA:
- права
rootлибо возможность выполнять команды черезsudo— установщик агента требует их; - сетевой интерфейс с доступом в сеть резервного копирования. Если интерфейсов несколько, нужно знать, какой из них использовать;
- код авторизации для регистрации агента — выдаётся при подключении услуги.
В самой СУБД:
- учётная запись с правами, достаточными для резервного копирования и восстановления;
- сведения об экземпляре SAP HANA — их потребуется указать при добавлении инстанса.
Если сервер SAP HANA работает в изолированной сети, доступ до инфраструктуры резервного копирования нужно согласовать заранее. Без сетевой связности агент не зарегистрируется, и дальнейшие шаги выполнить не получится.
Порядок настройки
Шаги выполняются последовательно — каждый следующий опирается на результат предыдущего.
| Шаг | Что делается | Где |
|---|---|---|
| 1 | Установка агента на сервер SAP HANA | Установка агента |
| 2 | Настройка прав учётной записи в СУБД | Права доступа |
| 3 | Регистрация экземпляра в системе резервного копирования | Добавление инстанса |
| 4 | Создание задания с расписанием и глубиной хранения | План резервного копирования |
Если агент нужно снять с сервера — см. удаление агента.
Другие приложения
Тот же принцип действует и для остальных приложений, которые поддерживает Commvault: агент внутри системы, согласование копии с приложением, отдельные задания под данные и журналы. Отличаются интерфейс взаимодействия с приложением и набор прав.
Полный перечень поддерживаемых приложений и версий публикует вендор: documentation.commvault.com. Настройку под конкретное приложение согласуйте с поддержкой ITGLOBAL.COM.