Aplicativos de backup do SQL Server - VSS (Serviço de Cópias de Sombra de Volume) e Gravador SQL

Aplica-se a: SQL Server em Windows

O SQL Server fornece suporte para o VSS (Serviço de Cópias de Sombra de Volume) fornecendo um gravador (o gravador SQL) para que um aplicativo de backup de terceiros possa usar a estrutura VSS para fazer backup de arquivos de banco de dados. Este documento descreve o componente de gravador SQL e sua função no processo de criação e restauração de instantâneos VSS para bancos de dados do SQL Server. Ele também captura detalhes sobre como configurar e usar o gravador SQL para trabalhar com aplicativos de backup na estrutura VSS.

Infraestrutura de VSS

O VSS fornece a infraestrutura do sistema para executar aplicativos VSS em sistemas Windows. Embora amplamente transparente para o usuário e o desenvolvedor, o VSS:

• Coordena as atividades de provedores, autores e solicitantes na criação e uso de cópias de sombra.
• Fornece o provedor de sistema padrão.
• Implementa a funcionalidade de driver de baixo nível necessária para o funcionamento de qualquer provedor.

O serviço VSS é iniciado sob demanda, portanto, esse serviço deve ser habilitado para que as operações VSS sejam bem-sucedidas.

Componentes VSS

O VSS coordena as atividades dos seguintes componentes cooperantes:

• Os provedores possuem os dados de cópia de sombra e instanciam as cópias de sombra.

• Os gravadores são aplicativos que alteram dados e participam do processo de sincronização de cópias de sombra.

• Os solicitantes iniciam a criação e destruição de cópias de sombra. O design é focado no cenário em que o solicitante é um aplicativo de backup.

O VSS fornece coordenação entre estas partes:

Este diagrama mostra todos os componentes que participam de uma atividade típica de instantâneo do VSS. Nesse cenário, o SQL Server (incluindo o escritor SQL) está atuando como um escritor em uma das instâncias do Writer. Outros gravadores podem ser o Exchange Server, etc.

• Interface de dispositivo virtual: o SQL Server fornece uma interface de programação de aplicativos chamada Virtual Device Interface (VDI), que ajuda fornecedores independentes de software a integrar o SQL Server em seus produtos, fornecendo suporte para operações de backup e restauração. Essas APIs são projetadas para fornecer confiabilidade e desempenho máximos e oferecem suporte a toda a gama de funcionalidades de backup e restauração do SQL Server, incluindo a gama completa de recursos de backup a quente e instantâneo. Para obter mais informações, consulte Especificação da interface de dispositivo de backup virtual do SQL Server 2005.

• Solicitante: um processo (automatizado ou GUI) que solicita que um ou mais conjuntos de instantâneos sejam tirados de um ou mais volumes originais. Neste artigo, um pedidor é também utilizado para referir-se a um aplicativo de backup que está a criar um instantâneo de bases de dados do SQL Server.

Para obter mais informações, consulte Serviço de Cópias Sombra de Volume.

Gravador SQL

O gravador SQL é um gravador VSS fornecido pela instância do SQL Server. Ele lida com a interação VSS com o SQL Server. O gravador SQL é fornecido com o SQL Server como um serviço autônomo e é instalado como parte da instalação do SQL Server.

A função do gravador SQL em uma operação de backup de instantâneo VSS:

Configurar o gravador SQL

O serviço de gravador SQL é instalado no sistema como parte da instalação do SQL Server e é configurado para iniciar automaticamente quando o Windows é iniciado.

Conta de serviço do escritor SQL

Durante a instalação, a conta de Escritor (Writer) SQL é configurada para usar a conta do Sistema Local. Como o gravador SQL precisa falar com o SQL Server usando APIs VDI exclusivas, a conta do gravador SQL deve ter direitos de acesso suficientes para SQL Server e VSS. Configurar o serviço como uma conta Sistema Local fornece direitos suficientes para que o serviço seja executado corretamente.

Reativar e iniciar o gravador SQL

Por padrão, o serviço de gravador SQL é habilitado e é iniciado automaticamente. Se essa configuração tiver sido modificada, as seguintes etapas deverão ser executadas para reverter para as configurações padrão:

O serviço de gravador SQL pode ser habilitado marcando esse serviço como Automático. Para abrir os serviços através do painel de controlo, selecione Iniciar, selecione Painel de Controlo, faça duplo clique em Ferramentas Administrativas e, em seguida, faça duplo clique em Serviços. No painel Serviços , clique duas vezes no serviço de gravador SQL e modifique a propriedade Tipo de Inicialização para Automático.

O serviço deve ser iniciado selecionando o botão Iniciar na propriedade Status do Serviço na tela de propriedades do serviço mencionada anteriormente.

Funcionalidades suportadas pelo escritor SQL

• Texto completo: O gravador SQL reporta contenedores de catálogo de texto completo com especificações de arquivos recursivos nos componentes de base de dados no documento de metadados do gravador. Eles são incluídos automaticamente no backup quando o componente de banco de dados é selecionado.

• Backup e restauração diferenciais: o gravador SQL oferece suporte a backup e restauração diferenciais por meio de dois mecanismos diferenciais VSS:

  • Arquivo parcial: O gravador SQL usa o mecanismo VSS Partial File para relatar intervalos de bytes alterados em seus arquivos de banco de dados.

  • Arquivo diferenciado pela hora da última modificação: o gravador SQL utiliza o mecanismo de Arquivo Diferenciado VSS pela Hora da Última Modificação para relatar arquivos alterados em catálogos de texto completo.

• Restaurar com movimento: O gravador SQL suporta a especificação New Target do VSS durante a restauração. A especificação New Target permite que um banco de dados/arquivo de log ou contêiner de catálogo de texto completo seja realocado como parte da operação de restauração.

• Renomeação de banco de dados: um solicitante pode precisar restaurar um banco de dados do SQL Server com um novo nome, especialmente se o banco de dados for restaurado lado a lado com o banco de dados original. O gravador SQL oferece suporte à renomeação de um banco de dados durante a operação de restauração, desde que o banco de dados permaneça dentro da instância SQL original.

• Backup somente cópia: às vezes é necessário fazer um backup destinado a uma finalidade especial, por exemplo, quando você precisa fazer uma cópia de um banco de dados para fins de teste. Esse backup não deve afetar os procedimentos gerais de backup e restauração do banco de dados. O uso da COPY_ONLY opção especifica que o backup é feito fora da banda e não deve afetar a sequência normal de backups. O gravador SQL suporta o tipo de backup apenas cópia em instâncias do SQL Server.

• Recuperação automática de instantâneo de banco de dados: normalmente um instantâneo de um banco de dados do SQL Server obtido usando a estrutura VSS está em um estado não recuperado. Os dados no snapshot não podem ser acessados com segurança antes de passarem pela fase de recuperação para reverter transações em voo e colocar o banco de dados em um estado consistente. É possível que um aplicativo de backup VSS solicite a recuperação automática dos snapshots, como parte do processo de criação de snapshots.

