Qu'est-ce qu'une sauvegarde à faible impact ?
Dans des circonstances normales, sur un appareil de sauvegarde et de reprise après sinistre, Backup and DR effectue une sauvegarde initiale complète d'une base de données, ce qui prend du temps. Ensuite, toutes les sauvegardes suivantes sont des sauvegardes incrémentielles beaucoup plus rapides. Une sauvegarde incrémentielle compare les bitmaps de l'instantané actuel et de l'instantané précédent, et n'applique que les modifications incrémentielles.
Une sauvegarde à faible impact est un type spécial de job de sauvegarde qui se produit lorsqu'une erreur système dans le job de sauvegarde précédent entraîne une image bitmap non fiable ou une incapacité à lire le bitmap. Le service qui lit le bitmap est cbt_server dans un environnement Linux et AAMService dans un environnement Windows.
Les sauvegardes à faible impact prennent plus de temps que les sauvegardes effectuées dans des conditions normales, car elles doivent effectuer une nouvelle ingestion complète pour recréer un bitmap fiable. Il peut ensuite appliquer les modifications incrémentielles sans avoir à remplacer la sauvegarde complète.
Éléments qui ne provoquent pas de sauvegardes à faible impact
- Mises à niveau des connecteurs
- Redémarrages progressifs du système
- Redémarrages en douceur de cbt_server ou d'AAMService, en supposant que le service est toujours en cours d'exécution au moment de la sauvegarde
Les basculements qui n'ont pas rencontré les erreurs à l'origine des bitmaps non fiables.
Causes des bitmaps non fiables
Un bitmap non fiable se produit lorsque quelque chose interrompt le job de sauvegarde, y compris les éléments suivants :
- Un arrêt incorrect de l'hôte :
- Un arrêt non progressif entraîne un faible taux d'affichage de l'écran de démarrage en raison du manque de fiabilité des bitmaps. Cela inclut le débranchement d'une machine physique ou toute autre méthode d'arrêt de Windows sans passer par un arrêt progressif, ou une erreur d'écran bleu. Cela est vrai même si une machine d'un cluster rencontre une erreur d'écran bleu qui déclenche un basculement, car le bitmap de la machine défaillante n'est pas fiable.
- Si tous les serveurs Windows d'un cluster qui ont hébergé la base de données depuis la sauvegarde précédente ne sont pas disponibles et n'exécutent pas l'agent Backup and DR. Nous extrayons les bitmaps de chaque hôte de cluster qui a hébergé la base de données depuis la sauvegarde précédente pour identifier les modifications. Sans tous les bitmaps, nous devons exécuter une sauvegarde low-splash pour préserver l'intégrité des données. Notez que si un hôte de cluster qui hébergeait une base de données rencontre un écran bleu de la mort, le bitmap peut être disponible lors de la sauvegarde, mais ne pas être fiable. Une récupération à faible impact est donc nécessaire.
- Échec de la mise à jour d'un module de noyau
- Un plantage ou un redémarrage du daemon en mode utilisateur
- Une erreur d'empreinte digitale s'est produite lors de l'exécution d'une sauvegarde. (Backup and DR effectue une "vérification d'empreinte" sur chaque job de sauvegarde pour détecter les erreurs.)
- Erreur lors de la mise en coffre-fort, si le disque de stockage est plein lors de l'arrêt de l'OS et que le système ne peut pas écrire toutes les données dans le coffre-fort.
- Basculement du nœud SAP HANA, entraînant la redirection de la sauvegarde vers un autre nœud.
- La sauvegarde s'exécute en mode dégradé, car le module du noyau n'a pas pu être chargé. Cela se produit généralement lorsque la version de l'OS n'est pas compatible.
- Si cbt_server ou AAMService est arrêté pendant la sauvegarde, les bitmaps ne peuvent pas être récupérés et le job de sauvegarde s'exécute en mode "low-splash".
Si le service AAMService n'est pas arrêté pendant une longue période, le démarrage du service AAMService rendra les bitmaps disponibles pour une sauvegarde normale.
- Si cbt_server ou AAMService est arrêté pendant une durée suffisante pour que plusieurs gigaoctets d'événements soient mis en file d'attente par le pilote, les bitmaps ne peuvent pas être recréés et la sauvegarde sera en mode "low-splash". La durée de cette opération dépend de la quantité d'E/S de disque sur la base de données. Cela nécessite généralement plusieurs jours d'indisponibilité du service AAM.
- L'arrêt non progressif de cbt_server ou d'AAMService peut rendre les bitmaps actuellement chargés non fiables. Les bitmaps sont chargés si le fichier suivi a été écrit au cours des 15 dernières minutes. En général, pour une base de données occupée, cela entraîne un faible impact.
- Si un volume contenant un fichier suivi (par exemple, un fichier .mdf SQL Server) est démonté sur l'hôte, puis remonté, les bitmaps ne sont pas fiables, car il n'y a aucun moyen de savoir ce qui a été écrit dans le fichier pendant qu'il était démonté.