una selecciono seguridad script restaurarlo restaurar restauracion respaldo puede porque para ningun log hay hacer existente ejecutar distinta datos copias copia contiene conjunto actual sql sql-server tsql sql-server-2012 backup

selecciono - script para hacer backup sql server



Copia de seguridad de una base de datos en un disco duro con un tamaƱo de sector diferente (6)

Este problema se debe a los diferentes tamaños de sector utilizados por diferentes unidades.

Puede solucionar este problema cambiando su comando de copia de seguridad original a:

BACKUP DATABASE MyDB TO DISK = N''D:/MyDB.bak'' WITH INIT , NOUNLOAD , NAME = N''MyDB backup'', STATS = 10, FORMAT

Tenga en cuenta que he cambiado NOFORMAT a FORMAT y he eliminado NOSKIP.

Se encontró una pista para resolver este problema en la sección de comentarios de la siguiente publicación del blog en MSDN: SQL Server – Espacios de almacenamiento / VHDx y Tamaño de sector 4K

Y más información sobre 4k unidades sectoriales: http://blogs.msdn.com/b/psssql/archive/2011/01/13/sql-server-new-drives-use-4k-sector-size.aspx

En nuestro entorno de desarrollo, durante mucho tiempo hemos estado utilizando un script de copia de seguridad y restauración particular para cada uno de nuestros productos a través de varias versiones de SQL Server y diferentes configuraciones de entorno sin problemas.

Recientemente, hemos actualizado a SQL Server 2012 como nuestro servidor de desarrollo estándar con el nivel de compatibilidad de SQL 2005 (90) para mantener el soporte con sistemas heredados. Ahora encontramos que en una máquina de un desarrollador en particular obtenemos el siguiente error al intentar hacer una copia de seguridad de la base de datos:

No se puede usar el archivo de copia de seguridad ''D: / MyDB.bak'' porque fue formateado originalmente con un tamaño de sector 512 y ahora está en un dispositivo con un tamaño de sector 4096. BACKUP DATABASE está terminando de manera anormal.

Con el comando siendo:

BACKUP DATABASE MyDB TO DISK = N''D:/MyDB.bak'' WITH INIT , NOUNLOAD , NAME = N''MyDB backup'', NOSKIP , STATS = 10, NOFORMAT

Lo curioso es que ni el hardware ni las particiones en la máquina de ese desarrollador han cambiado, aunque su tamaño de sector es diferente, esto no ha sido un problema anteriormente.

De mi investigación (es decir, googlear) no hay mucho sobre este tema aparte del consejo de usar la opción WITH BLOCKSIZE , pero eso me da el mismo mensaje de error.

Con mi consulta siendo:

BACKUP DATABASE MyDB TO DISK = N''D:/MyDB.bak'' WITH INIT , NOUNLOAD , NAME = N''MyDB backup'', NOSKIP , STATS = 10, NOFORMAT, BLOCKSIZE = 4096

¿Alguien puede aclarar cómo puedo hacer una copia de seguridad y restaurar una base de datos en discos duros con diferentes tamaños de sector?


Me encontré con el mismo problema que el OP. En una máquina dev, teníamos un script de PowerShell que hacía copias de seguridad de las bases de datos de servidores remotos y almacenaba los archivos de copia de seguridad localmente. La secuencia de comandos sobrescribió los mismos archivos de copia de seguridad, una y otra vez, y la secuencia de comandos funcionó bien durante un par de años. Luego cloné la unidad de medios giratorios en un SSD en la máquina dev. De repente, estábamos recibiendo el mismo error que el OP:

Backup-SqlDatabase: System.Data.SqlClient.SqlError: No se puede usar el archivo de copia de seguridad ''/ DevMachine / Back-Up / Demo.bak'' porque originalmente se le dio formato al tamaño de sector 4096 y ahora está en un dispositivo con el tamaño de sector 512.

Claro, podría eliminar todos los archivos .bak existentes para solucionar el problema. Pero ¿y si pasa, otra vez? Quería una solución de línea de comandos que funcionara consistentemente.

Aquí está nuestro código original:

Backup-SqlDatabase -ServerInstance "DBServer1" -Database "Demo" -BackupFile "//DevMachine/Back-Up/Demo.bak" -BackupAction Database -CopyOnly -CompressionOption On -ConnectionTimeout 0 -Initialize -Checksum -ErrorAction Stop

Después de algunos problemas, cambié a lo siguiente para solucionar el problema:

Backup-SqlDatabase -ServerInstance "DBServer1" -Database "Demo" -BackupFile "//DevMachine/Back-Up/Demo.bak" -BackupAction Database -CopyOnly -CompressionOption On -ConnectionTimeout 0 -Initialize -Checksum -FormatMedia -SkipTapeHeader -ErrorAction Stop

Básicamente, se agregaron las siguientes opciones para solucionar el problema:

-FormatMedia -SkipTapeHeader

Tenga en cuenta que si lee la documentación del cmdlet Backup-SqlDatabase , -FormatMedia aparece como que solo se aplica a las cintas y no a las copias de seguridad del disco. Sin embargo, parece que hace el trabajo de eliminar el archivo de copia de seguridad existente al realizar una copia de seguridad en el disco.
- https://docs.microsoft.com/en-us/powershell/module/sqlps/backup-sqldatabase

Descubrí que si utilizaba la opción -FormatMedia por sí misma, generaba el siguiente error:

Backup-SqlDatabase: las propiedades FormatMedia y SkipTapeHeader tienen configuraciones en conflicto.

-SkipTapeHeader el segundo error agregando una opción adicional: -SkipTapeHeader . Claramente eso también está destinado para copias de seguridad en cinta, pero funcionó.


Simplemente elimine el archivo .bak existente y vuelva a ejecutar.


Todo lo que tienes que hacer es respaldarlo con un nombre diferente.


Tuve el mismo problema, pero solo con restaurar . Recibí este error en Management studio: "La conversión especificada no es válida. (SqlManagerUI)" ... y este error en la consulta: "SQL Server no puede procesar esta familia de medios".

Luego hice una cosa simple: copié el conjunto de copia de seguridad en la carpeta de copia de seguridad predeterminada. Por ejemplo: C: / Archivos de programa / Microsoft SQL Server / MSSQL10_50.SQLEXPRESS2008R2 / MSSQL / Backup / bckup.bak Funcionó. Lo restauré desde este lugar. : -S parece que el SQL es sensible al tamaño del sector.


Tuvimos el mismo problema desde 2005 hasta 2008. El problema fue que intentamos utilizar el mismo archivo de copia de seguridad en 2008 que usamos en 2005 (adjuntando las copias de seguridad en 1 archivo).

Cambiamos la secuencia de comandos para hacer una copia de seguridad en un archivo diferente y el problema se resolvió. Me imagino que mover / borrar el archivo anterior tendría el mismo efecto