BACKUP (Transact-SQL)

Especifica opções a serem usadas com uma operação de backup.

• DIFFERENTIAL
  Usado apenas com BACKUP DATABASE, especifica que o backup de banco de dados ou de arquivo deve consistir apenas das partes do banco de dados ou arquivo alterado desde o último backup completo. Um backup diferencial normalmente usa menos espaço do que um backup completo. Use essa opção para que todos os backups de log individuais executados desde o último backup não precisem ser aplicados.

  Observação
  Por padrão, o BACKUP DATABASE cria um backup completo.

  Para obter mais informações, consulte Usando backups diferenciais.

Opções de conjunto de backup

Essas opções funcionam no conjunto de backup criado por esta operação de backup.

Observação
Para especificar um conjunto de backup para uma operação de restauração, use a opção FILE =<backup_set_file_number>. Para obter mais informações sobre como especificar um conjunto de backup, consulte "Especificando um conjunto de backup" em Argumentos de RESTORE (Transact-SQL).

• COPY_ONLY
  Especifica que o backup é um backup somente cópia, que não afeta a seqüência normal de backups. Um backup somente cópia é criado independentemente de seus backups convencionais agendados regularmente. Um backup somente cópia não afeta o backup global e restaura procedimentos do banco de dados.

  Backups somente cópia foram introduzidos no SQL Server 2005 para uso em situações em que um backup é feito com um objetivo especial, como fazer backup de log antes de uma restauração online. Normalmente, um backup de log somente cópia é usado uma vez e excluído em seguida.

  • Quando usado com BACKUP DATABASE, a opção COPY_ONLY cria um backup completo que não pode servir como uma base diferencial. O bitmap diferencial não é atualizado e backups diferenciais se comportam como se o backup somente cópia não existisse. Backups diferenciais subseqüentes usam o backup completo convencional mais recente como base.

    Importante
    Se as opções DIFFERENTIAL e COPY_ONLY forem usadas em conjunto, COPY_ONLY será ignorado e um backup diferencial será criado.

  • Quando usada com BACKUP LOG, a opção COPY_ONLY cria um backup de log somente cópia que não trunca o log de transações. O backup de log somente cópia não tem nenhum efeito na cadeia de logs e outros backups de log se comportam como se o backup somente cópia não existisse.

  Para obter mais informações, consulte Backups somente cópia.

• { COMPRESSION | NO_COMPRESSION }
  Especifica se compactação de backup é realizada neste backup. A compactação de backup foi introduzida no SQL Server 2008 Enterprise. A partir do SQL Server 2008 R2, a compactação de backup possui suporte pelo SQL Server 2008 R2 Standard e por todas as edições mais completas.

  Na instalação, o comportamento padrão é sem compactação de backup. Mas esse padrão pode ser alterado definindo a opção de configuração do servidor padrão de compactação de backup. Para obter informações sobre como exibir o valor atual dessa opção, consulte Como exibir propriedades do servidor (SQL Server Management Studio).

  • COMPRESSION
    Habilita explicitamente a compactação de backup.

    Observação
    Por padrão, quando um backup é compactado, somas de verificação são executadas para detectar danos de mídia.

  • NO_COMPRESSION
    Desabilita explicitamente a compactação de backup.

• DESCRIPTION = { 'text' | **@**text_variable }
  Especifica o texto de forma livre que descreve o conjunto de backup. A cadeia de caracteres pode conter um máximo de 255 caracteres.

• NAME = { backup_set_name| **@**backup_set_var }
  Especifica o nome do conjunto de backup. Nomes podem ter um máximo de 128 caracteres. Se NAME não estiver especificado, ele estará em branco.

• PASSWORD = { password | **@**password_variable }
  Define a senha do conjunto de backup. PASSWORD é uma cadeia de caracteres.

  Importante
  Esse recurso será removido na próxima versão do Microsoft SQL Server. Evite usar esse recurso em desenvolvimentos novos e planeje modificar os aplicativos que atualmente o utilizam.

  Se uma senha estiver definida para o conjunto de backup, ela deverá ser fornecida para executar qualquer operação de restauração do SQL Server no conjunto de backup. No entanto, uma senha de conjunto de backup não impede que o arquivo de backup seja substituído. Para impedir que um arquivo de backup seja substituído, use uma senha de conjunto de mídias (consulte a opção MEDIAPASSWORD, mais adiante nesta tabela). (Para obter mais informações sobre como usar senhas, consulte "Permissões", mais adiante neste tópico.)

  Observação sobre segurança

  A proteção fornecida por esta senha é fraca. Destina-se a impedir uma restauração incorreta com o uso de ferramentas do SQL Server por usuários autorizados ou não autorizados. Não impede a leitura dos dados de backup por outros meios ou a substituição da senha. A prática recomendada para proteger backups é armazenar as fitas de backup em um local seguro ou fazer backup em arquivos de disco protegidos por ACLs (listas de controle de acesso) adequadas. As ACLs devem ser definidas no diretório raiz no qual os backups são criados.

