Вопросы и ответы о резервном копировании баз данных 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.

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

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

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

• Отключите защиту (с сохранением данных) на первичном узле
• Запустите скрипт предварительной регистрации на вторичном узле
• Найдите базы данных на вторичном узле и настройте резервные копии на них

Эти действия необходимо выполнить вручную после каждой отработки отказа. Эти действия можно выполнить с помощью командной строки или протокола HTTP REST или на портале Microsoft Azure. Для автоматизации этих шагов можно использовать модуль Runbook Azure.

Ниже приведен подробный пример выполнения защиты коммутатора:

В этом примере у вас есть два узла: node 1 (основной) и node 2 (дополнительный) в HSR. Резервные копии настраиваются на узле 1. Как упоминалось выше, не пытайтесь настроить резервное копирование на узле 2.

Когда происходит первая отработка отказа, узел 2 станет основным. После этого

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

Затем сперва запустите полное резервное копирование на узле 2 и после этого завершите резервным копированием журналов.

При следующей отработки отказа узел 1 снова станет первичным, а узел 2 — вторичным. Теперь повторите эту процедуру.

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

Затем запустите полное резервное копирование на узле 1 и после этого завершите резервным копированием журналов.

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. Моментальные снимки еще не были.

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

В день можно выполнить не более 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.