Forum aux questions – Sauvegarde de bases de données SAP HANA sur des machines virtuelles Azure

Vous pouvez disposer d’une sauvegarde complète planifiée et de plusieurs sauvegardes à la demande par jour.

Les travaux de sauvegarde réussis ne génèrent pas d’alertes. Les alertes ne sont envoyées qu’en cas d’échec de la sauvegarde. Découvrez comment utiliser le portail Azure pour afficher les alertes de sauvegarde.

Vous pouvez vérifier l’état de vos sauvegardes (planifiées/à la demande) à partir de l’un des emplacements suivants :

1. Travaux de sauvegarde : Sauvegarde Azure affiche tous les travaux déclenchés manuellement dans la section Travaux de sauvegarde sur le portail Azure.
   
   Les travaux que vous voyez dans le portail Azure incluent la découverte de bases de données et l’inscription des opérations, ainsi que les opérations de sauvegarde et de restauration. Les travaux planifiés, notamment les sauvegardes de fichiers journaux, n’apparaissent pas dans cette section. Les sauvegardes déclenchées manuellement à partir des clients natifs SAP HANA (Studio/Cockpit/DBA Cockpit) ne sont pas non plus indiquées ici.

   

   

2. Alertes de sauvegarde : les alertes vous aident à surveiller les sauvegardes des bases de données SAP HANA. Elles vous aident à vous concentrer sur les événements requis, vous épargnant ainsi l’effort de vérification fréquente de la multitude d’événements qu’une sauvegarde génère. Pour plus d’informations, consultez Afficher les alertes de sauvegarde.

3. Rapports de sauvegarde : les rapports constituent une autre manière d’afficher l’état de vos travaux de sauvegarde. Vous rapports se présenteront comme suit :

   

   

   Découvrez Comment configurer des rapports de sauvegarde Azure.

4. Clients natifs SAP HANA : si vous êtes un client SAP HANA, vous pouvez également utiliser HANA Studio, un des clients HANA les plus courants. Dans ce client, accédez à Console de sauvegarde ->Catalogue de sauvegarde pour voir l’état de la sauvegarde.

   

Le menu Tâche de sauvegarde affiche uniquement les tâches de sauvegarde à la demande en cours, ayant réussi ou échoué. Pour les tâches planifiées, utilisez Azure Monitor.

Le service Sauvegarde Azure ne définit pas une période de rétention explicite sur les sauvegardes complètes de réparation automatique. Cette sauvegarde est conservée jusqu’au moment où vous conservez les sauvegardes delta dépendantes (différentielles ou incrémentielles) et les sauvegardes de journal. Une fois que vous avez supprimé la dernière sauvegarde dépendante sur cette sauvegarde de réparation automatique, celle-ci est également supprimée.

Oui, une sauvegarde complète et une sauvegarde de fichier journal peuvent s’exécuter simultanément. Ceci se produit de l’une des façons suivantes :

• Une sauvegarde complète est en cours et une sauvegarde de journal est déclenchée : la sauvegarde de journal doit réussir, indépendamment de la sauvegarde complète en cours, Sauf si la sauvegarde complète déclenchée était une solution complète pour gérer tout saut de chaîne LSN.
• Une sauvegarde de fichier journal est en cours et une sauvegarde complète est déclenchée : les deux sauvegardes doivent s’exécuter simultanément et réussir.

Non, cette opération n’est pas prise en charge actuellement.

Si une base de données est supprimée d’une instance SAP HANA, des tentatives de sauvegarde de cette base de données sont toujours effectuées. Cela implique que la base de données supprimée devient défectueuse sous Éléments de sauvegarde mais reste protégée. Pour ne plus protéger cette base de données, utilisez Arrêter la sauvegarde avec Supprimer des données sur cette base de données.

Une base de données renommée est traitée en tant que nouvelle base de données. Par conséquent, le service gère cette situation comme si la base de données était introuvable et les sauvegardes échouent. La base de données renommée s’affiche sous la forme d’une nouvelle base de données et doit être configurée pour la protection.

