Fazer backup e restaurar bases de dados do SQL Server

Aplica-se a:SQL Server

Este artigo descreve os benefícios de fazer backup de bases de dados do SQL Server, introduz termos básicos de backup e restauro, e aborda estratégias de backup e restauro e considerações de segurança para o SQL Server.

Observação

Este artigo apresenta os backups do SQL Server. Para obter etapas específicas para fazer backup de bancos de dados do SQL Server, consulte Criando backups.

O componente de backup e restauro do SQL Server fornece uma salvaguarda essencial para dados críticos armazenados nas suas bases de dados SQL Server. Para minimizar o risco de perda catastrófica de dados, faça cópias de segurança regulares das suas bases de dados para preservar modificações nos seus dados. Uma estratégia bem planeada de backup e restauro ajuda a proteger as bases de dados contra a perda de dados causada por vários tipos de falhas. Teste a sua estratégia restaurando um conjunto de backups e depois recuperando a sua base de dados, para estar preparado para responder a um desastre.

Para além do armazenamento local, o SQL Server também suporta backup e restauração a partir do Armazenamento de Blobs do Azure. Para mais informações, consulte backup e restauro do SQL Server com Armazenamento de Blobs do Azure. Para ficheiros de base de dados armazenados no Armazenamento de Blobs do Azure, o SQL Server 2016 (13.x) oferece a opção de utilizar instantâneos do Azure para cópias de segurança quase instantâneas e restauros mais rápidos. Para obter mais informações, consulte Cópias de segurança de instantâneo de ficheiro para ficheiros de base de dados no Azure. O Azure também oferece uma solução de backup de classe empresarial para SQL Server em execução em VMs do Azure. Uma solução de backup totalmente gerenciada, que oferece suporte a grupos de disponibilidade Always On, retenção de longo prazo, recuperação point-in-time e gerenciamento e monitoramento centralizados. Para obter mais informações, consulte Sobre o backup do SQL Server em VMs do Azure.

Por que criar uma cópia de segurança?

  • Fazer cópias de segurança das suas bases de dados do SQL Server, executar procedimentos de restauro de teste nos seus backups e armazenar cópias dos backups num local seguro e fora do local protege-o de uma possível perda catastrófica de dados. O backup é a única maneira de proteger seus dados.

    Com backups válidos de um banco de dados, você pode recuperar seus dados de muitas falhas, como:

    • Falha de mídia.

    • Erros do utilizador, por exemplo, eliminar uma tabela por engano.

    • Falhas de hardware, por exemplo, uma unidade de disco danificada ou perda permanente de um servidor.

    • Catástrofes naturais. Ao usar o SQL Server Backup para Armazenamento de Blobs do Azure, pode criar um backup fora do local numa região diferente da sua localização local, para usar caso um desastre natural afete a sua localização local.

  • Além disso, os backups de um banco de dados são úteis para fins administrativos de rotina, como copiar um banco de dados de um servidor para outro, configurar grupos de disponibilidade Always On ou espelhamento de banco de dados e arquivamento.

Glossário de termos de backup

Term Definition
fazer uma cópia de segurança[verbo] O processo de criação de uma cópia de segurança[substantivo] através da cópia de registos de dados de uma base de dados do SQL Server ou de registos do respetivo registo de transações.
cópia de segurança[substantivo] Uma cópia dos dados que você pode usar para restaurar e recuperar os dados após uma falha. Os backups de um banco de dados também podem ser usados para restaurar uma cópia do banco de dados para um novo local.
Dispositivo de backup Um dispositivo de disco ou fita no qual os backups do SQL Server são gravados e a partir do qual podem ser restaurados. Os backups do SQL Server também podem ser gravados em um Armazenamento de Blobs do Azure e o formato de URL é usado para especificar o destino e o nome do arquivo de backup. Para mais informações, consulte backup e restauro do SQL Server com Armazenamento de Blobs do Azure.
mídia de backup Uma ou mais fitas ou arquivos de disco nos quais um ou mais backups foram gravados.
cópia de segurança de dados Um backup de dados em um banco de dados completo (um backup de banco de dados), um banco de dados parcial (um backup parcial) ou um conjunto de arquivos de dados ou grupos de arquivos (um backup de arquivo).
cópia de segurança da base de dados Um backup de um banco de dados. Os backups completos do banco de dados representam todo o banco de dados no momento em que o backup foi concluído. Os backups diferenciais de banco de dados contêm apenas alterações feitas no banco de dados desde o backup completo mais recente do banco de dados.
backup diferencial Um backup de dados baseado no backup completo mais recente de um banco de dados completo ou parcial ou de um conjunto de arquivos de dados ou grupos de arquivos (a base diferencial) e que contém apenas os dados que foram alterados desde essa base.
cópia de segurança completa Um backup de dados que contém todos os dados em um banco de dados específico ou conjunto de grupos de arquivos ou arquivos, e também log suficiente para permitir a recuperação desses dados.
cópia de segurança do registo Uma cópia de segurança do registo de transações que inclui todos os registos que não foram incluídos numa cópia de segurança anterior do registo de transações (modelo de recuperação completa).
recover Para retornar um banco de dados a um estado estável e consistente.
recuperação Uma fase de inicialização da base de dados ou de um restauro com recuperação que coloca a base de dados num estado de consistência transacional.
modelo de recuperação Uma propriedade de banco de dados que controla a manutenção do log de transações em um banco de dados. Existem três modelos de recuperação: básico, completo e de processamento em massa. O modelo de recuperação de um banco de dados determina seus requisitos de backup e restauração.
restaurar Um processo multifásico que copia todas as páginas de dados e de registo de uma cópia de segurança especificada do SQL Server para uma base de dados especificada e, em seguida, reproduz todas as transações registadas na cópia de segurança, aplicando as alterações registadas para fazer avançar os dados no tempo.

