¿'Limpiar' un archivo de base de datos de SQL Server creado con la Inicialización instantánea de archivos habilitada?

8

Tengo la inicialización instantánea de archivos habilitada en nuestro servidor SQL, por lo que la parte 'vacía' del archivo de base de datos no se pone a cero antes de ser asignada. Entiendo que esto significa que el archivo podría contener datos 'eliminados'.

Así que ahora quiero enviar una copia de una base de datos (probablemente un archivo de respaldo) fuera de la empresa. Pero hay todos esos datos 'eliminados' potencialmente confidenciales dentro del archivo. Ahora me gustaría poner a cero la parte no utilizada del archivo.

¿Es eso posible? Me imagino que podría crear una nueva base de datos y copiar todo, o tal vez restaurar una copia de la base de datos a otro servidor sin la Inicialización instantánea de archivos habilitada y luego ser agresivo con un comando ShrinkFile para eliminar la mayor parte o la totalidad de la parte no utilizada del archivo de base de datos , pero ¿hay un método menos manual y lento? Idealmente, un comando para indicarle a SQL que ponga a cero el archivo como lo habría hecho si la Inicialización instantánea de archivos no estuviera habilitada.

sql-server sql-server-2008-r2 PaulH
fuente
Para referencia general, la inicialización de archivos de datos instantáneos se puede deshabilitar temporalmente sin perder el tiempo con los permisos de la cuenta de servicio mediante el uso de la marca de seguimiento 1806 como Paul Randal escribió en su blog aquí .
Jon Seigel

Respuestas:

5

Una COPIA DE SEGURIDAD de SQL Server solo realiza copias de seguridad de las extensiones que se utilizan para almacenar datos. La copia de seguridad deja atrás las extensiones no utilizadas . Cuando se utiliza una página para datos, se formateará para su uso según sea necesario, de modo que esa página esté libre de datos antiguos.

Por lo tanto, todo lo que debe hacer es hacer una copia de seguridad de la base de datos y restaurarla en otro lugar. Los archivos restaurados serán del mismo tamaño que la base de datos original, pero las extensiones no utilizadas se crearán utilizando las capacidades del servidor de destino. Esto puede inicializarse total o instantáneamente usando los bloques de disco en el servidor de destino.

Sin embargo, debido a que las extensiones son el nivel en el que se realizan las copias de seguridad, las páginas no utilizadas en la extensión aún podrían tener el potencial de exponer algunos datos cuando se restauran en otro servidor. No tanto como podría estar expuesto en el servidor de origen, ya que las extensiones no utilizadas no se restauran.

RLF
fuente
1
Extensiones no utilizadas en realidad. Teóricamente, incluso algunas de las extensiones utilizadas aún pueden contener espacio con 'datos antiguos', lo que no tiene sentido para SQLServer, pero podría ser un tesoro para un competidor armado con un editor hexadecimal y mucho tiempo libre. Sin embargo, si sus datos son tan confidenciales, ¿no estaría poniendo a cero todos los archivos de todos modos?
John Alan
@JohnAlan: modificado para reconocer la exposición dentro de los límites.
RLF
Los datos no son exactamente cosas de GCHQ: son solo datos básicos de los clientes y similares, por lo que es poco probable que alguien haga demasiado esfuerzo para recuperarlos. No me había dado cuenta de que las copias de seguridad funcionaban así, aunque tiene sentido que así sea. Si no hay otra solución rápida y sencilla, probablemente sea suficiente.
Paul
1

¿Ha considerado restaurar una copia de él, habilitar TDE que lo forzará a 0 y luego deshabilitar TDE nuevamente? No he probado esto, pero creo que funcionará, aunque tendremos que probarlo.

Algo más también, ¿ha considerado restaurar una copia de él con IFI deshabilitado, crear un nuevo grupo de archivos con nuevos archivos, prescribirlo, reconstruir el clúster y otros índices en el nuevo grupo de archivos, y luego soltar el grupo de archivos existente (si es el grupo de archivos principal) tendrás que reducirlo ya que no puedes soltar el primario)

Ali Razeghi
fuente
Usar TDE parece un enfoque interesante, aunque no estoy seguro de si eliminará más datos no deseados que el método de copia de seguridad y restauración. Si alguien sabe más información sobre eso, entonces me interesaría saberlo.
Paul