Reportez-vous au didacticiel pour obtenir un guide étape par étape pour démarrer avec Azure Backup pour les bases de données SAP HANA. Vous pouvez également utiliser CLI pour configurer et gérer les sauvegardes.

Consultez les conditions préalables pour l’utilisation de Sauvegarde Azure avec SAP HANA.

Reportez-vous à cette section du Guide de résolution des problèmes.

Reportez-vous à cette section du Guide de résolution des problèmes.

Nous ne sommes pas en mesure de configurer la solution sur une adresse IP virtuelle ou un proxy pour le moment. Une machine virtuelle est nécessaire pour exécuter la solution.

Vous pouvez déclencher une sauvegarde à la demande avec des clients natifs SAP HANA sur le système de fichiers local au lieu de Backint. Découvrez comment gérer les opérations avec des clients natifs SAP.

Vous pouvez élaguer le catalogue HANA en utilisant les méthodes recommandées par SAP, comme les instructions BACKUP CATALOG DELETE ou HANA Studio/Cockpit. Découvrez comment gérer les opérations avec des clients natifs SAP.

Actuellement, la sauvegarde Azure n’a pas la possibilité de comprendre une configuration HSR. Cela signifie que les nœuds principal et secondaire de la réplication HSR seront traités comme deux machines virtuelles indépendantes. Vous devez d’abord configurer la sauvegarde sur le nœud principal. Lorsqu’un basculement se produit, la sauvegarde doit être configurée sur le nœud secondaire (qui devient alors le nœud principal). Il n’y a pas de basculement automatique de la sauvegarde vers l’autre nœud.

Pour sauvegarder des données à partir du nœud actif (principal) à un moment donné, vous pouvez basculer la protection vers le nœud secondaire qui est désormais le principal après le basculement.

Pour effectuer ce basculement de protection, procédez comme suit :

• Arrêtez la protection (avec conservation des données) sur le nœud principal
• Exécutez le script de pré-inscription sur le nœud secondaire
• Détectez les bases de données sur le nœud secondaire et configurez les sauvegardes sur celles-ci

Ces étapes doivent être effectuées manuellement après chaque basculement. Vous pouvez effectuer ces étapes via la ligne de commande / HTTP REST en plus du portail Azure. Pour automatiser ces étapes, vous pouvez utiliser un runbook Azure.

Voici un exemple détaillé de la façon dont la protection des commutateurs doit être effectuée :

Dans cet exemple, vous avez deux nœuds – le nœud 1 (principal) et le nœud 2 (secondaire) dans la configuration HSR. Les sauvegardes sont configurées sur le nœud 1. Comme indiqué ci-dessus, ne tentez pas encore de configurer des sauvegardes sur le nœud 2.

Lorsque le premier basculement se produit, le nœud 2 devient le nœud principal. Ainsi,

1. Arrêtez la protection du nœud 1 (principal précédent) avec l’option de conservation des données.
2. Exécutez le script de pré-inscription sur le nœud 2 (qui est désormais le nœud principal).
3. Découvrez les bases de données sur le nœud 2, affectez la stratégie de sauvegarde et configurez les sauvegardes.

Ensuite, une première sauvegarde complète est déclenchée sur le nœud 2 et, une fois celle-ci terminée, les sauvegardes de fichiers journaux démarrent.

Lorsque le basculement suivant se produit, le nœud 1 redevient principal et le nœud 2 devient secondaire. À présent, répétez le processus :

1. Arrêtez la protection du nœud 2 avec l’option de conservation des données.
2. Exécutez le script de pré-inscription sur le nœud 1 (qui est redevenu principal).
3. Ensuite, reprenez la sauvegarde sur le nœud 1 avec la stratégie requise (car les sauvegardes ont été arrêtées plus tôt sur le nœud 1).

Ensuite, une sauvegarde complète est déclenchée de nouveau sur le nœud 1 et, une fois celle-ci terminée, les sauvegardes de fichiers journaux démarrent.

