Compartir a través de

Aplicaciones de copia de seguridad de SQL Server: Servicio de instantáneas de volumen (VSS) y Escritor de SQL

Se aplica a:SQL Server: solo Windows

SQL Server proporciona compatibilidad con el Servicio de instantáneas de volumen (VSS) al proporcionar un escritor (el escritor de SQL) para que una aplicación de copia de seguridad de terceros pueda usar el marco de VSS para realizar copias de seguridad de archivos de base de datos. En este artículo se describe el componente del objeto de escritura de SQL y su rol en el proceso de creación y restauración de instantáneas de VSS para las bases de datos de SQL Server. En él también se incluyen detalles sobre cómo configurar y utilizar el objeto de escritura de SQL para trabajar con aplicaciones de copia de seguridad en el marco de VSS.

Infraestructura de VSS

VSS proporciona la infraestructura del sistema para ejecutar aplicaciones de VSS en sistemas Windows. Aunque es muy transparente tanto para el usuario como para el desarrollador, VSS:

  • Coordina las actividades de los proveedores, escritores y solicitantes en la creación y el uso de instantáneas.
  • Proporciona el proveedor predeterminado del sistema.
  • Implementa la funcionalidad de controlador de bajo nivel necesaria para que cualquier proveedor funcione.

El servicio VSS se inicia a petición, por lo que este servicio debe estar habilitado para que las operaciones de VSS se realicen correctamente.

Componentes de VSS

VSS coordina las actividades de los siguientes componentes cooperativos:

  • Los proveedores poseen los datos de instantáneas y crean instancias de las instantáneas.

  • Los escritores son aplicaciones que cambian datos y participan en el proceso de sincronización de instantáneas.

  • Los solicitantes inician la creación y destrucción de instantáneas. El diseño se centra en el escenario en el que el solicitante es una aplicación de copia de seguridad.

VSS proporciona coordinación entre estas entidades:

Diagrama que muestra cómo VSS proporciona coordinación entre las partes.

En este diagrama se muestran todos los componentes que participan en una actividad típica de copia instantánea de VSS. En este escenario, SQL Server (incluido el escritor de SQL) actúa como escritor en uno de los cuadros Escritor. Otros escritores de este tipo pueden ser Exchange Server, etc.

  • Interfaz de dispositivo virtual: SQL Server proporciona una interfaz de programación de aplicaciones denominada Interfaz de dispositivo virtual (VDI), que ayuda a los proveedores de software independientes a integrar SQL Server en sus productos proporcionando compatibilidad con las operaciones de copia de seguridad y restauración. Estas API están diseñadas para ofrecer una confiabilidad y rendimiento máximos, así como para ser compatibles con todas las funciones relativas a las copias de seguridad y restauración de SQL Server , incluidas todas las capacidades de copias de seguridad interactivas y de instantáneas. Para obtener más información, consulte Especificación de la interfaz de dispositivo de copia de seguridad virtual de SQL Server 2005.

  • Solicitante: un proceso, ya sea automatizado o GUI, que solicita que se tomen uno o más conjuntos de instantáneas de uno o más volúmenes originales. En este artículo, también se usa un solicitante para implicar una aplicación de copia de seguridad que crea una instantánea de las bases de datos de SQL Server.

Para obtener más información, consulte Servicio de instantáneas de volumen.

Escritor de SQL

El escritor de SQL es un escritor de VSS proporcionado por la instancia de SQL Server. Controla la interacción de VSS con SQL Server. El escritor de SQL se proporciona con SQL Server como un servicio independiente y se instala como parte de la instalación de SQL Server.

El papel del escritor de SQL en una operación de copia de seguridad de instantáneas de VSS.

Captura de pantalla de la instantánea de VSS.

Configuración del sistema de escritura de SQL

El servicio del objeto de escritura de SQL está instalado en el sistema como parte de la instalación de SQL Server y está configurado para iniciarse automáticamente al iniciar Windows.

Cuenta de servicio de escritura de SQL

Durante la instalación, la cuenta de escritor de SQL se configura para utilizar la cuenta del sistema local. Puesto que el objeto de escritura de SQL necesita comunicarse con SQL Server mediante API de VDI exclusivas, la cuenta del objeto de escritura de SQL debe tener derechos de acceso suficientes para SQL Server y VSS. La configuración del servicio como una cuenta de sistema local proporciona derechos suficientes para que el servicio se ejecute correctamente.

Importante

Asegúrese de que el servicio de escritura de SQL se ejecuta en la cuenta del sistema local y de que la cuenta de SQL Server NT SERVICE\SQLWriter es miembro del rol sysadmin .

Volver a habilitar e iniciar el sistema de escritura de SQL

De forma predeterminada, el servicio de escritura de SQL está habilitado e inicia automáticamente. Si se ha modificado esta configuración, se deben seguir los pasos siguientes para revertir a la configuración predeterminada:

El servicio de escritura de SQL se puede habilitar marcando este servicio como Automático. Para abrir los servicios a través del panel de control, seleccione Inicio, Panel de control, haga doble clic en Herramientas administrativas y, a continuación, haga doble clic en Servicios. En el panel Servicios , haga doble clic en el servicio de escritura de SQL y modifique la propiedad Tipo de inicio en Automático.

Después, el servicio debe iniciarse seleccionando el botón Iniciar en la propiedad Estado del servicio en la pantalla de propiedades del servicio mencionada anteriormente.

Nota:

En determinados casos en los que se instala una instancia de SQL Server Express y una aplicación usa la característica Instancias de usuario, SQL Writer podría iniciarse automáticamente mediante SQL Server. Esto se hace para facilitar la enumeración de estas instancias de usuario durante una operación de copia de seguridad de VSS.

Características compatibles con el escritor de SQL

  • Texto completo: el escritor de SQL notifica contenedores de catálogo de texto completo con especificaciones de archivo recursivas en los componentes de la base de datos del documento de metadatos del escritor. Se incluyen automáticamente en la copia de seguridad cuando se selecciona el componente de base de datos.

  • Copia de seguridad y restauración diferenciales: el escritor de SQL admite copias de seguridad diferenciales y restauración a través de dos mecanismos diferenciales de VSS:

    • Archivo parcial: el escritor de SQL usa el mecanismo archivo parcial de VSS para notificar intervalos de bytes modificados dentro de sus archivos de base de datos.

    • Archivo diferenciado por última modificación: El escritor de SQL utiliza el mecanismo de Archivo Diferenciado por Hora de Última Modificación de VSS para informar sobre archivos modificados en catálogos de texto completo.

  • Restauración con movimiento: el escritor de SQL admite la especificación New Target de VSS durante la restauración. La especificación New Target permite reubicar un archivo de base de datos o registro o un contenedor de catálogo de texto completo como parte de la operación de restauración.

  • Cambio de nombre de la base de datos: es posible que un solicitante necesite restaurar una base de datos de SQL Server con un nuevo nombre, especialmente si la base de datos se va a restaurar en paralelo con la base de datos original. El objeto de escritura de SQL permite cambiar el nombre de una base de datos durante la operación de restauración, siempre y cuando la base de datos permanezca dentro de la instancia original de SQL.

  • Copia de seguridad de solo copia: a veces es necesario realizar una copia de seguridad diseñada para un propósito especial, por ejemplo, cuando necesite realizar una copia de una base de datos con fines de prueba. Esta copia de seguridad no debe afectar a los procedimientos generales de copia de seguridad y restauración de la base de datos. El uso de la COPY_ONLY opción especifica que la copia de seguridad se realiza fuera de banda y no debe afectar a la secuencia normal de copias de seguridad. El escritor de SQL admite el tipo de copia de seguridad de solo copia con instancias de SQL Server.

  • Autorecuperación de la instantánea de base de datos: normalmente, una instantánea de una base de datos de SQL Server obtenida mediante el marco de VSS se encuentra en un estado no recuperado. No se puede acceder a los datos de la instantánea de forma segura antes de pasar por la fase de recuperación para revertir las transacciones en curso y colocar la base de datos en un estado coherente. Es posible que una aplicación de copia de seguridad de VSS solicite la recuperación automática de las instantáneas como parte del proceso de creación de instantáneas.

