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

Aplica-se a:SQL Server para Windows

O SQL Server fornece suporte para o VSS (Serviço de Cópias de Sombra de Volume) ao providenciar um gravador (o Gravador do SQL), de modo que um aplicativo de backup de terceiros possa usar a estrutura VSS para fazer backup dos arquivos do banco de dados. Este documento descreve o componente Gravador do SQL e a função dele no processo de criação e restauração de instantâneos do VSS, para bancos de dados do SQL Server. Também captura detalhes de como configurar e usar o gravador SQL para trabalhar com aplicativos de backup no framework VSS.

Infraestrutura do VSS

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

• Coordena as atividades de provedores, gravadores e solicitantes na criação e no uso de cópias de sombra.
• Fornece o provedor do 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 do VSS sejam bem-sucedidas.

Componentes do VSS

O VSS coordena as atividades dos seguintes componentes de cooperação:

• Os provedores são os proprietários dos dados de cópia de sombra e criam uma instância das cópias de sombra.

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

• Os solicitantes iniciam a criação e a destruição das 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 Gravador do SQL) funciona como um gravador em uma das caixas do Gravador. Outros gravadores desse tipo podem ser o Exchange Server etc.

• Interface do Dispositivo Virtual: o SQL Server fornece uma interface de programação de aplicativo chamada VDI (Virtual Device Interface), que ajuda fornecedores de software independentes a integrar o SQL Server em seus produtos fornecendo suporte para operações de backup e restauração. Essas APIs são criadas para prover confiabilidade e desempenho máximos, e dão suporte a todas as funcionalidades de backup e de restauração do SQL Server , inclusive todas as capacidades de backup hot e instantâneo. Para obter mais informações, confira Especificação da Interface de Dispositivo de Backup Virtual do SQL Server 2005.

• Solicitante: um processo (automatizado ou por interface gráfica) que solicita que um ou mais conjuntos de instantâneos sejam tirados de um ou mais volumes originais. Neste artigo, o termo "solicitante" também se refere a um aplicativo de backup que está criando um instantâneo dos bancos de dados do SQL Server.

Para obter mais informações, confira Serviço de cópias de sombra de volume.

Escritor de SQL

O gravador SQL é um gravador VSS fornecido pela instância do SQL Server. Ele cuida da interação do VSS com o SQL Server. O SQL Writer é 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 do SQL em uma operação de backup de instantâneo do VSS:

Configurar o gravador do SQL

O serviço gravador do 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 gravador do SQL

Durante a instalação, a conta do escritor SQL é configurada para utilizar a conta do Sistema Local. Como o Gravador do SQL precisa se comunicar com o SQL Server usando APIs exclusivas da VDI, a conta do Gravador do SQL precisa ter direitos de acesso suficientes para o SQL Server e o VSS. A configuração do serviço como uma conta Sistema Local fornece direitos suficientes para que o serviço seja executado corretamente.

Habilitar e iniciar novamente o SQL Writer

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 gravador do SQL pode ser habilitado marcando esse serviço como Automático. Para abrir os serviços por meio do painel de controle, selecione Iniciar, selecione Painel de Controle, clique duas vezes em Ferramentas Administrativas e clique duas vezes em Serviços. No painel Serviços , clique duas vezes no serviço gravador do SQL e modifique a propriedade Tipo de Inicialização para Automático.

Em seguida, o serviço deve ser iniciado selecionando o botão Iniciar na propriedade Status do Serviço na tela da propriedade de serviço mencionada anteriormente.

Recursos compatíveis com o gravador do SQL

• Texto completo: o gravador do SQL relata contêineres de catálogo de texto completo com especificações de arquivo recursivo nos componentes do banco de dados no documento de metadados do gravador. Eles são incluídos automaticamente no backup quando o componente do banco de dados é selecionado.

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

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

  • Arquivo diferenciado pela hora da última modificação: o gravador do SQL usa o mecanismo VSS Differenced File by Last Modify Time para relatar arquivos alterados em catálogos de texto completo.

