DIFF promocionados a FULL

Nov 06 2020

Usamos el DatabaseBackupprocedimiento almacenado de Ola Hallengren para hacer una copia de seguridad de una carga de bases de datos de SharePoint en una instancia de SQL Server 2012 en Azure Blob Storage. Hemos estado haciendo esto durante bastante tiempo sin ningún problema. Sin embargo, durante las últimas 6 semanas, nos DIFFsestán promoviendo aleatoriamente FULLy no podemos averiguar por qué.

Este es el resultado del paso del agente

BACKUP DATABASE [Database] TO URL = N'https://strorgage.blob.core.windows.net/server/instance/Database/2020/11/diff/Database_FULL_20201105_200000.bak' 
WITH NO_CHECKSUM, COMPRESSION, CREDENTIAL = N'*storeageaccountname*'

Si echa un vistazo a la URL generada, notará que los procedimientos se están almacenando en el directorio DIFF, pero creando un archivo de respaldo COMPLETO.

https://strorgage.blob.core.windows.net/server/instance/Database/2020/11/diff/Database_FULL_20201105_200000.bak
                                                                        --^           --^

DatabaseBackup (Ola proc) es del 14-06-2019, por lo que necesita una actualización para ser justo, pero ha funcionado bien durante más de 18 meses.

No llamamos al código de Ola directamente ya que tenemos un pequeño procedimiento contenedor que crea el nombre de la ruta virtual para Azure, pero básicamente así es como llamamos al código de Ola.

Este es un problema en el que, por alguna razón desconocida, las copias de seguridad DIFF se están promocionando a COMPLETO, esto provoca petabytes de copias de seguridad de blob de Azure en lugar de gigabytes, cada día.

EXECUTE dbo.DatabaseBackup
    @Database = @DatabaseName,
    @URL = @BackupPath,
    @Credential = @StorageAccount,
    @BackupType = @backupType,
    @Compress = @Compression,
    @LogToTable = 'Y',
    @ChangeBackupType = 'Y',
    @Updateability = @DatabaseReadOnlyState,
    @DirectoryStructure = NULL,
    @AvailabilityGroupDirectoryStructure = NULL

¿Tiene alguna idea sobre eso?

Respuestas

6 alroc Nov 09 2020 at 23:00

Dice que esta promoción de copias de seguridad DIFF a FULL es "aleatoria", pero apuesto a que puede encontrar una conexión entre esta actividad y la rotación de datos (o mantenimiento del índice) en la base de datos misma.

Debido a que está utilizando ChangeBackupType='Y', el trabajo de copia de seguridad busca en sys.dm_db_file_space_usage para ver qué parte de la base de datos se ha cambiado y realiza una copia de seguridad COMPLETA si supera un umbral (tengo dificultades para distinguir el umbral predeterminado del código fuente ). Puede cambiar ese umbral ajustando el ModificationLevelparámetro, que es un porcentaje. De la documentación

ModificationLevel
Especifique un porcentaje cuando una copia de seguridad diferencial se cambiará a una copia de seguridad completa. Esta opción solo se puede usar junto con @ChangeBackupType = 'Y'. DatabaseBackup comprueba la cuenta de página de extensión asignada y la cuenta de página de extensión modificada en sys.dm_db_file_space_usage para calcular la cantidad de una base de datos que se ha modificado.

3 JohnK.N. Nov 10 2020 at 00:32

Introducción

Al observar su código, parece que ya está utilizando el @ChangeBackupTypeparámetro Ola proporcionado en su Solución de mantenimiento de SQL Server para el procedimiento almacenado DatabaseBackup . La documentación de este parámetro proporciona la siguiente información:

DatabaseBackup cheques differential_base_lsnen sys.master_filespara determinar si una copia de seguridad diferencial se puede realizar. Si no es posible realizar una copia de seguridad diferencial, la base de datos se omite de forma predeterminada. Alternativamente, puede establecer ChangeBackupType en Y para que se realice una copia de seguridad completa en su lugar.

relevante ... y ...

DatabaseBackup cheques last_log_backup_lsnen sys.database_recovery_statuspara determinar si una copia de seguridad de registro de transacciones en el modelo de recuperación completa o de registro masivo se puede realizar. Si no es posible realizar una copia de seguridad del registro de transacciones, la base de datos se omite de forma predeterminada. Alternativamente, puede establecer ChangeBackupType en Y para que se realice una copia de seguridad diferencial o completa en su lugar.

Irrelevante

Referencia: DatabaseBackup (ola.hallengren.com)

Suposición

Al ver que está utilizando el parámetro en cuestión y asumiendo que todas sus bases de datos se están ejecutando en el modelo de recuperación COMPLETA, esperaría que los scripts de Ola hagan lo que se les dijo y solo realicen una copia de seguridad diferencial, como lo estaba observando anteriormente ... ..