Estratégias de backup e restauração

Deve personalizar estratégias de backup e restauro para o seu ambiente e recursos disponíveis. Uma recuperação fiável requer uma estratégia de backup e restauração. Uma estratégia bem desenhada equilibra os requisitos empresariais para máxima disponibilidade e perda mínima de dados com o custo de manutenção e armazenamento de backups.

Uma estratégia de backup e restauração contém uma parte de backup e uma parte de restauração. A parte de backup define o tipo e a frequência dos backups, o tipo e velocidade do hardware que necessitam, como testar backups e onde e como armazenar os suportes de backup (incluindo considerações de segurança). A parte de restauro define quem é responsável por realizar restaurações, como realizar restaurações para atingir os objetivos de disponibilidade da base de dados e perda mínima de dados, e como testar restaurações.

Uma estratégia eficaz de backup e restauro requer planeamento, implementação e testes cuidadosos. É obrigatório fazer testes. Não tem uma estratégia de backup até restaurar com sucesso backups em todas as combinações incluídas na sua estratégia de restauro e testar cada base de dados restaurada para verificar a consistência física. Considere vários fatores, incluindo:

  • Os objetivos da sua organização em relação aos bancos de dados de produção, especialmente os requisitos de disponibilidade e proteção dos dados contra perdas ou danos.

  • A natureza de cada banco de dados: seu tamanho, seus padrões de uso, a natureza de seu conteúdo, os requisitos para seus dados, e assim por diante.

  • Restrições de recursos, como hardware, pessoal, espaço para armazenar mídia de backup, segurança física da mídia armazenada e assim por diante.

Recomendações de boas práticas

Não conceda às contas que realizam operações de backup ou restauro mais privilégios do que o necessário. Para mais informações, consulte backup e restauro para detalhes específicos de permissões. Encripte backups de bases de dados e, se possível, comprima-os.

Use extensões de ficheiros consistentes para facilitar a identificação e gestão dos backups. O SQL Server não exige nem impõe estas extensões, mas a consistência ajuda em tarefas operacionais, como configurar exclusões antivírus para ficheiros de backup. Para mais informações, consulte Configurar software antivírus para funcionar com SQL Server.

  • Os ficheiros de backup da base de dados devem ter a extensão .BAK .
  • Os arquivos de backup de log devem ter a .TRN extensão.

Use armazenamento separado

Coloque as suas cópias de segurança da base de dados num local físico separado ou num dispositivo separado dos ficheiros da base de dados. Quando o disco físico que armazena as tuas bases de dados falha ou falha, a recuperação depende da tua capacidade de aceder ao disco separado ou dispositivo remoto que armazenou as cópias de segurança. Podes criar vários volumes ou partições lógicas a partir do mesmo disco físico. Revê cuidadosamente a partição do disco e os layouts lógicos dos volumes antes de escolheres um local de armazenamento para os backups.

Escolha o modelo de recuperação apropriado

As operações de backup e restauração ocorrem no contexto de um modelo de recuperação. Um modelo de recuperação é uma propriedade de banco de dados que controla como o log de transações é gerenciado. Assim, o modelo de recuperação de uma base de dados determina que tipos de cenários de backup e restauro a base de dados suporta, bem como o tamanho das cópias de segurança dos registos de transações. Normalmente, um banco de dados usa o modelo de recuperação simples ou o modelo de recuperação completa. Você pode aumentar o modelo de recuperação completa alternando para o modelo de recuperação bulk-logged antes das operações em massa. Para obter uma introdução a esses modelos de recuperação e como eles afetam o gerenciamento do log de transações, consulte o log de transações.