Estas nuevas características y su uso se describen con más detalle en Detalles de opciones de copia de seguridad y restauración en este artículo.

Qué no se admite

  • El escritor de SQL no admite las copias de seguridad de registros.
  • No se admite la copia de seguridad de archivos y grupos de archivos.
  • No se admite la restauración de páginas.
  • No se admiten las instantáneas de base de datos y se omiten al crear instantáneas de VSS de componente y no componentes.
  • Bases de datos cerradas automáticamente o bases de datos con el apagado habilitado.
  • Linux no proporciona un marco de VSS y, por tanto, el escritor de SQL no está disponible en Linux.

En la tabla siguiente se enumeran los tipos de copias de seguridad de instantáneas compatibles con el escritor de SQL o SQL Server que trabajan con el marco de VSS para todas las ediciones de SQL Server en Windows.

Operación de copia de seguridad y restauración Basada en componentes No basado en componentes
Copia de seguridad de datos completa
(Incluido el catálogo de texto completo)		 Sí Sí
Restauración completa Sí Sí
Restauración completa (sin recuperación) Sí No
Copia de seguridad diferencial Sí No
Restauración diferencial Sí No
Restauración con desplazamiento Sí No
Cambio de nombre de la base de datos Sí No
Copia de seguridad solo Sí No
Instantáneas recuperadas automáticamente Sí No
Copia de seguridad de registros No No
Instantáneas de base de datos No No
Bases de datos cerradas automáticamente
Bases de datos con apagado		 Sí No
Bases de datos del grupo de disponibilidad Sí No en la secundaria

Operaciones de copia de seguridad

SQL Server (mediante el sistema de escritura de SQL) admite los siguientes modos de operaciones de copia de seguridad basadas en VSS:

  • No basado en componentes
  • Basada en componentes

Soporte de versiones

El objeto de escritura de SQL se incluye como parte de SQL Server y solo admite instancias de SQL Server. El escritor de SQL enumera también instancias de SQL Server Express, incluidas las instancias de usuario iniciadas por SQL Server Express Edition.

Operaciones de copia de seguridad no basadas en componentes

Las copias de seguridad no basadas en componentes seleccionan implícitamente las bases de datos mediante la lista de volúmenes del conjunto de instantáneas. El objeto de escritura de SQL busca bases de datos incompletas y, si encuentra alguna, genera un error. Una base de datos dividida es aquella en la que se selecciona un subconjunto de archivos mediante la lista de volúmenes.

En el modelo no basado en componentes, solo se admiten las bases de datos con el modelo de recuperación simple. No se admite la puesta al día después de que no se admita una restauración.

Operaciones de copia de seguridad basadas en componentes

Las copias de seguridad basadas en componentes son preferidas y recomendadas con el escritor de SQL, ya que la aplicación (aplicación de copia de seguridad de VSS) selecciona explícitamente las bases de datos de los metadatos que se devuelven del escritor de SQL. El conjunto de instantáneas debe incluir todos los volúmenes necesarios para hacer una copia de seguridad de esas bases de datos. La infraestructura de VSS no agrega automáticamente los volúmenes necesarios para el conjunto seleccionado de bases de datos. Todos los volúmenes de respaldo deben incluirse en el conjunto de instantáneas de volumen. Es responsabilidad de la aplicación de copia de seguridad asegurar que todos los volúmenes de copia de seguridad estén incluidos en el conjunto de instantáneas. El escritor de SQL detecta bases de datos rasgadas (con volúmenes de respaldo fuera del conjunto de instantáneas) y produce un error en la copia de seguridad.

En el resto de esta sección se supone que las copias de seguridad basadas en componentes se usan como parte del proceso de creación de instantáneas de VSS para SQL Server.

Proceso de creación de instantáneas

El marco de VSS coordina las actividades de un solicitante (una aplicación de copia de seguridad) y el escritor de SQL durante la creación de instantáneas de SQL Server. Para habilitar esta coordinación, el marco de VSS define interfaces de solicitante y escritor. Estas interfaces deben ser implementadas por aplicaciones solicitantes participantes y autores. El escritor de SQL implementa las interfaces de escritura necesarias. Como parte del proceso de creación de instantáneas, el marco de VSS llama a las interfaces del escritor de SQL. El objeto de escritura de SQL interactúa con las instancias de SQL Server en el sistema para facilitar la creación de instantáneas.

El marco de VSS define un conjunto de API para su uso por parte de una aplicación solicitante o de copia de seguridad. Un desarrollador de aplicaciones de copia de seguridad debe seguir estos patrones de llamada de API para trabajar con el proceso de creación de instantáneas de marco de VSS. En las secciones siguientes se describe el proceso de creación de instantáneas desde el punto de vista del objeto de escritura de SQL. También detallan algunas de las interacciones internas entre el solicitante, el marco de VSS, el objeto de escritura de SQL y las instancias de SQL Server.

Para obtener más información sobre estos pasos y para obtener más información sobre las interfaces del marco de VSS, consulte Servicio de instantáneas de volumen (VSS).

Nota:

Se supone que está familiarizado con el marco de VSS y el proceso de creación de copias de seguridad en general. Estas secciones se proporcionan como información adicional sobre la participación del escritor de SQL en el proceso de generación de copias de seguridad de VSS.

Flujo de trabajo de creación de instantáneas

En la imagen siguiente se muestra el diagrama de flujo de datos durante una operación de creación o copia de seguridad de instantáneas basada en componentes.

Captura de pantalla del flujo de datos.

Para comprender mejor las tareas básicas implicadas en la realización de una copia de seguridad, resulta útil desglosar esta información general en las siguientes fases:

Inicialización de la copia de seguridad

Durante esta fase de la copia de seguridad, el solicitante (aplicación de copia de seguridad) se enlaza a la interfaz IvssBackupComponentsde instantánea e lo inicializa como preparación para la copia de seguridad. También llama a la API de VSS IVssGatherWriterMetadata para indicar al marco de VSS que recopile los metadatos de todos los escritores.

El marco de VSS llama a cada uno de los escritores registrados, incluido el escritor de SQL, para los metadatos del escritor mediante el OnIdentify evento. El escritor de SQL consulta las instancias de SQL Server para obtener la información de metadatos de copia de seguridad de cada base de datos y crear el documento de metadatos del escritor. Esta fase también se conoce como enumeración de metadatos.

El documento de metadatos del escritor es un documento que contiene información que se pasa del escritor al solicitante (aplicación de copia de seguridad). El documento de metadatos del escritor contiene la siguiente información:

  • El identificador de la aplicación y el nombre amigable
  • Dónde existen archivos y componentes
  • Qué archivos deben incluirse y excluirse en una copia de seguridad
  • ¿Qué opciones se deben usar en el momento de la restauración?

Estos datos se devuelven al solicitante a través del marco de VSS.

Detección de copias de seguridad

En esta fase, un solicitante examina el documento de metadatos del escritor y crea y rellena un documento de componentes de copia de seguridad con cada componente del que se debe realizar una copia de seguridad. También especifica las opciones de copia de seguridad y los parámetros necesarios como parte de este documento. En el caso del objeto de escritura de SQL, cada instancia de base de datos de la que se debe hacer una copia de seguridad es un componente independiente.

