¿Cómo restaurar una base de datos de SQL Server y reducir sus archivos al mismo tiempo?

Digamos que tengo una base de datos SQL Server cuyos archivos de datos se han creado con un tamaño inicial de 100 GB, pero solo contiene 10 GB de datos. Una copia de seguridad de la base de datos tendrá un tamaño de solo 10 GB.

Quiero restaurar esta copia de seguridad en un servidor diferente (o una base de datos diferente en el mismo servidor), pero no quiero que ocupe el mismo espacio en disco que el original (100 GB), que es lo que sucede de forma predeterminada.

No puedo reducir la base de datos original antes de tomar una copia de seguridad (es una base de datos de producción, y necesita tanto espacio previamente asignado); Me podría reducir la base de datos restaurada después de la restauración que se hace, pero realmente preferiría tenerlo no tome 100 GB, mientras que haciendo eso; Además, en este escenario específico no tengo mucho espacio libre en el disco, por lo que la restauración no va a ninguna parte.

¿Hay alguna manera de restaurar la base de datos y hacer que ocupe solo el espacio que contienen los datos reales que contiene ?

No, lo siento, de ninguna manera. Restaurar restaura los archivos como estaban en la copia de seguridad. Se debe realizar un enlace después de eso o antes de tomar la copia de seguridad.

Si tiene poco espacio en el disco, puede colocar el archivo .bak en un recurso compartido de red y restaurarlo desde allí. Debería funcionar si está ejecutando un servidor SQL con una cuenta de dominio y le da al recurso suficiente derechos para leer el archivo.

La otra opción que estaba anteriormente en la canasta de nueces (pero solo útil si está ejecutando sql server 2008 r2) es que SQL Server admite la creación de archivos de base de datos directamente a un recurso compartido sin tener que usar un indicador de seguimiento y puedo decir por experiencia personal que funciona! Para que pueda hacer una restauración CON MOVER a un recurso compartido.

En general, no. Algunas ideas aleatorias que pueden o no serle de ayuda:

• A menos que necesite absolutamente datos de esa copia de seguridad específica , puede crear una nueva base de datos (vacía) del tamaño de destino y usar copias masivas (o SSIS) para insertar todas las tablas de la base de datos actual (en vivo) en su copia.
• Existen herramientas de terceros (Redgate Compare, por ejemplo) que pueden ayudar a automatizar este tipo de cosas, si esto es más que una operación de una sola vez.
• Algunos software de respaldo de terceros (Quest Litespeed, por ejemplo) tienen la capacidad de realizar una " recuperación a nivel de objeto ", que puede restaurar tablas individuales u otros objetos en una nueva base de datos (vacía). Incluso si la copia de seguridad no se creó con Litespeed, creo que el producto debería funcionar en copias de seguridad SQL nativas.

Finalmente, también me gusta un poco de "espacio de codo" en mis bases de datos de producción, pero 90 GB sin 100 GB en total suena un poco extremo. Los siguientes pasos pueden darle lo que necesita y no deberían afectar la producción:

1. Ejecute a DBCC SHRINKFILE ('myfile.MDF', TRUNCATEONLY)en el archivo de datos de producción para liberar temporalmente cualquier espacio libre al final del archivo (un TRUNCATEONLY no requiere mucha IO y no fragmentará los índices)
2. Si el archivo de registro también es grande, ejecute un DBCC SHRINKFILEarchivo de registro de producción en un momento de baja actividad, justo después de realizar una copia de seguridad del registro.
3. Ejecute su copia de seguridad
4. Haga una ALTER DATABASE MODIFY FILEpara volver a crecer el archivo de datos de producción al tamaño original.

No debería haber ningún impacto en la producción con estos pasos. El único riesgo es si algunos de los datos se encuentran al final del archivo de datos de 100 gb, en cuyo caso el Paso (1) no liberará mucho espacio.