Saudações aos leitores do nosso blog! De certa forma, já nos conhecemos – minhas postagens em inglês apareceram aqui na tradução da minha querida colega . Desta vez, decidi me dirigir diretamente ao público de língua russa.
Para minha estreia, queria encontrar um tema que fosse interessante para um público amplo e que exigisse uma análise detalhada. Daniel Defoe afirmava que todos estão destinados a enfrentar a morte e os impostos. Por minha parte, posso dizer que todos os engenheiros de suporte enfrentam questões sobre as políticas de retenção de pontos de restauração (ou, mais simplesmente, retenção). Eu comecei a explicar como funciona a retenção há 4 anos, quando era um engenheiro júnior de primeiro nível, e continuo explicando agora, já como líder de equipe de uma equipe de língua espanhola e italiana. Tenho certeza de que meus colegas de segundo e até terceiro nível de suporte também respondem regularmente às mesmas perguntas.
Nesse sentido, quis escrever um post definitivo e o mais detalhado possível, ao qual os usuários de língua russa poderiam recorrer repetidamente como um guia. O momento é adequado – a recém-lançada décima versão comemorativa adicionou novas funcionalidades ao funcionalismo básico, que não havia mudado por anos. Meu post é voltado principalmente para esta versão — embora grande parte do que está escrito seja válida também para versões anteriores, algumas das funcionalidades descritas você simplesmente não encontrará lá. Finalmente, olhando um pouco para o futuro, direi que algumas mudanças são esperadas na próxima versão, mas sobre isso falaremos quando chegar a hora. Então, vamos começar.
Tarefas de backup (Backup job)
Para começar, vamos analisar a parte que não sofreu alterações na versão 10. A política de retenção é determinada por vários parâmetros. Vamos abrir a janela de criação de uma nova tarefa e ir para a aba Armazenamento. Aqui veremos o parâmetro que define o número desejado de pontos de restauração:
No entanto, isso é apenas uma parte da equação. O número real de pontos também é determinado pelo modo de backup definido para a tarefa. Para selecionar este parâmetro, é necessário clicar no botão Avançado na mesma aba. Isso abrirá uma nova janela com várias opções. Vamos numerá-las e analisá-las uma a uma:
Se apenas a opção 1 for ativada, a tarefa funcionará em modo de "incremento infinito" (forever forward incremental). Não há complexidades aqui - a tarefa armazenará um número definido de pontos de recuperação desde o backup completo (arquivo com a extensão VBK) até o último incremento (arquivo com a extensão VIB). Quando o número de pontos exceder o valor definido, o incremento mais antigo será mesclado com o backup completo. Em outras palavras, se a tarefa está configurada para armazenar 3 pontos, logo após a sessão atual, haverá 4 pontos no repositório, após o que o backup completo será mesclado com o incremento mais antigo e o número total de pontos retornará a 3.
A retenção para o modo "incremento reverso" (reverse incremental) (opção 2) também é extremamente simples. Nesse caso, o ponto mais recente será um backup completo, seguido de uma cadeia de chamadas de rollbacks (arquivos com a extensão VRB), então, para aplicar a retenção, basta excluir o rollback mais antigo. A situação será a mesma: logo após a sessão, o número de pontos excederá o definido em 1, depois disso retornará ao valor desejado.
Note que com o modo de incremento reverso, um backup completo periódico também pode ser ativado (opção 4), mas isso não mudará a essência. Sim, a cadeia terá pontos de recuperação completos, mas ainda estaremos apenas removendo os pontos mais antigos um a um.
Finalmente, chegamos a uma parte interessante. Se ativar o backup incremental, mas além disso incluir as opções 3 ou 4 (ou ambas simultaneamente), a tarefa começará a criar backups completos periódicos de maneira "ativa" ou sintética. O método de criação de backup completo não é importante - ele conterá os mesmos dados, e a cadeia incremental será dividida em "subcadeias". Este método é chamado de forward incremental, e é ele que gera uma parte significativa das dúvidas de nossos clientes.
A retenção é aplicada aqui removendo a parte mais antiga da cadeia (do backup completo até o incremental). Nesse caso, não vamos remover apenas o backup vazio ou apenas parte dos incrementais. Toda a "subcadeia" é removida completamente de uma vez. O significado da configuração do número de pontos também muda – enquanto em outros métodos é o número máximo permitido, o que desencadeia a retenção, aqui essa configuração define o número mínimo. Em outras palavras, após a remoção da parte mais antiga da "subcadeia", o número de pontos na parte restante não deve cair abaixo desse mínimo.
Vou tentar ilustrar esse conceito graficamente. Suponha que a retenção está definida para 3 pontos, e a tarefa roda todos os dias com um backup completo na segunda-feira. A retenção, nesse caso, será aplicada quando o número total de pontos atingir 10:
Por que exatamente 10, quando configuramos 3? Na segunda-feira, foi criado um backup completo. Da terça até o domingo, a tarefa gerou incrementais. Finalmente, na próxima segunda-feira, é criado novamente um backup completo e somente quando 2 incrementais forem gerados, toda a parte antiga da cadeia pode ser removida, porque a quantidade restante de pontos não cairá abaixo dos 3 estabelecidos.
Se a ideia está clara, sugiro que você tente calcular a retenção sozinho. Vamos considerar as seguintes condições: a tarefa é iniciada pela primeira vez na quinta-feira (certamente, será feito um backup completo). A tarefa está programada para criar backups completos nas quartas e domingos e armazenar 8 pontos de recuperação. Quando a retenção será aplicada pela primeira vez?
Para responder a essa pergunta, recomendo que você pegue uma folha de papel, a divida por dias da semana e escreva qual ponto é criado a cada dia. A resposta se tornará óbvia.
Resposta
Explicação: para responder, basta perguntar a si mesmo "quando a retenção será aplicada"? A resposta é – quando pudermos remover os 3 primeiros pontos (VBK, VIB, VIB) e a cadeia restante não cair abaixo dos 8 pontos estabelecidos. Fica claro que poderemos fazer isso quando tivermos um total de 11 pontos, ou seja, no domingo da segunda semana.
Alguns leitores podem contestar: "por que tudo isso, se já existe ?». Без сомнения, это очень полезный инструмент, и в некоторых случаях я бы применял именно его, но есть у него и ограничения. Прежде всего, он не позволяет указать начальные условия, а во многих случаях случаев вопрос звучит именно «у нас есть такая цепочка, что будет, если изменить такие-то настройки?». Во-вторых, инструменту все-таки несколько не хватает наглядности. Показывая страничку RPS клиентам, я не находил понимания, а вот расписав ее как в примере (даже используя тот же Paint), день за днем, все становилось ясно.
Finalmente, não examinamos a opção "Transformar cadeias de backup anteriores em retrocessos" (marcada com o número 5). Esta opção às vezes confunde os clientes que a ativam "automaticamente", desejando apenas incluir um backup sintético. Entretanto, essa opção ativa um modo de backup bastante específico. Sem entrar em detalhes, posso dizer que, neste estágio de desenvolvimento do produto, "Transformar cadeias de backup anteriores em retrocessos" é uma opção obsoleta, e não consigo imaginar um único cenário em que deva ser utilizada. Seu valor é tão duvidoso que, por algum tempo, até mesmo Anton Gostev lançou um apelo no fórum pedindo que lhe enviassem exemplos de seu uso útil (se você os tiver, escreva nos comentários, estou muito interessado). Se não aparecerem (eu acho que não aparecerão), a opção será removida nas próximas versões.
A tarefa criará incrementos (VIB) até o dia em que um backup completo sintético for agendado. Naquele dia, um VBK é realmente criado, mas todos os pontos até esse VBK são transformados em retrocessos (VRB). Depois disso, a tarefa continuará criando incrementos para o backup completo até o próximo backup sintético. No final, cria-se uma mistura explosiva de arquivos VBK, VBR e VIB. A retenção é aplicada de maneira muito simples – deletando o último VBR:
Problemas
Além de entender como isso funciona, a maioria dos problemas que surgem ao usar o modo incremental geralmente estão relacionados ao backup completo. Um backup completo regular é necessário para esse modo, caso contrário, o repositório acumulará pontos até transbordar.
Por exemplo, um backup completo pode ser criado com muita raridade. Digamos que a tarefa está configurada para manter 10 pontos, mas um backup completo é criado uma vez por mês. É claro que o número real de pontos será significativamente maior do que o configurado. Ou a tarefa está configurada para operar em modo incremental infinito e manter 50 pontos. Então, alguém acidentalmente criou um backup completo. Pronto, a tarefa agora aguardará até que o ponto completo acumule 49 incrementos, após o que aplicará a retenção e retornará ao modo completamente infinito.
Em outros casos, o backup completo é configurado para ser criado regularmente, mas por algum motivo isso não acontece. Vou descrever aqui a razão mais comum. Alguns clientes preferem usar a opção de agendamento "run after" e configurar as tarefas para funcionarem em sequência. Vamos considerar o seguinte exemplo: existem 3 tarefas que são executadas todos os dias e criam um backup completo no domingo. A primeira tarefa começa às 22h30, e as outras são iniciadas em sequência. O backup incremental leva 10 minutos, e, portanto, às 23h00 todas as tarefas terminam. No entanto, o backup completo leva uma hora, então no domingo acontece o seguinte: a primeira tarefa funciona das 22h30 às 23h30. A segunda, das 23h30 à 00h30. E a terceira tarefa é iniciada apenas na segunda-feira. O backup completo está agendado para domingo, então, nesse caso, simplesmente não haverá. A tarefa vai aguardar o backup completo para aplicar a retenção. Portanto, tenha cuidado ao usar a opção "run after" ou não a use de jeito nenhum – apenas defina as tarefas para iniciar ao mesmo tempo e deixe o agendador de recursos fazer seu trabalho.
A complicada opção "Remove deleted items"
Ao percorrer as configurações da tarefa Storage – Advanced – Maintenance, você pode se deparar com a opção "remove deleted items data after", que é contabilizada em dias.
Alguns clientes esperam que isso seja a retenção. Na verdade, é uma opção completamente separada, cuja falta de compreensão pode levar a consequências inesperadas. No entanto, antes de tudo, precisamos explicar como o B&R reage a situações em que, durante a sessão, apenas algumas máquinas são backupadas com sucesso.
Vamos imaginar o seguinte cenário: uma tarefa incremental infinita, configurada para manter 6 pontos. Na tarefa, há 2 máquinas, uma sempre foi backupada com sucesso, a outra às vezes apresentava erros. Como resultado, ao chegar ao sétimo ponto, a seguinte situação se formou:
É hora de aplicar a retenção, mas uma máquina tem 7 pontos, enquanto a outra tem apenas 4. A retenção será aplicada aqui? A resposta é sim, será. Se ao menos um objeto foi backupado, o B&R considera que o ponto foi criado.
Uma situação semelhante pode ocorrer se alguma máquina simplesmente não foi incluída na tarefa durante uma determinada sessão. Isso acontece, por exemplo, quando as máquinas são adicionadas à tarefa não individualmente, mas como parte de contêineres (pastas, repositórios) e alguma máquina migra temporariamente para outro contêiner. Neste caso, a tarefa será considerada bem-sucedida, mas nas estatísticas você encontrará uma mensagem que alerta que determinada máquina não está mais sendo processada pela tarefa.
O que acontece se ignorarmos esse aviso? No caso de modos de backup incremental infinito ou incremental reverso, o número de pontos de restauração da máquina 'problemática' diminuirá a cada sessão, até atingir 1, que é salvo no VBK. Em outras palavras, mesmo que a máquina não seja salva por um longo período, ainda assim um ponto de restauração permanecerá. A situação é diferente se backups completos periódicos estiverem ativados. Se ignorarmos os avisos do B&R, no final o último ponto pode ser removido juntamente com a parte antiga da cadeia.
Entendendo esses detalhes, finalmente podemos considerar a opção 'Remover dados de itens excluídos após'. Ela removerá todos os pontos para uma determinada máquina se essa máquina não for salva por um período de X dias. Observe que esta configuração não reage a erros (tentou – não funcionou). Não deve haver sequer uma tentativa de backup da máquina. À primeira vista, essa opção parece útil e deve ser mantida ativada. Se o administrador excluiu a máquina da tarefa, é lógico limpar os dados desnecessários e a cadeia depois de algum tempo. No entanto, a configuração requer disciplina e atenção.
Vou dar um exemplo prático: na tarefa foram adicionados vários contêineres, cuja composição era bastante dinâmica. Devido à falta de RAM, o servidor B&R enfrentou problemas que passaram despercebidos. A tarefa foi iniciada e tentou fazer backup das máquinas, exceto uma, que naquele momento não estava presente no contêiner. Como muitas máquinas geraram erros, por padrão o B&R deve realizar 3 tentativas adicionais para fazer backup das máquinas "problemáticas". Devido aos constantes problemas de RAM, essas tentativas se prolongaram por vários dias. A nova tentativa de fazer backup da VM ausente não ocorreu (a ausência da VM não é um erro). Como resultado, durante uma das tentativas repetidas, a condição “Remover itens deletados” foi executada e todos os pontos da máquina foram removidos.
Sobre isso, posso dizer o seguinte: se você tem alertas configurados sobre os resultados das tarefas, e ainda melhor — usa a integração com o Veeam ONE, então provavelmente isso não acontecerá com você. Se você verifica o servidor B&R uma vez por semana para checar se tudo está funcionando, é melhor abrir mão das opções que podem potencialmente levar à exclusão de backups.
O que foi adicionado na v.10
O que discutimos anteriormente existia no B&R por muitas versões. Agora que entendemos esses princípios de funcionamento, vamos ver o que foi adicionado na celebração da "dezena".
Retenção diária
Acima, consideramos a política de armazenamento "clássica", baseada na quantidade de pontos. Uma abordagem alternativa é definir no mesmo menu "dias" ao invés de "pontos de restauração".
A ideia está clara pelo nome — a retenção irá armazenar o número definido de dias, enquanto o número de pontos em cada dia não importa. Entretanto, é necessário lembrar o seguinte:
- O dia atual não é considerado no cálculo da retenção
- Dias em que a tarefa não funcionou de jeito nenhum também são contados. Isso deve ser levado em conta para não perder acidentalmente os pontos das tarefas que funcionam irregularmente.
- O ponto de restauração é contado a partir do dia em que seu início foi registrado (ou seja, se a tarefa começou a funcionar na segunda-feira e terminou na terça-feira, então esse é o ponto da segunda-feira)
Nos outros aspectos, os princípios de aplicação do retention nas tarefas ainda são determinados pelo método de backup escolhido. Vamos tentar mais uma tarefa de cálculo, utilizando o mesmo método incremental. Digamos que o retention está definido para 8 dias e a tarefa é executada a cada 6 horas, com um backup completo na quarta-feira. Além disso, a tarefa não roda no domingo. A primeira execução da tarefa acontece na segunda-feira. Quando será aplicado o retention?
Resposta
Como de costume, é melhor desenhar um quadro. Vou me permitir simplificar a tarefa e não desenhar todos os pontos criados a cada dia, pois a quantidade de pontos por dia não importa aqui. O que importa é que na primeira segunda-feira e nas quartas, o primeiro ponto será um backup completo; nos outros dias, a tarefa apenas criará 4 pontos incrementais.
Entendemos que o retention será aplicado pela remoção do backup completo da segunda-feira e seu incremento. Quando isso ocorrerá? Quando o resto da cadeia contiver 8 dias. Notamos que não contamos o dia atual, mas contamos domingo. Portanto, a resposta é na quinta-feira da segunda semana.
Arquivamento pelo método GFS para tarefas normais
Até a versão 10, o método de armazenamento Grandfather-Father-Son (GFS) estava disponível apenas para tarefas de criação de cópias de backup (Backup copy) e tarefas de cópia para fita magnética. Agora, ele também está disponível para backups normais.
Embora isso não se refira ao tema atual, não posso deixar de mencionar que a nova funcionalidade não significa um afastamento da estratégia 3-2-1. A presença de pontos de arquivamento no repositório principal não afeta sua confiabilidade. Supõe-se que o GFS será usado juntamente com repositórios escaláveis, para enviar esses pontos para S3 e armazenamento semelhantes. Se você não os utiliza, é melhor continuar armazenando os pontos primários e de arquivamento em repositórios diferentes.
Agora vamos examinar os princípios de criação de pontos GFS. Nas configurações da tarefa, na etapa Storage, aparece um botão especial que chama o seguinte menu:
A essência do GFS pode ser resumida em alguns pontos (observe que o GFS em outros tipos de tarefas funciona de forma diferente, mas falaremos sobre isso um pouco mais tarde):
- A tarefa não cria um backup completo separado para o ponto GFS. Em vez disso, será utilizado o backup completo mais apropriado disponível. Portanto, a tarefa deve operar em modo incremental com um backup completo periódico, ou um backup completo deve ser criado manualmente pelo usuário.
- Se apenas um período estiver ativado (por exemplo, semanal), no início do período GFS a tarefa simplesmente começará a aguardar um backup completo e marcará o primeiro adequado como GFS.
Exemplo: a tarefa está configurada para armazenar GFS semanal, usando o backup na quarta-feira. A tarefa roda todos os dias, mas o backup completo está agendado para sexta-feira. Nesse caso, na quarta-feira começará o período GFS e a tarefa começará a esperar o ponto adequado. Ele aparecerá na sexta-feira e será marcado com a bandeira GFS.
- Se vários períodos estiverem ativados ao mesmo tempo (por exemplo, semanal e mensal), o B&R aplicará um método que permite usar o mesmo ponto como GFS para vários intervalos (para economizar espaço). As bandeiras serão atribuídas em sequência, começando do mais baixo.
Exemplo: GFS semanal é definido para quarta-feira e o mensal para a última semana do mês. A tarefa roda todos os dias e cria backups completos nas segundas e sextas-feiras.
Para simplificar, começaremos a contagem a partir da penúltima semana do mês. Nessa semana, será criado um backup completo na segunda-feira, mas ele será ignorado porque o intervalo GFS semanal começa na quarta-feira. Em vez disso, o backup completo de sexta-feira se encaixa perfeitamente para o ponto GFS. Esse sistema já nos é familiar.
Agora vamos considerar o que acontecerá na última semana do mês. O intervalo GFS mensal começará na segunda-feira, mas o VBK de segunda-feira não será marcado como GFS, pois a tarefa busca marcar um VBK como um ponto GFS tanto mensal quanto semanal. Nesse caso, a busca começa especificamente com a semanal, já que ela, por definição, também pode se tornar mensal.
Se apenas os intervalos semanal e anual forem ativados, eles operarão de forma independente um do outro e podem marcar 2 VBKs separados como correspondentes aos intervalos GFS.
Tarefas de criação de cópia de backup
Outro tipo de tarefa, frequentemente requerendo esclarecimentos sobre o funcionamento. Para começar, vamos analisar o método "clássico" de operação, sem inovações v.10.
Método simples de retenção.
Por padrão, essas tarefas funcionam em modo incremental infinito. A criação de pontos é determinada por dois parâmetros: o intervalo de cópia e a quantidade desejada de pontos de recuperação (não há retenção em dias aqui). O intervalo de cópia é definido na primeira guia Job ao criar a tarefa:
A quantidade de pontos é determinada um pouco mais adiante na guia Target
A tarefa cria 1 novo ponto a cada intervalo (quantos pontos foram criados para a VM por tarefas iniciais não importa). No final do intervalo, um novo ponto é finalizado e, se necessário, a retenção é aplicada por meio da combinação de VBK e o incremento mais antigo. Esse mecanismo já nos é familiar.
Método de retenção usando GFS
BCJ também pode armazenar pontos de arquivo. Isso é configurado na mesma guia Target, um pouco abaixo das configurações de quantidade de pontos de recuperação:
Os pontos GFS podem ser criados de duas maneiras – sinteticamente, usando dados em um repositório secundário, ou imitando um backup completo e lendo todos os dados do repositório primário (ativado pela opção marcada com o número 3). A retenção em ambos os casos será bastante diferente, então vamos analisá-los separadamente.
GFS Sintético
Neste caso, o ponto GFS não é criado exatamente no dia agendado. Em vez disso, o ponto GFS será criado quando o VIB do dia em que a criação do ponto GFS foi programada for combinado com o backup completo. Isso às vezes causa mal-entendidos, pois o tempo passa e o ponto GFS ainda não aparece. E somente um poderoso xamã do suporte técnico pode prever em que dia o ponto realmente aparecerá. Na verdade, não é necessária mágica – basta olhar para a quantidade de pontos definidos e o intervalo de sincronização (quantos pontos são criados a cada dia). Tente calcular você mesmo com este exemplo: a tarefa foi configurada para armazenar 7 pontos, o intervalo de sincronização é de 12 horas (ou seja, 2 pontos por dia). Atualmente, há 7 pontos na cadeia, hoje é segunda-feira, e a criação do ponto GFS foi programada para hoje. Em que dia ele será criado?
Resposta
Aqui é melhor descrever como a cadeia mudará dinamicamente, dia a dia:
Portanto, na segunda-feira, o último incremento na cadeia é marcado como GFS, mas não há outras mudanças visíveis. Todos os dias, a tarefa cria 2 novos pontos e a retenção avança implacavelmente na cadeia. Finalmente, na quinta-feira, chega o momento de aplicar a retenção ao mesmo incremento. Esta sessão levará mais tempo do que o habitual, pois a tarefa "extrairá" os blocos necessários da cadeia e criará um novo ponto completo. A partir de agora, a cadeia terá 8 pontos - 7 na cadeia principal + GFS.
Criação de pontos GFS com a opção "Ler ponto inteiro"
Acima, mencionei que o BCJ opera em modo incremental infinito. Agora, vamos discutir a única exceção a essa regra. Ao ativar a opção "Ler ponto inteiro", o ponto GFS será criado exatamente no dia programado. A própria tarefa funcionará em modo incremental com backups completos periódicos, que discutimos acima. A retenção também será aplicada removendo a parte mais antiga da cadeia. No entanto, neste caso, apenas os increments serão removidos, enquanto o backup completo será mantido como um ponto GFS. Assim, ao calcular a retenção, os pontos marcados com flags GFS não são considerados.
Suponha que a tarefa esteja configurada para manter 7 pontos e criar um ponto GFS semanal na segunda-feira. Nesse caso, toda segunda-feira a tarefa realmente criará um backup completo e o marcará como GFS. A retenção será aplicada quando, após a remoção dos increments da parte mais antiga, o número de increments restantes não cair abaixo de 7. Veja como isso aparece no esquema:
Assim, ao final da segunda semana, há um total de 14 pontos na cadeia. Durante a segunda semana, a tarefa criou 7 pontos. Se fosse uma tarefa simples, a retenção já teria sido aplicada. Mas este é o BCJ com retenção GFS, portanto, não contamos os pontos GFS, o que significa que há apenas 6. Ou seja, ainda não podemos aplicar a retenção. Na terceira semana, criamos mais um backup completo com a flag GFS. 15 pontos, mas novamente não contamos este. E, finalmente, na terça-feira da terceira semana, criamos um incremento. Agora, se removermos os increments da primeira semana da cadeia, o total de increments atenderá à retenção estabelecida.
Como mencionado anteriormente, neste método é muito importante que os backups completos sejam realizados regularmente. Vamos supor que se defina uma retenção principal de 7 dias, mas apenas 1 ponto anual; não é difícil imaginar que os incrementais se acumulem de forma muito maior do que 7. Nesses casos, é melhor usar o método sintético de criação de GFS.
E novamente “Remover itens excluídos”
Essa opção também está disponível para BCJ:
A lógica desta opção aqui é a mesma que nas tarefas de backup normais – se a máquina não for processada pelo número especificado de dias, seus dados são removidos da cadeia. No entanto, para BCJ, a utilidade desta opção é objetivamente maior, e aqui está o porquê.
No modo normal, o BCJ opera em modo incremental infinito, portanto, se em algum momento a máquina for removida da tarefa, a retenção gradualmente removerá todos os pontos de recuperação, até que reste apenas um – no VBK. Agora, vamos imaginar que a tarefa ainda está configurada para criar pontos GFS sintéticos. Quando chegar a hora, a tarefa terá que criar GFS para todas as máquinas na cadeia. Se alguma máquina não tiver novos pontos – bem, teremos que usar o que há. E assim em cada vez. No final, pode surgir a seguinte situação:
Preste atenção na seção Arquivos: temos o VBK principal e 2 pontos GFS semanais. Agora, observe a seção Pontos de restauração – na verdade, esses arquivos contêm a mesma imagem da máquina. Naturalmente, não faz sentido ter pontos GFS assim, eles apenas ocupam espaço.
Essa situação é possível apenas ao usar o GFS sintético. Para evitar isso, use a opção “Remover itens excluídos”. Mas não se esqueça de definir isso para um número adequado de dias. O suporte técnico já viu casos em que a opção foi definida para menos dias do que o intervalo de sincronização – o BCJ começou a se comportar de maneira estranha e a remover pontos antes de conseguí-los criar.
Considere também que esta opção não afeta pontos GFS já criados. Se você quiser limpar os arquivos, isso deve ser feito manualmente – clicando com o botão direito na máquina e selecionando “Excluir do disco” (na janela que aparece, não se esqueça de marcar a opção “Remover backup completo GFS”):
Novidade v.10 – cópia imediata (immediate copy)
Depois de entender as funcionalidades "clássicas", vamos passar para a nova. Há uma novidade, mas é muito importante. Este é um novo modo de operação.
Aqui não existe o conceito de "intervalo de sincronização"; a tarefa irá monitorar constantemente se novos pontos apareceram e copiá-los todos, não importando quantos sejam. Mas a tarefa continua sendo incremental, ou seja, mesmo que a tarefa principal crie VBK ou VRB, esses pontos serão copiados como VIB. Fora isso, neste modo não há surpresas – tanto a retenção padrão quanto a GFS operam de acordo com as regras descritas acima (embora aqui esteja disponível apenas o GFS sintético).
Os discos estão girando. Características dos repositórios com rotação de discos.
A ameaça constante de vírus sequestradores tornou um padrão de fato a segurança de ter uma cópia dos dados em um suporte inacessível ao vírus. Uma das opções é utilizar repositórios com rotação de discos, onde os discos são utilizados alternadamente: enquanto um disco está conectado e disponível para gravação, os outros são armazenados em um local seguro.
Para ensinar o B&R a trabalhar com esses repositórios, você precisa nas configurações do repositório, na etapa Repositório, clicar no botão Avançado e selecionar a opção correspondente:
Depois disso, o VBR irá esperar que periodicamente a cadeia existente desapareça do repositório, o que significa rotação do disco. Dependendo do tipo de repositório e do tipo de tarefa, o B&R se comportará de maneiras diferentes. Isso pode ser representado pela seguinte tabela:
Vamos considerar cada opção.
Tarefa comum e repositório Windows.
Portanto, temos uma tarefa que mantém as cadeias no primeiro disco. Com a rotação, a cadeia criada praticamente desaparece, e a tarefa precisa sobreviver a essa perda. Seu consolo é a criação de um backup completo. Assim, cada rotação significa um backup completo. Mas o que acontece com os pontos no disco desconectado? Eles são lembrados e considerados no cálculo da retenção. Portanto, o número de pontos definido na tarefa é o que precisa ser mantido em todos os discos. Vamos dar um exemplo:
A tarefa opera em modo incremental infinito e está configurada para armazenar 3 pontos de recuperação. Mas temos um segundo disco, e fazemos uma rotação uma vez por semana (pode haver mais discos, isso não altera a essência).
Na primeira semana, a tarefa criará pontos no primeiro disco e combinará os desnecessários. Assim, o número total de pontos será igual a três:
Em seguida, conectamos o segundo disco. Ao iniciar o B&R, ele perceberá que o disco foi trocado. A cadeia no primeiro disco desaparecerá da interface, mas as informações sobre ela permanecerão no banco de dados. Agora, a tarefa manterá 3 pontos no segundo disco. A situação geral será a seguinte:
Finalmente, reconectamos o primeiro disco. Antes de criar um novo ponto, a tarefa verificará o que está acontecendo com o retenção. E a retenção, lembre-se, está configurada para manter 3 pontos. Enquanto isso, temos 3 pontos no disco 2 (mas ele está desconectado e guardado em um local seguro, que o B&R não pode acessar) e 3 pontos no disco 1 (este está conectado). Portanto, podemos eliminar 3 pontos do disco 1, pois eles excedem a retenção. Depois disso, a tarefa cria novamente um backup completo, e nossa cadeia começa a parecer assim:
Se a retenção estiver configurada para manter dias em vez de um número de pontos, a lógica permanece a mesma. Além disso, a retenção GFS não é suportada de forma alguma ao usar repositórios com rotação de discos.
Tarefa padrão e repositório Linux como armazenamento em rede
Essa opção também é possível, mas geralmente menos recomendada devido às restrições impostas. Na rotação do disco e desaparecimento da cadeia, a tarefa reagirá da mesma forma - criando um backup completo. A restrição está relacionada ao mecanismo de retenção reduzido.
Aqui, na rotação, toda a cadeia no disco desconectado é simplesmente excluída do banco de dados B&R. Observe que é do banco de dados, os próprios arquivos permanecem no disco. Eles podem ser importados e usados para recuperação, mas não é difícil deduzir que, cedo ou tarde, essas cadeias esquecidas preencherão todo o repositório.
A solução está na adição do DWORD ForceDeleteBackupFiles conforme indicado nesta página: . Depois disso, a tarefa começará a excluir simplesmente todo o conteúdo da pasta da tarefa ou do repositório (dependendo do valor) a cada rotação.
No entanto, isso não é uma retenção elegante, mas sim uma limpeza de todo o conteúdo. Infelizmente, o suporte técnico encontrou casos em que o repositório era apenas o diretório raiz do disco, onde além dos backups havia outros dados. Tudo isso foi destruído durante a rotação.
Além disso, ao ativar o ForceDeleteBackupFiles, ele funciona para todos os tipos de repositórios, ou seja, até mesmo os repositórios no Windows deixarão de aplicar retenção e começarão a excluir conteúdo. Em outras palavras, um disco local no Windows é a melhor escolha para esse sistema de armazenamento de backups.
Cópia de backup e repositório do Windows
Com o BCJ, as coisas ficam ainda mais interessantes. Além de ter uma retenção completa, não é necessário fazer um backup completo toda vez que um disco é trocado! Funciona assim:
Primeiro, o B&R começa a criar pontos no primeiro disco. Digamos que configuramos a retenção para 3 pontos. A tarefa funcionará em modo infinitamente incremental e unirá tudo o que for excessivo (lembro que a retenção GFS não é suportada neste caso).
Em seguida, conectamos o segundo disco. Como ainda não existe uma cadeia nele, criamos um backup completo, após o que temos uma segunda cadeia de três pontos:
Finalmente, chega a hora de reconectar o primeiro disco. E é aqui que começa a mágica, pois a tarefa não criará um backup completo, mas simplesmente continuará a cadeia incremental:
Depois disso, na verdade, haverá uma cadeia independente em cada disco. Portanto, a retenção aqui não significa o número de pontos em todos os discos, mas o número de pontos em cada disco individualmente.
Cópia de backup e repositório Linux armazenamento em rede
Novamente, toda a elegância se perde se o repositório não estiver em um disco local do Windows. Este cenário funciona de forma semelhante ao descrito acima com a tarefa simples. A cada rotação, o BCJ criará um backup completo, e os pontos existentes serão esquecidos. Para não ficar sem espaço livre, é necessário usar o DWORD ForceDeleteBackupFiles.
Conclusão
Assim, como resultado de todo esse longo texto, examinamos dois tipos de tarefas. Claro, há muitos mais tipos de tarefas, mas não é possível abordá-los todos no formato de um único artigo. Se você ainda tiver alguma dúvida após a leitura, sinta-se à vontade para deixá-la nos comentários, ficarei feliz em responder pessoalmente.
Fonte: habr.com