Esses novos recursos e seu uso são descritos com mais detalhes em Detalhes da opção de backup e restauração neste artigo.

O que não é suportado

• Os backups de log não são suportados pelo gravador SQL.
• Não há suporte para backup de arquivos e grupos de arquivos.
• A restauração de página não é suportada.
• Os instantâneos de banco de dados não têm suporte e são ignorados na criação de instantâneos VSS, tanto componentes quanto não componentes.
• Feche automaticamente bancos de dados ou bancos de dados com desligamento habilitado.
• O Linux não fornece uma estrutura VSS e, portanto, o gravador SQL não está disponível no Linux.

A tabela a seguir lista os tipos de backups de instantâneo suportados pelo gravador SQL/SQL Server que trabalha com a estrutura VSS para todas as edições do SQL Server no Windows.

Operações de backup

O SQL Server (usando o gravador SQL) oferece suporte aos seguintes modos de operações de backup baseadas em VSS:

• Não baseado em componentes
• Baseado em componentes

Suporte de versão

O gravador SQL é fornecido como parte do SQL Server e dá suporte apenas a instâncias do SQL Server. O gravador SQL também enumera instâncias do SQL Server Express, incluindo instâncias de usuário iniciadas pela edição do SQL Server Express.

Operações de backup não baseadas em componentes

Os backups não baseados em componentes selecionam implicitamente bancos de dados usando a lista de volumes no conjunto de instantâneos. O gravador SQL verifica se há bancos de dados corrompidos, gerando um erro caso encontre algum. Um banco de dados rasgado é aquele em que um subconjunto de arquivos é selecionado pela lista de volumes.

No modelo não baseado em componentes, apenas bancos de dados com o modelo de recuperação simples são suportados. Não há suporte para a Roll-forward após uma restauração.

Operações de backup baseadas em componentes

Os backups baseados em componentes são preferidos e recomendados com o gravador SQL, uma vez que o aplicativo (aplicativo de backup VSS) seleciona explicitamente os bancos de dados dos metadados retornados do gravador SQL. O conjunto de instantâneas deve incluir todos os volumes necessários para efetuar cópias de segurança desses bancos de dados. A infraestrutura VSS não adiciona automaticamente os volumes necessários para o conjunto selecionado de bancos de dados. Todos os volumes de suporte devem ser incluídos no conjunto de instantâneos de volume. É responsabilidade do aplicativo de backup certificar-se de que todos os volumes de backup estejam incluídos no conjunto de snapshots. O gravador SQL deteta bases de dados danificadas (com volumes de backup fora do conjunto de instantâneos) e interrompe o backup.

O restante desta seção pressupõe que os backups baseados em componentes sejam usados como parte do processo de criação de instantâneo VSS para o SQL Server.

Processo de criação de snapshots

A estrutura VSS coordena as atividades de um solicitante (um aplicativo de backup) e o gravador SQL durante a criação de instantâneos do SQL Server. Para habilitar essa coordenação, a estrutura VSS define interfaces de solicitante e gravador. Essas interfaces devem ser implementadas por parte dos aplicativos solicitantes participantes e escritores. O gravador SQL implementa as interfaces de gravador necessárias. Como parte do processo de criação de um instantâneo, as interfaces do gravador SQL são chamadas pelo framework VSS. O escritor SQL interage com instâncias do SQL Server no sistema para facilitar a criação de instantâneos.

A estrutura VSS define um conjunto de APIs para uso por um aplicativo solicitante/de backup. Um desenvolvedor de aplicativos de backup precisa seguir esses padrões de chamada de API para trabalhar com o processo de criação de instantâneo da estrutura VSS. As próximas seções descrevem o processo de criação de instantâneos do ponto de vista do gravador SQL. Eles também detalham algumas das interações internas entre o solicitante, a estrutura VSS, o gravador SQL e as instâncias do SQL Server.

Para obter mais informações sobre estas etapas e detalhes das interfaces da estrutura VSS, consulte Serviço de Cópias Sombra de Volume (VSS).

Fluxo de trabalho de criação de instantâneos

A imagem a seguir mostra o diagrama de fluxo de dados durante uma operação de criação/backup de instantâneo baseada em componente.

Para entender melhor as tarefas básicas envolvidas na execução de um backup, é útil dividir essa visão geral nas seguintes fases:

• Inicialização de backup
• Fase de deteção de backup
• Tarefas de pré-backup
• Backup real de arquivos
• Terminação de backup

Inicialização de backup

Durante essa fase do backup, o solicitante (aplicativo de backup) se liga à interface IvssBackupComponentsde snapshot e a inicializa em preparação para o backup. Ele também chama a API IVssGatherWriterMetadata VSS para informar a estrutura VSS para coletar metadados de todos os escritores.

A estrutura VSS chama cada um dos escritores registados, incluindo o escritor SQL, para os metadados do escritor usando o evento OnIdentify. O escritor SQL consulta as instâncias do SQL Server para obter as informações de metadados de backup para cada base de dados e criar o Documento de Metadados do Escritor. Essa fase também é conhecida como enumeração de metadados.

O documento de metadados do gravador é um documento que contém informações que são passadas do gravador para o solicitante (aplicativo de backup). O documento de metadados do gravador contém as seguintes informações:

• O ID do aplicativo e o nome amigável
• Onde existem arquivos e componentes
• Quais arquivos precisam ser incluídos e excluídos em um backup
• Quais opções devem ser usadas no momento da restauração

Isso é passado de volta para o solicitante por meio da estrutura VSS.

Descoberta de backup

Nesta fase, um solicitante examina o documento de metadados do gravador e cria e preenche um documento do componente de backup com cada componente que precisa ser copiado. Ele também especifica as opções e os parâmetros de backup necessários como parte deste documento. Para o gravador SQL, cada instância de banco de dados que precisa de backup é um componente separado.

Documento de componentes de backup

Este é um documento XML criado por um solicitante (usando a IVssBackupComponents interface) durante a configuração de uma operação de restauração ou backup. O documento dos componentes de cópia de segurança contém uma lista dos componentes explicitamente incluídos, de um ou mais autores, que participam numa operação de cópia de segurança ou restauração. Ele não contém informações de componentes incluídas implicitamente. Por outro lado, um documento de metadados do gravador contém apenas componentes do gravador que podem participar de um backup. Os detalhes estruturais de um documento de componente de backup são descritos na documentação da API VSS.

Tarefas de pré-cópia de segurança

As tarefas de pré-backup no VSS são focadas na criação de uma cópia de sombra dos volumes que contêm dados para backup. O aplicativo de backup salva dados da cópia de sombra, não do volume real.

