Responder a errores de restauración de SQL Server provocados por copias de seguridad dañadas

Actualizado: 17 de julio de 2006

Los errores de restauración ocurren si los medios de copia de seguridad están dañados. El sistema operativo puede informar de estos errores de restauración; las sumas de comprobación también pueden detectarlos. En ambos casos, tiene tres opciones:

• Resolver el error y reiniciar la operación de restauración.
• Dejar que la restauración continúe a pesar de los errores y reparar la base de datos cuando la restauración finalice.
• Abandonar la operación de restauración y utilizar un plan de recuperación alternativo que evite la copia de seguridad dañada.

[!NOTA] El conjunto de medios o de copia de seguridad debe contener un mínimo de información correcta para que sea interpretado como formato de cinta de Microsoft. Si no fuera así, RESTORE se detendría e indicaría que el formato de la copia de seguridad no es válido.

Resolver y reiniciar la operación de restauración

Los errores pueden solucionarse de las siguientes maneras:

• Si ocurre un error en un dispositivo de cinta, puede borrar o reemplazar la unidad de cinta.
• En dispositivos de disco, puede resolver el error del dispositivo y reemplazar el archivo dañado.
• Si se había creado un reflejo del conjunto de medios, puede reemplazar los medios dañados por los medios equivalentes de otro reflejo.

Continuar a pesar de los errores

Advertencia:
Si especifica WITH CONTINUE_AFTER_ERROR en una instrucción RESTORE se intenta restaurar la base de datos. Sin embargo, hay muchos tipos de daños que impiden recuperar una base de datos. Es muy recomendable que reserve la opción CONTINUE_AFTER_ERROR hasta que haya agotado todas las alternativas.

La opción CONTINUE_AFTER_ERROR hace que una operación de restauración continúe aunque surjan errores, restaurando lo que pueda. Tiene lugar una puesta al día y se pueden aplicar copias de seguridad posteriores del registro de transacciones. Si la puesta al día encuentra un error que le impide alcanzar un momento dado establecido, el error se indica en el registro. La base de datos se conecta en el punto de recuperación, si es posible. Sin embargo, si no se puede completar la recuperación, la base de datos se deja desconectada.

La cantidad de datos perdidos depende del error. Por ejemplo, una suma de comprobación errónea en una página sólo cuestiona la página; los medios siguen leyéndose y procesándose. Sin embargo, un error de E/S desde un dispositivo de cinta puede impedir que la restauración siga leyendo después del error, lo que impide que se siga restaurando el resto de la cinta.

Cuando se indica a una restauración que continúe después de los errores, las páginas que no pueden comprobarse se escriben en el disco y se registran en la tabla suspect_pages y en el registro de errores.

Recomendaciones:  después de utilizar WITH CONTINUE_AFTER_ERROR para restaurar datos, examine los registros de errores para obtener los detalles de los errores. Guarde y analice también todos los mensajes que reciba directamente de la instrucción RESTORE.

Para continuar a pesar de los errores

• La sintaxis de RESTORE básica es:
• RESTORE DATABASE database_name FROM backup_device WITH CONTINUE_AFTER_ERROR, [ NORECOVERY ]

Administrar la base de datos desconectada

Al finalizar una secuencia de restauración que continúa a pesar de los errores, es posible que pueda reparar la base de datos con DBCC CHECKDB. Para que CHECKDB se ejecute de una forma más coherente después de utilizar RESTORE CONTINUE_AFTER_ERROR, se recomienda utilizar la opción WITH TABLOCK en el comando DBCC CHECKDB. Para obtener más información, vea DBCC CHECKDB (Transact-SQL). Todas las opciones de reparación están disponibles. Para saber el nivel mínimo de reparación necesario, ejecute DBCC CHECKDB sin una opción de reparación. Tenga en cuenta que, en casos extremos, puede que no haya información suficiente para reparar la base de datos.

Para obtener acceso limitado a los datos tal como están, puede colocar la base de datos en modo de emergencia mediante la opción EMERGENCY del comando ALTER DATABASE.

Vea también

Conceptos

Descripción y administración de la tabla suspect_pages

Otros recursos

ALTER DATABASE (Transact-SQL)
BACKUP (Transact-SQL)
DBCC CHECKDB (Transact-SQL)
RESTORE (Transact-SQL)
RESTORE VERIFYONLY (Transact-SQL)

Ayuda e información

Obtener ayuda sobre SQL Server 2005

Historial de cambios

Versión	Historial
17 de julio de 2006	Contenido nuevo: Se agregaron una nota de precaución y recomendaciones a la sección "Continuar a pesar de los errores".