A melhor escolha de modelo de recuperação de base de dados depende das necessidades do seu negócio. Para evitar o gerenciamento de logs de transações e simplificar o backup e a restauração, use o modelo de recuperação simples. Para minimizar a exposição à perda de trabalho ao custo das despesas gerais administrativas, use o modelo de recuperação completa. Para minimizar o efeito no tamanho do registo durante operações com registo em massa, continuando a permitir a recuperação dessas operações, utilize o modelo de recuperação com registo em massa. Para informações sobre o efeito dos modelos de recuperação na cópia de segurança e restauração, consulte a visão geral do Backup (SQL Server).

Projete sua estratégia de backup

Depois de selecionar um modelo de recuperação que cumpra os requisitos do seu negócio para uma base de dados específica, planeie e implemente uma estratégia de backup correspondente. A melhor estratégia de backup depende de vários fatores. Os seguintes fatores são especialmente importantes:

  • Quantas horas por dia as aplicações precisam para aceder à base de dados?

    Se houver um período previsível de menor utilização, deve programar cópias de segurança completas da base de dados para esse período.

  • Com que frequência é provável que ocorram alterações e atualizações?

    Se as alterações forem frequentes, considere:

    • No modelo de recuperação simples, pode agendar backups diferenciais entre backups completos da base de dados. Um backup diferencial captura apenas as alterações desde o último backup completo do banco de dados.

    • No modelo completo de recuperação, pode agendar backups frequentes de logs. O agendamento de backups diferenciais entre backups completos pode reduzir o tempo de restauração, reduzindo o número de backups de log que você precisa restaurar depois de restaurar os dados.

  • É provável que ocorram alterações apenas numa pequena parte da base de dados ou numa grande parte?

    Para uma grande base de dados em que as alterações se concentram num subconjunto dos ficheiros ou grupos de ficheiros, cópias de segurança parciais ou completas de ficheiros podem ser úteis. Para mais informações, consulte Backups Parciais (SQL Server) e Backups Completos de Ficheiros (SQL Server).

  • Quanto espaço em disco requer um backup completo de base de dados?

  • Até que ponto no passado sua empresa precisa manter backups?

    Certifique-se de que tem um calendário de backup adequado que corresponda às necessidades da aplicação e aos requisitos empresariais. À medida que os backups envelhecem, o risco de perda de dados aumenta, a menos que tenha uma forma de regenerar todos os dados até ao ponto de falha. Antes de descartar cópias de segurança antigas devido às limitações de armazenamento, considere se precisa de recuperar dados de uma data tão antiga.

Estimar o tamanho de um backup de banco de dados completo

Antes de implementar uma estratégia de backup e restauro, estima quanto espaço em disco um backup completo de base de dados consome. A operação de backup copia os dados no banco de dados para o arquivo de backup. A cópia de segurança contém apenas os dados reais da base de dados, não qualquer espaço não utilizado. Portanto, o backup geralmente é menor do que o próprio banco de dados. Para estimar o tamanho de uma cópia de segurança completa da base de dados, utilize o sp_spaceused procedimento armazenado do sistema. Para obter mais informações, consulte sp_spaceused.

Programar cópias de segurança

Uma operação de backup tem um efeito mínimo nas transações em execução, por isso pode fazer backups durante as operações normais. Você pode executar um backup do SQL Server com efeito mínimo nas cargas de trabalho de produção.

Observação

Para obter informações sobre restrições de simultaneidade durante o backup, consulte Visão geral do backup (SQL Server).

Depois de decidir que tipos de backups precisa e com que frequência realizar cada tipo, agende backups regulares como parte de um plano de manutenção de base de dados. Para obter informações sobre planos de manutenção e como criá-los para backups de banco de dados e backups de log, consulte Usar o Assistente de Plano de Manutenção.

Teste seus backups

Você não tem uma estratégia de restauração até testar seus backups. Teste minuciosamente a sua estratégia de backup para cada base de dados, restaurando uma cópia da base de dados num sistema de teste. Você deve testar a restauração de todos os tipos de backup que pretende usar. Depois de restaurar a cópia de segurança, executa DBCC CHECKDB na base de dados para confirmar que o suporte da cópia de segurança não está danificado.

Verificar a estabilidade e consistência da mídia

Use as opções de verificação fornecidas pelas utilidades de backup (BACKUPcomando T-SQL, Planos de Manutenção do SQL Server, o seu software ou solução de backup, e assim por diante). Para um exemplo, veja RESTORE Instruções - VERIFYONLY.

Utilize funcionalidades avançadas, como BACKUP CHECKSUM, para detetar problemas com o próprio suporte de cópia de segurança. Para mais informações, consulte Possíveis Erros de Media Durante Backup e Restauro (SQL Server).

