Atualmente, estamos implementando uma solução de backup para um cliente e sua solução de ERP usa SQL Server.
A solução de ERP foi configurada por uma empresa diferente. E eles estão me dizendo que é super importante fazer backup e truncar o log de transações.
Eu tenho lido um pouco sobre este log de transações e não entendo porque isso é tão importante quando já estou fazendo backup de toda a máquina de qualquer maneira (estamos usando o ArcServe UDP, que está ciente do SQL Server e usa VSS). Entendo que as tarefas de limpeza na VM do SQL Server já estão cuidando do truncamento do log, no entanto, o UDP também permite o truncamento do log do SQL Server.
Entendo que o log de transações pode ser usado para restaurar bancos de dados corrompidos, porque, bem, é um log de todas as transações. Mas eu já tenho um backup de hora em hora de todo o banco de dados, então, por que eu me importaria?
Você só precisa fazer isso se o modo de recuperação do banco de dados estiver definido como "completo". Se estiver definido como "simples", não é necessário fazer backup do log de transações. Mas cuidado com a diferença entre essas duas opções!
Primeiro de tudo: se você quiser restaurar o banco de dados para um ponto específico no tempo , use o modo "completo". (Acho que você pode ajustar o tempo com tanta precisão que pode até especificar os milissegundos para o ponto de restauração) No modo "simples", você só pode voltar para o último backup completo .
Se você não fizer backup/truncar seu log de transações, ele crescerá o tempo todo (no modo completo). Eu vi bancos de dados onde o arquivo .trn era mais que o dobro do tamanho do próprio banco de dados. Isso depende da frequência com que as alterações foram feitas no banco de dados.
Outro ponto é que um backup de log normalmente é mais rápido que um backup completo.
Portanto, acho que seu plano de backup para fazer um backup completo a cada hora não é o ideal. Mas depende da sua situação:
Se você disser: Ok, se eu puder restaurar o banco de dados para a última hora completa, está tudo bem. --> Você também pode definir o modo de recuperação como "simples" se quiser manter o backup completo a cada hora.
Na minha opinião, uma ideia melhor seria fazer um backup completo no início da manhã e, em seguida, fazer um backup do log de transações a cada hora. Deve ser muito mais rápido e você pode restaurar a qualquer momento que desejar. E também seu arquivo .trn não vai crescer muito...
Espero que isto ajude.
Nós iremos. Você se importa porque, se tiver seu modelo de recuperação definido como completo e não fizer backup do log de transações usando o backup do SQL (e não o backup do servidor), o log de transações continuará a crescer até consumir todo o espaço em disco disponível. (Certa vez, vi um colega menor instalar o SQL Server na unidade do sistema e nunca fazer backup do log de transações. Ele consumia o Windows .)
Sim, ele também restaurará para um ponto específico no tempo. Até o minuto. Como Twinkles diz, sim, pessoas derrubando mesas e coisas do gênero.
Não sei o que você está usando para o backup de hora em hora de todo o banco de dados e se é o mesmo produto que você está usando para toda a máquina. Nesse caso, uma solução de backup não compatível com SQL não é suportada para restaurações. A quantidade de tempo que leva para o VSS copiar os arquivos MDF e LDF pode causar uma incompatibilidade de timestamp interno, por exemplo.
Também gerenciamos vários sistemas ERP. E o problema geralmente é que, à noite, geralmente há trabalhos em lote de longa duração que sincronizam dados com outros sistemas. E às vezes levam uma hora ou mais. Portanto, o que você deseja fazer em caso de falha é pular para um ponto em que tenha dados consistentes. (O que significa exatamente entre dois trabalhos em lote.) Se você observar apenas a hora, talvez nem sempre saiba exatamente qual era o status do banco de dados naquele momento.
Mas claro que depende da situação. Se você não tiver nenhum trabalho automatizado, etc., pode ficar totalmente bem com um backup de hora em hora.
Existem várias razões pelas quais você deseja fazer isso:
Quando seu banco de dados cresce além do que você pode fazer backup em uma hora, você precisa de um modelo diferente.
Um backup completo do seu banco de dados truncará seus logs, mas ele precisa ser "consciente do SQL", porque nesse cenário, é o software de backup que informa ao servidor SQL o que ele fez backup e o que truncar.
Como outros mencionaram, se você tiver um banco de dados no modelo de recuperação "Full", seu log de transações crescerá indefinidamente, até que você faça um backup completo compatível com SQL.
A recuperação é realmente o problema aqui, não o backup. E não é uma decisão técnica, é uma decisão de negócios!
Se os proprietários de sua empresa concordarem em perder uma hora ou mais de suas transações de banco de dados (o que pode ser MUITO difícil ou impossível de refazer!), Então seu modelo funciona. Se eles estiverem bem com o sistema inativo por horas enquanto você restaura todo o banco de dados do backup, seu modelo funciona.
No entanto, se a sua empresa considera o sistema ERP um ativo crítico para a operação (não consideram todos?), Definir um tempo máximo de recuperação aceitável (também conhecido como RTO, objetivo de tempo de recuperação) para seus serviços críticos será uma decisão comercial.
Além disso, os proprietários de negócios ou partes interessadas do sistema precisam definir quantos dados estão dispostos a arriscar perder em um incidente, também conhecido como RPO (Recovery Point Objective).
A resposta, se você perguntar, pode ser "NENHUM dado pode ser perdido! O sistema ERP deve estar disponível 24 horas por dia, 7 dias por semana, 365 dias por ano!"... o que todos sabemos é altamente improvável que seja econômico. Se você apresentar a eles o custo associado à construção de um sistema totalmente redundante e ininterrupto, eles apresentarão um valor mais razoável. ;)
O ponto é que, se você puder evitar a perda de transações, estará economizando centenas ou milhares de horas de trabalho perdidas para sua empresa. Isso representa uma ENORME economia em qualquer empresa e cresce com o tamanho da sua empresa...
Todos tiveram ótimas respostas a isso, mas gostaria de acrescentar outra observação importante... ou duas.
Conhecer as particularidades dos modelos de recuperação do SQL Server e seus requisitos de negócios para perda de dados são muito importantes; no entanto, neste caso, é imperativo que você entenda como seu produto de backup funciona com o SQL Server. (Com base nos comentários acima, parece que você está fazendo backup de volumes de disco por meio de cópia VSS, o que significa que os backups do SQL Server podem ou não ser necessários.)
Tendo avaliado recentemente um produto similar, alguns dos pontos importantes que você pode precisar perguntar são:
Espero que isso seja útil.
A experiência que minha equipe teve com nossa avaliação recente forneceu algumas respostas muito interessantes para as perguntas acima. Uma coisa é certa, os backups são mais complexos para nós com um produto de backup VSS.
Como muitos outros já disseram, se você estiver usando uma ferramenta de terceiros para fazer backup / instantâneo da VM ou do armazenamento, ainda corre o risco de não ter um backup válido. Todas as ferramentas de terceiros que gerenciam backups do SQL Server serão implementadas e conectadas ao SQL Server usando VSS. Ele faz isso para solicitar que o SQL Server desative todas as E/S para os arquivos de dados para que um instantâneo consistente possa ser obtido. Caso contrário, você pode ter muitas transações em vários estados e uma restauração não saberá se essas transações podem ser revertidas ou avançadas.
Não trabalhei com todas as ferramentas de snapshot de VM/armazenamento de terceiros, mas aquelas com as quais trabalhei nunca conseguiram capturar o armazenamento de snapshot onde os bancos de dados do sistema estavam localizados - o SQL Server não pode desativar esses bancos de dados. Todos eles fizeram backup desses bancos de dados de maneira contínua - ou seja, emitindo os comandos BACKUP DATABASE e, em seguida, capturando o próprio arquivo de backup.
Além de tudo isso, como muitos também disseram, se você estiver no modelo de recuperação FULL e não emitir instruções BACKUP LOG regularmente, o log de transações continuará a crescer até que não haja mais espaço no disco.
A verdadeira pergunta que você precisa fazer, e talvez eu não a tenha percebido acima... você restaurou com êxito a partir desses backups várias vezes e está satisfeito com a consistência dos dados nessas restaurações? Pessoalmente, mesmo isso não seria suficiente para mim, ainda parece uma jogada de dados, e isso é algo que um bom DBA nunca faz quando se trata de backup e recuperação.
Reconheça que os logs de transação não são simplesmente um mecanismo de recuperação. A manutenção adequada do log também pode desempenhar um papel crítico no desempenho geral do banco de dados (ou seja, taxa de transferência da transação).
O backup frequente de seus arquivos de log faz algumas coisas:
Se você conseguir fazer um backup completo a cada hora, não tenho certeza de quanto você se beneficiaria com backups de log mais frequentes. Afinal, pelo que entendi, um backup completo também fará backup do log necessário para garantir uma restauração completa.
Por outro lado, se seu aplicativo gera toneladas de transações entre seus backups completos por hora, isso pode explicar por que os desenvolvedores originais sugeriram uma manutenção de log mais granular. Muitas transações podem aumentar a contagem de VLF em seus logs, o que pode incorrer em uma penalidade de desempenho até que o log seja truncado. Eu vi isso expresso como um erro de 'tempo limite de consulta expirado' em um aplicativo (pouco antes de travar).
As recomendações relacionadas à manutenção do log de transações são descritas muito bem neste artigo 8 etapas para melhorar a taxa de transferência do log de transações . Além disso, este artigo Dicas importantes para manutenção eficaz do banco de dados menciona uma contagem de VLF um tanto arbitrária a ser almejada (< 200), que funcionou muito bem para mim.
Outras pessoas já deram a maioria das razões para um backup translog, etc. Parece haver alguma dúvida sobre por que essa é uma boa estratégia quando você já faz backup do servidor.
Algumas boas razões surgiram para mim que não estão acima. E se o aplicativo de terceiros não conseguir fazer um backup que você possa restaurar? Você tentou restaurar seu backup? E quanto a um novo servidor que você acabou de criar a partir de seus modelos (pense em DR)? E quanto a outro servidor em seu domínio que tenha um agrupamento diferente? ou instância SQL?
Eu faço backups redundantes sem nenhum motivo, exceto que, às vezes, seu aplicativo de terceiros não é a maneira mais rápida de restaurar. Às vezes, o armazenamento no qual seu aplicativo de terceiros está salvando também é afetado ou está corrompido por seus próprios motivos.