Qu'est-ce qu'une sauvegarde à faible impact ?
Dans des circonstances normales, sur un appliance de sauvegarde/récupération du service Backup and DR, Backup and DR effectue une sauvegarde complète initiale de la base de données, qui prend du temps. 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 splash 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 progressifs de cbt_server ou AAMService en supposant que le service est toujours en cours d'exécution au moment de la sauvegarde
Bascules qui n'ont pas rencontré les erreurs qui entraînent des bitmaps non fiables.
Causes des bitmaps non fiables
Une bitmap non fiable se produit lorsqu'un élément interrompt le job de sauvegarde, y compris les éléments suivants :
- Arrêt non propre de l'hôte :
- Un arrêt non progressif entraîne un écran de démarrage réduit en raison du manque de fiabilité des bitmaps. Cela inclut la déconnexion d'une machine physique ou toute autre méthode d'arrêt de Windows sans arrêt progressif, ou une erreur d'écran bleu. Cela est vrai même si une machine d'un cluster affiche un écran bleu qui déclenche le basculement, car le bitmap de la machine défaillante n'est pas fiable.
- Si tous les serveurs Windows d'un cluster ayant 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 trouver les modifications. Sans tous les bitmaps, nous devons exécuter low-splash pour maintenir 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, le bitmap peut être disponible dans la sauvegarde, mais il peut quand même être peu fiable. Une récupération avec un faible écran de démarrage est donc nécessaire.
- Échec de la mise à jour d'un module du noyau
- Un plantage ou un redémarrage du démon en mode utilisateur
- Erreur d'empreinte digitale lors de l'exécution d'une sauvegarde. (Le service Backup and DR effectue une "vérification d'empreinte digitale" sur chaque tâche de sauvegarde pour détecter les erreurs.)
- Erreur lors de l'archivage, 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 l'archive.
- Basculement de 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 l'OS est une version non compatible.
- Si cbt_server ou AAMService sont arrêtés 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 AAMService n'est pas arrêté pendant très longtemps, le démarrage d'AAMService permettra de rendre les bitmaps disponibles pour une sauvegarde normale.
- Si cbt_server ou AAMService sont arrêtés pendant une durée suffisamment longue 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 est en mode "low-splash". Le temps nécessaire dépend de la quantité d'E/S de disque effectuée sur la base de données. Cela nécessite généralement des jours d'indisponibilité du service AAMService.
- L'arrêt non progressif de cbt_server ou d'AAMService peut rendre les bitmaps non fiables pour tous les bitmaps actuellement chargés. Les bitmaps sont chargés si le fichier suivi a été écrit au cours des 15 dernières minutes. En général, cela entraîne un faible éclaboussement pour une base de données très sollicitée.
- 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'est pas possible de savoir ce qui a été écrit dans le fichier pendant qu'il était démonté.