• Restauração com movimentação: o gravador do SQL dá suporte à especificação Novo Destino do VSS durante a restauração. A especificação Novo Destino permite que um arquivo de banco de dados/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 deve ser restaurado lado a lado com o banco de dados original. O Gravador do SQL dá 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 original do SQL.

• 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. Usar a opção COPY_ONLY especifica que o backup é feito fora de banda e não deve afetar a sequência normal de backups. O gravador do SQL dá suporte ao tipo de backup somente cópia com instâncias do SQL Server.

• Recuperação Automática do instantâneo do 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 instantâneo não podem ser acessados com segurança antes de passar pela fase de recuperação para reverter as transações em voo e colocar o banco de dados em um estado consistente. É possível que um aplicativo de backup do VSS solicite a recuperação automática dos instantâneos, como parte do processo de criação do instantâneo.

Esses novos recursos e seu uso são descritos com mais detalhes nos Detalhes da Opção de Backup e Restauração neste artigo.

O que não tem suporte

• Os backups de log não são compatíveis com o gravador do SQL.
• Não há suporte para backup de arquivo e grupo de arquivos.
• Não há suporte para restauração de página.
• Instantâneos de banco de dados não têm suporte e são ignorados durante a criação de instantâneos do VSS componente e não componente.
• Bancos de dados de fechamento automático ou bancos de dados com o 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 compatíveis com o gravador de 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) dá suporte aos seguintes modos de operações de backup baseadas em VSS:

• Não baseado em componente
• Baseados em componentes

Suporte de versão

O Gravador do SQL é enviado como parte do SQL Server e só dá suporte às instâncias do SQL Server. O gravador do SQL enumera também instâncias do SQL Server Express, incluindo instâncias de usuário iniciadas pelo SQL Server Express Edition.

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

Backups que não são baseados em componentes selecionam implicitamente bancos de dados usando a lista de volumes no conjunto de snapshots. O Gravador do SQL verifica se há bancos de dados subdivididos que geram um erro, se encontrado. Um banco de dados subdividido é aquele em que um subconjunto de arquivos é selecionado pela lista de volumes.

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

Operações de backup baseadas em componente

Os backups baseados em componente são preferenciais e recomendados com o gravador do SQL, já que o aplicativo (aplicativo de backup VSS) seleciona explicitamente os bancos de dados dos metadados retornados do gravador do SQL. O conjunto de instantâneos deve incluir todos os volumes necessários para fazer backup desses bancos de dados. A infraestrutura do VSS não adiciona automaticamente os volumes necessários para o conjunto de bancos de dados selecionado. Todos os volumes de backup devem ser incluídos no conjunto de instantâneos de volume. É responsabilidade do aplicativo de backup garantir que todos os volumes de backup sejam incluídos no conjunto de instantâneos. O gravador do SQL detecta bancos de dados rasgados (com volumes de backup fora do conjunto de instantâneos) e falha no backup.

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

Processo de criação de instantâneo

A estrutura do VSS coordena as atividades de um solicitante (um aplicativo de backup) e do gravador do 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 pelos aplicativos solicitantes e por escritores participantes. O Gravador do SQL implementa as interfaces de gravador necessárias. Como parte do processo de criação de instantâneo, as interfaces do Gravador do SQL são chamadas pela estrutura VSS. O escritor do SQL interage com as 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 de um aplicativo solicitante/de backup. Um desenvolvedor de aplicativos de backup precisa seguir esses padrões de chamada à API para trabalhar com o processo de criação de instantâneo da estrutura VSS. As seções a seguir descrevem o processo de criação de instantâneo do ponto de vista do Gravador do SQL. Elas também fornecem detalhes de algumas das interações internas entre o solicitante, a estrutura VSS, o Gravador do SQL e as instâncias do SQL Server.

Para mais informações sobre essas etapas e detalhes das interfaces da estrutura do VSS, consulte Volume Shadow Copy Service (VSS).