• { EXPIREDATE = 'date'| RETAINDAYS = days }
  Especifica quando o conjunto de backup desse backup pode ser substituído. Se essas duas opções forem usadas, RETAINDAYS terá precedência sobre EXPIREDATE.

  Se nenhuma opção estiver especificada, a data de validade será determinada pela definição da configuração da mídia deretenção. Para obter mais informações, consulte Definindo opções de configuração do servidor.

  Importante
  Essas opções apenas impedem que o SQL Server substitua um arquivo. Fitas podem ser apagadas por outros métodos e os arquivos de disco podem ser excluídos pelo sistema operacional. Para obter mais informações sobre verificação de validade, consulte SKIP e FORMAT neste tópico.

  • EXPIREDATE = { 'date'| **@**date_var }
    Especifica quando o conjunto de backup vence e pode ser substituído. Se fornecida como uma variável (@date_var), essa data deve seguir o formato datetime do sistema configurado e ser especificado como um dos seguintes:

    • Uma constante de cadeia de caracteres (@date_var = date)

    • Uma variável de tipo de dados de cadeia de caracteres (exceto para os tipos de dados ntext ou text)

    • Uma smalldatetime

    • Uma variável datetime

    Por exemplo:

    • 'Dec 31, 2020 11:59 PM'

    • '1/1/2021'

    Para obter informações sobre como especificar valores de datetime, consulte Usando dados de data e hora.

    Observação
    Para ignorar a data de validade, use a opção SKIP.

  • RETAINDAYS = { days| **@days_var }
    Especifica o número de dias que devem decorrer para que este conjunto de mídias de backup possa ser substituído. Se fornecido como uma variável (@**days_var), ela deve ser especificada como um inteiro.

Opções de conjunto de mídias

Essas opções funcionam no conjunto de mídias como um todo.

• { NOINIT | INIT }
  Controla se a operação de backup anexa ou substitui os conjuntos de backup existentes na mídia de backup. O padrão é anexar ao backup mais recente definido na mídia (NOINIT).

  Observação
  Para obter informações sobre as interações entre { NOINIT | INIT } e { NOSKIP | SKIP }, consulte "Comentários", mais adiante neste tópico.

  • NOINIT
    Indica que o conjunto de backup é anexado ao conjunto de mídias especificado, preservando conjuntos de backup existentes. Se uma senha de mídia estiver definida para o conjunto de mídias, a senha deverá ser fornecida. NOINIT é o padrão.

    Para obter mais informações, consulte Anexando a conjuntos de backup existentes.

  • INIT
    Especifica que todos os conjuntos de backup devem ser substituídos, mas preserva o cabeçalho de mídia. Se INIT estiver especificado, qualquer conjunto de backup existente naquele dispositivo será substituído, se as condições permitirem. Por padrão, BACKUP verificará as seguintes condições e não substituirá a mídia de backup se qualquer uma delas existir:

    • Um conjunto de backup ainda não expirou. Para obter mais informações, consulte as opções EXPIREDATE e RETAINDAYS.

    • O nome do conjunto de backup fornecido na instrução BACKUP, se fornecido, não corresponde ao nome na mídia de backup. Para obter mais informações, consulte a opção NAME, anteriormente nesta seção.

    Para substituir essas verificações, use a opção SKIP.

    Observação

    Se a mídia de backup estiver protegida por senha, o SQL Server não gravará na mídia a menos que a senha da mídia seja fornecida. Esta verificação não é substituída pela opção SKIP. Mídia protegida por senha pode ser substituída apenas através da reformatação da mídia, o que exclui os backups da mídia. Para obter informações sobre a senha de mídia, consulte "MEDIAPASSWORD", anteriormente neste tópico. Para obter informações sobre como reformatar mídia, consulte "FORMAT", anteriormente neste tópico.

    Para obter mais informações, consulte Substituindo conjuntos de backups.

