SQL Server

Noções básicas sobre os backups do SQL Server

Paul S. Randal

Em uma visão geral:

• Backups totais
• Backups do log de transações
• Os backups diferenciais
• Planejando a estratégia de backup e a integridade backup

Conteúdo

Backups completos
Backups diferenciais
Backups de log de transação
Planejamento de estratégia de backup
Integridade do backup
Resumo

Você realmente precisa fazer backups do SQL Server? Sim. A menos que você não se preocupa com seus dados ou não se incomoda ter que recriar completamente o banco de dados no caso de desastre, você precisa de alguns forma de restaurar o banco de dados para um ponto utilizável. Algumas pessoas argumentam que possuir uma cópia redundante do banco de dados em algum outro lugar remove a necessidade de ter backups, mas e se copiar está danificado ou inacessível? Backups ainda são necessários para verificar se que você sempre pode recuperar.

Mas o tipo de backups você deve levar? Com que freqüência você deve tomá-los? O efeito que elas terá no banco de dados e carga de trabalho? E como você verifique se que eles são válidos?

Montar uma estratégia de backup é realmente mais fácil do que você pode imaginar, mesmo que os comandos BACKUP e restauração têm uma grande quantidade de opções. E eu será ajudam a resolvê-lo todas as saída.

Este é o primeiro artigo de uma série de três partes. Aqui na parte 1, abrangem backups. Na parte 2 (setembro de 2009 problema), Falarei sobre recuperação de um desastre usando backups. E na parte 3 (novembro de 2009 problema), será examine recuperar de um desastre sem backups. Vou para ir um pouco mais profundo que comum nesses artigos, mas você deve ser capaz de acompanhar junto com a Ajuda do material de plano de fundo.