Documento de componentes de copia de seguridad

Se trata de un documento XML creado por un solicitante mediante la interfaz IVssBackupComponents en el transcurso de la configuración de una operación de restauración o copia de seguridad. El documento de componentes de copia de seguridad contiene una lista de los componentes incluidos explícitamente, de uno o varios escritores, que participan en una operación de copia de seguridad o restauración. No contiene información de componente incluida implícitamente. Por el contrario, un documento de metadatos de escritor contiene solo componentes de escritor que pueden participar en una copia de seguridad. Los detalles estructurales de un documento de componentes de copias de seguridad se describen en la documentación de la API de VSS.

Tareas previas a la copia de seguridad

Las tareas de prebackup en VSS se centran en crear una instantánea de los volúmenes que contienen datos para la copia de seguridad. La aplicación de copia de seguridad guarda los datos de la copia en la sombra, no del volumen real.

Los solicitantes suelen esperar a los escritores durante la preparación de la copia de seguridad y mientras se crea la instantánea. Si el escritor de SQL participa en la operación de copia de seguridad, debe configurar sus archivos y también estar listo para la copia de seguridad y la instantánea.

Preparación para la copia de seguridad

El solicitante debe establecer el tipo de operación de copia de seguridad que debe realizarse (IVssBackupComponents::SetBackupState) y, a continuación, notifica a los escritores a través de VSS, para prepararse para una operación de copia de seguridad mediante IVssBackupComponents::PrepareForBackup.

El escritor de SQL tiene acceso al documento del componente de copia de seguridad, que detalla las bases de datos de las que se debe realizar una copia de seguridad. Todos los volúmenes de respaldo deben incluirse en el conjunto de instantáneas de volumen. El escritor de SQL detecta bases de datos rasgadas (con volúmenes de respaldo fuera del conjunto de instantáneas) y produce un error en la copia de seguridad durante el evento PostSnapshot.

Copia de seguridad real de archivos

En esta fase, el solicitante puede trasladar los datos a un medio de copia de seguridad, si es necesario. En esta fase las interacciones son entre el solicitante y el marco de VSS. El escritor de SQL no está implicado.

  1. Obtener el estado del escritor. Devuelve el estado de los escritores. Es posible que el solicitante tenga que controlar los errores aquí.
  2. Realice la copia de seguridad.

En este momento, el solicitante puede trasladar los datos a un medio de copia de seguridad, si es necesario.

Copia de seguridad completa

Este evento indica que la copia de seguridad se completó correctamente.

También es el momento en el que el escritor de SQL puede confirmar la copia de seguridad como base diferencial, si la copia de seguridad actual es una copia de seguridad completa de la base de datos (y no una copia de seguridad de solo copia).

Nota:

El solicitante debe enviar explícitamente este evento (evento de copia de seguridad completa) para permitir que el escritor de SQL confirme las copias de seguridad diferenciales base. Si no se recibe este evento, la copia de seguridad que se crea no es una copia de seguridad diferencial válida.

Guardar metadatos del escritor

El solicitante debe guardar el documento del componente de copia de seguridad y los metadatos de copia de seguridad de cada componente, junto con los datos extraídos de la instantánea. Estos metadatos de escritura son necesarios para las operaciones de restauración de SQL writer/SQL Server.

Finalización de la copia de seguridad

El solicitante finaliza la instantánea liberando la IVssBackupComponents interfaz o llamando a IVssBackupComponents::DeleteSnapshots.

Documento de metadatos del escritor de SQL

Se trata de un documento XML creado por un escritor (el escritor de SQL en este caso) mediante la interfaz IVssCreateWriterMetadata y que contiene información sobre el estado y los componentes del escritor. Los detalles estructurales de un documento de metadatos de escritor se describen en la documentación de la API de VSS. Estos son algunos de los detalles del documento de metadatos del escritor de SQL.

  • Información de identificación del escritor

    • Nombre del escritor: L"SqlServerWriter"
    • Id. de clase del escritor: 0xa65faa63, 0x5ea8, 0x4ebc, 0x9d, 0xbd, 0xa0, 0xc4, 0xdb, 0x26, 0x91 y 0x2a
    • Id. de instancia del escritor: L"SQL Server:SQLWriter"
    • VSSUsageType: VSS_UT_USERDATA
    • VSSSourceType: VSS_ST_TRANSACTEDDB

  • Información de nivel de escritor: VSS_APP_BACK_END

  • VSS_RME_RESTORE_IF_CAN_REPLACE de especificación – del método restore.

  • Esquema de copia de seguridad admitido (IVssCreateWriterMetadata::SetBackupSchema API)

    • VSS_BS_DIFFERENTIAL: copia de seguridad diferencial
    • VSS_BS_TIMESTAMPED marca de – tiempo basada – en archivos de catálogo de texto completo.
    • VSS_BS_LAST_MODIFY: copia de seguridad diferencial según la hora de la última modificación.
    • VSS_BS_WRITER_SUPPORTS_NEW_TARGET: admite la opción de una nueva ubicación de destino.
    • – VSS_BS_WRITER_SUPPORTS_RESTORE_WITH_MOVE admite la restauración "con movimiento"
    • VSS_BS_COPY: admite la opción de copia de seguridad de "solo copia".

  • Información de nivel de componente (contiene información específica del nivel de componente proporcionada por el escritor de SQL)

    • Tipo: VSS_CT_FILEGROUP.
    • Nombre: nombre del componente (nombre de la base de datos).
    • Ruta de acceso lógica: de la instancia del servidor (en forma de "server\instance-name" para instancias con nombre y "servidor" para la instancia predeterminada).
    • Marcas de componentes
    • VSS_CF_APP_ROLLBACK_RECOVERY: indica que las instantáneas de SQL Server siempre requieren una fase de "recuperación" para que los archivos sean coherentes y se puedan utilizar en escenarios que no sean de copia de seguridad (es decir, escenario de reversión de aplicaciones).
    • Seleccionable: True
    • Se puede seleccionar para restauración: true.
    • Métodos de restauración admitidos: VSS_RME_RESTORE_IF_CAN_REPLACE

La única extensión de la estructura del conjunto de componentes en SQL Server es la introducción de los catálogos de texto completo. Los catálogos de texto completo son directorios de contenedor, que no se pueden expresar como archivos de registro o base de datos de VSS, dado que la base de datos de VSS y los archivos de registro no tienen especificación recursiva. Por lo tanto, el escritor de SQL utiliza un componente de grupo de archivos VSS (VSS_CT_FILEGROUP) para representar el componente de nivel de base de datos y los archivos de grupo de archivos para representar los archivos de base de datos, registro y catálogo de texto completo.

Se proporciona un documento de ejemplo de metadatos del escritor al final de este documento.

Iniciar instantánea

El solicitante inicia el proceso de instantánea llamando a la interfaz del marco de VSSDoSnapshotSet.

Creación de instantáneas

Esta fase implica una serie de interacciones entre el marco de VSS y el escritor de SQL.

  1. Preparación para tomar la instantánea: El escritor de SQL llama a SQL Server para prepararse para la creación de instantáneas.

  2. Inmovilizar. El escritor de SQL llama a SQL Server para inmovilizar todas las E/S de base de datos para cada una de las bases de datos de las que se realiza una copia de seguridad en la instantánea. Una vez que el evento de inmovilización vuelve al marco de VSS, VSS crea la instantánea.

  3. Reanudación. En este evento, el escritor de SQL llama a las instancias de SQL Server para descongelar o reanudar las operaciones de E/S normales.

La fase de creación de instantáneas tarda menos de 60 segundos en evitar el bloqueo de todas las escrituras en la base de datos.