Os requerentes normalmente esperam pelos escritores durante a preparação para o backup e enquanto a cópia sombra está a ser criada. Se o gravador SQL estiver participando da operação de backup, ele precisará configurar seus arquivos e também estar pronto para backup e cópia de sombra.

Prepare-se para o backup

O solicitante precisa definir o tipo de operação de backup que precisa ser executada (IVssBackupComponents::SetBackupState) e, em seguida, notifica os gravadores por meio do VSS, para se preparar para uma operação de backup usando IVssBackupComponents::PrepareForBackup.

O gravador SQL recebe acesso ao documento do componente de backup, que detalha quais bancos de dados precisam ser copiados. Todos os volumes de suporte devem ser incluídos no conjunto de instantâneos de volume. O gravador SQL deteta bancos de dados rasgados (com volumes de backup fora do conjunto de instantâneos) e falha no backup durante o evento PostSnapshot.

Backup real de arquivos

Nesta fase, o solicitante pode mover os dados para uma mídia de backup, se necessário. As interações neste estágio são entre o solicitante e a estrutura VSS. O gravador SQL não está envolvido.

1. Obter o status de escritor. Retorna o status de escritores. O solicitante pode precisar lidar com quaisquer falhas aqui.
2. Realize o backup.

O solicitante pode mover os dados para fazer backup de mídia, se necessário, neste momento.

Backup concluído

Esse evento indica que o backup foi concluído com êxito.

Este é também o momento em que o escritor SQL pode confirmar o backup como base diferencial, caso o backup atual seja um backup completo da base de dados (e não apenas um backup de cópia).

Salvar metadados do escritor

O solicitante deve salvar o documento do componente de backup e os metadados de backup de cada componente, juntamente com os dados copiados do snapshot. Esses metadados do escritor são necessários pelo escritor SQL/SQL Server para operações de restauração.

Terminação de backup

O solicitante encerra a cópia de sombra liberando a interface IVssBackupComponents, ou chamando IVssBackupComponents::DeleteSnapshots.

Documento de metadados do gravador SQL

Este é um documento XML criado por um gravador (o gravador SQL, neste caso) usando a IVssCreateWriterMetadata interface e contendo informações sobre o estado e os componentes do gravador. Os detalhes estruturais de um documento de metadados do escritor são descritos na documentação da API VSS. Aqui estão alguns dos detalhes do documento de metadados do escritor SQL.

• Informações de identificação do escritor

  • Nome do gravador - L"SqlServerWriter"
  • ID da classe Writer - 0xa65faa63, 0x5ea8, 0x4ebc, 0x9d, 0xbd, 0xa0, 0xc4, 0xdb, 0x26, 0x91, 0x2a
  • ID da instância do gravador - L"SQL Server:SQLWriter"
  • VSSUsageType - VSS_UT_USERDATA
  • VSSSourceType - VSS_ST_TRANSACTEDDB

• Informações de nível de escritor - VSS_APP_BACK_END

• Especificação do método de restauração – VSS_RME_RESTORE_IF_CAN_REPLACE.

• Esquema de backup suportado (IVssCreateWriterMetadata::SetBackupSchema API)

  • VSS_BS_DIFFERENTIAL – backup diferencial
  • VSS_BS_TIMESTAMPED – baseado em carimbo de data/hora – para arquivos de catálogo de texto completo.
  • VSS_BS_LAST_MODIFY –Backup diferencial baseado no tempo da última modificação,
  • VSS_BS_WRITER_SUPPORTS_NEW_TARGET – suporta a opção de novo destino.
  • VSS_BS_WRITER_SUPPORTS_RESTORE_WITH_MOVE – suporta restaurar "com movimento"
  • VSS_BS_COPY – suporta a opção de backup "somente cópia".

• Informações de nível de componente (contém informações específicas de nível de componente fornecidas pelo gravador SQL)

  • Tipo - VSS_CT_FILEGROUP
  • Nome - nome do componente (nome do banco de dados)
  • Caminho lógico – da instância do servidor (na forma de "server\instance-name" para instâncias nomeadas e "server" para instância padrão.)
  • Sinalizadores de componentes
  • VSS_CF_APP_ROLLBACK_RECOVERY – indica que os instantâneos do SQL Server sempre exigem uma fase de "recuperação" para tornar os arquivos consistentes e utilizáveis em cenários sem backup (isto é, de reversão de aplicativos).
  • Selecionável - Verdadeiro
  • Selecionável para restauração - True
  • Métodos de restauração suportados - VSS_RME_RESTORE_IF_CAN_REPLACE

A única extensão da estrutura do conjunto de componentes no SQL Server é a introdução de catálogos de texto completo. Os catálogos de texto completo são diretórios de contêiner, que não podem ser expressos como o banco de dados VSS ou arquivos de log, dado que o banco de dados VSS e os arquivos de log não têm especificação recursiva. Portanto, o gravador SQL usa um componente de grupo de arquivos VSS (VSS_CT_FILEGROUP) para representar o componente de nível de banco de dados e arquivos de grupo de arquivos para representar o banco de dados, log e arquivos de catálogo de texto completo.

Um exemplo de documento de metadados do autor é fornecido no final deste documento.

Iniciar captura

O solicitante inicia o processo de snapshot chamando a interface DoSnapshotSetda estrutura VSS.

Criar instantâneo

Esta fase envolve uma série de interações entre a estrutura VSS e o gravador SQL.

1. Prepare-se para o snapshot. O gravador SQL chama o SQL Server para se preparar para a criação de instantâneos.

2. Congelar. O gravador SQL chama o SQL Server para congelar todas as E/S do banco de dados para cada um dos bancos de dados cujo backup está sendo feito no instantâneo. Quando o evento de congelamento retorna ao framework VSS, o VSS cria o instantâneo.

3. Descongelar. Nesse evento, o escritor SQL chama as instâncias do SQL Server para descongelar ou retomar operações normais de E/S.

A fase de criação do snapshot leva menos de 60 segundos, para evitar o bloqueio de todas as gravações no banco de dados.

Pós-instantâneo

Se a recuperação automática for necessária para o instantâneo, o gravador SQL fará a recuperação automática para cada banco de dados que foi selecionado para ser incluído no instantâneo. Para obter uma explicação detalhada, consulte Instantâneos recuperados automaticamente.

Processo de restauração

Esta seção descreve o fluxo de trabalho da operação de restauração e as várias etapas envolvidas.

Restaurar fluxo de operações

A figura a seguir mostra o diagrama de fluxo de dados durante uma operação de restauração VSS.

Para entender melhor as tarefas básicas envolvidas na execução de uma restauração, é útil dividir esta visão geral nas seguintes seções:

• Restaurar inicialização
• Preparando-se para a restauração
• Restauração real de arquivos
• Restaurar, limpar e terminar

Em todos os cenários de restauração baseados em componentes VSS, a restauração do banco de dados é manipulada pelo gravador SQL em duas fases distintas.