Estratégia de backup/restauração de documentos

Documente os seus procedimentos de backup e restauro, e guarde uma cópia da documentação no seu livro de processos.

Deve também manter um manual de operações para cada base de dados. Este manual de operações deve documentar a localização dos backups, nomes dos dispositivos de backup (se existirem) e o tempo necessário para restaurar os backups de teste.

Risco de segurança ao restaurar backups de fontes não confiáveis

Esta secção descreve o risco de segurança associado à restauração de backups de fontes não confiáveis para qualquer ambiente SQL Server, incluindo on-premises, Azure SQL Managed Instance, SQL Server em Máquinas Virtuais Azure (VMs) e qualquer outro ambiente.

Por que motivo isto é importante

Restaurar ficheiros de backup SQL (.bak) introduz um risco potencial se o backup tiver origem numa fonte não confiável. O risco de segurança agrava-se ainda mais quando um ambiente SQL Server tem múltiplas instâncias, pois amplifica a área de ameaça. Embora backups que permaneçam dentro de um limite de confiança não representem qualquer problema de segurança, restaurar um backup malicioso pode comprometer a segurança de todo o ambiente.

Um ficheiro malicioso .bak pode:

  • Assumir o controlo total da instância do SQL Server.
  • Escalar privilégios e obter acesso não autorizado ao host ou máquina virtual subjacente.

Este ataque ocorre antes de qualquer script de validação ou verificação de segurança poder ser executado, o que o torna extremamente perigoso. Restaurar um backup não confiável equivale a executar aplicações não confiáveis num servidor crítico ou máquina virtual, e introduzir a execução arbitrária de código no seu ambiente.

Melhores práticas

Siga estas melhores práticas de segurança de backup para reduzir a ameaça aos seus ambientes SQL Server:

  • Trate a restauração de cópias de segurança como uma operação de alto risco.
  • Reduza a área de serviço de ameaça utilizando instâncias isoladas.
  • Permita apenas backups de confiança: nunca restaure backups de fontes desconhecidas ou externas.
  • Só permitam backups que tenham permanecido dentro de um limite de confiança: certifique-se de que os backups têm origem dentro do limite de confiança.
  • Não contorne os controlos de segurança por conveniência.
  • Permitir auditoria ao nível do servidor para capturar backups e restaurar eventos e mitigar evasão de auditoria.

Monitore o progresso com o XEvent

As operações de backup e restauro podem demorar muito tempo devido ao tamanho da base de dados e à complexidade das operações envolvidas. Quando surgirem problemas com qualquer das operações, use o evento estendido backup_restore_progress_trace para acompanhar o progresso em tempo real. Para obter mais informações sobre eventos estendidos, consulte Visão geral de eventos estendidos.

Advertência

O backup_restore_progress_trace evento prolongado pode causar problemas de desempenho e consumir uma grande quantidade de espaço em disco. Use-o por curtos períodos, tenha cuidado e teste cuidadosamente antes de o usar em produção.

-- Create the backup_restore_progress_trace extended event session
CREATE EVENT SESSION [BackupRestoreTrace] ON SERVER
ADD EVENT sqlserver.backup_restore_progress_trace
ADD TARGET package0.event_file (SET filename = N'BackupRestoreTrace')
WITH
(
    MAX_MEMORY = 4096 KB,
    EVENT_RETENTION_MODE = ALLOW_SINGLE_EVENT_LOSS,
    MAX_DISPATCH_LATENCY = 5 SECONDS,
    MAX_EVENT_SIZE = 0 KB,
    MEMORY_PARTITION_MODE = NONE,
    TRACK_CAUSALITY = OFF,
    STARTUP_STATE = OFF
);
GO

-- Start the event session
ALTER EVENT SESSION [BackupRestoreTrace] ON SERVER
STATE = START;
GO

-- Stop the event session
ALTER EVENT SESSION [BackupRestoreTrace] ON SERVER
STATE = STOP;
GO

Saída de exemplo de Evento Estendido

Captura de ecrã de um exemplo de backup xevent output.

Captura de ecrã de um exemplo de saída de xevent de cópia de segurança, continuação.

Mais sobre tarefas de backup

Trabalhar com dispositivos de backup e mídia de backup

Criar cópias de segurança

Para cópias de segurança parciais ou só de cópia, utilize a instrução Transact-SQL BACKUP com a opção PARTIAL ou COPY_ONLY, respetivamente.

Usar SSMS

Usar T-SQL

Restaurar backups de dados

Usar SSMS

Usar T-SQL

Restaurar logs de transações (modelo de recuperação completa)

Usar SSMS

Usar T-SQL