Posterior a la instantánea

Si se necesita recuperación automática para la instantánea, el escritor de SQL realiza la recuperación automática para cada base de datos que ha sido seleccionada para estar en la instantánea. Para obtener una explicación detallada, consulte Instantáneas recuperadas automáticamente.

Proceso de restauración

En esta sección se describe el flujo de trabajo de la operación de restauración y varios de los pasos implicados.

Flujo de trabajo de la operación de restauración

En la siguiente ilustración se muestra el diagrama de flujo de datos durante una operación de restauración de VSS.

Captura de pantalla del flujo de proceso de restauración.

Para comprender mejor las tareas básicas implicadas en la realización de una restauración, resulta útil desglosar esta información general en las secciones siguientes:

En todos los escenarios de restauración basados en componentes de VSS, el objeto de escritura de SQL controla la restauración de bases de datos en dos fases distintas.

  • Restauración previa: el escritor de SQL controla la validación, el cierre de identificadores de archivo, etc.
  • Posterior a la restauración: el escritor de SQL adjunta la base de datos y realiza la recuperación de bloqueos si es necesario.

Entre estas dos fases, la aplicación de copia de seguridad es responsable de mover los datos pertinentes dentro de SQL.

Restauración de la inicialización

Durante la fase de inicialización de una restauración, el solicitante debe tener acceso a los documentos de componentes de copia de seguridad almacenados.

El documento del componente de copia de seguridad que se genera durante la operación de copia de seguridad, se almacena como parte de los datos de copia de seguridad. La aplicación de copia de seguridad debe devolver estos datos al marco de VSS. El escritor de SQL obtiene acceso a estos datos al principio del proceso de restauración.

Preparación para la restauración

Cuando el solicitante se prepara para una restauración, usa el documento de componentes de copia de seguridad almacenados para determinar qué se va a restaurar y cómo. El solicitante selecciona los componentes que se van a restaurar y establece las opciones de restauración adecuadas según sea necesario.

Si una aplicación de copia de seguridad pretende aplicar copias de seguridad diferenciales o de registro sobre la operación de restauración actual (es decir, se necesita restaurar sin recuperación), se debe establecer la siguiente opción como parte de la creación de componentes de cada base de datos que se está restaurando.

IVssBackupComponents::SetAdditionalRestores(true)

Una vez que se establecen todos los detalles necesarios en el documento del componente de copia de seguridad, el solicitante realiza la IVssBackupComponents::PreRestore llamada para generar un evento de restauración previa a través de VSS que administran los escritores.

El escritor de SQL examina el documento del componente de copia de seguridad proporcionado para identificar las bases de datos adecuadas, eliminando los archivos adicionales creados desde el tiempo de copia de seguridad. También comprueba los espacios en disco y cierra los identificadores de archivos de las bases de datos abiertas para que el solicitante pueda copiar los datos necesarios durante la fase de restauración. Esta fase permite detectar cualquier condición de error temprana antes de que el solicitante haga la propia copia de los archivos. SQL Server también coloca la base de datos en estado de restauración. Desde este punto, la base de datos no se puede iniciar hasta una restauración exitosa.

Restauración de archivos

Se trata únicamente de una acción específica del solicitante. Es responsabilidad del solicitante (aplicación de copia de seguridad) copiar los archivos de base de datos necesarios (o copiar intervalos de datos pertinentes para restauraciones diferenciales) en los lugares adecuados. El escritor de SQL no está implicado en esta operación.

Limpieza y finalización

Una vez que se restauran todos los datos en los lugares correctos, una llamada desde un solicitante que notifica que se ha completado IvssBackupComponents::PostRestorela operación de restauración, permite al escritor de SQL saber que se pueden iniciar acciones posteriores a la restauración. El escritor de SQL en este momento realiza la fase de puesta al día de la recuperación de bloqueos. Si no se solicita la recuperación (es decir, SetAdditionalRestores(true) no se especifica en el solicitante), la fase de deshacer del paso de recuperación también se lleva a cabo durante esta fase.

Detalles de la opción de copia de seguridad y restauración

En esta sección se describen detalladamente todas las opciones de copia de seguridad y restauración admitidas por el escritor de SQL.

El solicitante crea una instantánea de volumen

El escritor de SQL podría estar implicado en el proceso de creación de instantáneas de volumen (fuera del contexto de copia de seguridad y restauración), ya que los volúmenes de respaldo de los archivos de base de datos se han agregado al conjunto de instantáneas de volumen. En este caso, el escritor de SQL solo participa en la enumeración de metadatos, Freeze, Thaw, PrepareForSnapshoty PostSnapshot la coordinación (consulte el diagrama de flujo de datos para obtener más información).

Copia de seguridad y restauración completas

El escritor de SQL admite operaciones completas de copia de seguridad y restauración en modo no basado en componentes y en modo basado en componentes.

Copia de seguridad y restauración no basadas en componentes

En una copia de seguridad y restauración no basada en componentes, el solicitante especifica un volumen o un árbol de carpetas de los que se va a realizar una copia de seguridad y restauración. Se hace una copia de seguridad y restauración de todos los datos del volumen y la carpeta especificados.

Copia de seguridad

En una copia de seguridad no basada en componentes, el escritor de SQL selecciona implícitamente las bases de datos mediante la lista de volúmenes del conjunto de instantáneas. El escritor comprueba si hay bases de datos rasgadas, lo que genera un error si se encuentra. Una base de datos fragmentada es aquella en la que se selecciona un subconjunto de archivos por la lista de volúmenes. Puesta al día (restauraciones diferenciales o de registro) después de que no se admita una restauración a través del escritor de SQL.

Restauración

El solicitante restaura las bases de datos de las que se ha realizado una copia de seguridad en modo no basado en componentes. Estas restauraciones no se pueden seguir mediante una restauración de puesta al día, como la restauración de registros o la restauración diferencial.

En el caso de las operaciones de restauración no basadas en componentes, la restauración debe realizarse con la instancia de SQL Server sin conexión o las bases de datos de destino se quitan o desasocian para asegurarse de que los archivos están sin conexión. Los archivos se copian en su lugar y, a continuación, las bases de datos adjuntas. Todo esto se produce fuera del ámbito del objeto de escritura de SQL.

Copia de seguridad y restauración basadas en componentes

En una copia de seguridad basada en componentes, el solicitante selecciona explícitamente los componentes de base de datos (a partir de los metadatos que el objeto de escritura de SQL devuelve al cliente) de los que se hará una copia de seguridad o restauración.

Copia de seguridad

En una copia de seguridad basada en componentes, todos los volúmenes de respaldo de las bases de datos seleccionadas deben incluirse en la instantánea de volúmenes. De lo contrario, el escritor de SQL detecta bases de datos rasgadas (con volúmenes de respaldo fuera del conjunto de instantáneas) y produce un error en la copia de seguridad. Una copia de seguridad completa hace copias de seguridad de los datos de la base de datos y de todos los archivos de registro necesarios para ponerla en un estado transaccionalmente coherente en el momento de la restauración.

Restauración completa sin puesta al día

A veces, se realiza una restauración completa de la copia de seguridad de la base de datos sin realizar ninguna puesta al día adicional. Esto puede deberse a que no hay metadatos para facilitar la puesta al día o, en algunos casos, no se necesita la puesta al día. En esta sección se describen brevemente las dos situaciones.

Sin metadatos o sin avance

Si no se guardan metadatos de escritor (metadatos de copia de seguridad basados en componentes) durante la operación de copia de seguridad, la restauración debe realizarse con la instancia de SQL Server sin conexión, o las bases de datos de destino se quitan o desasocian para asegurarse de que los archivos estén sin conexión. Los archivos se copian en su lugar y luego se adjuntan las bases de datos. Todo esto se produce fuera del ámbito del objeto de escritura de SQL.

