Backup com o modelo de recuperação completa
O modelo de recuperação completa usa backups de log para evitar a perda de dados no intervalo mais amplo de cenários com falhas e o backup e a restauração do log de transações (backups de log) são necessários. A vantagem de usar backups de log é que eles permitem que você restaure um banco de dados em qualquer ponto no tempo contido dentro de um backup de log (recuperação pontual). É possível usar uma série de backups de log para efetuar roll forward de banco de dados em qualquer momento determinado contido em um dos backups de log. Lembre-se de que para minimizar o tempo de restauração, você pode suplementar cada backup completo com uma série de backups diferenciais dos mesmos dados.
Supondo que é possível fazer backup do log ativo após ocorrer um desastre, você pode restaurar o banco de dados até o ponto de falha sem perder os dados. As desvantagens de usar backups de log são que eles requerem espaço de armazenamento e aumentam o tempo e a complexidade da restauração.
.gif "Observação") Observação |
|---|
Se os benefícios de usar backups de log não justificarem o custo de gerenciar os backups, recomendamos o uso do simple recovery model. |
Para um banco de dados que usa periodicamente o modelo de recuperação completa, você pode otimizar certas operações em massa usando temporariamente o modelo de recuperação bulk-logged. O modelo de recuperação bulk-logged incorre em diversas restrições que o tornam não apropriado para operações cotidianas. Para obter mais informações, consulte Backup no modelo de recuperação com log de operações em massa.
Estratégia de amostra de backup
A ilustração a seguir mostra a estratégia de backup mais fácil sob o do modelo de recuperação completa. Na ilustração, foram feitos um backup de banco de dados completo, Db_1 e dois backups de log de rotina, Log_1 e Log_2. Algum tempo depois do backup de log Log_2, ocorre a perda de dados no banco de dados. Antes de esses três backups serem restaurados, o administrador do banco de dados deve fazer backup do log ativo (o tail of the log). O administrador do banco de dados restaura em seguida o Db_1, Log_1 e Log_2 sem recuperar o banco de dados. Então o administrador do banco de dados restaura e recupera o backup do final do log (Tail). Isso recupera o banco de dados até o ponto da falha, recuperando todos os dados.
.gif "Restaurando um banco de dados de modelo de recuperação completa")
Para obter mais informações, consulte Backups completos de banco de dados e Trabalhando com backups de log de transações.
Minimizando a exposição à perda de trabalho
Depois que o primeiro backup de banco de dados completo é concluído e os backups de log regulares são iniciados, a exposição à perda de trabalho potencial fica restrita entre o tempo em que o banco de dados foi danificado e o backup de log regular mais recente. Portanto, recomendamos fazer backups de log com freqüência suficiente para manter sua exposição à perda de trabalho dentro dos limites exigidos pelos requisitos comerciais.
A ilustração a seguir mostra uma estratégia de backup que complementa backups de banco de dados completos e backups de log com backups de banco de dados diferenciais. Os backups de log de transações reduzem a exposição à perda de trabalho potencial ao momento seguinte ao backup de log mais recente, t14. Uma série de três backups diferenciais é usada para reduzir o número de logs de transações que precisam ser restaurados em caso de falha. O terceiro backup diferencial é grande o bastante para que o próximo backup seja um backup de banco de dados completo. Isto estabelece uma nova base diferencial.
.gif "Backups completos & diferenciais de bancos de dados & backups de log")
Antes do primeiro backup de banco de dados nesta figura, o banco de dados é exposto à perda de trabalho potencial (do tempo t0 a t1). Posteriormente, os backups de log rotineiros reduzem a exposição à perda de trabalho ao risco de perder alterações feitas depois do último backup de log (feito no tempo t14 nesta figura). Em caso de falha após o backup mais recente, o administrador do banco de dados tenta fazer backup da parte final do log (o log do qual ainda não foi feito o backup). Se o backup do final do log for bem-sucedido, o administrador do banco de dados poderá evitar qualquer perda de trabalho, restaurando o banco de dados até o ponto de falha.
Para obter informações sobre backups de banco de dados diferenciais, consulte Usando backups diferenciais.
Operações em massa e modelos de recuperação completa
Ao fazer o log de todas as operações, inclusive operações em massa como SELECT INTO, CREATE INDEX e dados de carregamento em massa, o modelo de recuperação completa permite a recuperação de um banco de dados até o ponto de falha ou para um momento determinado anterior, chamado restauração ponto no tempo.
Muitos usuários do modelo de recuperação completa mudam temporariamente para o modelo de recuperação bulk-logged quando os dados de carregamento em massa e o aumento de desempenho excedem o risco da possível perda de dados. O modelo de recuperação bulk-logged praticamente não faz o log das operações em massa, embora faça o log completo de outras transações. Para obter mais informações sobre o modelo de recuperação bulk-logged, consulte Backup no modelo de recuperação com log de operações em massa.
| Observação |
|---|
No SQL Server 2005 e em versões posteriores, a opção de banco de dados select into/bulkcopy do sp_dboption nunca é exigida e deve sempre ser evitada. Em vez disso, você deve usar ALTER DATABASE. Este procedimento armazenado de sp_dboption será removido em uma versão futura do SQL Server. |
Usando backups para restaurar um banco de dados
A restauração de um banco de dados exige uma seqüência de operações de restauração (uma seqüência de restauração). A seqüência de restauração inicia-se com a restauração de pelo menos um backup completo, seguida opcionalmente, por um backup diferencial correspondente.
Cada backup completo e diferencial contém registros de log suficientes para permitir que você os use para recuperar o banco de dados. No entanto, normalmente você desejará restaurar os backups de log subseqüentes, em seqüência, terminando com o backup do final do log, se houver algum. Por isso, antes de você começar a restaurar um banco de dados, você deve criar um backup do final do log. O backup do final do log permite restaurar o banco de dados até o ponto de falha. Quando o último backup de log for restaurado, você deve recuperar o banco de dados.
| Observação |
|---|
Sob o modelo de recuperação completa ou modelo de recuperação bulk-logged, o SQL Server 2005 Enterprise Edition e versões posteriores dão suporte à restauração de arquivos ou páginas ou ambos, enquanto um banco de dados estiver online. Isto é conhecido como restauração online. A sintaxe RESTORE para restaurar os arquivos ou páginas é a mesma caso o banco de dados esteja offline ou online. |
Para obter mais informações, consulte Visão geral da restauração e recuperação (SQL Server).
Consulte também