Fluxo de trabalho de criação de imagem instantânea

A imagem a seguir mostra o diagrama de fluxo de dados durante uma operação de criação de snapshot/backup baseada em componentes.

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 descoberta de backup
• Tarefas de pré-backup
• Backup real de arquivos
• Terminação de backup

Inicialização do backup

Durante essa fase do backup, o solicitante (aplicativo de backup) associa-se à interface de instantâneo IvssBackupComponents e inicializa-o em preparação para o backup. Ele também chama a API do VSS IVssGatherWriterMetadata para informar a estrutura do VSS para coletar metadados de todos os gravadores.

A estrutura do VSS chama cada um dos gravadores registrados, incluindo o gravador do SQL, para os metadados do gravador que usam o evento OnIdentify. O gravador do SQL consulta as instâncias do SQL Server para obter as informações de metadados de backup para cada banco de dados e criar o Documento de Metadados do Gravador. Essa fase também é conhecida como enumeração de metadados.

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

• A 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 é transmitido novamente 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 de Componente de Backup com cada componente que precisa ser feito backup. Ele também especifica as opções de backup e os parâmetros necessários como parte desse documento. Para o Gravador do SQL, cada instância do banco de dados que precisa ser copiada em backup é um componente separado.

Documento de componentes de backup

Este é um documento XML criado por um solicitante (com a interface IVssBackupComponents) no decorrer da configuração de uma operação de restauração ou backup. O documento de componentes de backup contém uma lista desses componentes explicitamente incluídos, de um ou mais gravadores, participando de uma operação de backup ou restauração. Ele não contém informações de componente incluídas implicitamente. Por outro lado, um documento de metadados do autor contém apenas componentes de autor que podem participar de um backup. Os detalhes estruturais de um documento de componente de backup são descritos na documentação da API do VSS.

Tarefas pré-backup

As tarefas pré-backup no VSS concentram-se 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 solicitantes normalmente esperam os gravadores durante a preparação para o backup e enquanto a cópia de sombra está sendo criada. Se o Gravador do SQL estiver participando da operação de backup, ele precisará configurar os arquivos e também estar pronto para o backup e a cópia de sombra.

Preparação do 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 do SQL recebe acesso ao documento do componente de backup, que detalha quais bancos de dados precisam ser armazenados em backup. Todos os volumes de backup devem ser incluídos no conjunto de instantâneos de volume. O gravador do SQL detecta bancos de dados rasgados (com volumes de backup fora do conjunto de instantâneos) e falha no backup durante o evento PostSnapshot.

Backup real dos arquivos

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

1. Obter status de escritor. Retorna o status dos gravadores. Talvez o solicitante precise lidar com quaisquer falhas aqui.
2. Faça o backup.

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

Backup concluído

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