1. Pour la réplication de système HANA (HSR), le nœud secondaire n’accepte aucune connexion. Une fois la sauvegarde configurée, le service Sauvegarde Azure effectue un test ping périodique et échoue. Parfois, ces échecs de tentatives sont reflétés sur le nœud principal. Après plusieurs défaillances, l’utilisateur est bloqué, puis le nœud principal commence à échouer avec l’erreur ODBCConnectionError.
   
   Nous avons remarqué que tous les utilisateurs ne rencontrent pas ce problème. Nous vous recommandons d’examiner la raison pour laquelle les utilisateurs sont bloqués dans le nœud principal quand la connexion utilisateur échoue sur le nœud secondaire.

2. Une fois que vous avez exécuté le script de préinscription, les informations utilisateur sont mises à jour avec le nouveau nœud principal. Ensuite, la connexion pour tenter la sauvegarde est rétablie. Toutefois, il se peut que vous soyez à nouveau confronté au même scénario.

3. En outre, les sauvegardes (sauvegardes complètes) qui échouent sur le nœud secondaire créent des alertes.

Pour éviter les problèmes ci-dessus, nous vous recommandons d’arrêter la protection d’un nœud une fois qu’il devient secondaire (afin qu’aucune connexion ne soit tentée et que l’utilisateur ne soit pas bloqué), et de reprendre la protection de ce nœud une fois qu’il devient principal. Si vous ne rencontrez pas cette situation de verrouillage sur les configurations HSR et que vous êtes familiarisé avec les alertes générées, vous pouvez configurer des sauvegardes sur les deux nœuds afin que le service gère la reprise et la restauration automatique.

Reportez-vous aux performances de débit de sauvegarde et de restauration qu’offre le service Sauvegarde Azure pour les charges de travail HANA.

Pour configurer votre système HANA afin de tirer parti des performances améliorées, utilisez les ressources suivantes :

• Sélectionner un type de disque pour les machines virtuelles Azure IaaS - disques managés
• Niveaux de performance des disques managés Azure
• Série M
• Configurations du stockage des machines virtuelles SAP HANA Azure

Actuellement, Sauvegarde Azure pour SAP HANA accepte 1 comme valeur de la propriété parallel_backup_using_backint. Toutefois, Sauvegarde Azure fractionne ce flux unique en plusieurs flux pour de meilleures performances.

Seules les sauvegardes basées sur Backint sont actuellement prises en charge pour HSR. Les instantanés ne le sont pas encore.

Vous devez exécuter la nouvelle détection de l’instance sur le serveur marqué « Non prêt » pour une mise à jour de son état.

Vous pouvez effectuer un maximum de 10 restaurations par système HANA ou instance par jour. Notez que, si une restauration est annulée ou échoue, elle est également considérée comme une tentative de restauration.

Vérifiez que toutes les conditions préalables pour la restauration vers la cible de l’instance SAP HANA sont remplies. Pour plus d’informations, consultez Conditions préalables - Restaurer des bases de données SAP HANA dans une machine virtuelle Azure.

Assurez-vous que l’option Forcer le remplacement est sélectionnée lors de la restauration.

Reportez-vous à la note SAP HANA 1642148 pour voir quels types de restauration sont actuellement pris en charge.

Oui, vous pouvez utiliser des sauvegardes en continu déclenchées sur une base de données HANA en cours d’exécution sur SLES pour la restaurer vers un système RHEL HANA, et vice versa. Autrement dit, la restauration entre systèmes d’exploitation est possible à l’aide de sauvegardes en continu. Toutefois, vous devez vous assurer que le système HANA vers lequel vous souhaitez restaurer et le système HANA utilisé pour la restauration sont tous deux compatibles pour la restauration en fonction de SAP. Pour connaître les types de restauration compatibles, consultez la Note SAP HANA 1642148.

Oui, vous pouvez télécharger des fichiers partiellement comme documentés ici.

Oui, vous devez désactiver la réplication du système HANA (HSR) sur le système cible, puis effectuer une restauration. Vous ne pouvez pas restaurer un système activé par HSR, selon SAP.

Avant de créer une stratégie, vous devez connaître les exigences en matière de RPO et de RTO, ainsi que ses implications en termes de coûts.

