Início / dba / Perguntas / 193573
Accepted
Guillermo Garcia
Asked: 2017-12-20 15:39:15 +0800 CST

(Ola Hallengren) Excluindo backups de log anteriores ao último backup FULL

  • 772

Quando implemento o script de backup de Ola Hallengren em meus servidores, sempre defino o @CleanupTimeparâmetro para backups de log como zero. Dessa forma, toda vez que o trabalho de backup de log é executado, ele verifica os arquivos de backup de log mais antigos que o último backup completo e os exclui. No entanto, isso também é verdade para COPY_ONLYbackups completos! A tarefa de backup de log deve verificar apenas o último COPY_ONLYbackup não completo para excluir arquivos de backup de log antigos.

Apenas me perguntando se eu sou o único que se deparou com isso, ou se o que estou sugerindo faz sentido. Se eu precisar fazer um backup somente de cópia completa no meio do dia para o IDK atualizar um banco de dados TEST, esse backup somente de cópia não deverá afetar a sequência de backup diário regular. Deixe-me saber seus pensamentos, por favor.

sql-server sql-server-2012

3 respostas

  1. Best Answer

    Parte II de II (teve que dividir minha resposta)

    Fazendo isso melhor

    Considerando seu RPO e RTO definidos pelo seu negócio, agora você pode querer alterar o parâmetro do @CleanupTimepara algo maior que 0. Por quê? Porque o valor 0só funcionará em conjunto com o mecanismo interno à prova de falhas.

    Vamos usar a seguinte linha do tempo:

    • 08:00 REGISTRO DE BACKUP
    • 09:00 REGISTRO DE BACKUP
    • 10:00 LOG DE BACKUP
    • ...
    • 20:00 BANCO DE DADOS DE BACKUP
    • 21:00 REGISTRO DE BACKUP
    • ...

    Em algum momento, seus backups de log de transações (e backups completos?) são copiados para uma unidade de rede e copiados de lá por meio de uma solução de backup, possivelmente combinada com algum tipo de armazenamento em fita e/ou disco. Assim que o primeiro BACKUP LOG ...ocorrer após o último , BACKUP DATABASE ...seus BACKUP LOG ...arquivos anteriores desapareceram...

    Perguntas para se questionar a si mesmo

    • O que acontece se o backup de rede falhar?
    • Quando ocorre esse backup (em fita)? Garantido?
    • Quando ocorre o backup completo do banco de dados?
    • O que você quer poder restaurar?
    • Qual RTO você tem?
    • Qual RPO sua empresa precisa?

    Observando as perguntas acima, considere usar um tempo de limpeza diferente (por exemplo @CleanupTime=48, ) para manter horas adicionais de backups do log de transações nos discos do servidor de banco de dados.

    Benefícios

    • Você não está mais confiando no mecanismo à prova de falhas do Ola
    • Seus dados ainda estão no disco, mesmo se você criar um COPY_ONLYbackup
    • Seus dados ainda estão no disco, mesmo que a rede caia e ...
      • ... você cria umBACKUP DATABASE ...
      • ... um COPY_ONLYbackup

    Construindo uma base sólida

    Em qualquer momento, algo irá falhar. Você tem que garantir que pode acomodar quaisquer falhas no futuro e ainda garantir aos interessados ​​que sua solução será 99,.....% à prova de erros.

    Como eu faço isso

    Trabalhar com a solução da Ola é muito fácil, SE você pensar uma ou duas vezes em como deseja recuperar um banco de dados e com base no RPO e RTO de seus negócios.

    Minha implementação pessoal é ter as seguintes políticas de agendamento/retenção:

    Sistemas de produção

    • Backup TLog
      • De hora em hora @ xx:05 (sistemas não SAP)
      • Trimestral por hora às xx:10, xx:25, xx:40, xx:55 (sistemas SAP)
      • Retenção: 48 horas
    • Backup Diferencial Diário
      • Segunda a sábado às 20:00 (sistemas não SAP)
      • Segunda a sábado às 22:00 (sistemas SAP)
      • Retenção: 168 horas
    • Backup completo semanal
      • Domingo às 20:00 (sistemas não SAP)
      • Domingo às 22:00 (sistemas SAP)
      • Retenção: 336 horas

    Sistemas de teste

    Será feito backup do sistema de teste durante o horário de produção. Isso pode ser às 10:00 da manhã ou às 14:00 da tarde para backups completos e xx:15 para os backups do log de transações.

    Por que eu faço assim

    ... ou meus pensamentos por trás dessas decisões ...

    Ao distribuir os tempos de backup para diferentes slots, estou distribuindo uniformemente a E/S de disco nos sistemas de armazenamento. Sem aglomeração de E/S maciça no disco nas horas completas (FULL) ou nas horas trimestrais (TLOG).

    Eu diferencio entre SAP e não SAP por causa dos tamanhos dos bancos de dados.

    Os sistemas de teste podem debulhar o armazenamento durante o dia. Sem impactos de alto desempenho.

    Os backups DIFF e FULL ocorrem antes do início dos backups em fita e normalmente são concluídos antes do início dos backups em fita.

    As políticas de retenção me permitem alcançar o RTO e o RPO definidos pela empresa, mesmo que a solução de backup (fita) fique inativa por um dia.

    Os backups ainda funcionarão e estarão em conformidade com RTO e RPO mesmo se a rede (como um todo ou apenas parcialmente) estiver inativa por um dia.

    Seu processo de pensamento

    Sua @CleanupTimeconfiguração provavelmente foi baseada em um entendimento errado do roteiro de Ola.

    • 5

  2. Parte I de II (teve que dividir minha resposta)

    Há uma ou duas coisas para pensar aqui. Na minha opinião, você pode ter tomado um atalho no processo de pensamento. Vou explicar enquanto estou fazendo essa suposição...

    Você pode querer dar uma olhada rápida na minha resposta aceita aqui, que foi postada em referência à pergunta Precisa de sugestão na estratégia de backup [fechada] para fornecer algumas ideias sobre RTO e RPO.

    Por quê? Porque configurar @CleanupTime=0pode ser uma má ideia...

    Primeiro a responder sua pergunta.

    É um bug no script de Ola? - Não. Ola projetou seu script para verificar o último BACKUP DATABASE...(Backup Completo) e, em seguida, excluir os backups de logs de transações ( BACKUP LOG ...) que ocorreram antes desse backup e somente se @CleanupTimefor menor do que quando ocorreu o Backup COMPLETO.

    Este é um mecanismo à prova de falhas e não deve ser usado como um recurso geral.

    Funciona conforme projetado, porque a BACKUP DATABASE ... WITH COPY_ONLY...ainda é um Backup Completo .

    Segurança primeiro

    Criar um backup com a BACKUP DATABASE ... COPY_ONLY...opção e, em seguida, criar BACKUP LOG...ainda permitirá restaurar o banco de dados para um estado consistente usando o COPY_ONLYbackup COMPLETO e os backups de log de transações disponíveis.

    Eu testei isso usando meu banco de dados StackExchange:

    • Criando um COPY_ONLYbackup manualmente
    • Modificando alguns dados
    • Executando um BACKUP LOG ...usando os scripts do Ola
    • Restaurando o banco de dados

    Backup manual comCOPY_ONLY

    --------------------------------------------------
