none
Melhor estrutura p/ Backup RRS feed

  • Pergunta

  • Bom dia pessoal, tudo bem? Sei que deve ter milhares de topicos falando sobre backup do SQL Server mas resolvi abrir um pra pedir ajuda sobre o meu cenário atual.

    Atualmente tenho um BD de 70GB, que trabalha com o ERP Protheus.

    Sempre discuti muito a questão de banco com meus colegas consultores/analistas e os mesmos sempre falaram que a maioria dos clientes fazem 1 backup full por dia. Segue as duvidas:

    - Atualmente eu faço 2 backup`s full por dia. Um as 12:00 e outro as 23:59. Ql seria a melhor forma pra estruturar o backup? 1 Full por dia e alguns incremental durante o dia? Eu queria perder o mínimo de informações possíveis, pois o volume de emissão de NF está alto.

    - Outra dúvida, é errado fazer um full diariamente? Ouvi falar que fazendo o full limpa o que tem na tempdb. Isso é verdade? A Tempdb é uma copia do meu banco atual?

    Grato pela ajuda. :)

    segunda-feira, 31 de março de 2014 12:45

Respostas

  • Olá Caio.

    Não é recomendado ficar fazendo backup's Full diários, ainda mais 2 por dia. Devido ao tamanho do seu banco, provavelmente o tempo demandado pelo backup não está sendo alto, porém a tendência é a base crescer, e consequentemente aumentar o tempo do backup e o tempo de resposta das operações realizadas no seu banco. Minha sugestão, de estratégia para backup é:

    - 1 backup full semanal, sendo realizado em um sábado ou domingo, na madrugada;

    - 1 backup differential por dia, durante a semana comercial, realizado na madrugada;

    - backups de T-logs diários (o intervalo de tempo deve ser avaliado por você, dentro da política determinada pela empresa como perda aceitável de dados). 

    Em relação ao backup do T-log, lembre que mesmo que você configure os backups para ocorrerem a cada 1 hora, por exemplo, você pode recuperar informações do Transactrion log que ainda não tenha ido para um backup. Ex.: Às 10:30 Hs ocorre uma falha no banco, e seu backup é a cada hora (9, 10, 11, etc...). Você pode realizar o chamado Backup de Tail Log, que recupera a parte ativa do log, mesmo que o banco esteja indisponível, porém desde que o arquivo do Transaction log esteja íntegro. Pesquise mais sobre o assunto.

    Lembrando que essa estratégia sugerida refere-se à backup realizado pelo SQL Server, e não por ferramentas de terceiros. Minha recomendação é que você tenha as 2 estratégias, afinal quem tem um backup não tem nenhum.

    Em relação ao TempDB, a afirmação não está correta, o que é armazenado nesse database são dados temporários, como objetos criados pelo SQL Server e versionamento de registros. Um banco de dados não é carregado para o TempDB.

    Mais informações sobre backup no SQL Server você pode obter no linka abaixo:

    http://angmaximo.wordpress.com/2012/05/15/backup-restore-databases/

    Espero ter ajudado.




    Angelo Máximo
    MCSA | MTA | MCITP | MCT | CCSQLA
    sqlmax@outlook.com
    http://angmaximo.wordpress.com/

    Se a resposta foi útil, não esqueça de classificá-la.

    • Sugerido como Resposta Angelo Maximo segunda-feira, 31 de março de 2014 18:31
    • Marcado como Resposta Caio Tostes segunda-feira, 31 de março de 2014 20:11
    segunda-feira, 31 de março de 2014 17:08

Todas as Respostas

  • Olá Caio.

    Não é recomendado ficar fazendo backup's Full diários, ainda mais 2 por dia. Devido ao tamanho do seu banco, provavelmente o tempo demandado pelo backup não está sendo alto, porém a tendência é a base crescer, e consequentemente aumentar o tempo do backup e o tempo de resposta das operações realizadas no seu banco. Minha sugestão, de estratégia para backup é:

    - 1 backup full semanal, sendo realizado em um sábado ou domingo, na madrugada;

    - 1 backup differential por dia, durante a semana comercial, realizado na madrugada;

    - backups de T-logs diários (o intervalo de tempo deve ser avaliado por você, dentro da política determinada pela empresa como perda aceitável de dados). 

    Em relação ao backup do T-log, lembre que mesmo que você configure os backups para ocorrerem a cada 1 hora, por exemplo, você pode recuperar informações do Transactrion log que ainda não tenha ido para um backup. Ex.: Às 10:30 Hs ocorre uma falha no banco, e seu backup é a cada hora (9, 10, 11, etc...). Você pode realizar o chamado Backup de Tail Log, que recupera a parte ativa do log, mesmo que o banco esteja indisponível, porém desde que o arquivo do Transaction log esteja íntegro. Pesquise mais sobre o assunto.

    Lembrando que essa estratégia sugerida refere-se à backup realizado pelo SQL Server, e não por ferramentas de terceiros. Minha recomendação é que você tenha as 2 estratégias, afinal quem tem um backup não tem nenhum.

    Em relação ao TempDB, a afirmação não está correta, o que é armazenado nesse database são dados temporários, como objetos criados pelo SQL Server e versionamento de registros. Um banco de dados não é carregado para o TempDB.

    Mais informações sobre backup no SQL Server você pode obter no linka abaixo:

    http://angmaximo.wordpress.com/2012/05/15/backup-restore-databases/

    Espero ter ajudado.




    Angelo Máximo
    MCSA | MTA | MCITP | MCT | CCSQLA
    sqlmax@outlook.com
    http://angmaximo.wordpress.com/

    Se a resposta foi útil, não esqueça de classificá-la.

    • Sugerido como Resposta Angelo Maximo segunda-feira, 31 de março de 2014 18:31
    • Marcado como Resposta Caio Tostes segunda-feira, 31 de março de 2014 20:11
    segunda-feira, 31 de março de 2014 17:08
  • Show de bola. Vou estudar como faz o backup do T-Log.. não conheco.

    Estou pensando em montar a estrutura pra fazer replicação pra outro servidor tb, do banco Angelo. O que voce acha?

    Muito obrigado pela resposta.

    segunda-feira, 31 de março de 2014 18:15
  • Nesse caso recomendo usar o AlwaysOn Availability Group (SQL Server 2012 apenas), porém caso você possua uma versão diferente, pode usar o database mirroring. Esse recurso sincroniza a base principal em uma base espelhada, em outra instância, mantendo os bancos sincronizados, dependendo do modo de operação (high safety = espelhamento síncrono, high performance = espelhamento assíncrono). É possível configurar um servidor Witness, que fica monitorando as instâncias, e quando não há resposta da base principal, o witness faz o chaveamento para a base espelhada.

    http://technet.microsoft.com/en-us/library/ms189852.aspx

    http://angmaximo.wordpress.com/2012/08/04/database-mirroring-workgroup/

    Espero ter ajudado.



    Angelo Máximo
    MCSA | MTA | MCITP | MCT | CCSQLA
    sqlmax@outlook.com
    http://angmaximo.wordpress.com/

    Se a resposta foi útil, não esqueça de classificá-la.

    segunda-feira, 31 de março de 2014 18:31
  • Angelo, ja testei aqui o backup full/diferencial blzinha. Agora como nunca mexi com backup do t-log surgiu a duvida.

    No caso, como é log, eu vou fazer o restore dele como? Só pra entender. Se eu faço o backup de 1 em 1 hora, vamos supor que acontece algum desastre no banco e preciso recuperar a ultima hora. Como faria p/ passar o bkp do Log pra meu banco real?


    Desculpa a ignorância mas é que estou começando agora a mexer com SQL Server. Valeu! :)

    segunda-feira, 31 de março de 2014 20:32
  • Caio, sem problemas, fico feliz em poder ajudar.

    Melhor apresentar um case do que ficar explicando.

    Você tem no seu ambiente a seguinte estratégia de backup:

    - Full aos Sábados, iniciando às 22 Hs;

    - Differential de Domingo à sexta, iniciando às 22 Hs;

    - Backup de Transaction Log diário, executando de hora em hora, entre 8 e 20 Hs.

    Na Quarta feira, às 11:30 Hs ocorre um problema com o banco, o mesmo fica indisponível. Ao rodar um DBCC CHECKDB, é reportado que o banco está corrompido. Para recuperar o banco, com perda mínima de dados, você deve restaurar seus backups na seguinte ordem:

    - realizar backup do transaction log, com o parâmetro WITH NORECOVERY (backup de Tail Log);

    - restore do backup Full realizado no Sábado, que é o backup base para qualquer estratégia de backup;

    - restore do backup differential de Terça-feira (o problema ocorreu na Quarta, às 11:30 Hs);

    - restore dos backups de Transaction log realizados na Quarta-feira, na ordem que eles foram realizados (8, 9, 10 e 11 Hs);

    - restore do backup de Tail log, com o parâmetro WITH RECOVERY.

    Nessa sequencia de restore, você conseguirá recuperar o banco com praticamente zero de perda de dados, devido ao backup de Tail Log pegar a parte ativa do transaction log que ainda não foi para backup (desde que o transaction log esteja íntegro, senão não poderá ser realizado o backup de tail log, e nesse caso você terá 30 minutos de perda, nesse exemplo).

    Uma das condições primordiais para essa estratégia, com backups de transaction logs, é que o database esteja com o modo de recovery Full, senão apenas backups Full e Differential estarão disponíveis.

    Recomendo que você pesquise sobre o assunto, faça labs para poder implantar em seu ambiente de produção.

    http://technet.microsoft.com/pt-br/library/ms187048.aspx

    Espero ter conseguido esclarecer um pouco mais sobre o assunto.


    Angelo Máximo
    MCSA | MTA | MCITP | MCT | CCSQLA
    sqlmax@outlook.com
    http://angmaximo.wordpress.com/

    Se a resposta foi útil, não esqueça de classificá-la.

    • Sugerido como Resposta Angelo Maximo terça-feira, 1 de abril de 2014 12:51
    segunda-feira, 31 de março de 2014 22:51
  • Show de bola, muito obrigado Angelo.
    terça-feira, 1 de abril de 2014 11:08