• Pré-restauração: O gravador SQL lida com a validação, fechamento de identificadores de arquivo, etc.
• Pós-restauração: o gravador SQL anexa o banco de dados e faz a recuperação de falhas, se necessário.

Entre essas duas fases, o aplicativo de backup é responsável por mover os dados relevantes por baixo do SQL.

Restaurar inicialização

Durante a fase de inicialização de uma restauração, o solicitante precisa ter acesso aos documentos dos componentes de backup armazenados.

O documento do componente de backup gerado durante a operação de backup é armazenado como parte dos dados de backup. O aplicativo de backup precisa passar esses dados de volta para a estrutura VSS. O gravador SQL obtém acesso a esses dados no início do processo de restauração.

Prepare-se para a restauração

Quando o solicitante se prepara para uma restauração, ele usa o documento de componentes de backup armazenados para determinar o que deve ser restaurado e como. O solicitante seleciona os componentes a serem restaurados e define as opções de restauração apropriadas, conforme necessário.

Se um aplicativo de backup pretende aplicar backups diferenciais ou de log sobre a operação de restauração atual (ou seja, a restauração com norecovery é necessária), a opção a seguir deve ser definida como parte da criação de componentes para cada banco de dados que está sendo restaurado.

IVssBackupComponents::SetAdditionalRestores(true)

Depois de todos os detalhes necessários estarem definidos no documento do componente de backup, o solicitante faz a IVssBackupComponents::PreRestore chamada para gerar um evento de pré-restauração por meio do VSS que é processado pelos escritores.

O gravador SQL examina o documento do componente de backup fornecido para identificar os bancos de dados apropriados, excluindo todos os arquivos adicionais criados desde o tempo de backup. Ele também verifica os espaços em disco e fecha todos os identificadores de arquivo de banco de dados abertos para que o solicitante possa copiar os dados necessários durante a fase de restauração. Esta fase permite que quaisquer condições de erro iniciais sejam detetadas antes que o solicitante faça a cópia do arquivo real. O SQL Server também coloca o banco de dados no estado de restauração. A partir deste ponto, o banco de dados não pode ser iniciado até uma restauração bem-sucedida.

Restaurar ficheiros

Trata-se de uma ação puramente específica do requerente. É responsabilidade do solicitante (aplicativo de backup) copiar os arquivos de banco de dados necessários (ou copiar intervalos relevantes de dados para restaurações diferenciais) para os locais apropriados. O gravador SQL não está envolvido nesta operação.

Limpeza e terminação

Depois que todos os dados forem restaurados para os lugares certos, uma chamada de um solicitante notificando que a operação de restauração foi concluída IvssBackupComponents::PostRestorepermitirá que o gravador SQL saiba que ações pós-restauração podem ser iniciadas. O gravador SQL neste ponto faz a fase de refazer da recuperação após falhas. Se a recuperação não for solicitada (ou seja, SetAdditionalRestores(true) não for especificada pelo solicitante), a fase de desfazer da etapa de recuperação também será executada durante essa fase.

Detalhes da opção de backup e restauração

Esta seção descreve em detalhes todas as opções de backup e restauração suportadas pelo gravador SQL.

O solicitante cria uma cópia de sombra de volume

O gravador SQL pode estar envolvido no processo de criação de cópias de sombra de volume (fora do contexto de backup e restauração), porque os volumes de backup para os arquivos de banco de dados foram adicionados ao conjunto de instantâneos de volume. Nesse caso, o gravador SQL participa apenas da enumeração de metadados, Freeze, Thaw, PrepareForSnapshote PostSnapshot coordenação (consulte o diagrama de fluxo de dados para obter detalhes).

Backup e restauração completos

O gravador SQL oferece suporte a operações completas de backup e restauração no modo não baseado em componentes e no modo baseado em componentes.

Backup e restauração não baseados em componentes

Em um backup e restauração não baseados em componentes, o solicitante especifica um volume ou uma árvore de pastas para backup e restauração. Todos os dados no volume e pasta especificados são copiados e restaurados.

Backup

Em um backup não baseado em componentes, o gravador SQL seleciona implicitamente bancos de dados usando a lista de volumes no conjunto de snapshots. O escritor verifica se há bancos de dados rasgados, gerando um erro se forem encontrados. Um banco de dados rasgado é aquele em que um subconjunto de arquivos é selecionado pela lista de volumes. Não há suporte para roll-forward (restaurações diferenciais ou de log) após uma restauração através do SQL writer.

Restaurar

O solicitante restaura os bancos de dados cujo backup foi feito no modo não baseado em componentes. Essas restaurações não podem ser acompanhadas por uma restauração roll-forward, como restauração de log ou restauração diferencial.

Para operações de restauração não baseadas em componentes, a restauração deve ser executada com a instância do SQL Server offline ou os bancos de dados de destino são descartados/desanexados para garantir que os arquivos estejam offline. Os arquivos são copiados no local e, em seguida, os bancos de dados anexados. Tudo isso acontece fora do escopo do escritor SQL.

Backup e restauração baseados em componentes

Em um backup baseado em componentes, o solicitante seleciona explicitamente os componentes do banco de dados (dos metadados que o gravador SQL retorna ao cliente) para backup/restauração.

Backup

Em um backup baseado em componentes, todos os volumes de backup para bancos de dados selecionados devem ser incluídos no conjunto de instantâneos de volume. Caso contrário, o gravador SQL deteta bancos de dados rasgados (com volumes de cópias de segurança fora do conjunto de snapshots) e falha o backup. Um backup completo faz backup dos dados do banco de dados e de todos os arquivos de log necessários para colocar o banco de dados em um estado transacionalmente consistente no momento da restauração.

Restauração completa sem avanço contínuo

Às vezes, uma restauração completa do backup do banco de dados é realizada sem fazer nenhuma roll-forward adicional. Isso pode ocorrer porque não há metadados para facilitar o roll-forward ou, em alguns casos, roll-forward não é necessário. Esta secção aborda sucintamente estas duas situações.

Sem metadados/sem roll-forward

Se nenhum metadados do gravador (metadados de backup baseados em componentes) for salvo durante a operação de backup, a restauração deverá ser executada com a instância do SQL Server offline ou os bancos de dados de destino serão descartados/desanexados para garantir que os arquivos estejam offline. Os arquivos são copiados no local e, em seguida, os bancos de dados anexados. Tudo isso acontece fora do escopo do escritor SQL.

Existem metadados, mas não é necessário um avanço adicional

O solicitante restaura bancos de dados cujo backup foi feito no modo baseado em componente, mas nenhuma roll-forward é solicitada. Nesse caso, o SQL Server executa a recuperação de falhas no banco de dados como parte da restauração.

Restauração completa com roll-forward adicional

O requerente pode emitir uma restauração especificando a opção SetAdditionalRestores(true). Esta opção indica que o requerente vai efetuar o acompanhamento com mais restaurações roll-forward (como restauração de log, restauração diferencial, etc.). Isso instrui o SQL Server a não executar a etapa de recuperação no final da operação de restauração.