• { NOSKIP | SKIP }
  Controla se a operação de backup verifica a data e a hora de validade dos conjuntos de backup existentes na mídia antes de substituí-los.

  Observação
  Para obter informações sobre as interações entre { NOINIT | INIT } e { NOSKIP | SKIP }, consulte "Comentários", mais adiante neste tópico.

  • NOSKIP
    Instrui a instrução BACKUP a verificar a data de validade de todos os conjuntos de backup na mídia antes de permitir que eles sejam substituídos. Esse é o comportamento padrão.

  • SKIP
    Desabilita a verificação de validade e nome do conjunto de backup que normalmente é executada pela instrução BACKUP para impedir a substituição de conjuntos de backup. Para obter informações sobre as interações entre { INIT | NOINIT } e { NOSKIP | SKIP }, consulte "Comentários", mais adiante neste tópico.

    Para exibir as datas de validade de conjuntos de backup, consulte a coluna expiration_date da tabela de histórico backupset.

• { NOFORMAT | FORMAT }
  Especifica se o cabeçalho da mídia deve ser gravado nos volumes usados para esta operação de backup, substituindo qualquer cabeçalho de mídia e conjuntos de backup existentes.

  • NOFORMAT
    Especifica que a operação de backup preserva o cabeçalho da mídia e os conjuntos de backup existentes nos volumes de mídia usados para esta operação de backup. Esse é o comportamento padrão.

  • FORMAT
    Especifica que um novo conjunto de mídias deve ser criado. FORMAT faz com que a operação de backup grave um novo cabeçalho de mídia em todos os volumes de mídia usados para a operação de backup. O conteúdo existente do volume se torna inválido, porque qualquer cabeçalho de mídia e conjuntos de backup existentes são substituídos.

    Importante
    Use FORMAT com cuidado. A formatação de qualquer volume de um conjunto de mídias renderiza todo o conjunto de mídias como inutilizável. Por exemplo, se você iniciar uma única fita pertencente a um conjunto de mídias distribuído existente, todo o conjunto de mídias será renderizado como inútil.

    A especificação de FORMAT implica SKIP. SKIP não precisa ser declarado explicitamente.

• MEDIADESCRIPTION = { text | **@**text_variable }
  Especifica a descrição de texto de forma livre do conjunto de mídias, com um máximo de 255 caracteres.

• MEDIANAME = { media_name | **@**media_name_variable }
  Especifica o nome da mídia de todo o conjunto de mídias de backup. O nome da mídia não deve ter mais de 128 caracteres. Se MEDIANAME estiver especificado, ele deverá corresponder ao nome da mídia especificado anteriormente já existente nos volumes de backup. Se não estiver especificado ou se a opção SKIP estiver especificada, não haverá nenhuma verificação do nome da mídia.

• MEDIAPASSWORD = { mediapassword | **@**mediapassword_variable }
  Define a senha do conjunto de mídias. MEDIAPASSWORD é uma cadeia de caracteres.

  Importante
  Esse recurso será removido na próxima versão do Microsoft SQL Server. Evite usar esse recurso em desenvolvimentos novos e planeje modificar os aplicativos que atualmente o utilizam.

  Se uma senha estiver definida para o conjunto de mídias, esta senha deverá ser fornecida para que seja possível criar um conjunto de backup neste conjunto de mídias. Além disso, essa senha de mídia também deve ser fornecida para executar qualquer operação de restauração no conjunto de mídias. Mídia protegida por senha pode ser substituída apenas por meio de reformatação. Para obter mais informações, consulte a opção FORMAT. (Para obter mais informações sobre como usar senhas, consulte a seção Permissões, mais adiante neste tópico.)

  Observação sobre segurança

  A proteção fornecida por esta senha é fraca. Destina-se a impedir uma restauração incorreta com o uso de ferramentas do SQL Server por usuários autorizados ou não autorizados. Não impede a leitura dos dados de backup por outros meios ou a substituição da senha. A prática recomendada para proteger backups é armazenar as fitas de backup em um local seguro ou fazer backup em arquivos de disco protegidos por ACLs (listas de controle de acesso) adequadas. As ACLs devem ser definidas no diretório raiz em que os backups são criados.

• BLOCKSIZE = { blocksize | **@**blocksize_variable }
  Especifica o tamanho do bloco físico, em bytes. Os tamanhos com suporte são 512, 1024, 2048, 4096, 8192, 16384, 32768 e 65536 (64 KB) bytes. O padrão é 65536 para dispositivos de fita e 512 para outros dispositivos. Normalmente, essa opção é desnecessária porque BACKUP seleciona automaticamente um tamanho de bloco apropriado ao dispositivo. A declaração explícita de um tamanho de bloco substitui a seleção automática de tamanho de bloco.

  Se estiver fazendo um backup que planeja copiar e restaurar de um CD-ROM, especifique BLOCKSIZE=2048.

  Observação
  Normalmente, essa opção afeta o desempenho apenas durante a gravação em dispositivos de fita.