Existen metadatos, pero no se necesita ningún avance adicional.

El solicitante restaura las bases de datos de las que se ha realizado una copia de seguridad en modo basado en componentes, pero no se solicita ninguna puesta al día. En este caso, SQL Server realiza la recuperación ante fallos en la base de datos como parte de la restauración.

Restauración completa con puesta al día adicional

El solicitante puede emitir una restauración que especifique la SetAdditionalRestores(true) opción . Esta opción indica que el solicitante va a seguir con más restauraciones de puesta al día (como la restauración de registros, la restauración diferencial, etc.). Esto indica a SQL Server que no realice el paso de recuperación al final de la operación de restauración.

Esto solo es posible si los metadatos del escritor de SQL se guardaron durante la copia de seguridad y están disponibles para el escritor de SQL en el momento de la restauración. El servicio SQL Server debe estar en ejecución antes de que el solicitante indique a VSS que realice la actividad de restauración.

El escritor de SQL espera la siguiente secuencia:

  1. Preparación para restaurar cada base de datos: esta actividad implica cerrar todos los identificadores de archivos para permitir que la aplicación solicitante copie o monte los archivos de base de datos.

  2. La aplicación solicitante copia o monta los archivos.

  3. Finalizar la restauración (con NORECOVERY). Las bases de datos se conectan, pero en un restaurar estado.

Después, se pueden usar copias de seguridad, diferenciales o registros convencionales de SQL Server para reenviar la base de datos a través de VDI o Transact-SQL, o bien aplicar la restauración diferencial mediante el marco de VSS.

Compatibilidad con texto completo

El escritor de SQL notifica contenedores de catálogo de texto completo con especificaciones de archivo recursivas en los componentes de la base de datos del documento de metadatos del escritor. Se incluyen automáticamente en la copia de seguridad cuando se selecciona el componente de base de datos.

Copia de seguridad diferencial y restauración

Una operación de copia de seguridad diferencial respalda solo los datos que han cambiado desde la copia de seguridad completa de base más reciente. Una copia de seguridad diferencial solo contiene las partes de los archivos de base de datos que han cambiado. Para realizar dicha copia de seguridad, el solicitante (aplicación de copia de seguridad) necesitaría información sobre la ubicación de los cambios en los archivos de base de datos, de modo que se pueda realizar una copia de seguridad de las secciones adecuadas de los archivos. Durante una operación de copia de seguridad diferencial, el escritor de SQL proporciona esta información en el formato especificado por la información de archivo parcial de VSS. Esta información se puede usar para realizar copias de seguridad solo de la parte modificada de los archivos de base de datos.

Copia de seguridad

El solicitante puede emitir una copia de seguridad diferencial estableciendo la DIFFERENTIAL opción VSS_BT_DIFFERENTIAL en el documento IVssBackupComponents::SetBackupStatedel componente de copia de seguridad , al iniciar una operación de copia de seguridad con VSS. El escritor de SQL pasa la información de archivo parcial (devuelta por SQL Server) a VSS. El solicitante puede obtener esta información de archivo llamando al de la API de VSSIVssComponent::GetPartialFile. Esta información de archivo parcial permite que el solicitante elija solo los intervalos de bytes modificados para hacer una copia de seguridad de los archivos de base de datos.

Durante la fase de tareas previas a la copia de seguridad, el escritor de SQL se asegura de que existe una base diferencial única para cada base de datos seleccionada.

Durante el PostSnapshot evento, el escritor de SQL obtiene la información de archivo parcial de SQL Server y la agrega al documento del componente de copia de seguridad usando la llamada IVssComponent::AddPartialFile.

Nota:

El objeto de escritura de SQL solo admite una única línea base diferencial para copias de seguridad diferenciales. No se admiten líneas base múltiples.

Formato de información de archivo parcial

Para cada base de datos de la que se realiza una copia de seguridad durante una copia de seguridad diferencial, el escritor de SQL almacena la información de archivo parcial para cada archivo de base de datos. Esta información la usan el solicitante o la aplicación de copia de seguridad para copiar solo las partes pertinentes del archivo en el medio de copia de seguridad durante la propia copia de seguridad de los archivos.

Para obtener más información sobre el formato de esta información parcial de archivo, consulte Servicio de instantáneas de volumen (VSS).

Un solicitante puede determinar estos archivos llamando a IVssComponent::GetPartialFileCount y IVssComponent::GetPartialFile. IVssComponent::GetPartialFile devuelve una ruta de acceso y un nombre de archivo que apunta al archivo, y una cadena de intervalos que indica qué partes del archivo deben respaldarse.

Para obtener más detalles sobre la recuperación de información parcial de archivos, consulte la documentación de VSS.

Realización de una copia de seguridad de los archivos

Durante esta fase, la aplicación de copia de seguridad debe examinar los metadatos del escritor almacenados en el documento del componente de copia de seguridad y realizar copias de seguridad solo de las partes pertinentes de los archivos. (Para los archivos de catálogo de texto completo, esta copia de seguridad debe realizarse en función de las marcas de tiempo del archivo. Esto se describe más adelante en este artículo).

Una copia de seguridad diferencial siempre se relaciona con la copia de seguridad base más reciente que existe para la base de datos. En el momento de la restauración, SQL Server detecta copias de seguridad base y diferenciales que no coinciden. Por lo tanto, es responsabilidad de la aplicación de copia de seguridad o del administrador del sistema asegurarse de que la diferencia es relativa a la copia de seguridad completa esperada. Si algún procedimiento fuera de banda ha realizado otra copia de seguridad completa, es posible que la aplicación de copia de seguridad no pueda restaurar la diferencial, ya que no posee la copia de seguridad base.

Actualmente, si la información de intervalo de bytes (información de archivo parcial) es demasiado grande (superando 64 KB en el tamaño del búfer), SQL Server produce un error que indica al usuario que realice una copia de seguridad completa.

Solución de problemas

La adición, eliminación, reducción, expansión, cambio de nombre lógico y cambio de nombre físico de archivos presentan casos interesantes en la solución de problemas de copia de seguridad.

Archivos recién agregados después de tomar la base

Estos archivos se incluyen en la especificación parcial porque cada encabezado del archivo de base de datos debe estar en la especificación parcial. Además de la página de encabezado, todas las páginas asignadas deben incluirse en la especificación parcial.

Archivos eliminados después de tomar la base

Después de tomar la base, se podrían quitar los archivos de datos. Estos archivos no se incluyen en el documento de metadatos del redactor durante la copia de seguridad diferencial. Además, no hay información parcial asociada al archivo eliminado.

Los archivos se reducen después de tomar la base

La información parcial no se recopila de los archivos hasta que el archivo se ha deshabilitado en el servidor. Esto garantiza que VSS nunca incluya ninguna información parcial que corresponda a la región reducida de un archivo de datos.

Archivos crecidos después de tomar la base

Si el aumento tuvo lugar antes de que se recopilara la información parcial, esta debe haber incluido las páginas asignadas en la región aumentada. Si el crecimiento tuvo lugar después de recopilar la información parcial, la información parcial no incluye cambios en la región de crecimiento. En las secciones siguientes, verá que el lanzamiento de registros restaura estos cambios.

Se cambió el nombre lógico del archivo después de tomar la base

Un cambio de nombre lógico del archivo no afecta a la copia de seguridad o restauración, ya que no se hace referencia al nombre lógico del archivo en ningún lugar del documento de metadatos del escritor ni en el documento del componente de copia de seguridad.