sin embargo

... algo está alterando las bases de datos de SharePoint de tal manera, que el procedimiento de Ola asume que la base de datos requiere una copia de seguridad COMPLETA. Ola comprueba varias situaciones, una de las cuales se basa en el parámetro ....

Nivel de modificación

Existe el parámetro adicional @ModificationLevelque convertiría una copia de seguridad DIFF en una copia de seguridad COMPLETA si se establece el primer parámetro @ChangeBackupType = 'Y'. Mirar el código de Ola nos proporciona esto:

  IF @ModificationLevel IS NOT NULL AND @BackupType <> 'DIFF'
  BEGIN
    INSERT INTO @Errors ([Message], Severity, [State])
    SELECT 'The value for the parameter @ModificationLevel is not supported.', 16, 3
  END

Eso significa que si el parámetro @ModifcationLevelse establece en un valor y @ChangeBackupTypese establece en Y, entonces el procedimiento de copia de seguridad convertirá la copia de seguridad DIFF en una copia de seguridad COMPLETA. Si la cantidad de páginas cambiadas activa el caso .

Debido a que no lo ha configurado @ModificationLevel, permanece NULLcomo se puede ver en el código de Ola:

@ModificationLevel int = NULL,

Este no parece ser el caso en su situación, a menos que, por supuesto, el valor de su parámetro para @ModificationLevelno lo sea NULL.

Solución 1

En cuyo caso, hemos encontrado al culpable. Cambie el valor para @ModificationLevelvolver a NULLy todo está bien.

Otras razones para la conversión

Otra razón por la que la copia de seguridad cambiaría de DIFFa FULLes el parámetro en @ChangeBackupTypesí.

La descripción (de arriba) se escribió como:

DatabaseBackup (el procedimiento) cheques differential_base_lsnen sys.master_filespara determinar si una copia de seguridad diferencial se puede realizar. Si no es posible realizar una copia de seguridad diferencial, la base de datos se omite de forma predeterminada. Alternativamente, puede establecer ChangeBackupType en Y para que se realice una copia de seguridad completa en su lugar.

Comprobación del código

Ola escribió esto en el código:

SELECT @CurrentDifferentialBaseLSN = differential_base_lsn
FROM sys.master_files
WHERE database_id = DB_ID(@CurrentDatabaseName)
AND [type] = 0
AND [file_id] = 1

y esta parte aquí:

   IF @CurrentBackupType = 'DIFF'
    BEGIN
      SELECT @CurrentDifferentialBaseIsSnapshot = is_snapshot
      FROM msdb.dbo.backupset
      WHERE database_name = @CurrentDatabaseName
      AND [type] = 'D'
      AND checkpoint_lsn = @CurrentDifferentialBaseLSN
    END

    IF @ChangeBackupType = 'Y'
    BEGIN
      IF @CurrentBackupType = 'DIFF' AND @CurrentDifferentialBaseIsSnapshot = 1
      BEGIN
        SET @CurrentBackupType = 'FULL'
      END
    END;

¿Qué significa esto?

Traduciendo el código de Ola

Bueno, se lee un poco así:

  1. Obtener el valor de differntial_base_lsnpara la base de datos actual

  2. Si el tipo de copia de seguridad es DIFF, entonces ...

    • Lea la is_snapshotcolumna de la msdb.dbo.backupsettabla para la base de datos actual con @CurrentDifferentialBaseLSNy la copia de seguridad typees D(Copia de seguridad de la base de datos)
    • Si
      • @ChanageBackupType is Y` y
      • @CurrentBackupType es `DIFF y
      • @CurrentDifferentialBaseIsSnapshot es 1
    • Entonces
      • Establecer @CurrentBackupTypeenFULL

Aquí tienes una posible situación ...

Solucion 2

... si su base de datos fue respaldada por una solución de terceros (CommVault, NetApp, et. al.), entonces la solución de terceros habrá creado una copia de respaldo de base de datos válida y consistente utilizando el servicio SQL Server VSS Writer, que anotará en el msdb.dbo.backupsetque se tomó una copia instantánea de la base de datos, que establece el is_snapshotparámetro para esa base de datos para el dado en el differntial_base_lsnque se basaría su DIFF.

Debido a esto, la copia de seguridad DIFF que está tratando de realizar ya no puede basarse en la is_snapshotcopia de seguridad y debe crear una nueva copia de seguridad COMPLETA nuevamente, para restablecer is_snapshotel differntial_base_lsnvalor y y para crear una nueva base para futuras copias de seguridad DIFF.

Encuentra la otra copia de seguridad

Tendrá que determinar qué tercero (u otra solución de respaldob) se está entrometiendo con su solución implementada y asegurarse de que sean ...

  1. modificado para coexistir
  2. minimizado a una solución de respaldo.