No artigo deste mês, explicarei as noções básicas de como os vários tipos de trabalho de backup e como você pode usá-los em uma estratégia de backup. Ela ajuda a se você tiver algum conhecimento de como o log de transações funciona (consulte meu artigo" Noções básicas sobre log e recuperação no SQL Server." Não há nenhum ponto na backups se eles para estar corrompido quando você tenta usá-los, para também explicarei como adicionar alguns integridade verifica a eles. Ao longo do caminho será debunk alguns dos erros de concepção comuns e fornecer links para informações adicionais.

Uma coisa que não vou fazer é explicar como funciona a sintaxe BACKUP e como executar os vários tipos de backup. Manuais online do SQL Server tem excelentes seções que abordam esse caso por isso que desperdiçar espaço duplicando-lo aqui? Consulte o tópico" Backup (Transact-SQL)"para obter mais informações, especialmente a seção exemplos no final. O tópico" Fazendo backup e restaurando tópicos como (SQL Server Management Studio)"explica como usar as ferramentas para executar backups. É aconselhável revisar o como depois de ler este artigo, como aqui vou explicar o que e o motivo.

A implementação de sua estratégia de backup é a parte relativamente fácil. Criar uma estratégia eficaz é importante, embora normalmente ignorado, parte.

Backups completos

O tipo mais simples de backup é um backup completo do banco de dados. Também é possível fazer um backup completo de um arquivo de dados único ou um grupo de arquivos. No entanto, esses não são usados e como todos os princípios discutidos se aplicam a eles, também, que vou foco em backups de nível de banco de dados. Mas como do SQL Server 2005, cada um dos mais granulares tipos de backup funciona exatamente da mesma (isso não ocorria no SQL Server 2000). O mesmo se aplica para os backups diferenciais — elas podem ser realizadas no arquivo, grupo de arquivos ou nível de banco de dados — mas essas todo o trabalho na mesma forma, também, independentemente do componente que está sendo feito.

Um backup completo do banco de dados fornece uma cópia completa do banco de dados e fornece um único ponto-in-time para o qual o banco de dados pode ser restaurado. Mesmo que pode levar várias horas para o processo de backup executar, você ainda só pode restaurar o backup para um único ponto (com eficiência no final do backup, mas abordarei exatamente o que ponto é mais adiante neste artigo). Um backup completo não permite a recuperação para qualquer ponto no tempo enquanto o backup foi executado. Isso também é o mesmo para os backups diferenciais.

Há uma equivocada sobre isso, no entanto, fuelled pelo fato de que você pode usar o WITH STOPAT = < um número seqüencial tempo ou log > opção em uma restauração de backups normal e diferencial. Embora a sintaxe permite que ele, a opção não tem nenhum efeito e há apenas por conveniência.

Outra equivocada sobre backups totais é que eles contêm somente dados. Os backups totais e os backups diferenciais também contêm alguns registros de log de transação para que o componente restaurado (banco de dados, arquivo ou grupo de arquivos) pode ser feito transacionalmente consistente.

Considere uma transação de exemplo que insere um registro em uma tabela com um único índice que não estão em cluster. As páginas de tabela e índice são espalhadas através do arquivo de dados. A transação é dividida em duas partes internamente: um registro de inserção em uma página de dados na tabela e, em seguida, a inserção do Registro necessária em uma página de índice no índice que não estão em cluster. Se o processo de backup apenas por acaso, leia a página índice que não está em cluster antes da inserção de registro, mas lê a página de dados de tabela após a inserção de registro, em seguida, o banco de dados representado por apenas os dados no backup é transacional inconsistente.

Isso é onde o log de transações entra em cena. Também, incluindo alguns registros de log de transação no backup, recuperação pode ser executada na cópia restaurada do banco de dados, tornando transacionalmente consistente. Para esta transação de exemplo, dependendo de quando ele confirma a parte de recuperação de restauração pode adiá-lo (que significa que ele será exibido como confirmada na cópia restaurada do banco de dados) ou revertê-la novamente (que significa que ele não será exibido em todos os na cópia restaurada do banco de dados). Em ambos os casos, é mantida consistência transacional, que é crucial.

Um backup completo faz o seguinte:

1. Forçar uma verificação de banco de dados e anote o número de seqüência de log neste momento. Isso libera todas as páginas atualizadas na memória em disco antes de tudo é lido por ajudar a minimizar a quantidade de trabalho que a parte de recuperação de restauração tem para fazer o backup.
2. Inicie leitura a partir dos arquivos de dados no banco de dados.
3. Parar de ler os arquivos de dados e criar uma nota do número de seqüência de log do início nesse ponto da transação de ativo mais antigo (consulte meu artigo "Noções básicas sobre log e recuperação no SQL Server" para obter uma explicação desses termos).
4. Ler quanto log de transações conforme necessário.

Explicar quanto log de transações é necessário melhor é feito com o auxílio visual na Figura 1 . Os números de vermelhos na linha do tempo são explicados nesta lista:

1. Ponto de verificação e começar a leitura do banco de dados.
2. A operação de leitura lê página X.
3. Inicia A transação.
4. A transação faz uma alteração para página X. A cópia no backup agora está desatualizada. Observe que o backup não irá ler página X novamente — ele já é passado esse ponto no banco de dados.
5. Transação B inicia. Ele não é concluída antes que os dados lidos operação é concluída.
6. Confirma A transação. Isso confirma as alterações para página X.
7. Os dados de backup leia operação é concluída e inicia o log de transações de leitura.

A Figura 1 cronograma de exemplo das alterações durante um backup completo

Fazendo backup suficiente do log de transação é necessária para que recuperação pode executar com êxito durante a restauração e para que todas as páginas do banco de dados estejam no mesmo ponto no tempo — o tempo em que os dados lendo parte a operação de backup concluído (7 ponto). O log de transação do início do mais antigo ativo (ou não confirmado) transação (5 pontos, transações B) para o final do backup (7 ponto), é necessário para permitir a recuperação executar. Log de transações do ponto de verificação backup (1 ponto) para o final do backup (7 ponto) é necessário para permitir que todas as páginas a ser colocado para o mesmo ponto no tempo.

Se o log de transações foi incluído somente do início da transação ativa mais antiga (5 pontos), a cópia da página ler X foi restaurado a partir do backup em 2 de ponto não deve ser atualizado com as alterações de transação A, que ocorreu em 4 de ponto. Isso significa que poderia não ser transacionalmente consistente com o resto do banco de dados como do tempo que a operação de leitura de dados concluída (ponto 7).

Portanto, o número de seqüência de log mínimo (LSN) de log de transação que está incluído no backup completo é mínimo (LSN de ponto de verificação de backup, LSN de transação ativa mais antiga) e pode ser para uma transação que foi iniciada mesmo antes do backup começou. Isso garante que a cópia restaurada do banco de dados (ou que você restaurou — página, o arquivo, o grupo de arquivos, o banco de dados) é totalmente consistente.

Esse mecanismo significa que as transações não estão em pausa de qualquer forma por operações de backup, embora a carga de trabalho E/s extra no banco de dados pode tornar lento-los um pouco. A desvantagem desse mecanismo é que o log de transações não é possível seja limpo para a duração da backup completo porque é necessária. Se houver muita atividade de atualização e o backup completo leva muito tempo para concluir, isso pode levar a crescimento de log de transação — um problema que já abordei em vários artigos anteriores e na coluna p+r SQL.

Os dados contidos em um backup completo não são necessariamente todo o conteúdo de todos os arquivos de dados. O backup somente conterá as páginas alocadas dos arquivos de dados. Por exemplo, um banco de dados de arquivo único pode ser 100 GB, mas contêm apenas 15 GB de dados alocados. Nesse caso, o backup completo conterá apenas 15 GB de dados alocados mais o log de transação necessárias. (No entanto, o banco de dados restaurado sempre será o mesmo tamanho que o original — nesse caso, 100 GB.)

Outra equivocada é que o processo de backup examina ou altera os dados que está fazendo backup. Isso é verdadeiras, exceto em um caso simples quando as somas de verificação de backup estiverem ativadas, que explicarei em breve.

Backups diferenciais

O outro tipo de backup de dados é um backup diferencial. Um backup diferencial executa as mesmas operações como um backup completo, mas só contém todos os dados que tem alterados ou adicionados desde o backup completo anterior. Uma concepção equivocada é que os backups diferenciais são incrementais. Eles são realmente cumulativos e sucessivos os backups diferenciais após um backup completo e aumentarão de tamanho conforme mais dados são alterados ou adicionados.

Em cada 4 GB seção (chamada de um intervalo GAM) de cada arquivo de dados existe é uma página de banco de dados especial chamada um bitmap diferencial que controla quais partes da seção 4 GB (chamados de extensões) foram alterados desde o último backup completo, que indica dados que tem alterado ou foram adicionados ao banco de dados. (Há vários outros bitmaps de alocação, muito e você pode encontrar mais informações sobre esses no meu artigo de blog" Dentro o mecanismo de armazenamento: GAM SGAM, PFS e outros mapeamentos de alocação").

Um backup diferencial examina a esses bitmaps e somente faz backup de dados extensões de arquivo que são marcadas como alterados. Os bitmaps são redefinidos pelo próximo backup total, para que você possa ver que como mais e mais as alterações de banco de dados, maior dela será marcado em bitmaps diferenciais e backups diferenciais sucessivos será maior e maior. Finalmente, se a maioria dos banco de dados foi alterado, um backup diferencial pode ficar tão grande quanto o backup completo. Você pode descobrir quanto o próximo backup diferencial estará usando um script que escrevi que está disponível no meu artigo de blog" Novo script: como muito do banco de dados foi alterado desde o último backup completo?." Por acaso, esse script também pode ser usado para ter uma idéia da taxa de variação de um banco de dados — por exemplo, em um banco de dados conteúdo do SharePoint.

Como uma observação lado, se você desejar fazer um backup completo ad-hoc e não-redefinir bitmaps diferencial, você deve usar a opção WITH COPY_ONLY na instrução BACKUP. Isso é muito útil, como caso contrário, os os backups diferenciais poderiam ser base o ad-hoc backup total você tirou, em vez de no backup completo (provavelmente agendado) regular. Isso pode levar a grandes problemas ao tentar restaurar uma situação de desastre.

Então, por que são os backups diferenciais útil? Como discutirei a seção de estratégia de backup, os backups diferenciais podem realmente acelerar as operações de restauração, permitindo que muitos backups de log de transação a ser ignorado no processo de restauração. É muito mais rápido para saltar essencialmente avanço no tempo usando um backup diferencial que para necessário repetir muita de registros de log de transação para obter o mesmo ponto no tempo.

Backups de log de transação

Backups do log de transações são possíveis somente em modelos de recuperação FULL ou BULK_LOGGED, enquanto os backups normal e diferenciais também são possíveis no modelo de recuperação simples.

Um backup do log de transações contém todos os os registros de log de transações gerados desde o último backup de log (ou backup completo que inicia uma cadeia de backup de log) e é usado para permitir que o banco de dados ser recuperado até um ponto específico no tempo (geralmente o tempo correto antes de um desastre). Isso significa que eles são incrementais, ao contrário dos backups diferenciais, que são cumulativos. Como esses são incrementais, se você desejar restaurar o banco de dados para um ponto específico no tempo, você precisa ter todos os transação log registros necessários para reproduzir as alterações no banco de dados até que ponto no tempo. Eles estão contidos na cadeia de backup de log.

Uma cadeia de backup de log é uma série sem interrupções de backups de log que contêm todos os registros de log de transação necessários para recuperar um banco de dados para um ponto no tempo. Uma cadeia começa com um backup completo do banco de dados e continua até que algo quebras a cadeia, evitando assim que mais backups de log que está sendo executados até que outro backup total (ou diferencial) é tirado.

Operações quebrar a cadeia de backup de log incluem alternar para o modelo de recuperação simples, a reversão de um instantâneo de banco de dados e forçosamente limpar o log usando as opções TRUNCATE_ONLY ou WITH NO_LOG (que não estão disponíveis no SQL Server 2008). É quebrar a cadeia de backup de log, pois ela força outro backup total (potencialmente grande) a ser tomada.

Embora Alonga uma cadeia de backup do log de volta para um backup completo, você não precisa necessariamente o restaurar os backups de log durante a recuperação. Se você desempenhou um completo backup, digamos, no domingo e na noite de quarta-feira, com cada meia hora desde domingo, de backups de log, em seguida, restaurar o banco de dados após um desastre na sexta-feira poderia usar backup completo do quarta-feira mais todos os backups de log desde a noite de quarta-feira em vez de ter que ir todo o caminho de volta para backup completo do domingo. (O segundo artigo de nossa série irá mais profundo para este tópico.)

Os backups de log também são necessários para ajudar a gerenciar o tamanho do log de transação. Em modelos de recuperação FULL ou BULK_LOGGED, o log não limpará até que um backup do log foi executado (consulte o artigo de fevereiro para obter detalhes do que significa limpar log), para que backups de log regulares devem ser executados para impedir que o arquivo de log crescendo fora do controle. Se não é possível limpar o log, o log irá crescer até que for executado fora do espaço. Assim, se você quiser fazer a recuperação de ponto-in-time usando backups de log, a opção mais fácil é alternar para o modelo de recuperação simples e não usar os modelos de recuperação FULL ou BULK_LOGGED. Abordarei isso mais detalhadamente na postagem do blog" Importância do gerenciamento de tamanho de log de transações apropriado."

Há um caso especial no log que melhora o desempenho, permitindo que algumas operações executar como operações minimamente registrada, onde somente as alocações de página estiverem conectadas, não a inserção real de dados. Isso pode melhorar o desempenho das operações como carregamentos em massa e recria do índice. Nesses casos, nem tudo sobre a operação estiver conectado, portanto, o backup log registros não contém informações suficientes para repetir a operação completamente. Nesse caso, como podem restauração e recuperação possivelmente funcionam se não houver informações suficientes?

A resposta é que o primeiro backup de log após uma operação registrado minimamente também irá conter alguns dados. Assim como os bitmaps diferenciais que mencionei anteriormente, há outro bitmap chamado o bitmap minimamente registrada (às vezes chamado mapa alterado em massa). Este bitmap controla quais extensões de um arquivo de dados foram alteradas devido a uma operação registrado minimamente.

O backup de log após uma operação registrado minimamente examinará a esses bitmaps e também o backup essas extensões de dados são marcadas como tivesse sido alterado. Os bitmaps são limpos após ser digitalizada. Isso significa que o backup de log tem informações suficientes para repetição completamente os efeitos da operação registrado minimamente no banco de dados, quando o backup de log é restaurado. Há uma variação embora: há nada no backup log informando quando qualquer extensão de dados específico foi alterado. Para um backup de log que contém dados de uma operação registrado minimamente também não pode ser restaurado a qualquer ponto no tempo, exceto o fim do período período coberto (ou além, se o backup de log fizer parte de uma cadeia de backup de log que você está restaurando de). Portanto, enquanto você pode obter aprimoramentos de desempenho ao alternar para o modelo de recuperação BULK_LOGGED, você deve considerar uma alteração a ele como uma operação temporária — apenas para melhorar o processo em lotes e depois de concluído o processo em lotes, você deve alternar de volta para FULL e executar um backup log assim que possível.

Também é um backup de log caso especial para permitir que o log para ser feito após um desastre que danifica os arquivos de dados. Isso é chamado de um backup de cauda de log (ou cauda log), onde os arquivos de dados podem estar danificados ou destruídos, mas todos os o log de transação levando a até o ponto de desastre pode ser feito. Isso permite que perda de um mínimo de trabalho (chamada recuperação atualizada) quando o banco de dados posteriormente é restaurado; no entanto, ele é suportado somente quando o banco de dados está em execução no modelo de recuperação FULL. Mais informações sobre esses e restrições com operações registradas minimamente podem ser encontradas no tópico Books Online" Backups de log de cauda." A primeira tela conversão que acompanha este artigo mostra me demonstrando os backups de cauda de log.

Versões do SQL Server anteriores ao SQL Server 2005, backups do log de transações não podem ser executados simultaneamente com backups diferencial do banco de dados ou completo do banco de dados — eles seriam bloqueada até que o backup de nível de banco de dados concluído. Arquivo e backups baseados em grupo de arquivos não causam backups de log bloquear. Enquanto isso complicado o processo de recuperação para backups de arquivo e o grupo de arquivos, ele deu-los uma vantagem bloqueando não backups de log. SQL Server 2005, todos os backups normal e diferenciais (independentemente do componente) trabalhar da mesma maneira. Agora, o comportamento é que o backup de log de transações simultâneas é concluído, mas o log de transações não é desmarcado até o total ou backup diferencial (que requer o log) também é concluído.

Planejamento de estratégia de backup

Agora que você sabe sobre os três tipos de backups e como eles funcionam, mostrarei como você pode colocá-los juntos em uma estratégia de backup.

Uma pergunta comum que recebo é como começar a pensar uma estratégia de backup. Eu sempre gostaria de dizer que você não deve criar uma estratégia de backup. Você deve criar uma estratégia de restauração — que permite restaurar mínimo possível no caso de desastre, portanto, o tempo de inatividade é o menor possível enquanto preserva os dados ainda. Após você trabalhou que check-out, em seguida, trabalhar que você precisa para que você possa executar a restauração de backups que você precisa. Em outras palavras, sua estratégia de backup deve permitir que você atender às suas RTO (recuperação Time Objective) e um RPO (Recovery Point objetivo).

Com uma estratégia que inclui apenas backups completos você estiver um pouco limitado no que você pode fazer com restaurações. Basicamente, você só pode restaurar o tempo de cada backup completo, como na Figura 2 . Se desastre em 23: 59 sábado, apenas antes que o próximo backup total está agendado, em seguida, todo o trabalho desde o último backup completo pode ser perdido. Por esse motivo, se a perda de dados precisa ser evitado e os dados não podem ser recriados, os backups de log também estão incluídos, como mostrado na Figura 3 .

Figura 2 estratégia de backup com apenas os backups totais

Figura 3 estratégia de backup com completo e backups de log

Imagine que os backups de log são seja executados a cada 30 minutos. Desde que todos os backups estão disponíveis, isso significa que o banco de dados possa ser restaurado para qualquer ponto no tempo. No entanto, isso ainda pode não ser a melhor estratégia. E se desastre em 23: 59 sábado com essa estratégia em lugar? Primeira coisa que seria levar um cauda-de-a-log de backup e, em seguida, iniciar a restauração.

Para restaurar o banco de dados até o ponto do desastre significaria restaurando backup completo do último domingo e, em seguida, 336 backups de log (que é seis dias de 48 backups de log por dia, além de 47 sábado mais o backup de cauda de log). Dependendo do quanto variação houve no banco de dados sobre a semana que pode ser uma quantidade enorme de log de transação que levarão muito tempo para repetição. Isso não é claramente uma estratégia de restauração ideal — mas é uma estratégia comum consulte o campo. Se você tiver uma estratégia assim, certifique-se que você tiver praticado fazer uma restauração para saber se pode atender o RTO no caso de desastre.

Para atenuar esse problema, algumas estratégias usam backups mais freqüentes completos — mas isso podem ser excessivamente grandes se todos os dias, por exemplo. A alternativa é usar os backups diferenciais, que contêm somente os dados que foram alterados desde o backup completo anterior. Continuando nosso exemplo, essa estratégia é ilustrada na Figura 4 .

Figura 4 estratégia de backup com integral, log e backups diferenciais

Com essa estratégia, a recuperação de um desastre em 23: 59 sábado é muito mais rápido. Lembre-se que um backup diferencial é cumulativo — portanto, a estratégia de restauração é o backup completo de domingo, o backup diferencial de Sábado 00: 00, além de todos os backups de log de sábado. Ter o backup diferencial de 00: 00 Sábado significa que todos os backups de log antes que podem ser ignorados, pois o backup diferencial contém o mesmo que o resultado líquido de restaurando todos esses backups de log.

Isso foi um exemplo muito simples e forçado, mas ele mostra claramente os benefícios de cada tipo de backup. Depois de você ter criado sua estratégia de backup, verifique se que você testá-lo para garantir que ele permite que você executar restaurações de desejado.

Eis um exemplo que vi uma face de cliente alguns anos consecutivos. Um cliente tinha um banco de dados corrompido e queria recuperar com zero perda de dados. Eles foram relutantes usar seus backups e tentaram executando reparo em uma cópia do banco de dados, mas ele teria que excluir dados, forçá-los em usando seus backups. Aconteceu que tinham um backup completo de janeiro mais um backup do log de cada meia hora até abril — mais de 5.000 backups no total e todos os em fita! Tenho certeza você está sem interrupção seus olhos e pensando "Aposto que funcionou,", mas na verdade foi; no entanto, levou três dias para fazê-lo! O cliente pensou que tinham uma excelente estratégia de backup — backups de recuperação FULL modelo mais log —, mas sua estratégia de backup não permitir que eles fazer restaurações que eles queriam.

Integridade do backup

Não há nenhum ponto na backups se você achar que eles são corrompidos quando tentar restaurar a partir deles. Obviamente, a melhor maneira para verificar a validade dos backups é para restaurá-los em outro servidor, mas no SQL Server 2005 foi introduzido um novo recurso permitido alguns integridade backup verifica a ser executada sem a necessidade, na verdade, restaurá-los. Você pode usar a opção WITH CHECKSUM quando fazer um backup (de qualquer variedade).

Isso cria uma soma de verificação sobre o fluxo de backup inteiro, que é armazenado no backup propriamente dito. Se o backup for um completo ou diferencial e o banco de dados tiver somas de verificação ativadas, esta opção também causar todas as somas existente a ser testado como o processo de backup lê as páginas. Se uma soma de verificação incorreto página for encontrada, a operação de backup falhará. Isso oferece excelente proteção contra acidentalmente fazer backup de um banco de dados que já está corrompido de alguma forma. (Você pode encontrar mais informações sobre somas de verificação no artigo "Principais dicas para efetivas Database manutenção" de agosto de 2008.)

Depois que o backup for concluído, ele pode ser verificado usando um comando semelhante ao seguinte:

RESTORE VERIFYONLY FROM <backup device(s)> WITH CHECKSUM

Será recalcular a soma de verificação sobre o fluxo de backup inteiro e compará-lo contra um armazenados em backup. Para backups normal e diferenciais, ele também testará as somas de verificação em páginas no backup. Se forem encontrados problemas, você saberá que backup foi danificado de alguma forma.

Naturalmente, há exceções à regra, talvez queira fazer backup de um banco de dados corrompido (se ele for a cópia única do banco de dados que têm e você terá que que executar o reparo, por exemplo). Nesse caso, você pode forçar o backup para concluir usando a opção WITH CONTINUE_AFTER_ERROR.

Você pode encontrar mais informações na validação do backup em informações sobre backup validação no meu bloge também observe me demonstram alguns aspectos de validação de backup na segunda tela converter que acompanha este artigo.

Resumo

Como com qualquer tópico complexo, existem muitas áreas de backups que não tenho espaço para abordar, mas agora que são abordadas as noções básicas, você pode aprofundar em alguns dos links manuais online e blog para obter mais informações. O melhor lugar para começar nos manuais online do é o tópico" Visão geral do backup (SQL Server)." No meu blog, você pode iniciar com o Categoria de backup/restauração.

Uma área que você talvez ache é conspicuous na sua ausência é compactação de backup. Isso é proposital como que vai ser abrangendo-lo mais tarde no ano em um artigo sobre todos os as tecnologias de compactação de novo no SQL Server 2008. In enquanto isso, você pode verificar o tópico Books Online" Compactação de backup (SQL Server)"e também em meu blog.

Se eu tivesse somar neste artigo em três pontos de marcador, seriam:

• Verifique se que tem backups.
• Verifique se que tem backups válidos.
• Verifique se que tem backups direita.

Em outras palavras, backups têm se quiser ser capaz de restaurar o banco de dados, faça algo para que você saiba que os backups funcionarão quando você precisá-los e certifique-se que você pode restaurar de seus backups e atender seus RTO e RPO.

No próximo artigo, explicarei tudo sobre restauração de backups, incluindo os diferentes tipos de operações de restauração e como eles funcionam, restaurando de backups de vários e disponibilidade parcial do banco de dados.

Enquanto isso e como sempre, se você tiver qualquer comentário ou dúvida, solte-me uma linha em Paul@SQLskills.com.

Paul S. Randal é o diretor de gerenciamento de SQLskills.com, um MVP do SQL Server e diretor regional da Microsoft. Ele trabalhou na equipe o mecanismo de armazenamento do SQL Server da Microsoft de 1999 a 2007. Paul escreveu o DBCC CHECKDB/repair para SQL Server 2005 e foi responsável pelo mecanismo de armazenamento principal durante o desenvolvimento do SQL Server 2008. Paul é especialista em recuperação de desastres, alta disponibilidade e manutenção de banco de dados e é apresentador regular em conferências pelo mundo. Blogs de he no SQLskills.com/blogs/paul.