Opções de transferência de dados

• BUFFERCOUNT = { buffercount | **@**buffercount_variable }
  Especifica o número total de buffers de E/S a ser usado para a operação de backup. É possível especificar qualquer inteiro positivo. No entanto, grandes números de buffers podem provocar erros de "memória insuficiente" devido a espaço de endereço virtual inadequado no processo Sqlservr.exe.

  O espaço total usado pelos buffers é determinado por: buffercount*****maxtransfersize.

  Observação
  Para obter informações importantes sobre como usar a opção BUFFERCOUNT, consulte o blog A opção incorreta de transferência de dados de BufferCount pode levar a condição de OOM.

• MAXTRANSFERSIZE = { maxtransfersize | **@**maxtransfersize_variable }
  Especifica a maior unidade de transferência em bytes a ser usada entre a mídia de backup e o SQL Server. Os valores possíveis são múltiplos de 65536 bytes (64 KB), estendendo-se até 4194304 bytes (4 MB).

Opções de gerenciamento de erros

Essas opções permitem determinar se somas de verificação de backup estão habilitadas para a operação de backup e se a operação será parada quando um erro for encontrado.

• { NO_CHECKSUM | CHECKSUM }
  Controla se somas de verificação de backup estão habilitadas.

  • NO_CHECKSUM
    Desabilita explicitamente a geração de somas de verificação de backup (e a validação de somas de verificação de página). Esse é o comportamento padrão, com exceção de um backup compactado.

  • CHECKSUM
    Habilita somas de verificação de backup, de forma que BACKUP possa fazer o seguinte:

    1. Antes de gravar uma página na mídia de backup, BACKUP verifica a página (soma de verificação de página ou página interrompida), se essas informações estiverem presentes na página.

    2. Independentemente de somas de verificação de página estarem presentes, BACKUP gera uma soma de verificação de backup separada para os fluxos de backup. Operações de restauração podem usar opcionalmente a soma de verificação de backup para validar se o backup não está corrompido. A soma de verificação de backup é armazenada na mídia de backup, não nas páginas do banco de dados. A soma de verificação de backup pode ser usada opcionalmente na hora da restauração.

    O uso de somas de verificação de backup pode afetar uma carga de trabalho e a taxa de transferência do backup.

    Esse é o comportamento padrão de um backup compactado.

• { STOP_ON_ERROR | CONTINUE_AFTER_ERROR }
  Controla se uma operação de backup pára ou continua depois de encontrar um erro de soma de verificação de página.

  • STOP_ON_ERROR
    Instrui BACKUP a falhar se uma soma de verificação de página não estiver correta. Esse é o comportamento padrão.

  • CONTINUE_AFTER_ERROR
    Instrui BACKUP a continuar apesar de encontrar erros como somas de verificação inválidas ou páginas interrompidas.

    Se não for possível fazer backup do final do log usando a opção NO_TRUNCATE quando o banco de dados estiver danificado, é possível tentar um backup do final do log especificando CONTINUE_AFTER_ERROR em vez de NO_TRUNCATE.

Opções de compatibilidade

• RESTART
  Não tem nenhum efeito. Esta opção é aceita pela versão para compatibilidade com versões anteriores do SQL Server.

Opções de monitoramento

• STATS [ **=**percentage ]
  Exibe uma mensagem sempre que outra percentage for concluída e é usada para medir o progresso. Se percentage for omitido, o SQL Server exibirá uma mensagem depois da conclusão de cada 10 por cento.

  A opção STATS informa a porcentagem concluída de acordo com o limite de relatório do próximo intervalo. Esse limite é aproximadamente a porcentagem especificada. Por exemplo, com STATS=10, se a quantidade concluída for 40%, a opção poderá exibir 43%. Para conjuntos de backup grandes, isso não é um problema, porque a porcentagem concluída muda muito lentamente entre chamadas de E/S concluídas.

Opções de fita

Essas opções são usadas apenas para dispositivos TAPE. Se um dispositivo que não seja de fita estiver sendo usado, essas opções serão ignoradas.