Esse também é o momento em que o Gravador do SQL pode confirmar o backup como uma base diferencial, se o backup atual é um backup completo do banco de dados (e não um backup somente 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 apoiados no instantâneo. Esses metadados do gravador são necessários para o Gravador do SQL/o SQL Server em operações de restauração.

Término do backup

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

Documento de metadados do gravador do SQL

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

• Informações de Identificação do Autor

  • Nome do gravador – L"SqlServerWriter"
  • ID da classe do gravador – 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 no nível do gravador – VSS_APP_BACK_END

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

• Esquema de backup com suporte (API IVssCreateWriterMetadata::SetBackupSchema)

  • 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 na hora da última modificação.
  • VSS_BS_WRITER_SUPPORTS_NEW_TARGET – dá suporte à opção de localização de novo destino.
  • VSS_BS_WRITER_SUPPORTS_RESTORE_WITH_MOVE – dá suporte à restauração "com movimentação"
  • VSS_BS_COPY – dá suporte à opção de backup "somente cópia".

• Informações de nível de componente (contém informações específicas do nível do componente fornecidas pelo gravador do 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 "servidor" 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 para cenários de não backup (ou seja, reversão de aplicativo).
  • Selecionável – verdadeiro
  • Disponível para restauração – sim
  • Métodos de restauração compatíveis – 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. 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 os arquivos de log, considerando que o banco de dados VSS e os arquivos de log não têm especificação recursiva. Portanto, o gravador do SQL usa um componente de grupo de arquivos VSS (VSS_CT_FILEGROUP) para representar o componente de nível de banco de dados e os arquivos de grupo de arquivos para representar os arquivos de banco de dados, log e catálogo de texto completo.

Um documento de metadados de gravador de exemplo é fornecido no final deste documento.

Iniciar instantâneo

O solicitante inicia o processo de instantâneo chamando a interface da estrutura do VSS DoSnapshotSet.

Criar instantâneo

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

1. Preparar instantâneo. O gravador do SQL chama o SQL Server para se preparar para a criação de instantâneos.

2. Congelar. O gravador do SQL chama o SQL Server para congelar todas as E/Ss de banco de dados para cada um dos bancos de dados que estão sendo armazenados em backup no instantâneo. Depois que o evento de congelamento retorna à estrutura do VSS, o VSS cria o instantâneo.

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

A fase de criação do instantâneo leva menos de 60 segundos para impedir 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 do SQL fará a recuperação automática para cada banco de dados que foi selecionado para estar 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.

Fluxo de trabalho de operação de restauração

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

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

• Inicialização de restauração
• Preparando-se para restauração
• Restauração efetiva de arquivo
• Restaurar limpeza e término

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

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

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

Restaurar inicialização

Durante a fase de inicialização de uma restauração, o solicitante precisa ter acesso aos documentos de 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 transmitir esses dados novamente para a estrutura VSS. O gravador do SQL obtém acesso a esses dados no início do processo de restauração.

Preparar para 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 além da operação de restauração atual (ou seja, a restauração com sem recuperação é necessária), a opção a seguir deve ser definida como parte da criação do componente para cada banco de dados que está sendo restaurado.

IVssBackupComponents::SetAdditionalRestores(true)

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

O gravador do SQL examina o documento de componente de backup fornecido para identificar os bancos de dados apropriados, excluindo os arquivos adicionais criados desde o tempo de backup. Ele também verifica os espaços em disco e fecha os identificadores de arquivo de banco de dados abertos, de modo que o solicitante possa copiar os dados necessários durante a fase de restauração. Essa fase permite que qualquer condição de erro antecipada seja detectada antes que o solicitante faça a cópia real dos arquivos. O SQL Server também coloca o banco de dados em estado de restauração. Desse ponto em diante, o banco de dados não pode ser iniciado até uma restauração bem-sucedida.

Restaurar arquivos

Essa é meramente uma ação específica do solicitante. É 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 do SQL não está envolvido nesta operação.

Limpeza e encerramento

Depois que todos os dados forem restaurados para os locais certos, uma chamada de um solicitante notificando que a operação de restauração foi concluída IvssBackupComponents::PostRestore, permite que o gravador do SQL saiba que as ações pós-restauração podem ser iniciadas. O gravador do SQL neste momento executa a fase refazer da recuperação de falhas. Se a recuperação não for solicitada (ou seja, SetAdditionalRestores(true) não for especificada pelo solicitante), a fase de reversão do passo de recuperação também será executada durante este passo.

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

Esta seção descreve detalhadamente todas as opções de backup e restauração compatíveis com o gravador do SQL.

O solicitante cria uma cópia de sombra de volume

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

Backup e restauração completos

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

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 serem feitas cópias de segurança e restauração. Todos os dados na pasta e no volume especificados são submetidos a backup e restaurados.

Backup

Em um backup não baseado em componente, o gravador do SQL seleciona implicitamente bancos de dados usando a lista de volumes no conjunto de instantâneos. O gravador verifica se há bancos de dados subdivididos que geram um erro, se encontrado. Um banco de dados subdividido é aquele em que um subconjunto de arquivos é selecionado pela lista de volumes. Roll-forward (diferencial ou restaurações de log) depois que uma restauração não tem suporte por meio do gravador do SQL.

Restaurar

O solicitante restaura bancos de dados que foram copiados no modo não baseado em componentes. Essas restaurações não podem ser seguidas por uma restauração reversa, 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 então os bancos de dados são anexados. Tudo isso acontece fora do escopo do escritor de 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 escritor SQL retorna ao cliente) para serem usados no backup/restauração.

Backup

Em um backup baseado em componentes, todos os volumes de backup para os bancos de dados selecionados devem ser incluídos no conjunto de instantâneos de volume. Caso contrário, o gravador do SQL detectará bancos de dados rasgados (com volumes de backup fora do conjunto de instantâneos) e falhará no backup. Um backup completo faz backup de 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 roll forward

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

Nenhum metadado/nenhum avanço

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

Metadados existem, mas nenhum avanço adicional é necessário

O solicitante restaura bancos de dados que foram copiados em backup no modo baseado em componente, mas nenhum roll-forward é solicitado. Nesse caso, o SQL Server executa a recuperação de falha no banco de dados como parte da restauração.

Restauração completa com roll forward adicional

O solicitante pode emitir uma restauração especificando a opção SetAdditionalRestores(true) . Essa opção indica que o solicitante vai acompanhar 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ó será possível se os metadados do gravador tiverem sido salvos durante o backup e estiverem disponíveis para o gravador do SQL no momento da restauração. O serviço SQL Server precisa estar em execução antes que o solicitante instrua o VSS a executar a atividade de restauração.

O Escritor do 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 a fim de 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. Finalizar a restauração (com NORECOVERY). Os bancos de dados são colocados online, mas em um estado de restauração.

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

Suporte a texto completo

O gravador do SQL relata contêineres de catálogo de texto completo com especificações de arquivo recursivo nos componentes do banco de dados no documento de metadados do gravador. Eles são incluídos automaticamente no backup quando o componente do banco de dados é selecionado.

Backup diferencial e restauração

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 seções apropriadas dos arquivos possam ser backup. Durante uma operação de backup diferencial, o gravador do SQL fornece essas informações no formato, conforme especificado pelas informações de arquivo parciais 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 opção DIFFERENTIALVSS_BT_DIFFERENTIAL no documento IVssBackupComponents::SetBackupStatedo componente de backup ao iniciar uma operação de backup com o VSS. O gravador do SQL passa as informações parciais do arquivo (retornadas a ela pelo SQL Server) para o VSS. O solicitante pode obter essas informações de arquivo chamando a API do IVssComponent::GetPartialFileVSS. Essas informações de arquivo parcial permitem que o solicitante escolha apenas os intervalos de bytes alterados para fazer backup dos arquivos de banco de dados.

Na fase de tarefas de pré-backup, o escritor do SQL garante que exista uma única base diferencial para cada banco de dados selecionado.

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

Formato parcial das informações de arquivo

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

Para obter mais informações sobre o formato para essas informações parciais do arquivo, consulte o Volume Shadow Copy Service (VSS).

Um solicitante pode determinar esses arquivos chamando IVssComponent::GetPartialFileCount e IVssComponent::GetPartialFile. IVssComponent::GetPartialFile retorna um caminho e um nome de arquivo apontando para o arquivo e uma cadeia de caracteres de intervalos indicando o que precisa ser feito em backup no arquivo.

Para obter mais informações sobre a recuperação das informações de arquivo parcial, confira 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 posteriormente neste artigo).

