Резервное копирование баз данных репликации системы SAP HANA на виртуальных машинах Azure

Базы данных SAP HANA являются критическими рабочими нагрузками, требующими низкой целевой точки восстановления (RPO) и долгосрочного хранения. В этой статье описывается, как создать резервную копию баз данных SAP HANA, работающих на виртуальных машинах Azure (виртуальных машинах) в хранилище служб восстановления Azure Backup с помощью Azure Backup.

Вы также можете переключить защиту базы данных SAP HANA на виртуальную машину Azure (автономную) в Azure Backup на HSR. Подробнее.

Примечание.

• Поддержка сценария HSR и аварийного восстановления в настоящее время недоступна, так как в одном регионе существует ограничение на виртуальную машину и хранилище. Чтобы включить операцию резервного копирования третьего узла, расположенного в другом регионе, необходимо настроить резервное копирование в другом хранилище как автономный узел.
• Дополнительные сведения о поддерживаемых конфигурациях и сценариях см . в таблице поддержки резервного копирования SAP HANA.

Необходимые компоненты

Перед резервной копией базы данных репликации системы SAP HANA на виртуальных машинах Azure убедитесь, что:

• Определите или создайте хранилище служб восстановления в том же регионе и подписке, что и две виртуальные машины и узлы базы данных репликации системы HANA (HSR).
• Разрешить подключение с каждой из виртуальных машин или узлов к Интернету для связи с Azure.
• Запустите скрипт предварительной регистрации на виртуальных машинах или узлах, которые входят в состав репликации системы HANA (HSR). Здесь можно скачать последний скрипт предварительной регистрации. Вы также можете скачать его по ссылке в разделе "Резервное копирование службы>восстановления",>чтобы обнаружить DBS в виртуальных машинах>при запуске обнаружения.

Внимание

Убедитесь, что объединенная длина имени виртуальной машины сервера SAP HANA и имя группы ресурсов не превышает 84 символов для виртуальных машин Azure Resource Manager и 77 символов для классических виртуальных машин. Это ограничение обусловлено тем, что некоторые символы зарезервированы службой.

Создание хранилища Служб восстановления

Хранилище служб восстановления — это сущность управления, которая хранит точки восстановления, созданные с течением времени, и предоставляет интерфейс для выполнения операций, связанных с резервным копированием. (создание резервных копий по запросу, восстановление и создание политик резервного копирования).

Чтобы создать хранилище служб восстановления, сделайте следующее:

1. Войдите на портал Azure.

2. Найдите центр резервного копирования и перейдите на панель мониторинга Центра архивации.

   

3. На панели обзора выберите Vault.

   

4. Выберите Хранилище Служб восстановления > Продолжить.

   

5. В области хранилища служб восстановления введите следующие значения:

   • Подписка. Выберите нужную подписку. Если вы являетесь участником только одной подписки, будет отображено ее имя. Если вы не уверены, какая подписка используется, используйте подписку по умолчанию. Вариантов будет несколько только в том случае, если рабочая или учебная учетная запись связана с несколькими подписками Azure.

   • Группа ресурсов: выберите имеющуюся группу ресурсов или создайте новую. Чтобы просмотреть список доступных групп ресурсов в подписке, выберите "Использовать существующий", а затем выберите ресурс в раскрывающемся списке. Чтобы создать новую группу ресурсов, нажмите кнопку "Создать", а затем введите имя. Дополнительные сведения о группах ресурсов см. в статье Общие сведения об Azure Resource Manager.

   • Имя хранилища. Введите понятное имя для идентификации хранилища. Это имя должно быть уникальным в пределах подписки Azure. Введите имя, которое содержит от 2 до 50 знаков. Оно должно начинаться с буквы и может содержать только буквы, цифры и дефисы.

   • Область. Выберите географический регион для хранилища. Хранилище, создаваемое для защиты любого источника данных, должно находиться в том же регионе, что и источник данных.

     Внимание

     Если вы не уверены в расположении источника данных, закройте окно. Перейдите к списку ресурсов на портале. Если у вас есть источники данных в нескольких регионах, создайте хранилище Служб восстановления в каждом из них. Создайте хранилище в первом расположении перед созданием хранилища в другом расположении. Не нужно указывать учетные записи хранения для хранения данных резервного копирования. Хранилище Служб восстановления и Azure Backup обрабатывают это автоматически.

   

6. Указав значения, выберите Просмотр и создание.