Isso só é possível se os metadados do gravador foram salvos durante o backup e estão disponíveis para o gravador SQL no momento da restauração. O serviço do SQL Server deve estar em execução antes que o solicitante direcione o VSS para executar a atividade de restauração.

O gravador SQL espera a seguinte sequência:

1. Preparação para restaurar cada banco de dados. Essa atividade envolve o fechamento de todos os identificadores de arquivo para permitir que os arquivos de banco de dados sejam copiados/montados pelo aplicativo solicitante.

2. Os arquivos são copiados/montados pelo aplicativo solicitante.

3. Finalize a restauração (com NORECOVERY). Os bancos de dados são colocados on-line, mas num estado de restauração.

Os backups convencionais, diferenciais ou logs do SQL Server podem ser utilizados para avançar o banco de dados por meio do VDI ou Transact-SQL, ou aplicando a restauração diferencial usando a estrutura VSS.

Suporte de texto completo

O escritor SQL reporta contentores do catálogo de texto integral com especificações de ficheiros recursivos sob os componentes de base de dados no documento de metadados do escritor. Eles são incluídos automaticamente no backup quando o componente de banco de dados é selecionado.

Backup e restauração diferenciais

Uma operação de backup diferencial faz backup apenas dos dados que foram alterados desde o backup completo de base mais recente. Um backup diferencial contém apenas as partes dos arquivos de banco de dados que foram alteradas. Para fazer esse backup, o solicitante (aplicativo de backup) precisaria de informações sobre o local das alterações nos arquivos de banco de dados, para que as seções apropriadas dos arquivos possam ser copiadas. Durante uma operação de backup diferencial, o gravador SQL fornece essas informações no formato especificado pelas informações de arquivo parcial do VSS. Essas informações podem ser usadas para fazer backup apenas da parte alterada dos arquivos de banco de dados.

Backup

O solicitante pode emitir um backup diferencial definindo a DIFFERENTIAL opção VSS_BT_DIFFERENTIAL no documento IVssBackupComponents::SetBackupStatedo componente de backup , ao iniciar uma operação de backup com o VSS. O gravador SQL passa as informações parciais do arquivo (retornadas a ele pelo SQL Server) para o VSS. O solicitante pode obter essas informações de arquivo chamando VSS API's IVssComponent::GetPartialFile. Essas informações parciais de arquivo permitem que o solicitante escolha apenas intervalos de bytes alterados para fazer backup dos arquivos de banco de dados.

Durante a fase de tarefas de pré-backup, o gravador SQL garante a existência de uma única base diferencial para cada banco de dados selecionado.

Durante o PostSnapshot evento, o gravador SQL obtém as informações parciais do arquivo do SQL Server e as adiciona ao documento do componente de backup usando uma chamada IVssComponent::AddPartialFile.

Formato de informação parcial do ficheiro

Para cada banco de dados cujo backup está sendo feito durante um backup diferencial, o gravador SQL armazena as informações parciais de cada arquivo de banco de dados. Essas informações são usadas pelo solicitante ou pelo aplicativo de backup para copiar apenas partes relevantes do arquivo para a mídia de backup durante o backup real dos arquivos.

Para obter mais informações sobre o formato desse arquivo parcial, consulte VSS (Serviço de Cópias de Sombra de Volume).

Um solicitante pode determinar esses arquivos chamando IVssComponent::GetPartialFileCount e IVssComponent::GetPartialFile. IVssComponent::GetPartialFile Retorna um caminho e um nome de ficheiro apontando para o ficheiro, e uma cadeia de caracteres de intervalos indicando o que precisa ser salvaguardado no ficheiro.

Para obter mais informações sobre a recuperação parcial de informações de arquivo, consulte a documentação do VSS.

Fazer backup de arquivos

Durante essa fase, o aplicativo de backup deve examinar os metadados do gravador armazenados no documento do componente de backup e fazer backup apenas das partes relevantes dos arquivos. (Para arquivos de catálogo de texto completo, esse backup deve ser feito com base nos carimbos de data/hora do arquivo. Isso é descrito mais adiante neste artigo).

Um backup diferencial sempre se relaciona com o backup de base mais recente que existe para o banco de dados. No momento da restauração, o SQL Server deteta backups básicos e diferenciais incompatíveis. Portanto, é responsabilidade do administrador do aplicativo de backup ou do sistema ter certeza de que o diferencial é relativo ao backup completo esperado. Se algum procedimento fora de banda tiver realizado outro backup completo, a aplicação de backup pode não conseguir restaurar o diferencial, uma vez que não detém o backup de base.

Atualmente, se as informações do intervalo de bytes (informações parciais do arquivo) forem muito grandes (excedendo 64 KB no tamanho do buffer), o SQL Server lançará um erro instruindo o usuário a executar um backup completo.

Solução de problemas

Ações de adicionar/remover/reduzir/crescer/renomeação lógica/renomeação física de ficheiros criam casos interessantes na resolução de problemas de backup.

Arquivos recém-adicionados depois que a base foi tomada

Esses arquivos são incluídos na especificação parcial porque cada cabeçalho do arquivo de banco de dados precisa estar na especificação parcial. Além da página de cabeçalho, todas as páginas alocadas precisam ser incluídas na especificação parcial.

Arquivos descartados após a base ter sido tomada

Depois que a base foi tomada, os arquivos de dados poderiam ser descartados. Esses ficheiros não são incluídos no documento de metadados do autor durante a cópia de segurança diferencial. Além disso, nenhuma informação parcial está associada ao arquivo descartado.

Os arquivos encolheram depois que a base foi tomada

As informações parciais não são coletadas dos arquivos até que as reduções de arquivo tenham sido desabilitadas no servidor. Isso garante que o VSS nunca inclua nenhuma informação parcial que corresponda à região reduzida de um arquivo de dados.

Arquivos criados depois que a base foi tomada

Se o crescimento ocorreu antes da coleta de informações parciais, as informações parciais deveriam ter incluído as páginas alocadas na região cultivada. Se o crescimento ocorreu após a coleta de informações parciais, as informações parciais não incluem mudanças na região cultivada. Nas secções a seguir, irá ver que essas alterações são restauradas pelo avanço do log.

Arquivo logicamente renomeado após a base ter sido tomada

Uma renomeação lógica do arquivo não afeta o backup ou a restauração, uma vez que o nome lógico do arquivo não é referenciado em nenhum lugar no documento de metadados do gravador ou no documento do componente de backup.

Para obter mais informações, consulte Documento de metadados do Escritor: um exemplo mais à frente neste artigo.

Arquivo fisicamente renomeado após a base ter sido tomada

