Qu'est-ce qu'une sauvegarde à faible impact ?
Dans des conditions normales, le service de sauvegarde et de reprise après sinistre effectue une sauvegarde complète initiale d'une base de données, ce qui prend du temps. Toutes les sauvegardes suivantes sont ensuite 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 tâche de sauvegarde qui se produit lorsqu'une erreur système dans la tâche de sauvegarde précédente entraîne une image bitmap non fiable ou l'impossibilité de 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 sont plus longues que les sauvegardes effectuées dans des conditions normales, car elles doivent effectuer à nouveau une ingestion complète pour recréer une bitmap fiable. Il peut ensuite appliquer les modifications incrémentielles sans avoir à remplacer l'image complète.
Éléments qui ne provoquent pas de sauvegardes à faible impact
- Mises à niveau des connecteurs
- Redémarrages du système en douceur
- Redémarrages élégants de cbt_server ou d'AAMService en supposant que le service est toujours en cours d'exécution au moment de la sauvegarde
- Défaillances qui n'ont pas rencontré les erreurs qui provoquent des bitmaps peu fiables.
Causes de bitmaps peu fiables
Un bitmap non fiable se produit lorsqu'un élément interrompt la tâche de sauvegarde, y compris les éléments suivants:
- Arrêt non propre de l'hôte
- Un arrêt non correctif entraîne un faible splash en raison de l'instabilité des bitmaps. Cela inclut l'arrêt de l'alimentation d'une machine physique ou toute autre méthode d'arrêt de Windows sans passer par un arrêt correct 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 est peu 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 de services Actifio. Nous extrayons des bitmaps de chaque hôte de cluster qui hébergeait la base de données depuis la sauvegarde précédente pour détecter les modifications. Sans tous les bitmaps, nous devons exécuter une faible éclaboussure pour préserver l'intégrité des données. Notez que si un hôte de cluster qui héberge une base de données rencontre un écran bleu de la mort, le bitmap peut être disponible lors de la sauvegarde, mais il reste peu fiable, donc peu visible.
- Échec de la mise à jour du module du kernel
- Un plantage ou un redémarrage dans le daemon en mode utilisateur
- Erreur d'empreinte lors de l'exécution d'une sauvegarde. (Le service Backup and DR effectue une "vérification d'empreinte" sur chaque tâche de sauvegarde pour rechercher les erreurs.)
- Erreur lors de la mise en coffre si, lors de l'arrêt de l'OS, le disque de stockage est saturé et que le système ne peut pas écrire toutes les données dans le coffre.
- Basculement du nœud SAP HANA, ce qui entraîne la redirection de la sauvegarde vers un autre nœud.
- La sauvegarde s'exécute en mode dégradé, car il est impossible de charger le module du noyau. Cela se produit généralement lorsque le système d'exploitation est une version non prise en charge.
- Si cbt_server ou AAMService est arrêté pendant la sauvegarde, les bitmaps ne peuvent pas être récupérés et la tâche de sauvegarde s'exécute en mode faible éclaboussure.
Si AAMService n'est pas indisponible très longtemps, le démarrage d'AAMService permet de rendre les bitmaps disponibles pour une sauvegarde normale.
- Si cbt_server ou AAMService est arrêté suffisamment longtemps 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 faible éclaboussure. La durée de cette opération dépend du nombre d'E/S de disque sur la base de données. Cela nécessite généralement plusieurs jours d'indisponibilité d'AAMService.
- L'arrêt non correct du serveur cbt_server ou d'AAMService peut entraîner une perte de fiabilité des 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, pour une base de données active, cela entraîne un faible splash.
- Si un volume contenant un fichier suivi (par exemple, un fichier .mdf SQL Server) est désinstallé sur l'hôte, puis réinstallé, les bitmaps ne sont pas fiables, car il n'est pas possible de savoir ce qui a été écrit dans le fichier lorsqu'il était désinstallé.