Le RPO (objectif de point de récupération) indique la quantité de perte de données acceptable pour l’utilisateur ou le client. Celle-ci est déterminée par la fréquence de sauvegarde du journal. Des sauvegardes de fichier journal plus fréquentes indiquent un RPO inférieur et la valeur minimale que prend en charge le service Sauvegarde Azure est de 15 minutes. La fréquence de sauvegarde de fichier journal peut être de 15 minutes ou plus.

Le RTO (objectif de temps de récupération) indique la vitesse à laquelle les données doivent être restaurées sur le dernier point dans le temps disponible après un scénario de perte de données. Celle-ci dépend de la stratégie de récupération employée par HANA, qui dépend généralement du nombre de fichiers requis pour la restauration. Elle a également des implications financières et le tableau suivant doit vous aider à comprendre tous les scénarios et leurs implications.

Par conséquent, vous pouvez sélectionner la variante de stratégie en fonction d’objectifs de RPO et de RTO et de considérations financières.

Il convient de prendre en compte quelques principes lors de la détermination de l’impact du changement de stratégie de sauvegarde d’un élément, passant de la stratégie 1 (P1) à la stratégie 2 (P2), ou de la modification de la stratégie 1 (P1).

• Toutes les modifications sont également appliquées de façon rétroactive. La stratégie de sauvegarde la plus récente est appliquée également aux points de récupération pris précédemment. Par exemple, supposons que la rétention de sauvegarde quotidienne complète est de 30 jours et que 10 points de récupération ont été pris conformément à la stratégie actuellement active. Si la rétention de la sauvegarde quotidienne complète est modifiée en 10 jours, l’heure d’expiration du point précédent est également recalculée comme l’heure de début + 10 jours, et supprimée si elle a expiré.
• L’étendue de la modification inclut également le jour de la sauvegarde, le type de sauvegarde, ainsi que la rétention. Exemple : Si une stratégie est modifiée de sauvegarde quotidienne complète en sauvegarde hebdomadaire complète le dimanche, toutes les sauvegardes complètes antérieures qui n’ont pas été effectuées un dimanche sont marquées pour suppression.
• Un parent n’est pas supprimé tant que l’enfant est actif ou n’a pas expiré. Chaque type de sauvegarde a une heure d’expiration conformément à la stratégie actuellement active. Toutefois, un type de sauvegarde complète est considéré comme parent des « sauvegardes différentielles », des « sauvegardes incrémentielles » et des « journaux » suivants. Une « sauvegarde différentielle » et un « journal » ne sont parents de rien. Une « sauvegarde incrémentielle » peut être parente d’une « sauvegarde incrémentielle » ultérieure. Même si un « parent » est marqué pour suppression, il n’est pas réellement supprimé si les « sauvegardes différentielles » ou les « journaux » enfants ne sont pas arrivés à expiration. Par exemple, si une stratégie est modifiée de sauvegarde quotidienne complète en sauvegarde hebdomadaire complète le dimanche, toutes les sauvegardes complètes antérieures qui n’ont pas été effectuées un dimanche sont marquées pour suppression. Mais elles ne sont pas réellement supprimées tant que les journaux quotidiens précédents n’ont pas expiré. En d’autres termes, elles sont conservées en fonction de la durée du dernier journal. Quand les journaux expirent, les journaux et les sauvegardes complètes sont supprimés.

Avec ces principes à l’esprit, vous pouvez lire le tableau suivant pour comprendre les implications d’une modification de stratégie.

Vous pouvez gérer l’espace dans le dossier racine à l’aide de l’une des options suivantes :

• Créez une propre LV pour /opt/msawb.
• Créez un link/symlink soft vers un autre emplacement/dossier sur le même disque/différent.
• Augmentez l’espace sur la partition racine.

Étapes suivantes

• Découvrez comment sauvegarder des bases de données SAP HANA qui s’exécutent sur des machines virtuelles Azure.
• Découvrez comment résoudre les problèmes de sauvegarde de base de données SAP HANA.