Backups Full e Diferencial

Não existem formulas tudo vai do cenário, principalmente quantidade de transações, crescimento e a importância dos dados a serem backpeados.

As vezes apesar da base ser grande os dados não são estratégicos e nem são atualizados a todo momento. Então vai muito de como o DBA percebe o ambiente e os dados como um todo.

Para um detalhamento das modalidades de backup acho interessante ler o póst Tipos de backup no SQL Server


Muitas vezes é feito um backup full por dia, Backup Diferencial de tempos em tempo (vai depender da periodicidade que sua base é atualizada) e Backup de Log de Transação.

Acho que o mais importante, que as vezes e negligenciado, seria onde o backup vai ser armazenado e o tamanho do backup. Claro que o ideal seria um back up full mas lembre-se que irá consumir espaço para o backup então dai usa-se o Backup Diferencial.

Outra boa pratica é guardar o backup fora da empresa, pois já muita empresa que faz o backup em um servidor ao lado do servidor de bd ou em fita que fica ao lado do servidor de bd. Se ocorrer qual catástrofe (fogo, desabamento, enchentes e etc) tanto o servidor de bd quanto o backup será atingido. O melhor é conseguir guardar uma cópia fora do espaço físico do cliente de preferencia em um lugar preparado para isto.

Sei que estou sendo pessimista e pintando um cenário de catástrofe (só faltou ops zumbis), mas a perda de seus dados é uma catástrofe, então não custa ser precavido.

Já li um pouco catastrofes, inclusive historias de que empresas fecharam suas portas depois do atentado do 11 setembro, pois um backup iria para outro predio, vizinho!
São varios tipos de backup, não conhecia essas.

Só complementando o colega Jothaz, na empresa implementei uma estratégia de backup no SQL Server que consiste hein:
- Um backup full por dia (de madrugada)
- A partir das 7:00 da manhã até as 18:00 com intervalos de 2 horas executo um backup diferencial
- A partir das 8:00 da manhã até as 17:00, backups de log

Uma vez por semana é feito um backup full do disco (com banco de dados, scripts dos portais e etc) para fora do servidor (serviço cloud)

Uma boa visão tenho agora, isso depende da base ou de alguma outra coisa?

Então Marília, no meu caso fiz um estudo sobre os picos de acessos e escritas aos bancos de dados dos portais e ao nosso ERP, após algumas métricas chegamos a conclusão que das 7:00 as 18:00 hs seria um horário importante para ser coberto por backups, após esses horários os acessos aos 14 portais despencam além de não possuir um fluxo de escrita no banco muito grande.

Quanto ao backup full é realizado de madrugada então acaba não impactando, também executo alguns planos de manutenção no bancos e reindexação que são demorados, mas sempre durante a madrugada.

É com auditoria que se obtem tais informações?

Nós temos algumas ferramentas, principalmente para medir os acessos aos portais, já o sistema ERP é sempre acessado durante o horário comercial pelas vendedoras.

Por favor, cite as ferramentas, sendo pagas ou não.

Marilia, algumas opções.

[url]https://www.google.com/search?q=tipos+de+backup+ql+server&ie=utf-8&oe=utf-8[/url]

Obrigada, são muito, tenho que ver com calma cada um.

As informações compartilhadas pelo William, são completas e pode ser usadas como um norteador.

Só que mais importante que o backup é garantir a disponibilidade do ambiente (aplicação e bd) com redundância de links, espelhamento e clusters.

Porque nem sempre efetuar o restore de um backup é tarefa trivial. Se você possui um bd com base distintas pode ser bem simples. Mas se os sistemas compartilharem informações pode ser bem complicado.

Por exemplo atualmente sou responsavel por sistemas da área de engenahria (são 5 módulos que compartilham informações) e ainda compartilham informações com a área financeira e gestão estratégica. Estes sistemas funcionam 24 hs, pois temos projetos em dezenas de paises (china, india, europa, africa e e etc) então efetuar um restore da base de dados é muito complicado, então o backup é fundamental, mas nem sempre o restore simple é fácil de efetuar.

O ideal é nunca precisar do backup, pois quando você precisa a coisa esta feia. kkkkkkkkkkkkk

Imagino, por isso que sempre falam que um banco bem desenvolvido quase nunca dará problemas.

Raramente se encontra um banco assim.

Mesmo banco de desenvolvimento podem dar problemas.

Normalmente usa-se 3 ambiente: desenvolvimento, homologação ou QA - qualidade (seria a cópia da produção) e produção.

Imagina que você esta com um banco de desenvolvimento onde esta desenvolvendo várias melhorias. Ai algum gaiato faz um cópia do banco da homologação e sobrescrever no banco de desenvolvimento e mata suas melhorias. Dai somente restaurando backup oque nem sempre é banal.

Então não existem estas lendas. Só não vai dar problemas ou os problemas serão simples de resolver o banco de dados de estudos na sua máquina pessoal. Que normalmente não tem informações relevantes.

Tambem imagino que com o decorrer do tempo o banco passar a possuir uns "remendos".