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

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

Для успешно выполненных заданий резервного копирования оповещения не создаются. Они отправляются только в случае сбоя. Узнайте, как просматривать оповещения о резервном копировании на портале Azure.

Вы можете проверить состояние резервных копий (создаваемых по расписанию или по запросу) в следующих расположениях:

1. Задания резервного копирования: Azure Backup отображает все инициированные вручную задания на портале Azure в разделе "Задания резервного копирования".
   
   Задания, которые вы видите в портал Azure, включают операции обнаружения и регистрации базы данных, а также операции резервного копирования и восстановления. Запланированные задания, включая резервные копии журналов, не отображаются в этом разделе. Резервное копирование, инициированное вручную из собственных клиентов SAP HANA (Studio, Cockpit или DBA Cockpit), также не отображается здесь.

   

   

2. Оповещения о резервном копировании. Оповещения помогают отслеживать резервное копирование баз данных SAP HANA. Это поможет вам сосредоточиться на необходимых событиях, не тратя при этом усилий на частую проверку различных событий, генерируемых резервной копией. Дополнительные сведения см. в разделе Просмотр оповещений о резервном копировании.

3. Отчеты о резервном копировании. Отчеты — это еще один способ просмотра состояния заданий резервного копирования. Отчеты будут следующими:

   

   

   Дополнительные сведения о настройке отчетов Azure Backup.

4. Клиенты SAP HANA Native: если вы являетесь клиентом SAP HANA, вы также можете использовать HANA Studio, один из наиболее распространенных клиентов HANA. В этом клиенте перейдите к консоли резервного копирования ->каталог резервных копий, чтобы увидеть состояние резервного копирования.

   

В меню "Задание архивации" отображаются только задания резервного копирования по запросу, которые выполняются, завершились успешно или сбоем. Для запланированных заданий используйте Azure Monitor.

Azure Backup не устанавливает явный период хранения полных резервных копий для автоматического восстановления. Эта резервная копия сохраняется до тех пор, пока не будет храниться зависимый разностный (разностный или добавочный) и резервные копии журналов. После удаления последней зависимой резервной копии на такой резервной копии для автоматического восстановления резервная копия для автоматического восстановления также удаляется.

Да, полная резервная копия и резервная копия журнала могут выполняться одновременно. Этот экземпляр создается одним из следующих способов:

• Выполняется полное резервное копирование и запускается резервное копирование журналов. Резервное копирование журнала должно быть успешным, независимо от выполнения текущего полного резервного копирования. Если только полное резервное копирование, которое активировалось, было исправлено полностью для обработки любого разрыва цепочки LSN.
• Выполняется резервное копирование журналов, и активируется полная резервная копия: обе резервные копии должны выполняться одновременно и успешно.

Нет, в настоящий момент это не поддерживается.

Если удалить базу данных из экземпляра SAP HANA, попытки ее резервного копирования все равно будут продолжаться. Это означает, что удаленная база данных начнет отображаться как неработоспособная в разделе Элементы архивации и будет по-прежнему обрабатываться как защищенная. Правильный способ отключения защиты этой базы данных — выполнить в этой базе данных остановку резервного копирования с удалением данных.

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

Пошаговые инструкции по началу работы с Azure Backup для баз данных SAP HANA см. в этом руководстве. Для настройки резервных копий и управления ими также можно использовать интерфейс командной строки.

Предварительные условия для использования Azure Backup с SAP HANA приведены здесь.

В этом разделе содержится руководство по устранению неполадок.

В этом разделе содержится руководство по устранению неполадок.

На данный момент настроить решение для виртуального IP-адреса или прокси невозможно. Для работы этого решения требуется виртуальная машина.

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

Вы можете обрезать каталог HANA с помощью рекомендуемых методов SAP, таких как инструкции BACKUP CATALOG DELETE или HANA Studio/Cockpit. Узнайте больше об управлении операциями с помощью собственных клиентов SAP.

1. При репликации системы HANA (HSR) дополнительный узел не принимает подключения. После настройки резервного копирования служба Azure Backup периодически проверяет связь, и такие проверки могут оказаться неудачными. Иногда такие неудачные попытки отражаются на основном узле. После нескольких сбоев пользователь блокируется, а затем главный узел запускается с ошибкой ODBCConnectionError.
   
   Мы заметили, что эта проблема наблюдается не у всех пользователей. Мы рекомендуем вам/SAP изучить причину блокировки пользователей в основном узле при сбое подключения пользователя к дополнительному узлу.

2. После запуска сценария предварительной регистрации сведения о пользователе обновляются с помощью нового пароля в основном узле. Затем подключение будет снова установлено в целях попытки резервного копирования. Однако этот сценарий может повториться.

3. Кроме того, при сбое резервного копирования (полной резервной копии) на дополнительном узле создаются оповещения.

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

Обратитесь к пропускной способности резервного копирования и восстановления, которую Azure Backup обеспечивает для рабочих нагрузок HANA.

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

• Выбор типа диска для виртуальных машин IaaS Azure — управляемые диски
• Уровни производительности для управляемых дисков Azure
• серия M;
• Конфигурации хранилища виртуальных машин SAP HANA в Azure

В настоящее время Azure Backup для SAP HANA принимает 1 в качестве значения свойства parallel_backup_using_backint . Однако Azure Backup разделяет один поток в нескольких потоках для повышения производительности.

В настоящее время поддерживаются только резервные копии на основе Backint для HSR. Моментальные снимки еще не были.

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

