Este é meu primeiro post DBA.SE, então por favor me informe sobre qualquer erro, obrigado!
Sou um novo DBA (não um profissional de TI, apenas mais ninguém na empresa para fazer isso), portanto, quanto mais básica a explicação, melhor. Tenho lido sobre estratégias de backup de banco de dados (ou, como aprendi a chamá-las, "estratégias de restauração"). Entendo o que os backups completos, diferenciais e de log de transações fazem, mas quero saber por que um backup diferencial só pode ser baseado no backup completo mais recente.
Se um backup diferencial é tudo o que mudou desde o último backup completo, por que o diferencial não pode ser baseado em nenhum backup de minha escolha? Para ser mais claro, estou perguntando sobre especificar a base quando o backup é feito , não ao restaurar. Estou assumindo que ao restaurar você escolheria a base correta e o diferencial correspondente para realizar a restauração (não usar um diferencial feito da base B para restaurar da base A).
Qual é o motivo que impede que essa funcionalidade seja possível? Acho que deve haver uma razão, só não sei qual é.
Nota: Entendo que a base não pode ser especificada, mas minha dúvida é por que não ? (Também não estou interessado em discussões sobre "por que você faria isso?")
Analogia
Aqui está uma analogia de como eu entendo um backup diferencial:
Eu tenho um arquivo do Excel com alguns dados nas células.
No dia 1, faço uma cópia desse arquivo e o armazeno em outro lugar (o "backup completo").
No dia 2, eu olho para o arquivo e comparo com a cópia de backup que fiz no dia 1, e anoto todas as células que foram alteradas e quais são seus novos valores (um "backup diferencial"). Não estou anotando todas as alterações feitas em uma célula, apenas qual é o seu valor final. Se a célula A1 começasse como "Alfred", mudasse para "Betty", "Charlie" e depois "Dave", eu observaria apenas que "A1 agora é Dave".
No dia 3, comparo o arquivo atual com o arquivo de backup novamente e observo as alterações (outro "backup diferencial" com a mesma base do dia 2). Novamente, anotando apenas os valores finais por célula no horário observado, não todos os valores que a célula ficou ao longo do dia.
No dia 4, comparo novamente e observo as mudanças novamente. Continuando com a célula A1, agora diz "Sarah", mesmo que fossem 10 outros nomes ao longo do dia, e tudo que noto é "Agora A1 é Sarah".
No dia 5, meu arquivo fica confuso; então, vejo a cópia de backup que fiz no dia 1, depois os estados finais anotados no dia 4 e aplico as alterações anotadas na cópia de backup e agora tenho o arquivo "restaurado" como estava no dia 4 Então, eu olho para o backup feito no dia 1, vejo que no dia 4 a célula A1 terminou como "Sarah", e altero a célula de backup A1 para "Sarah".
Por que importaria se eu tivesse feito outra cópia de backup ("completa") do arquivo no dia 2? Por que ainda não seria possível comparar (leia-se, "fazer um backup diferencial de") o arquivo no dia 3 ou 4 com a cópia feita no dia 1? Pelo que entendi, o SQL Server exigiria que eu comparasse (ao fazer outro backup diferencial) com um backup completo feito no dia 2 (se um tivesse sido feito) - nenhuma outra opção.
Um backup diferencial usa o que é chamado de mapa de alteração diferencial para criar uma lista de páginas que foram modificadas desde o último backup completo. Esta lista é uma lista "diferencial", daí o nome do tipo de backup e o motivo pelo qual o backup só pode ser restaurado sobre o backup completo associado.
Executar um backup completo redefine o mapa de alteração diferencial. A partir daí, qualquer página modificada é registrada no mapa. Se você fizer um diferencial, esse backup contém apenas as páginas que foram modificadas desde o último backup completo e registradas no mapa.
Na sua analogia, os dois backups completos, que servem de base para todo o processo de restauração, provavelmente teriam conteúdos diferentes e, portanto, mapas diferenciais diferentes. Se você restaurar um diff com base no primeiro backup sobre o segundo backup, o banco de dados provavelmente será corrompido. Na verdade, o SQL Server impede a restauração de um backup diff sobre qualquer coisa, exceto o backup completo original no qual ele se baseia.
Quando você pede ao SQL Server para fazer um backup diferencial, a única "base" para o diferencial é o único mapa de alteração diferencial presente no banco de dados no momento em que o backup diferencial é iniciado. É por isso que você não pode especificar a base para o backup diferencial.
Em resposta a um comentário de @MartinSmith - você pode usar
COPY_ONLYbackups para restaurar um backup diferencial em vários backups completos. Considere o seguinte cenário:BACKUP DATABASE xyz TO DISK = 'path_to_backup.bak';BACKUP DATABASE xyz TO DISK = 'path_to_backup_2.bak' WITH COPY_ONLY;BACKUP DATABASE xyz TO DISK = 'path_to_backup_3.bak' WITH COPY_ONLY;BACKUP DATABASE xyz TO DISK = 'path_to_backup_4.bak' WITH COPY_ONLY;BACKUP DATABASE xyz TO DISK = 'path_to_backup_diff.bak' WITH DIFFERENTIAL;O backup diferencial na etapa 5 deve poder ser restaurado sobre qualquer um dos backups feitos nas etapas 1 a 4, pois o mapa de alteração diferencial só é limpo quando ocorre o backup completo na etapa 1. Os
COPY_ONLYbackups nas etapas 2, 3 e 4 não redefinem o mapa de alterações. Como o mapa de alteração diferencial acumula alterações feitas desde o backup completo, cada um dos backups sucessivosCOPY_ONLYcontém informações suficientes para que o backup diferencial funcione em qualquer um dos 4 backups anteriores.Embora pareça que deveria funcionar, na prática, restaurar um diferencial por cima de um backup copy_only resulta no seguinte erro:
Eu criei uma reprodução de plataforma do SQL Server 2012 para testar restaurações diferenciais e copy_only e salvei o arquivo em gist.github.com - ATENÇÃO, o script eliminará qualquer banco de dados nomeado
RestoreTestcomo sua primeira etapa.O recurso que você deseja pode existir em princípio. Não seria eficiente com as estruturas de banco de dados atuais (consulte a resposta de Max Vernon). O SQL Server teria que manter um conjunto de mapas de diferenças ou comparar o conteúdo atual do banco de dados com o backup completo especificado como base.
Existem aplicativos que desduplicam arquivos grandes. Você pode fazer dois backups completos e apenas os dados alterados serão realmente armazenados. Isso é como um diff com base personalizada.
exdupepor exemplo pode fazer isso.O bom disso é que ele funciona com qualquer conjunto de arquivos de backup. Na verdade, começando com o terceiro arquivo de backup completo, você pagará apenas pelo uso de espaço incremental (não diferencial). O uso do espaço é a diferença para o arquivo de backup anterior (não para o primeiro). O armazenamento de desduplicação tem um comportamento semelhante.
Por que o recurso que você descreve não existe? Cada recurso consome orçamento fazendo com que outros recursos não estejam presentes. Este aparentemente não foi longe o suficiente na lista de prioridades. Não tenho certeza do que seria bom. Parece um requisito bastante esotérico usar bases personalizadas.
Não confunda backups de log de transações com backups diferenciais, eles têm propósitos diferentes! O que você está chamando de "backup diferencial", pelo qual você "observa todas as alterações nas células", é na verdade um log de transações .
A finalidade de um backup diferencial é manter pequeno o tamanho do arquivo de backup resultante, registrando apenas as informações que foram alteradas desde o último backup completo e manter o tempo de restauração dentro do seu objetivo de tempo de recuperação (RTO).
A finalidade de um backup de log de transações é permitir que você repita as transações em um ponto arbitrário no tempo - frequentemente, mas definitivamente não necessariamente para "o que aconteceu mais recentemente " .
O que você está falando é de fato possível - mas você precisa restaurar o backup completo e, em seguida, restaurar os logs de transação.
Se você tiver o backup completo do dia 1 e todos os backups do log de transações entre o dia 1 e o dia 5, nada o impedirá de restaurar o backup do dia 1 e repetir o log de transações até que você tenha os dados como estavam no dia 4. Você também poderia começar a partir do backup do dia 2, o que seria um pouco mais rápido para restaurar, já que você repetiria menos transações. Você também pode restaurar o backup completo do dia 1, o backup diferencial do dia 3 e, em seguida, restaurar os logs de transações para o dia 4.
Editar: OK, sua analogia editada faz um pouco mais de sentido. A resposta é então "porque você já pode conseguir o que deseja com backups de log de transações". Um backup diferencial é apenas uma maneira barata e conveniente de gravar um monte de atividades de log de transações. Ele não oferece nenhuma granularidade de recuperação de dados que um backup de log de transação não oferece. Existem tantos recursos que oferecem "mera conveniência" que o transformam em um produto.
Fazer uma analogia com o Excel é comparar maçãs e laranjas. Por quê ? O Excel não é um banco de dados, pois carece de integridade de dados. O Excel é um aplicativo de planilha muito bom e pode ser um complemento para o banco de dados.
O SQL Server é um sistema de banco de dados relacional que permite armazenar todos os seus dados e fornece um mecanismo para consultá-los. A parte importante é "Relacional", pois o relacionamento de dados é importante junto com a integridade dos dados (propriedades ACID).
Fundamentos :
Os dados no banco de dados são organizados em componentes lógicos (tabelas, visualizações, procs, gatilhos, etc) que são visíveis ao usuário. No mínimo, um banco de dados também é implementado fisicamente como dois (arquivo de dados e log) ou mais (arquivo de dados secundário) em disco.
Com base na sua analogia sobre o Excel, o que você está fazendo é aplicar o que mudou no anterior. Isso está aplicando todas as transações confirmadas do log de transações
with STOP AT(nota: no dia 5, o arquivo fica confuso e você para no dia 4)Em cada seção de 4 GB (chamada de intervalo GAM) de cada arquivo de dados, há uma página de banco de dados especial chamada bitmap diferencial que rastreia quais partes (chamadas extensões) dessa seção de 4 GB foram alteradas desde o último backup completo, indicando os dados que foram alterados ou adicionado ao banco de dados.
Um backup diferencial varre esses bitmaps e faz backup apenas das extensões de arquivo de dados marcadas como alteradas. Os bitmaps são redefinidos pelo próximo backup completo (portanto, um backup diferencial só pode ser baseado no backup completo mais recente) . e os backups diferenciais sucessivos serão cada vez maiores.
Você pode até usar este script para descobrir quanto do banco de dados foi alterado desde o último backup completo? .
As informações de base diferencial são armazenadas no
masterbanco de dados -sys.database_fileou (sys.master_files- útil quando o banco de dados é somente leitura ou offline).Existem 3 colunas importantes que armazenam informações relacionadas à base diferencial .
differential_base_lsné a base para backups diferenciais. As extensões de dados alteradas posteriormentedifferential_base_lsnserão incluídas no backup diferencial.differential_base_guidé o identificador exclusivo do backup base no qual um backup diferencial é baseado.differential_base_timeé o tempo que corresponde adifferential_base_lsnUm backup diferencial é útil para acelerar o RTO (objetivo de tempo de recuperação = tempo que leva para recuperar seu banco de dados), em oposição a backups completos mais frequentes, que serão um problema para bancos de dados grandes ou restaurar o volume de backups de log de transação, pois eles podem crescer muito ao longo do tempo.
Observação: um backup completo COPY_ONLY não redefine a base diferencial, portanto, um backup COPY_ONLY não pode servir como base diferencial.
Referências :