Para obtener más información, vea El documento de metadatos de escritor: un ejemplo más adelante en este artículo.

Se cambió el nombre físico del archivo después de tomar la base

Un cambio de nombre de archivo de base de datos físico no surte efecto hasta que se reinicie la base de datos. Por lo tanto, la información de configuración de la base de datos o la información de la ruta de acceso del archivo en el búfer de información parcial todavía se basa en las rutas de acceso físicas anteriores, que son las únicas rutas válidas a esos archivos de base de datos en la instantánea.

Restauración

Durante una restauración diferencial, los metadatos de copia de seguridad que la instancia de solicitud devuelve al escritor de SQL contienen información sobre el tipo de copia de seguridad. Por lo tanto, no se necesita ningún tratamiento especial por parte del autor de SQL. SQL Server determina que es una restauración diferencial por sí misma. SQL Server controla esta restauración diferencial de la misma manera que en una restauración diferencial nativa que no se realiza a través de VSS.

Fase previa a la restauración

Durante esta fase, SQL Server cambia el tamaño de todos los archivos al tamaño adecuado en función de los metadatos del archivo de la copia de seguridad diferencial. Si el archivo se aumenta, SQL Server cero la parte de crecimiento. Si se tiene que crear un nuevo archivo (una vez que se ha tomado la base), SQL Server pone a cero el nuevo archivo. También se cierran todos los identificadores de archivo para que la aplicación de copia de seguridad pueda sobrescribir los archivos con los datos restaurados del medio de copia de seguridad.

Restauración de archivos

El cliente debe restaurar los archivos en función de la especificación del archivo parcial. Los datos deben restaurarse en el mismo desplazamiento o intervalo del archivo de base de datos que se especifica en la especificación de archivo parcial almacenada en los metadatos del escritor.

El archivo de base de datos agrega, quita o reduce, reduce, el cambio de nombre lógico o el cambio de nombre físico vuelve a hacer casos de solución de problemas interesantes en el momento de la restauración.

Si se ha agregado un archivo de base de datos después de tomar la base completa

SQL Server debe haber creado dichos archivos previamente durante la fase de preparación de la restauración. Deben haberse ampliado al tamaño correcto y se han a cero. El cliente solo debe establecer los datos según la especificación parcial (la especificación parcial incluye todas las extensiones asignadas).

Si se ha quitado un archivo de base de datos después de tomar la base completa

La información parcial proporcionada por SQL Server no incluye ninguna información de seguimiento para dichas caídas de archivos. SQL Server es responsable de detectar los archivos que se van a eliminar, comparando los metadatos de los archivos restaurados con los contenedores existentes y eliminándolos realmente. Esto se hace antes de la restauración como un paso de preparación.

Si un archivo de base de datos ha crecido desde que se tomó la base completa

Estos archivos deben ampliarse al tamaño correcto por SQL Server durante la fase de preparación de la restauración. SQL Server también debe eliminar la región extendida. Por lo tanto, el cliente puede establecer de forma segura los datos incluso en la región de crecimiento según la especificación parcial. Si el archivo se ha crecido después de tomar la información parcial, los cambios en la región de crecimiento se restauran mediante la reproducción del registro del que se ha realizado una copia de seguridad junto con la copia de seguridad diferencial.

Si un archivo de base de datos se ha reducido desde que se tomó la base completa

SQL Server es responsable de truncar el archivo al tamaño requerido según los metadatos. Esto se hace antes de la restauración como un paso de preparación.

Si se ha cambiado el nombre lógico de un archivo de base de datos desde que se tomó la base completa

Esto no afecta a la restauración, ya que el nombre lógico no aparece en el documento de metadatos del escritor ni en el documento del componente de copia de seguridad. El cambio de nombre lógico se restaura cuando el cliente aplica el cambio al archivo de base de datos principal, que contiene la información del catálogo del sistema.

Si se ha cambiado el nombre de un archivo de base de datos físicamente desde que se tomó la base completa

Si en el momento de la copia de seguridad diferencial, el cambio de nombre no surtió efecto, el cliente todavía restaura los datos a la ubicación antigua. Un reinicio posterior a la restauración de la base de datos hace que el cambio de nombre físico surta efecto. Si en el momento de la copia de seguridad diferencial, el cambio de nombre del archivo físico ya tuvo efecto, se realiza una copia de seguridad de los datos parciales, si los hay, desde la nueva ruta de acceso física.

Después de la restauración

Durante los eventos posteriores a la restauración, el escritor de SQL realiza la operación de puesta al día y la recuperación normales (si SetAdditionalRestores() se establece en False) de la base de datos.

Copia de seguridad diferencial y restauración para catálogos de texto completo

Los catálogos de texto completo de SQL Server forman parte de los recursos de la base de datos de los que es necesario hacer una copia de seguridad o restauración, junto con el resto de los archivos de la base de datos. Una copia de seguridad diferencial se basa en marca de tiempo para el catálogo de texto completo. La copia de seguridad y restauración diferenciales de VSS de SQL Server tiene una sola copia de seguridad base. En otras palabras, no hay bases diferentes para distintos contenedores. Para la copia de seguridad del catálogo de texto completo de VSS, esto significa que para todos los contenedores de catálogos de texto completo, la copia de seguridad diferencial se basa en una sola marca de tiempo, a diferencia del caso de la copia de seguridad diferencial nativa de SQL Server, en la que hay una base de marca de tiempo por contenedor de catálogo de texto completo.

En VSS, esta marca de tiempo se expresa como una propiedad de todo el componente que se establece durante la copia de seguridad completa y se usa durante una copia de seguridad diferencial subsiguiente.

OnIdentify

En OnIdentify, el escritor de SQL llama IVssCreateWriterMetadata::SetBackupSchema() a para establecer el valor VSS_BS_TIMESTAMPED. Esto indica a la aplicación de copia de seguridad que el escritor de SQL gestiona la administración de la base diferencial.

Establecimiento de la marca de tiempo base

La marca de tiempo de base se establece durante una copia de seguridad completa. En OnPostSnapshot(), el autor utiliza IVssComponent::SetBackupStamp() para almacenar la marca de tiempo junto con el componente en el documento de copia de seguridad.

Copia de seguridad diferencial

La aplicación de copia de seguridad recupera esta marca de tiempo de la copia de seguridad completa base y hace que la marca de tiempo esté disponible para el escritor llamando a IVssComponent::GetBackupStamp() para recuperar la marca base de la copia de seguridad base anterior. Después, lo pone a disposición del autor llamando a IVssBackupComponent::SetPreviousBackupStamp(). A continuación, writer recupera la marca llamando IVssComponent::GetPreviousBackupStamp() a y lo traduce en una marca de tiempo que se usa para IVssComponent::AddDifferencedFilesByLastModifyTime().

Responsabilidad de la aplicación de copia de seguridad durante la copia de seguridad diferencial

Durante una copia de seguridad diferencial, la aplicación de copia de seguridad es responsable de:

  • Realice una copia de seguridad de cualquier archivo (el archivo completo) cuya marca de tiempo de última modificación sea mayor que la marca de tiempo especificada por la última hora de modificación para el archivo establecido en el componente.

  • Realizar un seguimiento y detectar los archivos eliminados.

Responsabilidades de la aplicación de copia de seguridad durante una restauración diferencial

Durante una restauración diferencial, la aplicación de copia de seguridad es responsable de:

  • Restaurar todos los archivos de los que se ha realizado una copia de seguridad, ya sea mediante la creación de un nuevo archivo si aún no existe o mediante la sobrescritura de un archivo existente si ya existe.

  • Aumentar el tamaño del archivo antes de establecer el contenido si el archivo restaurado es mayor que el archivo existente.

  • Truncar el archivo al mismo tamaño que el del archivo restaurado si este es más pequeño que el existente.

  • Eliminar todos los archivos que se deben eliminar; es decir, esos archivos que no deben existir a partir del momento dado de la copia de seguridad diferencial.

