none
Backup SQL RRS feed

 > 

  • Pergunta

  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Tenho uma aplicação que é critica e para manter essa base, gostaria de uma solução que me garantisse o menor down-time possível. então, estou venda a seguinte solução:

    Toda a noite, um backup full da base;

    a partir das 07:00 um backup dos logs de 10 em 10 min;

    e um backup diferencial a cada 1 hora.

    Esses jobs estão sendo agendados para serem executados através do sql agent, mas agora surgiu uma dúvida.

    para efetuar esse backup dos logs, eu posso incluir o parâmetro WITH INIT, ou seja, manter somente o último backup ou tenho que manter os anteriores para efetuar a restauração? minha dúvida é que caso eu mantenha os arquivos anteriores, que seria somente adicionar o log ao arquivo de backup, ao restaurar um backup diferencial, eu estaria com problemas ao restaurar os logs.

    está correto?

    Seria no caso, adicionar ao job o With INIT e manter somente o ultimo arquivo do log?

    Obrigado a todos,

    marcelo_varga

    segunda-feira, 20 de maio de 2013 01:23
    |

Respostas

  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Fala Marcelo.

    Quanto tempo demora o restore do seu backup Full?

    Se a aplicação é crítica, imagino que você deve pensar além do backup, pensando no restore. Se você está fazendo backup em disco, está correndo o risco de ficar sem dado nenhum em caso de falha gereneralizada no hardware. Ja vi situação similar com um RAID1. Um dos discos apresentou falha e enquanto era realizado um processo de compras para substituí-lo, o segundo disco também parou de funcionar.

    Imagine que para fazer o restore de sua base, você precisará fazer o backup do tail do transaction log, portanto, se for uma falha de disco, haverá perda de dados.

    Opções para ambientes críticos:

    Preparar um documento de plano de restore para todos casos de desastres: indispensável a qualquer uma das opções abaixo, onde você deve estimar o tempo de restore para cada uma delas e passar para os responsáveis avaliarem se o tempo está adequado a estratégia do negócio.

    Fazer o backup em outros servidores da rede: pelo menos seus arquivos de backup estarão a salvo em caso de falhas no disco. Mas e se o seu servidor SQL precisar ser reinstalado do zero ou ser substituído?

    Fazer o backup em fita ou outra mídia: já pensou o prédio interditado pelos bombeiros e seus dados lá no segundo servidor correndo risco? Uma outra mídia te possibilita transportar o backup para outro lugar.


    Utilizar um segundo servidor com Failover Cluster, Log Shipping ou Database Mirroring configurado: neste caso, mesmo que seu servidor SQL apresente falhas graves, sua aplicação fica online rapidamente.

    Colocar seus servidores em um Data Center: diminui riscos como roubo, incêndio, falta de energia, problemas no ar condicionado, além de oferecer políticas de backup mais adequadas.

    Executar testes de restore: para todas as opções acima, frequentemente executar testes de restore, avaliando o sucesso da operação, tempo gasto, procedimentos a melhorar, etc.

    O mais importante é pensar sempre no restore quando estiver fazendo qualquer política de backup.

    Abs!

    Luiz Mercante
    MCITP SQL 2008 | MCTS SQL 2008 | MCTS Windows Apps | MCTS Windows Network | MCP 2003
    sqldicas@outlook.com
    http://sqldicas.com.br


    Se a resposta foi útil de alguma forma, classifique como resposta ou vote como útil.

    sábado, 25 de maio de 2013 16:12
    |

Todas as Respostas

  • Question
    Entrar para Votar
    1
    Entrar para Votar

    Ola!

    Se sua base tem muitas escritas e leituras, talvez seja interessante manter todas as logs, veja o script no link abaixo que pode te dar um auxilio em automatizar a rotina:

    http://www.mssqltips.com/sqlservertip/1318/automating-transaction-log-backups-for-all-sql-server-databases/

    Um abraço!

    André CR / Helped? If the answer is yes mark! If the answer is no, wait a little bit because i'll back! Visit my blog! sqlmagu.blogspot.com.br

    segunda-feira, 20 de maio de 2013 02:35
    |
  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Fala Marcelo.

    Quanto tempo demora o restore do seu backup Full?

    Se a aplicação é crítica, imagino que você deve pensar além do backup, pensando no restore. Se você está fazendo backup em disco, está correndo o risco de ficar sem dado nenhum em caso de falha gereneralizada no hardware. Ja vi situação similar com um RAID1. Um dos discos apresentou falha e enquanto era realizado um processo de compras para substituí-lo, o segundo disco também parou de funcionar.

    Imagine que para fazer o restore de sua base, você precisará fazer o backup do tail do transaction log, portanto, se for uma falha de disco, haverá perda de dados.

    Opções para ambientes críticos:

    Preparar um documento de plano de restore para todos casos de desastres: indispensável a qualquer uma das opções abaixo, onde você deve estimar o tempo de restore para cada uma delas e passar para os responsáveis avaliarem se o tempo está adequado a estratégia do negócio.

    Fazer o backup em outros servidores da rede: pelo menos seus arquivos de backup estarão a salvo em caso de falhas no disco. Mas e se o seu servidor SQL precisar ser reinstalado do zero ou ser substituído?

    Fazer o backup em fita ou outra mídia: já pensou o prédio interditado pelos bombeiros e seus dados lá no segundo servidor correndo risco? Uma outra mídia te possibilita transportar o backup para outro lugar.


    Utilizar um segundo servidor com Failover Cluster, Log Shipping ou Database Mirroring configurado: neste caso, mesmo que seu servidor SQL apresente falhas graves, sua aplicação fica online rapidamente.

    Colocar seus servidores em um Data Center: diminui riscos como roubo, incêndio, falta de energia, problemas no ar condicionado, além de oferecer políticas de backup mais adequadas.

    Executar testes de restore: para todas as opções acima, frequentemente executar testes de restore, avaliando o sucesso da operação, tempo gasto, procedimentos a melhorar, etc.

    O mais importante é pensar sempre no restore quando estiver fazendo qualquer política de backup.

    Abs!

    Luiz Mercante
    MCITP SQL 2008 | MCTS SQL 2008 | MCTS Windows Apps | MCTS Windows Network | MCP 2003
    sqldicas@outlook.com
    http://sqldicas.com.br


    Se a resposta foi útil de alguma forma, classifique como resposta ou vote como útil.

    sábado, 25 de maio de 2013 16:12
    |