BACKUP DATABASE [StackExchange] TO DISK = 'C:\adhoc\StackExchange_Full_CopyOnly_20171221_082242.bak'
                WITH COPY_ONLY, COMPRESSION, RETAINDAYS = 3, NOFORMAT, NOINIT, NAME = N'StackExchange-Full Backup Sichern', SKIP, NOREWIND,
                     NOUNLOAD, STATS = 10, CHECKSUM
--------------------------------------------------
10 por cento processado.
21 por cento processados.
31 por cento processados.
40 por cento processado.
50 por cento processado.
61 por cento processados.
70 por cento processado.
80 por cento processado.
91 por cento processado.
376 páginas processadas para o banco de dados 'StackExchange', arquivo 'StackExchange' no arquivo 1.
100 por cento processado.
2 páginas processadas para o banco de dados 'StackExchange', arquivo 'StackExchange_log' no arquivo 1.
BACKUP DATABASE processou com sucesso 378 páginas em 0,027 segundos (109,103 MB/s).
--------------------------------------------------
Finalizado

    Backup do log de transações com os scripts do Ola

    Data 21.12.2017 08:29:06
Histórico de tarefas de log (Backup de banco de dados OLA - USER_DATABASES - LOG)

ID da Etapa 1
Servidor MYNOTEBOOK
Nome do trabalho Backup de banco de dados OLA - USER_DATABASES - LOG
Nome da etapa Backup do banco de dados OLA - USER_DATABASES - LOG
Duração 00:00:01
Gravidade do SQL 0
ID da mensagem SQL 0
Operador enviado por e-mail    
Operadora Net enviada   
Operador paginado  
Tentativas Tentadas 0

Mensagem
Executado como usuário: NT Service\SQLSERVERAGENT. ...557.0 Edition: Developer Edition (64 bits) Procedimento: [msdb].[dbo].[DatabaseBackup] Parâmetros: @Databases = 'USER_DATABASES', @Directory = 'C:\SQL\Backup', @BackupType = 'LOG', @Verify = 'Y', @CleanupTime = 48, @CleanupMode = 'AFTER_BACKUP', @Compress = NULL, @CopyOnly = 'N', @ChangeBackupType = 'N', @BackupSoftware = NULL, @CheckSum = 'Y', @BlockSize = NULL, @BufferCount = NULL, @MaxTransferSize = NULL, @NumberOfFiles = NULL, @CompressionLevel = NULL, @Description = NULL, @Threads = NULL, @Throttle = NULL, @Encrypt = 'N' , @EncryptionAlgorithm = NULL, @ServerCertificate = NULL, @ServerAsymmetricKey = NULL, @EncryptionKey = NULL, @ReadWriteFileGroups = 'N', @OverrideBackupPreference = 'N', @NoRecovery = '