7. Чтобы завершить создание хранилища служб восстановления, нажмите кнопку "Создать".

   Для создания хранилища Служб восстановления может потребоваться некоторое время. Отслеживайте уведомления о состоянии в области уведомлений в правом верхнем углу. После создания хранилища он появится в списке хранилищ служб восстановления. Если хранилище не отображается, нажмите кнопку "Обновить".

   

Примечание.

Azure Backup теперь поддерживает неизменяемые хранилища, которые помогают гарантировать, что точки восстановления после создания не могут быть удалены до истечения срока действия политики резервного копирования. Вы можете сделать неизменяемость необратимой для максимальной защиты данных резервного копирования от различных угроз, включая атаки программ-шантажистов и вредоносных субъектов. Подробнее.

Запуск скрипта предварительной регистрации

При отработке отказа пользователи реплицируются в новый первичный ресурс, но hdbuserstore не реплицируется. Таким образом, необходимо создать один и тот же ключ во всех узлах установки HSR, что позволяет службе Azure Backup подключаться к любому новому первичному узлу автоматически без каких-либо действий вручную.

1. Создайте пользовательского пользователя резервного копирования в системе HANA со следующими ролями и разрешениями:

   Роль	Разрешение	Description
   MDC	Администратор базы данных и администратор резервного копирования (HANA 2.0 SPS05 и более поздние версии)	Создает новые базы данных во время восстановления.
   SDC	Администратор резервного копирования	Считывает каталог резервных копий.
   SAP_INTERNAL_HANA_SUPPORT		Обращается к нескольким частным таблицам. Требуется только для одной базы данных контейнеров (SDC) и нескольких версий базы данных контейнеров (MDC), предшествующих HANA 2.0 SPS04 ред 46. Она не требуется для версий HANA 2.0 SPS04 ред 46 и более поздних версий, так как теперь мы получаем необходимую информацию из общедоступных таблиц после исправления из команды HANA.

   Пример:

   - hdbsql -t -U SYSTEMKEY CREATE USER USRBKP PASSWORD AzureBackup01 NO FORCE_FIRST_PASSWORD_CHANGE
   - hdbsql -t -U SYSTEMKEY 'ALTER USER USRBKP DISABLE PASSWORD LIFETIME'
   - hdbsql -t -U SYSTEMKEY 'ALTER USER USRBKP RESET CONNECT ATTEMPTS'
   - hdbsql -t -U SYSTEMKEY 'ALTER USER USRBKP ACTIVATE USER NOW'
   - hdbsql -t -U SYSTEMKEY 'GRANT DATABASE ADMIN TO USRBKP'
   - hdbsql -t -U SYSTEMKEY 'GRANT CATALOG READ TO USRBKP'
   

2. Добавьте ключ в hdbuserstore для пользовательского пользователя резервного копирования, который позволяет подключаемым модулю резервного копирования HANA управлять всеми операциями (запросами базы данных, операциями восстановления, настройкой и выполнением резервного копирования).

   Пример:

   - hdbuserstore set BKPKEY localhost:39013 USRBKP AzureBackup01
   

3. Передайте пользовательский ключ пользователя резервного копирования в скрипт в качестве параметра:

   -bk CUSTOM_BACKUP_KEY_NAME` or `-backup-key CUSTOM_BACKUP_KEY_NAME
   

   Если срок действия пароля этого пользовательского ключа резервного копирования истекает, операции резервного копирования и восстановления завершаются ошибкой.

   Пример:

   hdbuserstore set SYSTEMKEY localhost:30013@SYSTEMDB <custom-user> '<some-password>'
   hdbuserstore set SYSTEMKEY <load balancer host/ip>:30013@SYSTEMDB <custom-user> '<some-password>'
   

   Примечание.

   Вы можете создать пользовательский ключ резервного копирования с помощью узла или IP-адреса подсистемы балансировки нагрузки вместо локального узла для использования виртуального IP-адреса (VIP).

   На схеме показано создание пользовательского ключа резервного копирования с помощью локального узла или IP-адреса.

   

   На схеме показано создание пользовательского ключа резервного копирования с помощью виртуального IP-адреса (внешний IP-адрес или узел подсистемы балансировки нагрузки).

   

4. Создайте один и тот же пользователь пользовательского резервного копирования (с одинаковым паролем) и ключ (в hdbuserstore) на обеих виртуальных машинах и узлах.