Uma renomeação de arquivo de banco de dados físico não terá efeito até que o banco de dados seja reiniciado. Portanto, as informações de configuração do banco de dados ou as informações do caminho do arquivo no buffer parcial de informações ainda se baseiam nos caminhos físicos antigos, que são os únicos caminhos válidos para esses arquivos de banco de dados no instantâneo.

Restaurar

Durante uma restauração diferencial, os metadados de backup que o solicitante devolve ao gravador SQL têm as informações de tipo de backup. Portanto, nenhum tratamento especial do autor de SQL é necessário. O SQL Server descobre automaticamente que é uma restauração diferencial. O SQL Server lida com essa restauração diferencial da mesma forma que em relação a uma restauração diferencial nativa que não é executada por meio do VSS.

Fase de pré-restauração

Durante essa fase, o SQL Server redimensiona todos os arquivos para o tamanho apropriado com base nos metadados de arquivo do backup diferencial. Se o arquivo for aumentado, o SQL Server zerará a parte cultivada. Se um novo arquivo tiver que ser criado (ele foi criado depois que a base foi tirada), o SQL Server zerará o novo arquivo. Ele também fecha todos os identificadores de arquivo para que o aplicativo de backup possa substituir os arquivos com os dados restaurados da mídia de backup.

Restaurar ficheiros

O cliente deve restaurar os arquivos com base na especificação parcial do arquivo. Os dados devem ser restaurados para o mesmo deslocamento/intervalo do arquivo de banco de dados conforme especificado na especificação de arquivo parcial armazenada nos metadados do gravador.

O processo de adicionar, remover, aumentar, diminuir, renomear logicamente ou fisicamente arquivos de banco de dados volta a criar casos interessantes para a resolução de problemas durante a restauração.

Se um arquivo de banco de dados tiver sido adicionado após a base completa ter sido tomada

Esses arquivos devem ter sido pré-criados pelo SQL Server durante a fase de preparação da restauração. Eles deveriam ter sido estendidos para o tamanho certo e zerados. O cliente só precisa estabelecer os dados de acordo com a especificação parcial (a especificação parcial inclui todas as extensões alocadas).

Se um arquivo de banco de dados tiver sido descartado depois que a base completa foi tirada

As informações parciais fornecidas pelo SQL Server não incluem nenhuma informação de rastreio para essas transferências de ficheiros. O SQL Server é responsável por detetar os arquivos a serem excluídos, comparando os metadados dos arquivos restaurados com os contêineres existentes e realmente excluí-los. Isso é feito antes da restauração como uma etapa de preparação.

Se um arquivo de banco de dados tiver crescido desde que a base completa foi tomada

Esses arquivos devem ser estendidos para o tamanho certo pelo SQL Server durante a fase de preparação da restauração. A região estendida também deve ser zerada pelo SQL Server. Portanto, o cliente pode armazenar os dados com segurança, mesmo na região desenvolvida, de acordo com a especificação parcial. Se o arquivo tiver crescido depois que as informações parciais tiverem sido obtidas, as alterações na região cultivada serão restauradas reproduzindo o log do qual foi feito backup junto com o backup diferencial.

Se um arquivo de banco de dados tiver diminuído desde que a base completa foi tomada

O SQL Server é responsável por truncar o arquivo para o tamanho necessário de acordo com os metadados. Isso é feito antes da restauração como uma etapa de preparação.

Se um arquivo de banco de dados tiver sido logicamente renomeado desde que a base completa foi tomada

Isso não afeta a restauração, pois o nome lógico não aparece no documento de metadados do gravador ou no documento do componente de backup. A alteração de nome lógico é restaurada quando o cliente aplica a alteração ao arquivo de banco de dados primário, que contém as informações do catálogo do sistema.

Se um arquivo de banco de dados tiver sido fisicamente renomeado desde que a base completa foi tomada

Se, no momento do backup diferencial, a renomeação não tiver entrado em vigor, o cliente ainda restaurará os dados para o local antigo. Uma reinicialização do banco de dados pós-restauração faz com que a renomeação física entre em vigor. Se, no momento do backup diferencial, a renomeação do arquivo físico já tiver entrado em vigor, o backup dos dados parciais, se houver, será feito a partir do novo caminho físico.

Pós-restauração

Durante os eventos de pós-restauração, o gravador SQL executa a operação normal de refazer e recuperação (se SetAdditionalRestores() estiver definido como False) do banco de dados.

Cópia de segurança e restauração diferencial para catálogos de texto completo

Os catálogos de texto completo do SQL Server fazem parte dos recursos de banco de dados que precisam ser copiados ou restaurados junto com o restante dos arquivos de banco de dados. O backup diferencial para o catálogo de texto completo é baseado numa marca de hora. O backup diferencial e a restauração do VSS do SQL Server possuem um único backup de base. Em outras palavras, não há bases diferentes para diferentes contêineres. Para o backup de catálogo de texto completo VSS, isso significa que, para todos os contêineres de catálogo de texto completo, o backup diferencial é baseado em carimbo de data/hora único, ao contrário do caso do backup diferencial nativo do SQL Server, no qual há uma base de carimbo de data/hora por contêiner de catálogo de texto completo.

No VSS, este carimbo de data/hora é expresso como uma propriedade pertencente a todo o componente, que é definida durante o backup completo e utilizada durante um backup diferencial posterior.

OnIdentify

No OnIdentify, o gravador SQL chama IVssCreateWriterMetadata::SetBackupSchema() para definir o valor VSS_BS_TIMESTAMPED. Isso indica ao aplicativo de backup que o gravador SQL possui o gerenciamento da base diferencial.

Definir o carimbo de data/hora base

O carimbo de data/hora base é definido durante um backup completo. No OnPostSnapshot(), o escritor invoca IVssComponent::SetBackupStamp() para armazenar o carimbo de data/hora juntamente com o componente no documento de backup.

Backup diferencial

O aplicativo de backup recupera esse carimbo de data/hora do backup completo de base e disponibiliza o carimbo de data/hora para o gravador chamando IVssComponent::GetBackupStamp() para recuperar o carimbo de base do backup de base anterior. Em seguida, ele o disponibiliza para o escritor ligando para IVssBackupComponent::SetPreviousBackupStamp(). Em seguida, o Writer recupera o carimbo chamando IVssComponent::GetPreviousBackupStamp() e o traduz em um carimbo de data/hora usado para IVssComponent::AddDifferencedFilesByLastModifyTime().

Responsabilidade do aplicativo de backup durante o backup diferencial

Durante um backup diferencial, o aplicativo de backup é responsável por:

• Fazer backup de qualquer ficheiro (o ficheiro inteiro) cujo carimbo de data/hora da última modificação seja maior do que o carimbo de data/hora especificado pela hora da última modificação para o conjunto de ficheiros no componente.

• Rastreando e detetando arquivos excluídos.

Responsabilidades do aplicativo de backup durante uma restauração diferencial

Durante uma restauração diferencial, o aplicativo de backup é responsável por:

• Restaurando todos os arquivos cujo backup foi feito, seja criando um novo arquivo, se ele ainda não existir, ou substituindo um arquivo existente, se ele já existir.

• Aumentar o arquivo antes de definir o conteúdo se o arquivo restaurado for maior do que o arquivo existente.

• Truncar o arquivo para o mesmo tamanho do arquivo restaurado se o arquivo restaurado for menor do que o arquivo existente.

• Excluir todos os arquivos que devem ser excluídos; ou seja, aqueles arquivos que não deveriam existir a partir do momento do backup diferencial.

Backup somente cópia

Às vezes, é necessário fazer um backup destinado a uma finalidade especial. Por exemplo, talvez seja necessário fazer uma cópia de um banco de dados para fins de teste. Esse backup não deve afetar os procedimentos gerais de backup e restauração do banco de dados. O uso da COPY_ONLY opção especifica que o backup é feito fora da banda e não deve afetar a sequência normal de backups. O gravador SQL suporta o tipo de backup apenas cópia em instâncias do SQL Server.

Durante a fase de descoberta de backup, o gravador SQL indica a sua capacidade de fazer um backup de cópia única, definindo a opção VSS_BS_COPY de esquema de backup suportado usando a chamada IVssCreateWriterMetadata::SetBackupSchema. O solicitante pode definir o tipo de backup como um backup de apenas cópia ao definir a opção VSS_BACKUP_TYPE como VSS_BT_COPY com a chamada IVssBackupComponents::SetBackupState.

Quando um backup somente cópia é selecionado, presume-se que os arquivos no disco são copiados para uma mídia de backup (pelo solicitante), independentemente do estado do histórico de backup de cada arquivo. O SQL Server não atualiza o histórico de backup. Esse tipo de backup não constitui um backup básico para operações de backup diferenciais adicionais e também não perturba o histórico dos backups diferenciais anteriores.

Restaurar com transferência

O VSS permite que o solicitante (aplicativo de backup) especifique um novo destino de restauração usando a IVssComponent::SetNewTarget chamada. Em ambos, PreRestore() e PostRestore(), o gravador SQL verifica se há pelo menos um novo destino especificado. É responsabilidade do aplicativo de backup copiar fisicamente os arquivos para o novo local durante o tempo real de restauração/cópia do arquivo.

O aplicativo de backup só tem permissão para especificar novos destinos para o caminho físico, mas não a especificação do arquivo. Por exemplo, para um arquivo de banco de dados localizado em c:\data\test.mdf, o nome test.mdf do arquivo real não pode ser alterado. Apenas o caminho c:\data pode ser alterado. Para um contêiner de catálogo de texto completo localizado em c:\ftdata\foo, uma vez que a especificação do arquivo no VSS é "*" e a especificação do caminho no VSS é c:\ftdata\foo, todo o caminho pode ser alterado.

Renomeação do banco de dados

Um solicitante pode precisar restaurar um banco de dados do SQL Server com um novo nome, especialmente se o banco de dados for restaurado lado a lado com o banco de dados original. Esta opção pode ser especificada pelo solicitante durante a operação de restauração, definindo uma opção de restauração personalizada como "New Component Name" = <"New Name"> usando a chamada IVssBackupComponents::SetRestoreOptions() VSS (no wszRestoreOptions parâmetro).

O escritor SQL utiliza o valor completo de "Novo Nome do Componente" como o novo nome para o banco de dados restaurado. Se nenhuma opção for especificada, o SQL Server restaurará o banco de dados com seu nome original (nome do componente).

Instantâneos recuperados automaticamente

Normalmente, um instantâneo do banco de dados do SQL Server obtido utilizando a estrutura VSS está num estado não recuperado. Os dados no snapshot não podem ser acessados com segurança antes de passar pela fase de recuperação para reverter transações em voo e colocar o banco de dados em um estado consistente. Como o instantâneo está num estado de leitura apenas, ele não pode ser recuperado pelo processo normal de anexar à base de dados.

É possível recuperar automaticamente os snapshots como parte do processo de criação de snapshots. Como parte do documento de metadados do gravador, o gravador SQL especifica o sinalizador VSS_CF_APP_ROLLBACK_RECOVERY do componente para indicar que a recuperação precisa ser executada para o banco de dados no snapshot antes que o banco de dados possa ser acessado ao especificar o conjunto de snapshots, o solicitante pode indicar que o snapshot deve ser um snapshot de reversão de aplicativo (ou seja, todos os arquivos de banco de dados em um snapshot devem estar em um estado consistente para uso do aplicativo) ou um snapshot de backup (um snapshot usado para fazer backup de dados a serem restaurados posteriormente se houver uma falha do sistema).

O solicitante deve definir VSS_VOLSNAP_ATTR_ROLLBACK_RECOVERY para indicar que o backup desse componente está sendo feito para uma finalidade que não seja de backup. Em seguida, o VSS correlaciona VSS_CF_APP_ROLLBACK_RECOVERY com o especificado pelo gravador SQL no componente selecionado VSS_VOLSNAP_ATTR_ROLLBACK_RECOVERY, e determina que a recuperação automática está em curso. O VSS torna o snapshot gravável por um período limitado de tempo e adiciona automaticamente o VSS_VOLSNAP_ATTR_AUTORECOVERY bit ao contexto do snapshot.

No SQL Server, a recuperação automática deverá ser aplicada apenas a instantâneos de reversão de aplicação, mas não a instantâneos de backup. Para snapshots de reversão de aplicativos, um processo de recuperação automática é iniciado pelo gravador SQL durante o PostSnapShotevent. Esse processo faz o seguinte para cada banco de dados SQL Server explicitamente selecionado (pelo solicitante) no conjunto de instantâneos:

• Anexe o banco de dados de instantâneo à instância original do SQL Server (ou seja, a instância à qual o banco de dados original está anexado).

• Recupere o banco de dados (isso acontece como parte da operação "anexar").

• Reduza os arquivos de log.

  Isso reduz a quantidade de operações desnecessárias de copy-on-write que precisam ser feitas pelo framework VSS, caso o fornecedor VSS seja um fornecedor de software. Reduzir os arquivos de log é o comportamento padrão. Isso pode ser desabilitado definindo o valor para a seguinte chave do Registro como 1.

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

  Isso pode ser útil em cenários em que o instantâneo pode ser usado para exportar dados de uma página específica (em um ponto específico no tempo) do log para corrigir um problema no banco de dados online.

• Desanexe o banco de dados.

Agora há um instantâneo consistente e recuperado que pode ser anexado para consulta.

Transações em vários bancos de dados

Em versões mais antigas do SQL Server, as bases de dados de instantâneos às vezes contêm transações em andamento envolvendo múltiplas bases de dados. Durante o processo de recuperação, o gravador SQL acopla a base de dados aos instantâneos com a opção Presumed Abort. Isso reverteria qualquer transação de vários bancos de dados que ainda não esteja confirmada (incluindo quaisquer transações que estejam em um estado Preparado para confirmar). Isso pode levar a algumas inconsistências entre bancos de dados no conjunto de instantâneos.