Copia de seguridad de solo copia

A veces es necesario realizar una copia de seguridad diseñada para un propósito especial. Por ejemplo, tal vez necesite hacer una copia de una base de datos con fines de prueba. Esta copia de seguridad no debe afectar a los procedimientos generales de copia de seguridad y restauración de la base de datos. El uso de la COPY_ONLY opción especifica que la copia de seguridad se realiza fuera de banda y no debe afectar a la secuencia normal de copias de seguridad. El escritor de SQL admite el tipo de copia de seguridad de solo copia con instancias de SQL Server.

Durante la fase de detección de copias de seguridad, el escritor de SQL indica su capacidad de realizar una copia de seguridad única estableciendo la opción VSS_BS_COPY de esquema de copia de seguridad admitida usando la llamada IVssCreateWriterMetadata::SetBackupSchema. El solicitante puede establecer el tipo de copia de seguridad como una copia de seguridad sólo de copia al configurar la opción VSS_BACKUP_TYPE como VSS_BT_COPY mediante la llamada a IVssBackupComponents::SetBackupState.

Cuando se selecciona una copia de seguridad de solo copia, se supone que los archivos del disco se copian en un medio de copia de seguridad (por el solicitante) independientemente del estado del historial de copia de seguridad de cada archivo. SQL Server no actualiza el historial de copia de seguridad. Este tipo de copia de seguridad no constituye una copia de seguridad base para operaciones de copia de seguridad diferenciales adicionales y tampoco altera el historial de las copias de seguridad diferenciales anteriores.

Restauración con desplazamiento

VSS permite al solicitante (aplicación de copia de seguridad) especificar un nuevo destino de restauración mediante la IVssComponent::SetNewTarget llamada. En ambos PreRestore() y PostRestore(), el redactor de SQL comprueba si se ha especificado al menos un nuevo destino. Es responsabilidad de la aplicación de copia de seguridad copiar físicamente los archivos en la nueva ubicación durante el tiempo real de restauración o copia de archivos.

La aplicación de copia de seguridad solo puede especificar nuevos destinos para la ruta de acceso física, pero no la especificación del archivo. Por ejemplo, para un archivo de base de datos ubicado en c:\data\test.mdf, no se puede cambiar el nombre test.mdf de archivo real. Solo se puede cambiar la ruta c:\data. Para un contenedor de catálogo de texto completo ubicado en c:\ftdata\foo, ya que la especificación de archivo en VSS es "*" y la especificación de ruta de acceso en VSS es c:\ftdata\foo, se puede cambiar toda la ruta de acceso.

Cambio de nombre de la base de datos

Es posible que un solicitante tenga que restaurar una base de datos de SQL Server con un nuevo nombre, especialmente si la base de datos se va a restaurar en paralelo con la base de datos original. El solicitante puede especificar esta opción durante la operación de restauración estableciendo una opción de restauración personalizada como "Nuevo nombre de componente" = <"Nuevo nombre"> mediante la llamada IVssBackupComponents::SetRestoreOptions() de VSS (en el wszRestoreOptions parámetro ).

El escritor de SQL toma todo el contenido del valor de Nuevo Nombre del Componente y lo usa como el nuevo nombre para la base de datos restaurada. Si no se especifica ninguna opción, SQL Server restaura la base de datos con su nombre original (nombre del componente).

Nota:

El escritor de SQL no admite actualmente el cambio de nombre entre instancias para mover una base de datos a una nueva instancia.

Instantáneas recuperadas automáticamente

Normalmente, una instantánea de una base de datos de SQL Server obtenida mediante el marco de VSS se encuentra en un estado no recuperado. No se puede acceder a los datos de la instantánea de forma segura antes de pasar por la fase de recuperación para revertir las transacciones en curso y colocar la base de datos en un estado coherente. Dado que la instantánea está en un estado de solo lectura, no se puede recuperar mediante el proceso normal de adjuntar la base de datos.

Es posible recuperar automáticamente las instantáneas como parte del proceso de creación de instantáneas. Como parte del documento de metadatos de escritor, el escritor de SQL especifica la marca VSS_CF_APP_ROLLBACK_RECOVERY de componente para indicar que la recuperación debe realizarse para la base de datos en la instantánea antes de que se pueda tener acceso a la base de datos al especificar el conjunto de instantáneas, el solicitante puede indicar que la instantánea debe ser una instantánea de reversión de la aplicación (es decir, todos los archivos de base de datos de una instantánea están diseñados para estar en un estado coherente para el uso de la aplicación) o una instantánea de copia de seguridad (una instantánea). se usa para realizar copias de seguridad de datos que se restaurarán más adelante si se produce un error del sistema).

El solicitante debe establecer VSS_VOLSNAP_ATTR_ROLLBACK_RECOVERY para indicar que se está haciendo una copia de seguridad de este componente para un propósito que no es de copia de seguridad. VSS correlaciona VSS_CF_APP_ROLLBACK_RECOVERY que el escritor de SQL ha especificado en el componente seleccionado con VSS_VOLSNAP_ATTR_ROLLBACK_RECOVERY, y determina que se está produciendo la recuperación automática. VSS hace que la instantánea sea escribible durante un período de tiempo limitado y agrega automáticamente el VSS_VOLSNAP_ATTR_AUTORECOVERY bit al contexto de la instantánea.

En SQL Server, la conmutación automática solo se debe aplicar a las instantáneas de reversión de aplicaciones, pero no para las instantáneas de copia de seguridad. En el caso de las instantáneas de reversión de aplicaciones, el escritor de SQL inicia un proceso de reversión automática durante el PostSnapShotevent. Este proceso realiza lo siguiente para cada base de datos de SQL Server seleccionada explícitamente (por el solicitante) en el conjunto de instantáneas:

  • Conectar la base de datos de instantánea a la instancia de SQL Server original (es decir, la instancia a la que se adjunta la base de datos original).

  • Recuperar la base de datos (esto sucede como parte de la operación "adjuntar").

  • Reducir el tamaño de los archivos de registro.

    Esto reduce la cantidad de copia en escritura innecesaria que debe realizar el marco de VSS, si el proveedor de VSS es un proveedor de software . La reducción de los archivos de registro es el comportamiento predeterminado. Esto se puede deshabilitar estableciendo el valor en la siguiente clave del Registro en 1.

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SQLWriter\Settings\DisableLogShrink

    Esto puede ser útil en escenarios en los que la instantánea se puede usar para exportar datos desde una página específica (en un momento dado específico) desde el registro para corregir un problema en la base de datos en línea.

  • Separe la base de datos.

Ahora hay una instantánea coherente y recuperada que se puede adjuntar para realizar consultas.

Transacciones de varias bases de datos

En versiones anteriores de SQL Server, las bases de datos de instantáneas a veces pueden contener algunas transacciones de varias bases de datos en curso. Durante la operación de recuperación, el escritor de SQL adjunta la base de datos en las instantáneas con la opción Presunta anulación. Esto revertiría cualquier transacción de varias bases de datos que aún no se confirme (incluidas las transacciones que se encuentran en un estado Preparado para confirmar). Esto puede provocar algunas incoherencias entre las bases de datos del conjunto de instantáneas.

Por ejemplo, considere dos bases de datos A y B. Hay una transacción distribuida entre estas dos bases de datos y esta transacción está en estado Confirmado en la base de datos A y en Estado preparado para confirmar en la base de datos B. Como parte del proceso de autorecovery, esta transacción se confirma en la base de datos A y se revierte en la base de datos B. Esto puede provocar algunas incoherencias en el conjunto de instantáneas.