Um backup diferencial sempre se relaciona com o backup base mais recente que existe para o banco de dados. No momento da restauração, o SQL Server detecta backups básicos e diferenciais incompatíveis. Portanto, é responsabilidade do aplicativo de backup ou administrador do sistema ter certeza de que o diferencial é relativo ao backup completo esperado. Se algum procedimento fora de banda tiver feito outro backup completo, o aplicativo de backup poderá não ser capaz de restaurar o diferencial, pois ele não possui o backup base.

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

Solução de problemas

Adição, remoção, redução, crescimento, renomeação lógica e renomeação física de arquivos geram casos interessantes na soluçã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 removidos depois que a base foi tomada

Depois que a base é obtida, os arquivos de dados podem ser removidos. Esses arquivos não são incluídos no documento de metadados do writer durante o backup diferencial. Além disso, nenhuma informação parcial está associada ao arquivo descartado.

Arquivos reduzidos depois que a base foi tomada

As informações parciais não são coletadas dos arquivos até que os encolhimentos de arquivos tenham sido desabilitados no servidor. Isso garante que o VSS nunca inclua informações parciais que correspondam à região reduzida de um arquivo de dados.

Arquivos cultivados depois que a base foi obtida

Se o crescimento tiver ocorrido antes de as informações parciais serem coletadas, as informações parciais deverão ter incluído as páginas alocadas na região aumentada. Se o crescimento ocorreu após a coleta das informações parciais, as informações parciais não incluem alterações na região cultivada. Nas seções a seguir, você verá que essas alterações são restauradas pelo roll-forward de log.