5. Укажите уникальный идентификатор HSR в качестве входных данных для скрипта:

   -hn HSR_UNIQUE_VALUE или --hsr-unique-value HSR_Unique_Value.

   Необходимо указать один и тот же идентификатор HSR на обеих виртуальных машинах и узлах. Этот идентификатор должен быть уникальным в хранилище. Оно должно быть буквенно-цифровым значением, содержащим по крайней мере одну цифру, одну строчную букву и один прописный знак, и он должен содержать от 6 до 35 символов.

   Пример:

   - ./script.sh -sk SYSTEMKEY -bk USRBKP -hn HSRlab001 -p 39013
   

6. При выполнении скрипта предварительной регистрации на вторичном узле необходимо указать порт SDC/MDC в качестве входных данных. Это связано с тем, что команды SQL для идентификации установки SDC/MDC не могут выполняться на вторичном узле. Необходимо указать номер порта в качестве параметра, как показано ниже:

   -p PORT_NUMBER или –port_number PORT_NUMBER.

   • Для MDC используйте формат 3<instancenumber>13.
   • Для SDC используйте формат 3<instancenumber>15.

   Пример:

   - MDC: ./script.sh -sk SYSTEMKEY -bk USRBKP -hn HSRlab001 -p 39013
   - SDC: ./script.sh -sk SYSTEMKEY -bk USRBKP -hn HSRlab001 -p 39015
   

7. Если программа установки HANA использует частные конечные точки, запустите скрипт предварительной регистрации с -sn помощью или --skip-network-checks параметра. После успешного выполнения скрипта предварительной регистрации перейдите к следующим шагам.

8. Запустите скрипт конфигурации резервного копирования SAP HANA (скрипт предварительной регистрации) на виртуальных машинах, где HANA устанавливается в качестве корневого пользователя. Этот скрипт настраивает систему HANA для резервного копирования. Дополнительные сведения о действиях скрипта см . в разделе "Что делает скрипт предварительной регистрации".

   Для установки HSR не создается уникальный идентификатор HANA. Таким образом, необходимо указать уникальный идентификатор, который помогает службе резервного копирования группировать все узлы HSR в качестве одного источника данных.

Сведения о настройке базы данных для резервного копирования см. в предварительных требованиях и скрипте предварительной регистрации.

Обнаружение баз данных

Чтобы обнаружить базу данных HSR, выполните следующие действия.

1. В портал Azure перейдите в центр резервного копирования и нажмите кнопку +Резервное копирование.

   

2. Выберите SAP HANA на виртуальной машине Azure в качестве типа источника данных, выберите хранилище служб восстановления, используемое для резервной копии, а затем нажмите кнопку "Продолжить".

   

3. Выберите "Начать обнаружение", чтобы инициировать обнаружение незащищенных виртуальных машин Linux в регионе хранилища.

   • После обнаружения на портале появятся незащищенные виртуальные машины, упорядоченные по имени и группе ресурсов.
   • Если виртуальная машина не указана должным образом, проверьте, уже ли она создана в хранилище.
   • Несколько виртуальных машин могут иметь одно и то же имя, но они должны принадлежать разным группам ресурсов.

   

4. В области "Выбор Виртуальные машины" в нижней части экрана выберите эту ссылку в разделе "Запуск этого сценария" на виртуальных машинах SAP HANA, чтобы предоставить эти разрешения службе Архивации Azure.

   

5. Запустите скрипт на каждой виртуальной машине, в которой размещаются базы данных SAP HANA, которые требуется создать резервную копию.

6. На панели "Выбор Виртуальные машины" после запуска скрипта на виртуальных машинах выберите виртуальные машины и выберите пункт "Обнаружение DOB".

   Azure Backup обнаруживает все базы данных SAP HANA на виртуальной машине. Во время обнаружения Azure Backup регистрирует виртуальную машину в хранилище и устанавливает на ней расширение. Он не устанавливает агент в базе данных.

   Чтобы просмотреть сведения обо всех базах данных каждой обнаруженной виртуальной машины, выберите "Просмотреть сведения " на шаге 1. Обнаружение DOB-объектов в разделе "Виртуальные машины".

Примечание.

При обнаружении или настройке резервного копирования на вторичном узле игнорируйте состояние, если состояние готовности к резервному копированию отображается не готово , так как это ожидаемое состояние вторичного узла в HSR.

Настроить резервное копирование