• { REWIND | NOREWIND }

  • REWIND
    Especifica que o SQL Server libera e rebobina a fita. REWIND é o padrão.

  • NOREWIND
    Especifica que o SQL Server mantém a fita aberta após a operação de backup. É possível usar essa opção para ajudar a melhorar o desempenho ao executar várias operações de backup em uma fita.

    NOREWIND implica NOUNLOAD e essas opções são incompatíveis dentro de uma única instrução BACKUP.

    Observação

    Se NOREWIND for usado, a instância do SQL Server reterá a propriedade da unidade de fita até que uma instrução BACKUP ou RESTORE em execução no mesmo processo use a opção REWIND ou UNLOAD, ou que a instância do servidor seja encerrada. Manter a fita aberta evita que outros processos a acessem. Para obter informações sobre como exibir uma lista de fitas abertas e fechar uma fita aberta, consulte Dispositivos de backup.

• { UNLOAD | NOUNLOAD}

  Observação
  UNLOAD/NOUNLOAD é uma configuração de sessão que persiste durante a vida útil da sessão ou até que ela seja redefinida especificando a alternativa.

  • UNLOAD
    Especifica que a fita é rebobinada e descarregada automaticamente quando o backup for concluído. UNLOAD é o padrão quando uma sessão começa.

  • NOUNLOAD
    Especifica que depois da operação BACKUP a fita permanecerá carregada na unidade de fita.

Observação
Para um backup em um dispositivo de backup de fita, a opção BLOCKSIZE afeta o desempenho da operação de backup. Normalmente, essa opção afeta o desempenho apenas durante a gravação em dispositivos de fita.

Opções específicas de log

Estas opções são usadas apenas com BACKUP LOG.

Observação
Se você não quiser fazer backups de log, use o modelo de recuperação simples. Para obter mais informações, consulte Backup com o modelo de recuperação simples.

• { NORECOVERY | STANDBY **=**undo_file_name }

  • NORECOVERY
    Faz backup do final do log e deixa o banco de dados no estado de RESTORING. NORECOVERY é útil ao executar failover em um banco de dados secundário ou ao salvar o final do log antes de uma operação RESTORE.

    Para executar um backup de log de melhor esforço que ignora o truncamento do log e coloca o banco de dados no estado RESTORING atomicamente, use as opções NO_TRUNCATE e NORECOVERY em conjunto.

  • STANDBY **=**standby_file_name
    Faz BACKUP do final do log e deixa o banco de dados em um estado STANDBY e somente leitura. A cláusula STANDBY grava dados em espera (executando reversão, mas com a opção de restaurações adicionais). O uso da opção STANDBY é equivalente a BACKUP LOG WITH NORECOVERY seguido por um RESTORE WITH STANDBY.

    O uso do modo em espera requer um arquivo em espera especificado por standby_file_name, cujo local é armazenado no log do banco de dados. Se o arquivo especificado já existir, o Mecanismo de Banco de Dados o substituirá. Se o arquivo não existir, ele será criado pelo Mecanismo de Banco de Dados. O arquivo em espera se torna parte do banco de dados.

    Esse arquivo contém as alterações revertidas que deverão ser revertidas se operações RESTORE LOG forem aplicadas subseqüentemente. Deve haver espaço em disco suficiente para que o arquivo em espera cresça para que possa conter todas as páginas distintas do banco de dados que foi modificado pela reversão de transações não confirmadas.

• NO_TRUNCATE
  Especifica que o log não é truncado e faz com que o Mecanismo de Banco de Dados tente fazer backup, independentemente do estado do banco de dados. Conseqüentemente, um backup feito com NO_TRUNCATE pode conter metadados incompletos. Essa opção permite fazer backup do log em situações em que o banco de dados está danificado.

  A opção NO_TRUNCATE de BACKUP LOG é equivalente a especificar COPY_ONLY e CONTINUE_AFTER_ERROR.

  Sem a opção NO_TRUNCATE, o banco de dados deve estar no estado ONLINE. Se o banco de dados estiver no estado SUSPENDED, talvez você possa criar um criar um backup especificando NO_TRUNCATE. Mas se o banco de dados estiver no estado OFFLINE ou EMERGENCY, BACKUP não será permitido mesmo com NO_TRUNCATE. Para obter informações sobre estados de banco de dados, consulte Estados de banco de dados.

Para evitar o preenchimento do log de transações de um banco de dados, os backups rotineiros são essenciais. No modelo de recuperação simples, o truncamento do log ocorre automaticamente depois que o backup do banco de dados é feito, e no modelo de recuperação completa, depois que o backup do log de transações é feito. No entanto, às vezes o processo de truncamento pode ser demorado. Para obter informações sobre como identificar e responder aos fatores de atraso, consulte Fatores que podem atrasar o truncamento de log.