Arquivo renomeado logicamente depois que a base foi tomada

Uma renomeação lógica do arquivo não afeta o backup ou a restauração, pois 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 o documento de metadados do Writer: um exemplo neste artigo posterior.

Arquivo renomeado fisicamente depois que a base foi 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 de caminho do arquivo no buffer de informações parciais ainda são baseadas 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 retorna ao Gravador do SQL têm as informações de tipo de backup. Portanto, não é necessário nenhum tratamento especial por parte do gerador de SQL. O SQL Server descobre automaticamente que é uma restauração diferencial. O SQL Server manipula uma restauração diferencial da mesma forma que em 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 expandido, SQL Server zera a porção expandida. Se um novo arquivo precisar ser criado (ele foi criado depois que a base foi criada), o SQL Server zera o novo arquivo. Ele fecha também todos os identificadores de arquivo, permitindo que o aplicativo de backup substitua os arquivos pelos dados restaurados a partir da mídia de backup.

Restaurar arquivos

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

O arquivo de banco de dados add/drop/growth/shrink/logical-rename/physical-rename novamente torna interessantes os casos de solução de problemas no momento da restauração.

Se um arquivo de banco de dados tiver sido adicionado depois que a base completa foi tomada

Esses arquivos devem ter sido pré-criado pelo SQL Server durante a fase de preparação da restauração. Eles devem ter sido estendidos para o tamanho correto e zerados. O cliente só precisa dispor 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 removido depois que a base completa foi tomada

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

Se um arquivo de banco de dados cresceu 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 expandida, de acordo com a especificação parcial. Se o arquivo tiver sido cultivado após a tomada das informações parciais, as alterações na região adulta serão restauradas reproduzindo o log que foi feito com backup junto com o backup diferencial.

Se um arquivo de banco de dados encolheu 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 renomeado logicamente 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 renomeado fisicamente desde que a base completa foi tomada

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

Pós-restauração

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

Backup diferencial e restauração 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 em backup ou restaurados junto com o restante dos arquivos de banco de dados. Um backup diferencial é baseado no carimbo de data/hora para o catálogo de texto completo. O backup e a restauração diferenciais do VSS do SQL Server têm um só backup de base. Em outras palavras, não há bases diferentes para contêineres diferentes. Para o backup do catálogo de texto completo do VSS, isso significa que, para todos os contêineres de catálogo de texto completo, o backup diferencial é baseado em carimbo de data/hora, diferentemente 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, esse carimbo de data/hora é expresso como uma propriedade de todo o componente que é definida durante o backup completo e usada durante um próximo backup diferencial.

OnIdentify

