No se puede restaurar la base de datos habilitada para TDE cuando se utiliza MAXTRANSFERSIZE y CHECKSUM

Actualización : @AmitBanerjee - El Gerente Senior de Programas del Grupo de Productos de Microsoft SQL Server confirmó que MS analizará el problema ya que es un defecto.

¿Alguien ha tenido problemas para restaurar las copias de seguridad realizadas en SQL Server 2016 con TDE habilitado y usando MAXTRANSFERSIZE> 65536 (en mi caso, he elegido 65537 para poder comprimir la base de datos TDE ) y CHECKSUM?

A continuación hay una reproducción:

--- create database 
create database test_restore
go
-- create table
create table test_kin (fname char(10))
go
-- Enable TDE 

use master
GO
CREATE CERTIFICATE test_restore WITH SUBJECT = 'test_restore_cert'
GO
SELECT name, pvt_key_encryption_type_desc, * FROM sys.certificates WHERE name = 'test_restore'
GO
use test_restore
go
CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_128 ENCRYPTION BY SERVER CERTIFICATE test_restore
GO 
alter database test_restore set encryption ON

Tome copia de seguridad solo copia de seguridad ... hazlo dos veces

backup database test_restore 
to disk = 'D:\temporary-short-term\test_restore_KIN_test_restore_1.bak' -- change as per your location !!
with init, stats =10  -- overwrite ..using INIT !!
, maxtransfersize = 65537
, compression
,CHECKSUM

Ahora haz un verifyonly...

restore verifyonly from disk = 'D:\temporary-short-term\test_restore_KIN_test_restore_1.bak'

Mensaje de error :

Mensaje 3241, Nivel 16, Estado 40, Línea 11 La familia de medios en el dispositivo 'D: \ temporary-short-term \ test_restore_KIN_test_restore_1.bak' está formada incorrectamente. SQL Server no puede procesar esta familia de medios. Msg 3013, Nivel 16, Estado 1, Línea 11 VERIFICAR BASE DE DATOS está terminando anormalmente.

Resultados (1 = ON, 0 = OFF) con diferentes combinaciones:

+-------------------------+-------------+----------+--------+
| MAXTRANSFERSIZE (65537) | COMPRESSION | CHECKSUM | RESULT |
+-------------------------+-------------+----------+--------+
|                       1 |           1 |        1 | FAIL   |
|                       1 |           1 |        0 | PASS   |
|                       1 |           0 |        1 | FAIL   |
|                       0 |           0 |        0 | PASS   |
|                       0 |           1 |        1 | PASS   |
|                       0 |           1 |        0 | PASS   |
+-------------------------+-------------+----------+--------+

El problema ocurre en:

Microsoft SQL Server 2016 (RTM-CU1) (KB3164674) - 13.0.2149.0 (X64) 11 de julio de 2016 22:05:22 Copyright (c) Microsoft Corporation Enterprise Edition (64 bits) en Windows Server 2012 R2 Standard 6.3 (Build 9600 :)

Pude reproducir tu problema.

Agregando FORMATa laBACKUP comando lo resolvió para mí.

Si bien parece que no puedo encontrar documentación concreta, es mi opinión que esto está relacionado con el hecho de que INITretiene el encabezado de medios existente en el conjunto de copia de seguridad mientras FORMATcrea un nuevo encabezado de medios.

Todavía estoy investigando este problema y si encuentro información adicional, actualizaré esta respuesta.

Parece que esto podría haberse abordado con KB 4032200:

• REVISIÓN: no se puede comprimir el archivo de copia de seguridad cuando se usa la opción INIT y COMPRESSION en una base de datos habilitada para TDE en SQL Server 2016

De esa entrada:

Síntomas

Suponga que habilita el cifrado de datos transparente (TDE) para una base de datos en Microsoft SQL Server 2016. Intenta hacer una copia de seguridad de la base de datos utilizando la BACKUP DATABASEinstrucción T-SQL que tiene ambos COMPRESSIONyINIT opciones opción especificada. En este escenario, puede observar que el nuevo archivo de copia de seguridad sobrescribe el archivo de copia de seguridad existente y que el nuevo archivo de copia de seguridad no está comprimido.

Resolución

Este problema se soluciona en las siguientes actualizaciones acumulativas para SQL Server:

• Actualización acumulativa 7 para SQL Server 2016 RTM
• Actualización acumulativa 4 para SQL Server 2016 SP1

Esto podría parecer el mismo problema que la publicación de blog a la que hizo referencia en su pregunta se actualizó más tarde para referirse a:

Actualización 6 de abril de 2017

Recientemente hemos descubierto algunos problemas relacionados con el uso de TDE y la compresión de copia de seguridad en SQL Server 2016. Si bien los solucionamos, aquí hay algunos consejos para ayudarlo a evitar encontrarse con esos problemas conocidos:

• Actualmente no es aconsejable usar copias de seguridad segmentadas con TDE y compresión de copia de seguridad

• Si su base de datos tiene archivos de registro virtuales (VLF) de más de 4 GB, no utilice la compresión de respaldo con TDE para sus respaldos de registro. Si no sabe qué es un VLF, comience aquí .

• Evite usar WITH INIT por ahora cuando trabaje con TDE y compresión de respaldo. En cambio, por ahora puedes usar WITH FORMAT.

La ingeniería SQL está trabajando para solucionar estos problemas en SQL Server 2016. Actualizaremos esta publicación de blog una vez más una vez que tengamos más información para compartir.

A pesar de esa nota, la publicación del blog no se ha actualizado con más información desde entonces.

Sin embargo, KB 4019893 también puede abordar esto:

• REVISIÓN: la restauración falla cuando realiza una copia de seguridad utilizando compresión y suma de comprobación en una base de datos habilitada para TDE en SQL Server 2016

Aunque el mensaje de error informado en ese artículo de KB es diferente al que está informando, los factores contribuyentes suenan muy similares. SQL Server 2016 SP1 CU3 primero incluyó la corrección, como se ve en su lista de revisiones . Sin embargo, ha habido informes que no resolvió el problema en todas las situaciones.

SQL Server 2016 SP1 CU4 también incluye una solución (presumiblemente actualizada) para esto , y KB 4019893 desde entonces se ha actualizado para mostrar SP1 CU4 como la versión en la que se solucionó el problema.

Desafortunadamente, puedo confirmar por mi propia experiencia que incluso la solución en SP1 CU4 no resuelve completamente ese problema. Actualmente tengo una base de datos habilitada para TDE que todavía produce copias de seguridad constantemente corruptas incluso en SP1 CU4 cuando uso COMPRESSION(a través de MAXTRANSFERSIZE> 64 KB) y CHECKSUM. También tengo varias docenas de otras bases de datos habilitadas para TDE en este entorno que no siempre producen copias de seguridad corruptas en esas configuraciones, incluida una que es una variación de la que sí lo hace, con un esquema casi idéntico pero un conjunto de datos más pequeño. Esto parecería indicar que Microsoft está eliminando los escenarios que pueden causar esto, pero aún no los ha resuelto a todos.

Todavía no he intentado usar FORMATpara solucionar este problema, como se menciona en otra respuesta y en la publicación del blog SQLCAT , pero proporcionaré una actualización aquí si puedo intentarlo y resuelve el problema. La única base de datos que tengo que reproduce esto es desafortunadamente bastante grande (~ 1 TB), y reside en un clúster de Desarrollo / QA que no tiene mucho espacio de almacenamiento adicional disponible (al menos a esa escala), por lo que las variaciones de prueba de esto tienen demostrado ser logísticamente desafiante y lento.