Чтобы включить резервное копирование, выполните следующие действия.

1. На панели "Цель резервного копирования" в шаге 2 выберите "Настройка резервного копирования".

   

2. На панели "Выбор элементов", чтобы создать резервную копию, выберите все базы данных, которые требуется защитить, и нажмите кнопку "ОК".

   

3. В раскрывающемся списке политики резервного копирования выберите политику, которую вы хотите использовать, и нажмите кнопку "Добавить".

   

4. После создания политики на панели резервного копирования нажмите кнопку "Включить резервное копирование".

   

5. Чтобы отслеживать ход выполнения конфигурации резервного копирования, перейдите к уведомлениям в портал Azure.

Примечание.

На этапе резервного копирования системной базы данных необходимо задать этот параметр [inifile_checker]/replicate на основном узле. Это позволяет реплицировать параметры из первичного на вторичный узел или виртуальную машину.

создание политики архивации;

Политика резервного копирования определяет расписания резервного копирования и длительность хранения резервных копий.

Примечание.

• Политика создается на уровне хранилища.
• Несколько хранилищ могут использовать одну и ту же политику резервного копирования, но тогда необходимо применить эту политику резервного копирования к каждому хранилищу.
• Azure Backup не настраивает автоматическое изменение летнего времени при резервном копировании базы данных SAP HANA, работающей на виртуальной машине Azure. Измените политику вручную, если это необходимо.

Чтобы настроить параметры политики, выполните следующие действия.

1. В области политики резервного копирования в поле "Имя политики" введите имя новой политики.

   

2. В разделе "Полная резервная копия" для частоты резервного копирования выберите "Ежедневно" или "Еженедельно".

   • Ежедневно: выберите часовой и часовой пояс, в котором должно начинаться задание резервного копирования.

     • Необходимо запустить полную резервную копию. Этот параметр нельзя отключить.
     • Щелкните Полная резервная копия, чтобы просмотреть политику.
     • При ежедневном создании полных резервных копий невозможно создавать разностные резервные копии.

   • Еженедельно: выберите день недели, часа и часового пояса, в котором должно выполняться задание резервного копирования.

   

3. На панели "Полная политика резервного копирования" в диапазоне хранения настройте параметры хранения для полной резервной копии.

   • По умолчанию выбраны все варианты. Снимите ограничения диапазона хранения, которые вы не хотите использовать, а затем задайте их как необходимые.
   • Минимальный срок хранения для любого типа резервного копирования (полный или разностный или журнал) составляет 7 дней.
   • Точки восстановления отмечены для хранения исходя из их диапазона хранения. Например, если выбран параметр "Ежедневно", то каждый день активируется создание только одной полной резервной копии.
   • Данные резервного копирования для определенного дня помечены и сохраняются на основе еженедельного диапазона хранения и параметров.

4. Нажмите кнопку "ОК ", чтобы сохранить параметры политики.

5. Чтобы добавить политику разностного резервного копирования, щелкните Разностная резервная копия.

6. В меню Differential Backup policy (Политика разностной резервной копии) выберите Включить для открытия элементов управления периодичностью и хранением.

   • Вы можете активировать не более одного разностного резервного копирования в день.
   • Разностные резервные копии можно хранить не более 180 дней. Если требуется более длительное хранение, необходимо использовать полные резервные копии.

   

   Примечание.

   Вы можете выбрать разностную или добавочную резервную копию в качестве ежедневной резервной копии в указанное время.

7. На панели "Добавочная политика резервного копирования" выберите "Включить", чтобы открыть элементы управления частотой и хранением.

   • Вы можете активировать не более одного добавочного резервного копирования в день.
   • Добавочные резервные копии можно хранить не более 180 дней. Если требуется более длительное хранение, необходимо использовать полные резервные копии.

   

8. Для сохранения политики и возврата к главному меню Политика архивации нажмите кнопку ОК.

9. Выберите "Резервное копирование журналов", чтобы добавить политику резервного копирования журналов транзакций.

   • В разделе Резервная копия журналов выберите Включить.

     Этот параметр нельзя отключить, так как SAP HANA управляет всеми резервными копиями журналов.

   • Задайте частоту и элементы управления хранением.

   Примечание.

   Потоковая передача резервных копий журналов начинается только после завершения успешной полной резервной копии.

10. Для сохранения политики и возврата к главному меню Политика архивации нажмите кнопку ОК.