Observação
As opções BACKUP LOG WITH NO_LOG e WITH TRUNCATE_ONLY foram descontinuadas. Se você estiver usando o modelo de recuperação completa ou bulk-logged e dever remover a cadeia de backup de log de um banco de dados, alterne para o modelo de recuperação simples. Para obter mais informações, consulte Considerações sobre como alternar do modelo de recuperação completa ou bulk-logged.

Para obter mais informações sobre truncamento de log em geral, consulte Truncamento de log de transações.

O SQL Server usa um processo de backup online para permitir que um backup de banco de dados seja feito enquanto o banco de dados ainda está uso. Durante um backup, a maior parte das operações é possível. Por exemplo, instruções INSERT, UPDATE ou DELETE são permitidas durante uma operação de backup

Operações que não podem ser executadas durante um backup de banco de dados ou de log de transações incluem:

• Operações de gerenciamento de arquivos, como a instrução ALTER DATABASE com as opções ADD FILE ou REMOVE.

• Operações de redução do banco de dados ou de arquivos. Isso inclui operações de redução automática.

Se uma operação de backup for sobreposta por uma operação de gerenciamento ou de redução de arquivos, um conflito será gerado. Independentemente de qual operação em conflito começou primeiro, a segunda operação aguardará até que o tempo limite do bloqueio definido pela primeira operação seja esgotado (o período limite é controlado pela configuração de tempo limite de uma sessão). Se o bloqueio for liberado durante o período de tempo limite, a segunda operação continuará. Se o tempo limite do bloqueio for esgotado, a segunda operação falhará.

A mídia de backup será formatada por uma instrução BACKUP se, e apenas se, qualquer uma das seguintes situações for verdadeira:

• A opção FORMAT estiver especificada.

• A mídia estiver vazia.

• A operação estiver gravando uma fita de continuação.

Para obter mais informações, consulte Criando um novo conjunto de mídias.

Os tipos de backup com suporte dependem do modelo de recuperação do banco de dados, da seguinte maneira:

• Todos os modelos de recuperação oferecem suporte a backups completos e diferenciais de dados.

  Escopo do backup	Tipos de backup
  Banco de dados inteiro	Backups de banco de dados abrangem o banco de dados inteiro. Opcionalmente, cada backup de banco de dados pode servir como a base de uma série de um ou mais backups de banco de dados diferenciais.
  Banco de dados parcial	Backups parciais abrangem grupos de arquivos de leitura/gravação e, possivelmente, um ou mais arquivos ou grupos de arquivos somente leitura. Opcionalmente, cada backup parcial pode servir como a base de uma série de um ou mais backups parciais diferenciais.
  Arquivo ou grupo de arquivos	Backups de arquivos abrangem um ou mais arquivos ou grupos de arquivos e são relevantes apenas para bancos de dados que contêm vários grupos de arquivos. No modelo de recuperação simples, os backups de arquivos são essencialmente restritos a grupos de arquivos secundários somente leitura. Opcionalmente, cada backup parcial pode servir como a base de uma série de um ou mais backups de arquivos diferenciais.

• No modelo de recuperação completa ou modelo de recuperação bulk-logged, os backups convencionais também incluem backups de log de transações sequenciais (ou backups de log), que são necessários. Cada backup de log cobre a parte do log de transações que estava ativo quando o backup foi criado e inclui todos os registros de log cujo backup não foi feito em um backup de log anterior.

  Para minimizar a exposição de perda de trabalho, à custa de sobrecarga administrativa, você deve agendar backups de log freqüentes. O agendamento de backups diferenciais entre backups completos pode reduzir o tempo de restauração reduzindo o número de backups de log a serem restaurados após a restauração dos dados.

  Recomendamos que você coloque backups de log em um volume separado dos backups de banco de dados.

  Observação
  Para poder criar o primeiro backup de log, você deve criar um backup completo.

  Para obter mais informações, consulte Trabalhando com backups de log de transações.

• Um backup somente cópia é um backup completo com objetivo especial ou backup de log que é independente da seqüência de backups convencionais. Para criar um backup somente cópia, especifique a opção COPY_ONLY na instrução BACKUP. Para obter mais informações, consulte Backups somente cópia.

Esta tabela descreve interações entre as opções { NOINIT | INIT} e { NOSKIP | SKIP }.

Observação
Se a mídia de fita estiver vazia ou se o arquivo de backup em disco não existir, todas essas interações gravarão um cabeçalho de mídia e continuarão. Se a mídia não estiver vazia e não tiver um cabeçalho de mídia válido, essas operações fornecerão comentários informando que essa não é uma mídia MTF válida e terminarão a operação de backup.