Por exemplo, considere dois bancos de dados A e B. Há uma transação distribuída entre esses dois bancos de dados e essa transação está no estado Confirmado no banco de dados A e no estado Preparado para Confirmar no banco de dados B. Como parte do processo de recuperação automática, essa transação é confirmada no banco de dados A e revertida no banco de dados B. Isso pode levar a algumas inconsistências no conjunto de instantâneos.

As versões mais recentes do Windows têm um componente Microsoft Distributed Transaction Coordinator (MS DTC) melhorado que corrige esse problema de inconsistência para transações que abrangem bancos de dados em instâncias do SQL Server. As versões mais recentes do SQL Server corrigem essas inconsistências para transações que abrangem bancos de dados em uma instância do SQL Server.

Implicações de segurança para snapshots recuperados automaticamente

Para os instantâneos VSS, após a recuperação automática, os arquivos são protegidos usando ACLs (Listas de Controle de Acesso) para permitir acesso apenas ao grupo interno especial ao qual pertence a conta do SQL Server. Isso implica que os membros de qualquer administrador de caixa ou desse grupo especial podem anexar o banco de dados. O cliente que solicita a anexação dos arquivos de banco de dados num instantâneo deve ser membro de Builtin/Administrators ou ter acesso à conta do SQL Server.

Bancos de dados de usuário de modelo de recuperação simples

Se o master banco de dados for restaurado juntamente com bancos de dados de usuário que estão usando o modelo de recuperação simples, os bancos de dados de usuário podem ser restaurados com a mesma técnica do master banco de dados: com a instância desligada, basta copiar ou montar os volumes. Quando a instância SQL é iniciada, tudo se recupera.

Avançar bancos de dados de utilizadores

Se os bancos de dados de usuário devem ser recuperados e avançados junto com master a recuperação do banco de dados, a instância não deve iniciar e recuperar os bancos de dados de master e usuário juntos.

O procedimento é o seguinte:

1. Verifique se a instância do SQL Server está parada.

2. Execute a restauração em duas fases.

   1. Restaure os bancos de dados do sistema e os bancos de dados de usuários que devem ser recuperados ao mesmo tempo (ou seja, bancos de dados de usuários no modelo de recuperação simples) via cópia de arquivo ou montagem de volume, por meio do VSS.

      • Se os bancos de dados de usuário a serem implantados não estiverem no mesmo volume que os bancos de dados do sistema, esse volume não deverá ser trazido de volta neste momento. Esse cenário requer planejamento antes do backup.

      • Se os bancos de dados de usuário estiverem no mesmo volume que os bancos de dados do sistema, os bancos de dados de usuário precisarão ser ocultos do SQL Server.

   2. Inicie a instância do SQL Server usando o -f parâmetro. (Ao usar a -f opção de inicialização, somente o master banco de dados pode ser restaurado.)

      1. Emita um ALTER DATABASE <database> SET OFFLINE (ou desanexar o banco de dados) para cada banco de dados a ser avançado.

      2. Pare a instância do SQL Server.

      3. Inicie a instância do SQL Server (os arquivos para os bancos de dados de usuário rolarem para frente não são visíveis para o SQL Server).

Use o VSS para restaurar os bancos de dados WITH NORECOVERYdos utilizadores, conforme descrito em Restauração completa com *roll-forward* adicional.

Documento de metadados do Writer: um exemplo

Um banco de dados chamado DB1, pertencente à instância Instance1 do SQL Server na máquina Server1, contém os seguintes arquivos de banco de dados/log:

• Arquivo de banco de dados chamado "primário" armazenado em c:\db\DB1.mdf
• Arquivo de banco de dados chamado "secundário" armazenado em c:\db\DB1.ndf
• Arquivo de log do banco de dados chamado "log" armazenado em c:\db\DB1.ldf
• Catálogo de texto completo chamado "foo" armazenado no diretório c:\db\ftdata\foo
• Catálogo de texto completo chamado "bar" armazenado no diretório c:\db\ftdata\bar

A seguir estão os metadados do escritor do banco de dados.

Componente de grupo de arquivos no nível do banco de dados

Arquivo de banco de dados primário:

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

Arquivo de banco de dados secundário:

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

Registo de ficheiros de texto completo:

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

Arquivo 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 ficheiros 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

Se a instância do servidor for a instância padrão na máquina, o caminho lógico se tornará uma parte: Server1.

Casos especiais

Esta seção descreve alguns dos casos especiais encontrados durante as operações de backup e restauração baseadas em gravador SQL.

Fechar bancos de dados automaticamente

Para backups não baseados em componentes, o fechamento automático de bancos de dados é feito ao verificar condições rasgadas, mas os bancos de dados fechados automaticamente não são explicitamente congelados durante as operações de backup.

O cenário esperado aqui é que muitos bancos de dados fechados podem existir e você deseja minimizar o custo do snapshot. Os bancos de dados fechados automaticamente são normalmente usados em configurações low-end onde os recursos são escassos.

Lista de ficheiros

A lista de arquivos para cada banco de dados é determinada durante uma etapa de enumeração antes do evento Preparar para Backup. Se a lista de arquivos de banco de dados for alterada entre enumeração e congelamento, o banco de dados poderá ser rasgado, a menos que o aplicativo verifique novamente a lista de arquivos. Embora esse cenário seja improvável, é algo que os fornecedores precisam estar cientes.

Instâncias paradas

Se uma instância do SQL Server não estiver em execução no momento em que a etapa de enumeração ocorrer, nenhum dos bancos de dados dessas instâncias poderá ser selecionado.

Se uma instância parar no intervalo entre a enumeração e o evento Preparar para Backup, todos os bancos de dados na instância interrompida serão ignorados.

Bases de dados de sistemas e utilizadores

Os bancos de dados do sistema no SQL Server incluem o master, modele os msdb bancos de dados enviados e instalados como parte do SQL Server. Esta seção descreve como esses bancos de dados são tratados em um processo de backup de instantâneo VSS.

O master banco de dados só pode ser restaurado interrompendo a instância, substituindo os arquivos de banco de dados (feito pelo aplicativo de backup) e, em seguida, reiniciando a instância. Não é possível avançar.

O gravador SQL oferece suporte à restauração on-line de ambos os bancos de dados model e msdb, sem desligar a instância.

Conteúdo relacionado

• Registro de log do gravador VSS do SQL Server
• CÓPIA DE SEGURANÇA (Transact-SQL)
• Instruções RESTORE (Transact-SQL)
• Backup e restauração de bancos de dados do SQL Server
• Backups somente de cópia
• Backups de log de transações (SQL Server)
• Aplicar backups do log de transações (SQL Server)
• Guia de arquitetura e gerenciamento de log de transações do SQL Server