¿Qué es una copia de seguridad con poco ruido?
En circunstancias normales, el servicio Backup y DR tarda en hacer una copia de seguridad inicial completa de una base de datos, y luego todas las copias de seguridad posteriores son incrementales y mucho más rápidas. Una copia de seguridad incremental compara los mapas de bits de la captura actual y la anterior, y solo aplica los cambios incrementales.
Una copia de seguridad con pocos errores es un tipo especial de tarea de copia de seguridad que se produce cuando se produce algún error del sistema en la tarea de copia de seguridad anterior, lo que provoca que la imagen de mapa de bits no sea fiable o que no se pueda leer. El servicio que lee el mapa de bits es cbt_server en un entorno Linux y AAMService en un entorno Windows.
Las copias de seguridad con pocos picos de actividad consumen más tiempo que las que se hacen en condiciones normales, ya que deben realizar una ingestión completa de nuevo para recrear un mapa de bits fiable. De esta forma, puede aplicar los cambios incrementales sin tener que sustituir la imagen completa.
Elementos que no provocan copias de seguridad con poca luz
- Actualizaciones de conectores
- Reinicio del sistema sin interrupciones
- Reinicios controlados de cbt_server o AAMService, suponiendo que el servicio siga ejecutándose en el momento de la copia de seguridad
- Conmutaciones por error que no han experimentado los errores que provocan mapas de bits poco fiables.
Causas de los mapas de bits no fiables
Se produce un mapa de bits poco fiable cuando algo interrumpe el trabajo de copia de seguridad, como lo siguiente:
- El host se ha apagado de forma incorrecta.
- Un cierre no correcto provoca un error de baja resolución debido a la falta de fiabilidad de los mapas de bits. Esto incluye desenchufar una máquina física o cualquier otro método para apagar Windows sin completar el proceso de apagado correctamente o si se produce un error de pantalla azul. Esto ocurre aunque una máquina de un clúster sufra un error de pantalla azul que active la conmutación por error, ya que el mapa de bits de la máquina que ha fallado no es fiable.
- Si todos los servidores Windows de un clúster que han alojado la base de datos desde la copia de seguridad anterior no están disponibles y no ejecutan servicios de Actifio. Extraemos mapas de bits de cada host del clúster que ha alojado la base de datos desde la copia de seguridad anterior para buscar cambios. Si no tenemos todos los mapas de bits, tenemos que ejecutar low-splash para mantener la integridad de los datos. Ten en cuenta que, si un host de clúster que alojaba una base de datos sufre un error BSOD, el mapa de bits podría estar disponible en la copia de seguridad, pero seguiría siendo poco fiable, por lo que se produciría un error de baja resolución.
- No se ha podido actualizar un módulo del kernel
- Un fallo o un reinicio en el daemon del modo de usuario
- Se ha producido un error con la huella digital al ejecutar una copia de seguridad. (El servicio de copias de seguridad y recuperación tras desastres realiza una "comprobación de huella digital" en cada trabajo de copia de seguridad para detectar errores).
- Error durante el cifrado si el disco de almacenamiento está lleno durante el apagado del SO y el sistema no puede escribir todos los datos en el archivo cifrado.
- Conmutación por error de un nodo de SAP HANA, lo que provoca que la copia de seguridad se redirija a otro nodo.
- La copia de seguridad se está ejecutando en modo degradado porque no se ha podido cargar el módulo del kernel. Esto suele ocurrir cuando el SO es una versión no compatible.
- Si cbt_server o AAMService se detienen durante la copia de seguridad, no se podrán obtener mapas de bits y el trabajo de copia de seguridad se ejecutará en modo de pantalla de inicio de baja resolución.
Si AAMService no está inactivo durante mucho tiempo, al iniciarlo, se podrán usar mapas de bits para crear una copia de seguridad normal.
- Si cbt_server o AAMService se detienen durante el tiempo suficiente para que el controlador ponga en cola algunos gigabytes de eventos, las imágenes de mapa de bits no se podrán volver a crear y la copia de seguridad estará en modo de salpicadura baja. El tiempo que se tarda en completar este proceso depende de la cantidad de operaciones de E/S de disco que se produzcan en la base de datos. Este proceso suele requerir días de inactividad del servicio AAM.
- Si cbt_server o AAMService se cierran de forma incorrecta, los mapas de bits pueden dejar de ser fiables para los mapas de bits cargados en ese momento. Los mapas de bits se cargan si el archivo monitorizado se ha escrito en los últimos 15 minutos, por lo que, en general, en una base de datos con mucha actividad, esto provocaría un bajo nivel de salpicaduras.
- Si se desmonta en el host un volumen que contiene un archivo monitorizado (por ejemplo, un archivo .mdf de SQL Server) y, a continuación, se vuelve a montar, los mapas de bits no serán fiables, ya que no hay forma de saber qué se ha escrito en el archivo mientras estaba desmontado.