11. После завершения настройки политики резервного копирования нажмите кнопку "ОК".

    Все резервные копии журналов связаны с предыдущей полной резервной копией для формирования цепочки восстановления. Полная резервная копия сохраняется до истечения срока действия последней резервной копии журнала. Таким образом, полная резервная копия сохраняется в течение дополнительного периода, чтобы обеспечить восстановление всех журналов.

    Например, предположим, что у вас есть еженедельная полная резервная копия, ежедневные разностные журналы и 2 часа . Все они хранятся в течение 30 дней. Но еженедельное полное резервное копирование удаляется только после следующей полной резервной копии (т. е. после 30 + 7 дней).

    Если еженедельное полное резервное копирование происходит 16 ноября, оно должно храниться в зависимости от политики хранения до 16 декабря. Последняя резервная копия журнала для этой полной резервной копии происходит до следующего запланированного полного резервного копирования 22 ноября. Пока этот журнал не станет доступным 22 декабря, полная резервная копия 16 ноября не удаляется. Таким образом, 16 ноября полная резервная копия сохраняется до 22 декабря.

Выполнение резервного копирования по требованию

Резервное копирование выполняется в соответствии с расписанием политики. Узнайте, как выполнить резервное копирование по запросу.

Примечание.

Перед плановая отработка отказа убедитесь, что обе виртуальные машины и узлы зарегистрированы в хранилище (физическая и логическая регистрация). Подробнее.

Запуск резервного копирования собственных клиентов SAP HANA в базе данных с помощью Azure Backup

Резервное копирование по запросу можно выполнять с помощью собственных клиентов SAP HANA в локальной файловой системе вместо Backint. Узнайте больше об управлении операциями с помощью собственных клиентов SAP.

Сценарии защиты узлов HSR в Службе архивации Azure

Теперь вы можете переключить защиту базы данных SAP HANA на виртуальную машину Azure (автономную) в Azure Backup на HSR. Если вы уже настроили HSR и защитили только основной узел с помощью Azure Backup, можно изменить конфигурацию, чтобы защитить как первичные, так и вторичные узлы.

Два автономных узла /HSR никогда не защищены с помощью резервного копирования базы данных SAP HANA на виртуальной машине Azure

1. (Обязательный) Запустите последний скрипт предварительной регистрации как на первичных, так и на вторичных узлах виртуальной машины.

   Примечание.

   Атрибуты на основе HSR добавляются в последний скрипт предварительной регистрации.

2. Настройте HSR вручную или с помощью любых средств кластеризации, таких как pacemaker,

   Перейдите к следующему шагу, если конфигурация HSR уже завершена.

3. Обнаружение и настройка резервного копирования для этих виртуальных машин.

   Примечание.

   Для развертываний HSR стоимость защищенного экземпляра взимается с логического контейнера HSR (два узла — первичный и вторичный) будет формировать один логический контейнер HSR.

4. Перед плановая отработка отказа убедитесь, что обе виртуальные машины и узлы зарегистрированы в хранилище (физическая и логическая регистрация).

Две автономные виртуальные машины/ одна автономная виртуальная машина, уже защищенная с помощью резервного копирования базы данных SAP HANA на виртуальной машине Azure

1. Чтобы остановить резервное копирование и сохранить данные, перейдите в хранилище>элементов>резервного копирования SAP HANA на виртуальной машине Azure, а затем выберите пункт "Просмотр сведений>об остановке резервного копирования резервных>копий".>

2. (Обязательный) Запустите последний скрипт предварительной регистрации как на первичных, так и на вторичных узлах виртуальной машины.

   Примечание.

   Атрибуты на основе HSR добавляются в последний скрипт предварительной регистрации.

3. Настройте HSR вручную или с помощью любых средств кластеризации, таких как pacemaker.

4. Обнаружение виртуальных машин и настройка резервного копирования в логическом экземпляре HSR.

   Примечание.

   Для развертываний HSR стоимость защищенного экземпляра будет взиматься с логического контейнера HSR (два узла — первичный и /вторичный) будет формировать один логический контейнер HSR.

5. Перед плановая отработка отказа убедитесь, что обе виртуальные машины и узлы зарегистрированы в хранилище (физическая и логическая регистрация).

Следующий шаг

• Восстановление баз данных репликации системы SAP HANA на виртуальных машинах Azure
• Резервное копирование баз данных репликации системы SAP HANA на виртуальных машинах Azure