In OnIdentify, o gravador SQL chama IVssCreateWriterMetadata::SetBackupSchema() para definir o valor VSS_BS_TIMESTAMPED. Isso indica ao aplicativo de backup que o escritor de SQL é responsável pelo gerenciamento da base diferencial.

Definir o carimbo de data/hora base

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

Backup diferencial

O aplicativo de backup recupera esse carimbo de data/hora do backup completo base e disponibiliza o carimbo de data/hora para o gravador chamando IVssComponent::GetBackupStamp() para recuperar o carimbo base do backup base anterior. Em seguida, ele o disponibiliza para o gravador chamando IVssBackupComponent::SetPreviousBackupStamp(). Em seguida, o gravador recupera o carimbo chamando IVssComponent::GetPreviousBackupStamp() e converte-o 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:

• Fazendo backup de qualquer arquivo (o arquivo inteiro) cujo carimbo de data/hora modificado último é maior do que o carimbo de data/hora especificado pelo último tempo de modificação para o conjunto de arquivos no componente.

• Acompanhar e detectar os 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 com backup, criando um novo arquivo se ele ainda não existir ou substituindo um arquivo existente se ele já existir.

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

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

• Removendo todos os arquivos que precisam ser eliminados; ou seja, os arquivos que não devem existir no momento do backup diferencial.

Backup de cópia única

À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. Usar a opção COPY_ONLY especifica que o backup é feito fora de banda e não deve afetar a sequência normal de backups. O gravador do SQL dá suporte ao tipo de backup somente cópia com instâncias do SQL Server.

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

Quando um backup somente cópia é selecionado, supõe-se que os arquivos em disco sejam copiados para um meio 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 base para operações de backup diferenciais adicionais e também não perturba o histórico dos backups diferenciais anteriores.

Restaurar e mover

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 escritor de 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 para a especificação de arquivo. Por exemplo, para um arquivo de banco de dados localizado em c:\data\test.mdf, o nome real do arquivo, test.mdf, não pode ser alterado. Somente 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 de arquivo no VSS é "*" e a especificação de caminho no VSS é c:\ftdata\foo, todo o caminho pode ser alterado.

Renomear 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 deve ser restaurado lado a lado com o banco de dados original. Essa opção pode ser especificada pelo solicitante durante a operação de restauração definindo uma opção de restauração personalizada como "Novo Nome do Componente" = <"Novo Nome"> usando a chamada IVssBackupComponents::SetRestoreOptions() VSS (no wszRestoreOptions parâmetro).

O gravador do SQL usa todo o conteúdo do valor do Novo Nome do Componente e o usa 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 de um banco de dados do SQL Server obtido usando o framework VSS está em um estado não recuperável. Os dados no instantâneo não podem ser acessados com segurança antes de passar pela fase de recuperação para reverter as transações em voo e colocar o banco de dados em um estado consistente. Como o instantâneo está em um estado somente leitura, ele não pode ser recuperado pelo processo normal de anexação do banco de dados.

É possível fazer a recuperação automática dos instantâneos como parte do processo de criação do instantâneo. Como parte do documento de metadados do gravador, o gravador do SQL especifica o sinalizador de componente VSS_CF_APP_ROLLBACK_RECOVERY para indicar que a recuperação precisa ser executada para o banco de dados no instantâneo antes que o banco de dados possa ser acessado ao especificar o conjunto de instantâneos, o solicitante pode indicar que o instantâneo deve ser um instantâneo de reversão de aplicativo (ou seja, todos os arquivos de banco de dados em um instantâneo devem estar em um estado consistente para uso do aplicativo) ou um instantâneo de backup (um instantâneo usado para fazer backup de dados a serem restaurados posteriormente se houver uma falha no 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 que o gravador do SQL especificou no componente selecionado com VSS_VOLSNAP_ATTR_ROLLBACK_RECOVERY e determina que a recuperação automática está acontecendo. O VSS torna o instantâneo gravável por um período limitado e adiciona automaticamente o bit VSS_VOLSNAP_ATTR_AUTORECOVERY ao contexto do instantâneo.

No SQL Server, a recuperação automática deve ser aplicado somente a instantâneos de reversão de aplicativo, mas não para instantâneos de backup. Para instantâneos de reversão de aplicativo, um processo de recuperação automática é iniciado pelo Gravador do SQL durante o PostSnapShotevent. Esse processo faz o seguinte para cada banco de dados do SQL Server selecionado explicitamente (pelo solicitante) no conjunto de instantâneos:

• Anexar 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).