[encurtado]

  ... Código de saída do processo 0. A etapa foi bem-sucedida.

    Restaurar

    USE [master]
-- Restore the COPY_ONLY Backup 
RESTORE DATABASE [StackExchange] FROM  DISK = N'C:\adhoc\StackExchange_Full_CopyOnly_20171221_082242.bak' 
WITH  REPLACE, FILE = 1,  NORECOVERY,  NOUNLOAD,  STATS = 5
-- Restore an OLA Transaction Log backup
RESTORE LOG [StackExchange] FROM  DISK = N'C:\SQL\Backup\MYNOTEBOOK\StackExchange\LOG\NB31710_StackExchange_LOG_20171221_082906.trn' 
WITH  FILE = 1,  NOUNLOAD,  STATS = 5

    Você pode não a diferença nos timestamps é de aprox. 7 minutos.

    Resultados

    6 por cento processado.
10 por cento processado.
16 por cento processados.
21 por cento processados.
25 por cento processado.
31 por cento processados.
36 por cento processados.
40 por cento processado.
46 por cento processados.
50 por cento processado.
55 por cento processado.
61 por cento processados.
65 por cento processado.
70 por cento processado.
76 por cento processados.
80 por cento processado.
86 por cento processados.
91 por cento processado.
95 por cento processado.
100 por cento processado.
376 páginas processadas para o banco de dados 'StackExchange', arquivo 'StackExchange' no arquivo 1.
2 páginas processadas para o banco de dados 'StackExchange', arquivo 'StackExchange_log' no arquivo 1.
RESTORE DATABASE processou com sucesso 378 páginas em 0,021 segundos (140,276 MB/s).
100 por cento processado.
0 páginas processadas para o banco de dados 'StackExchange', arquivo 'StackExchange' no arquivo 1.
2 páginas processadas para o banco de dados 'StackExchange', arquivo 'StackExchange_log' no arquivo 1.
RESTORE LOG processou com sucesso 2 páginas em 0,005 segundos (2,441 MB/s).

    Resumo

    O roteiro de Ola funciona conforme projetado. Verificamos que a BACKUP DATABASE ... WITH COPY_ONLY...e um adicional BACKUP LOG ...funcionarão juntos. O recurso à prova de falhas garante que você possa restaurar seu banco de dados com o último backup completo (seja COPY_ONLY ou não) e os backups de log de transações disponíveis.

    (Por favor, leia a Parte II de II para mais respostas)

    • 3

  3. Você está certo! Eu acho que isso é um bug ou by-design. Consegui repo o cenário.

    Então, basicamente, quando você executa o script de Ola com isso:

    EXECUTE [master].[dbo].[DatabaseBackup] 
@Databases = 'UserShrinkSizeTest', 
@Directory = N'C:\Backup', 
@BackupType = 'FULL', 
@Verify = 'Y', 
@CleanupTime = NULL, 
@CheckSum = 'Y', 
@LogToTable = 'Y',
@CopyOnly = 'Y' --copy_only param

    Ou nativa:

    -- native copy_only
BACKUP DATABASE [UserShrinkSizeTest] 
TO  DISK = N'C:\Backup\machine$SQLSERVER16\UserShrinkSizeTest\COPY_ONLY\UserShrinkSizeTest_21122017_COPYONLY.bak'
 WITH  COPY_ONLY, INIT, STATS = 1
GO

    Ao executar um novo backup completo ou copy_onlybackup completo ou mesmo backup diferencial, todos os backups de log anteriores serão excluídos após a execução de outro backup de log (script de backup de log do Ola com @CleanupTime = 0param).

    Testado usando a versão do script de Ola: 7 de outubro de 2016 .

    Baseado no site da Ola :

    Tempo de limpeza

    Especifique o tempo, em horas, após o qual os arquivos de backup serão excluídos. Se nenhuma hora for especificada, nenhum arquivo de backup será excluído.

    O DatabaseBackup tem uma verificação para verificar se os backups de log de transações mais recentes que o backup completo ou diferencial mais recente não são excluídos.

    Não mencionou sobre COPY_ONLYbackups.

    Enquanto isso, você pode alterar o parâmetro de backup de log @CleanupTime = NULLcomo uma solução alternativa. Ou considere mudar para outras ferramentas de backup (por exemplo, Minion Backup ou dbatools ) ou role seu próprio código personalizado porque a última atualização do Plano de Manutenção de Ola foi em 7 de outubro de 2016. Há um github se você quiser levantar um problema/aprimoramento.

    • 1

relate perguntas