1 A validade inclui o número de versão de MTF e outras informações de cabeçalho. Se a versão especificada não tiver suporte ou for um valor inesperado, ocorrerá um erro.

2 O usuário deve pertencer à função fixa de banco de dados ou de servidor apropriada e fornecer a senha de mídia correta para executar uma operação de backup.

SQL Server inclui as seguintes tabelas de histórico de backup que controlam as atividades do banco de dados:

• backupfile (Transact-SQL)

• backupfilegroup (Transact-SQL)

• backupmediafamily (Transact-SQL)

• backupmediaset (Transact-SQL)

• backupset (Transact-SQL)

Quando uma restauração é executada, se o conjunto de backup ainda não tiver sido registrado no banco de dados msdb, as tabelas de histórico de backup poderão ser modificadas.

Cuidado
Backups criados por uma versão mais recente do SQL Server não podem ser restaurados em versões anteriores do SQL Server.

BACKUP oferece suporte à opção RESTART para fornecer compatibilidade com versões anteriores do SQL Server. Mas RESTART não tem nenhum efeito no SQL Server 2005 e em versões posteriores.

Um conjunto distribuído é um conjunto de arquivos de disco nos quais os dados são divididos em blocos e distribuídos em uma ordem fixa. O número de dispositivos de backup usados em um conjunto distribuído deve permanecer o mesmo (a não ser que a mídia seja reiniciada com FORMAT).

O exemplo a seguir grava um backup do banco de dados AdventureWorks2008R2 em um novo conjunto de mídias distribuído que usa três arquivos de disco.

BACKUP DATABASE AdventureWorks2008R2
TO DISK='X:\SQLServerBackups\AdventureWorks2008R2_1.bak', 
DISK='Y:\SQLServerBackups\AdventureWorks2008R2_2.bak', 
DISK='Z:\SQLServerBackups\AdventureWorks2008R2_3.bak'
WITH FORMAT,
   MEDIANAME = 'AdventureWorks2008R2StripedSet0',
   MEDIADESCRIPTION = 'Striped media set for AdventureWorks2008R2 database;
GO

Após a definição de um dispositivo de backup como parte de um conjunto distribuído, ele não pode ser usado como um backup de dispositivo único a menos que FORMAT seja especificado. Do mesmo modo, um dispositivo de backup que contém backups não distribuídos não pode ser usado em um conjunto distribuído a menos que FORMAT seja especificado. Para dividir um conjunto de backup distribuído, use FORMAT.

Se nem MEDIANAME nem MEDIADESCRIPTION estiver especificado quando um cabeçalho de mídia for gravado, o campo de cabeçalho de mídia correspondente ao item em branco estará vazio.

Normalmente, backups não são espelhados e instruções BACKUP simplesmente incluem uma cláusula TO. No entanto, um total de quatro espelhos é possível por conjunto de mídias. Em um conjunto de mídias espelhado, a operação de backup grava em vários grupos de dispositivos de backup. Cada grupo de dispositivos de backup compõe um único espelho dentro do conjunto de mídias espelhado. Todos os espelhos devem usar a mesma quantidade e tipo de dispositivos físicos de backup que devem ter as mesmas propriedades.

Para fazer backup em um conjunto de mídias espelhado, todos os espelhos devem estar presentes. Para fazer backup em um conjunto de mídias espelhado, especifique a cláusula TO para especificar o primeiro espelho e especifique uma cláusula MIRROR TO para cada espelho adicional.

Para um conjunto de mídias espelhado, cada cláusula MIRROR TO deve listar o mesmo número e tipo de dispositivos que a cláusula TO. O exemplo a seguir grava em um conjunto de mídias espelhado que contém dois espelhos e usa três dispositivos por espelho:

BACKUP DATABASE AdventureWorks2008R2
TO DISK='X:\SQLServerBackups\AdventureWorks2008R2_1a.bak', 
DISK='Y:\SQLServerBackups\AdventureWorks2008R2_2a.bak', 
DISK='Z:\SQLServerBackups\AdventureWorks2008R2_3a.bak'
MIRROR TO DISK='X:\SQLServerBackups\AdventureWorks2008R2_1b.bak', 
DISK='Y:\SQLServerBackups\AdventureWorks2008R2_2b.bak', 
DISK='Z:\SQLServerBackups\AdventureWorks2008R2_3b.bak';
GO

Importante
Este exemplo foi criado para permitir teste em seu sistema local. Na prática, fazer backup em vários dispositivos na mesma unidade deve afetar o desempenho e eliminar a redundância para a qual conjuntos de mídias espelhados foram projetados.