• Recuperar o banco de dados (isso ocorre como parte da operação de "anexação").

• Reduzir os arquivos de log.

  Isso reduz a quantidade de cópia em gravação desnecessária que precisa ser feita pela estrutura VSS, se o provedor VSS for um provedor de software. A redução dos arquivos de log é o comportamento padrão. Isso pode ser desabilitado definindo o valor da seguinte chave do Registro para 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 momento específico) 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 de vários bancos de dados

Em versões mais antigas do SQL Server, os bancos de dados de instantâneo às vezes podem conter algumas transações de vários bancos de dados em versão de pré-lançamento. Durante a operação de recuperação, o gravador do SQL anexa o banco de dados nos instantâneos com a opção Anular Presumido. 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 snapshots.

As versões mais recentes do Windows têm um componente ms DTC (Coordenador de Transações Distribuídas da Microsoft) aprimorado que corrige esse problema de inconsistência para transações que abrangem bancos de dados em instâncias do SQL Server. 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 instantâneos recuperados automaticamente

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

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

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

Como efetuar roll forward de bancos de dados de usuário

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

O procedimento é o seguinte:

1. Verifique se a instância do SQL Server foi interrompida.

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

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

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

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

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

      1. Emita um ALTER DATABASE <database> SET OFFLINE (ou destatch o banco de dados) para cada banco de dados a ser revertido.

      2. Interrompa a instância do SQL Server.

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

Use o VSS para restaurar os bancos de dados de usuário WITH NORECOVERY, conforme descrito na Restauração completa com roll-forward adicional.

Documento de metadados do escritor: um exemplo

Um banco de dados chamado DB1, pertencente à instância Instance1 do SQL Server no computador 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 de 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

Estes são os metadados do escritor do banco de dados.

Componente do 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

Log de arquivo 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

Foo de arquivo de texto completo:

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 arquivo 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 no computador, 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 no SQL Writer.

Bancos de dados de fechamento automático

Para backups não baseados em componentes, o fechamento automático de bancos de dados é feito ao verificar se há condições interrompidas, mas os bancos de dados 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 instantâneo. Em geral, os bancos de dados fechados automaticamente são usados em configurações de baixo nível na qual os recursos são escassos.

Lista de arquivos

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 a enumeração e o congelamento, o banco de dados poderá ser subdividido, 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 interrompidas

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 for interrompida no intervalo entre a enumeração e o evento Preparação do Backup, todos os bancos de dados na instância interrompida serão ignorados.

Bancos de dados do sistema e do usuário

Os bancos de dados do sistema no SQL Server incluem os bancos de dados master, model e msdb, que são fornecidos 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 do VSS.

O master banco de dados só pode ser restaurado interrompendo a instância, substituindo os arquivos de banco de dados (feitos pelo aplicativo de backup) e reiniciando a instância. Nenhum roll forward é possível.

O gravador do SQL dá suporte à restauração de bancos de dados model e msdb online, sem desligar a instância.

Conteúdo relacionado

• Registro em log do gravador VSS do SQL Server
• BACKUP (Transact-SQL)
• Instruções RESTORE (Transact-SQL)
• Fazer backup e restaurar bancos de dados do SQL Server
• Backups somente cópia
• Backups de log de transações (SQL Server)
• Aplicar backups de log de transações (SQL Server)
• Guia de arquitetura e gerenciamento de log de transações do SQL Server