Во время операции резервного копирования задание резервного копирования подключается к трем конечным точкам службы — AzureBackupAzureStorageи Microsoft Entra ID. In this scenario, we recommend you to configure the Service Endpoint to AzureStorage», что помогает отправлять трафик из виртуальная сеть непосредственно в хранилище. Для Azure Backup и идентификатора Microsoft Entra можно настроить UDR по тегам службы, чтобы трафик перемещается в магистральную сеть вместо локальной сети.

В хранилище служб восстановления отображаются все узлы, которые являются частью репликации системы SAP HANA. Все узлы перечислены здесь, как по выходным hdbnsutil данным. Однако в соответствии с ожидаемым поведением регистрируется только настроенный узел в этом хранилище.

При запуске задания резервного hdbbackint копирования с помощью агента Backint он записывает сведения в /var/tmp каталог. Например, если во время резервного копирования возникает ошибка, сообщение об ошибке записывается в файл в /var/tmp каталоге. Имя файла создается в формате hdbbackint_<SID>.<random_string>, где <SID> находится идентификатор системы экземпляра SAP HANA и <random_string> является случайно созданной строкой.

Процесс резервного hdbbackint копирования не затрагивается, если удалить файл в каталоге /var/tmp . Однако в процессе резервного копирования могут быть удалены сообщения об ошибках, записанные в файл.

В день можно выполнить не более 10 операций восстановлений для каждой системы или экземпляра HANA. Обратите внимание, что если восстановление отменено или завершается сбоем, он также считается попыткой восстановления.

Проверьте, выполнены ли все предварительные условия для восстановления в целевом экземпляре SAP HANA. Дополнительные сведения см. в разделе Восстановление баз данных SAP HANA на виртуальных машинах Azure. Предварительные требования.

Убедитесь, что при восстановлении выбран параметр Принудительная перезапись.

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

Да, вы можете использовать резервные копии потоковой передачи, активируемые в базе данных HANA, работающей на SLES, чтобы восстановить ее в систему RHEL HANA и наоборот. То есть восстановление между разными операционными системами возможно с помощью потоковой архивации. Однако, необходимо убедиться, что система HANA, в которую требуется выполнить восстановление, и система HANA, используемая для восстановления, совместимы согласно данных SAP. Типы систем, совместимых для восстановления, см. в документе SAP HANA Note 1642148 (Заметка 1642148 по SAP HANA).

Да, вы можете скачать файлы частично, как описано здесь.

Да, необходимо отключить репликацию системы HANA (HSR) в целевой системе, а затем выполнить восстановление. Вы не можете восстановить систему с поддержкой HSR, как по sap.

Перед созданием политики необходимо четко понимать требования к RPO и RTO и соответствующим расходам.

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

RTO (время восстановления) указывает скорость восстановления данных до последнего доступного момента времени после потери данных. Это зависит от стратегии восстановления, применяемой HANA, которая обычно зависит от того, сколько файлов требуется восстановить. Это также влияет на затраты. Ниже приводится таблица, призванная помочь в распознавании всех сценариев и их влиянии.

Таким образом, можно выбрать вариант политики на основе целевых показателей RPO и RTO, а также учитывать затраты.

При определении влияния переключения политики резервного копирования с Политики 1 (P1) на Политику 2 (P2) или изменения Политики 1 (P1) следует учитывать несколько принципов.

• Все изменения также применяются задним числом. Последняя политика архивации также применяется к точкам восстановления, сделанным ранее. Например, предположим, что ежедневное полное хранение составляет 30 дней и 10 точек восстановления в соответствии с действующей в настоящее время политикой. Если ежедневное полное хранение изменяется на 10 дней, время окончания срока действия предыдущей точки также пересчитывается как время начала + 10 дней и удаляется, если срок их действия истек.
• Область изменений также включает в себя день резервного копирования, тип резервного копирования и срок хранения. Например, если политика изменяется с ежедневного полного на еженедельное по воскресеньям, все более ранние заполнения, которые не выполнялись в воскресенье, будут помечены для удаления.
• родительский объект не удаляется, пока дочерний активен и не истек срок его действия. У каждого типа резервных копий есть свой срок действия согласно текущей действующей политике. Но тип полного резервного копирования считается материнским для последующих "дифференциальных", "инкрементных" копий и "журналов". "Дифференциальная копия" и копия "журнал" не являются материнскими для каких-либо еще. "Инкрементная копия" может быть материнской для следующей "инкрементной". Даже если материнская копия помечена для удаления, она фактически не удаляется, если срок действия дочерних "дифференциальных копий" или копий "журналов" не истек. Например, если политика изменяется с ежедневного полного на еженедельное по воскресеньям резервное копирование, все более ранние заполнения, которые не выполнялись в воскресенье, будут помечены для удаления. Но они не удаляются, пока не истечет срок действия ежедневных журналов, которые были сделаны раньше. Иными словами, они будут храниться в соответствии с последним сроком журнала. После истечения срока действия журналов все журналы и эти заполнения удаляются.

С помощью этих принципов можно прочитать следующую таблицу, чтобы понять последствия изменения политики.

Вы можете управлять пространством в корневой папке с помощью одного из следующих параметров:

• Создание собственного LV для /opt/msawb.
• Создание ссылки/символьной ссылки на другое расположение или папку на том же или другом диске.
• Увеличение пространства в корневой секции.

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

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