Las versiones más recientes de Windows tienen un componente mejorado del Coordinador de transacciones distribuidas de Microsoft (MS DTC) que corrige este problema de incoherencia para las transacciones que abarcan bases de datos entre instancias de SQL Server. Las versiones más recientes de SQL Server corrigen estas incoherencias para las transacciones que abarcan bases de datos dentro de una instancia de SQL Server.

Implicaciones de seguridad para las instantáneas recuperadas automáticamente

En el caso de las instantáneas de VSS, después de la recuperación automática, los archivos se protegen mediante listas de control de acceso (ACL) para permitir el acceso solo al grupo integrado especial al que pertenece la cuenta de SQL Server. Esto implica que los miembros del administrador de cuadros o de ese grupo especial pueden adjuntar la base de datos. El cliente que solicita adjuntar los archivos de la base de datos a una instantánea debe ser miembro de Builtin/Administrators o de la cuenta de SQL Server.

Bases de datos de usuario del modelo de recuperación simple

Si la master base de datos se restaura junto con las bases de datos de usuario que usan el modelo de recuperación simple, las bases de datos de usuario se pueden restaurar con la misma técnica que la master base de datos: con la instancia apagada, simplemente copie o monte los volúmenes. Cuando se inicia la instancia de SQL, se recupera todo.

Puesta al día de las bases de datos de usuario

Si las bases de datos de usuario deben recuperarse y avanzar junto con la recuperación de la base de datos master, la instancia no debe iniciarse ni recuperar las bases de datos master y de usuario simultáneamente.

El procedimiento es el siguiente:

  1. Asegúrese de que la instancia de SQL Server está detenida.

  2. Realice la restauración en dos fases.

    1. Restaure las bases de datos del sistema y las bases de datos de usuario que se deben recuperar al mismo tiempo (es decir, las bases de datos de usuario en el modelo de recuperación simple) a través de la copia de archivos o el montaje del volumen, a través de VSS.

      • Si las bases de datos del usuario que se van a adelantar no están en el mismo volumen que las bases de datos del sistema, ese volumen no debería ser traído de vuelta en este momento. Este escenario requiere planear antes de la copia de seguridad.

      • Si las bases de datos de usuario se encuentran en el mismo volumen que las del sistema, las bases de datos de usuario deben estar ocultas en SQL Server.

    2. Inicie la instancia de SQL Server mediante el -f parámetro . (Cuando se usa la -f opción de inicio, solo se puede restaurar la master base de datos).

      1. Emita un ALTER DATABASE <database> SET OFFLINE (o destache la base de datos) para cada base de datos que se va a implementar.

      2. Detenga la instancia de SQL Server.

      3. Inicie la instancia de SQL Server (los archivos de las bases de datos de usuario que se van a poner al día no son visibles para SQL Server).

Use VSS para restaurar las bases de datos WITH NORECOVERYde usuario, como se describe en Restauración completa con puesta al día adicional.

Documento de metadatos del escritor: un ejemplo

Una base de datos denominada DB1, que pertenece a la instancia Instance1 de SQL Server en la máquina Server1, contiene los siguientes archivos de base de datos o registro:

  • Archivo de base de datos denominado "principal" almacenado en c:\db\DB1.mdf
  • Archivo de base de datos denominado "secundario" almacenado en c:\db\DB1.ndf
  • Archivo de registro de base de datos denominado "log" almacenado en c:\db\DB1.ldf
  • Catálogo de texto completo denominado "foo" almacenado en el directorio c:\db\ftdata\foo
  • Catálogo de texto completo denominado "bar" almacenado en el directorio c:\db\ftdata\bar

A continuación se indican los metadatos del escritor de la base de datos:

Componente de grupo de archivos de nivel de base de datos

Archivo principal de base de datos:

ComponentType: VSS_CT_FILEGROUP
LogicalPath: "Server1\Instance1"
ComponentName: "DB1"
Caption: NULL
pbIcon: NULL
cbIcon: 0
bRestoreMetadata: FALSE
NotifyOnBackupComplete: TRUE
Selectable: TRUE
SelectableForRestore: TRUE
ComponentFlags: VSS_CF_APP_ROLLBACK_RECOVERY

Archivo de base de datos secundario:

LogicalPath: "Server1\Instance1"
GroupName: "DB1"
Path: "c:\db"
FileSpec: "DB1.mdf"
Recursive: FALSE
AlternatePath: NULL
BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED
Filegroup file
LogicalPath: "Server1\Instance1"
GroupName: "DB1"
Path: "c:\db"
FileSpec: "DB1.ndf"
Recursive: FALSE
AlternatePath: NULL
BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED

Archivo de texto completo "log":

LogicalPath: "Server1\Instance1"
GroupName: "DB1"
Path: "c:\db"
FileSpec: "DB1.ldf"
Recursive: FALSE
AlternatePath: NULL
BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED

Archivo de texto completo "foo":

LogicalPath: "Server1\Instance1"
GroupName: "DB1"
Path: "c:\db\ftdata\foo"
FileSpec: "*"
Recursive: TRUE
AlternatePath: NULL
BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED

Barra de archivo de texto completo:

LogicalPath: "Server1\Instance1"
GroupName: "DB1"
Path: "c:\db\ftdata\bar"
FileSpec: "*"
Recursive: TRUE
AlternatePath: NULL
BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED

Si la instancia del servidor es la instancia predeterminada de la máquina, la ruta de acceso lógica se convierte en una parte: Server1.

Casos especiales

En esta sección se describen algunos de los casos especiales que se producen durante las operaciones de copia de seguridad y restauración basadas en el objeto de escritura de SQL.

Bases de datos cerradas automáticamente

En el caso de las copias de seguridad no basadas en componentes, se realiza la inclusión automática de bases de datos, al comprobar si hay condiciones rasgadas, pero las bases de datos cerradas no se inmovilizan explícitamente durante las operaciones de copia de seguridad.

El escenario esperado aquí es que probablemente existan muchas bases de datos cerradas y se quiere minimizar el costo de la instantánea. Las bases de datos cerradas automáticamente se usan normalmente en configuraciones de bajo perfil en las que los recursos son escasos.

Lista de archivos

La lista de archivos de cada base de datos se determina durante un paso de enumeración antes del evento Preparar para copia de seguridad. Si la lista de archivos de base de datos cambia entre la enumeración y la inmovilización, la base de datos podría desgarrarse, a menos que la aplicación vuelva a comprobar la lista de archivos. Aunque este escenario es poco probable, es algo que los proveedores deben tener en cuenta.

Instancias detenidas

Si una instancia de SQL Server no se está ejecutando en el momento en que se produce el paso de enumeración, no se puede seleccionar ninguna de las bases de datos de esas instancias.

Si una instancia se detiene en el intervalo entre la enumeración y el evento de preparación para la copia de seguridad, se omiten todas las bases de datos de la instancia detenida.

Bases de datos del sistema y del usuario

Las bases de datos del sistema de SQL Server incluyen las master, model y msdb, que se entregan e instalan como parte de SQL Server. En esta sección se describe la forma en la que se controlan estas bases de datos en un proceso de copia de seguridad de instantáneas de VSS.

La master base de datos solo se puede restaurar deteniendo la instancia, reemplazando los archivos de base de datos (realizados por la aplicación de copia de seguridad) y reiniciando la instancia. No se puede poner al día.

El escritor de SQL admite la restauración de bases de datos de model y msdb en línea, sin apagar la instancia.

Contenido relacionado