Famílias de mídia em conjuntos de mídia espelhados

O exemplo a seguir faz backup do banco de dados AdventureWorks2008R2 em um arquivo de disco.

BACKUP DATABASE AdventureWorks2008R2 
 TO DISK = 'Z:\SQLServerBackups\AdvWorksData.bak'
   WITH FORMAT;
GO

O exemplo a seguir faz backup do banco de dados de exemplo AdventureWorks2008R2 que, por padrão, usa o modelo de recuperação simples. Para oferecer suporte a backups de log, o banco de dados AdventureWorks2008R2 é modificado para usar o modelo de recuperação completa.

Em seguida, o exemplo usa sp_addumpdevice para criar um dispositivo de backup lógico para fazer backup dos dados, AdvWorksData, e cria outro dispositivo de backup lógico para fazer backup do log, AdvWorksLog.

Em seguida, o exemplo cria um backup de dados completo em AdvWorksData e, após um período de atividades de atualização, faz o backup do log em AdvWorksLog.

-- To permit log backups, before the full database backup, modify the database 
-- to use the full recovery model.
USE master;
GO
ALTER DATABASE AdventureWorks2008R2
   SET RECOVERY FULL;
GO
-- Create AdvWorksData and AdvWorksLog logical backup devices. 
USE master
GO
EXEC sp_addumpdevice 'disk', 'AdvWorksData', 
'Z:\SQLServerBackups\AdvWorksData.bak';
GO
EXEC sp_addumpdevice 'disk', 'AdvWorksLog', 
'X:\SQLServerBackups\AdvWorksLog.bak';
GO

-- Back up the full AdventureWorks2008R2 database.
BACKUP DATABASE AdventureWorks2008R2 TO AdvWorksData;
GO
-- Back up the AdventureWorks2008R2 log.
BACKUP LOG AdventureWorks2008R2
   TO AdvWorksLog;
GO

Observação
Para um banco de dados de produção, faça backup do log regularmente. Os backups de log devem ser freqüentes o suficiente para fornecer proteção contra perda de dados.

O exemplo a seguir cria um backup de arquivo completo de todos os arquivos dos dois grupos de arquivos secundários.

--Back up the files in SalesGroup1:
BACKUP DATABASE Sales
   FILEGROUP = 'SalesGroup1',
   FILEGROUP = 'SalesGroup2'
   TO DISK = 'Z:\SQLServerBackups\SalesFiles.bck'
GO

O exemplo a seguir cria um backup diferencial de cada arquivo nos dois grupos de arquivos secundários.

--Back up the files in SalesGroup1:
BACKUP DATABASE Sales
   FILEGROUP = 'SalesGroup1',
   FILEGROUP = 'SalesGroup2'
   TO DISK = 'Z:\SQLServerBackups\SalesFiles.bck'
   WITH 
      DIFFERENTIAL
GO

O exemplo a seguir cria um conjunto de mídias espelhado que contêm uma única família de mídia e quatro espelhos nos quais faz backup do banco de dados AdventureWorks2008R2.

BACKUP DATABASE AdventureWorks2008R2
TO TAPE = '\\.\tape0'
MIRROR TO TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2'
MIRROR TO TAPE = '\\.\tape3'
WITH
   FORMAT,
   MEDIANAME = 'AdventureWorks2008R2Set0'

O exemplo a seguir cria um conjunto de mídias espelhado no qual cada espelho consiste em duas famílias de mídia. Em seguida, o exemplo faz backup do banco de dados AdventureWorks2008R2 nos dois espelhos.

BACKUP DATABASE AdventureWorks2008R2
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'
WITH
   FORMAT,
   MEDIANAME = 'AdventureWorks2008R2Set1'

O exemplo a seguir anexa um conjunto de backup ao conjunto de mídias criado no exemplo anterior.

BACKUP LOG AdventureWorks2008R2
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'
WITH 
   NOINIT,
   MEDIANAME = 'AdventureWorks2008R2Set1'

Observação
NOINIT, que é o padrão, é mostrado aqui para maior clareza.

[Início dos exemplos]

O exemplo a seguir formata a mídia, criando um novo conjunto de mídias e executa um backup completo compactado do banco de dados AdventureWorks2008R2.

BACKUP DATABASE AdventureWorks2008R2 TO DISK='Z:\SQLServerBackups\AdvWorksData.bak' 
WITH 
   FORMAT, 
   COMPRESSION

[Início dos exemplos]