A replicação de instantâneos preenche um pool de destino quando os instantâneos retidos e os blocos alterados se acumulam mais rapidamente do que a política de limpeza do destino consegue libertar espaço.
A solução preventiva consiste em definir a retenção na origem, a retenção no destino, a frequência de replicação e os alertas de espaço livre como uma única política. Uma réplica pode legitimamente manter mais histórico do que a origem, mas essa escolha deve ter limites. Registe quais os instantâneos necessários como bases incrementais, a quantidade de dados exclusivos que os instantâneos antigos mantêm reservada, se os marcadores podem substituir alguns instantâneos locais da origem e quanto espaço de margem resta antes da chegada do próximo grande conjunto de alterações.
Defina Explicitamente uma Política de Retenção no Destino
Decida quantos pontos de recuperação horários, diários, semanais e mensais o destino deve manter e documente por que motivo esse histórico difere do da origem. Não assuma que o software de replicação irá eliminar automaticamente todos os instantâneos antigos do destino quando estes forem eliminados na origem.
Uma visão geral da replicação ZFS explica que a replicação precisa de uma política de instantâneos, porque os instantâneos são simultaneamente pontos de recuperação e limites para transferências incrementais.
Aplique a retenção mais curta a conjuntos de dados com muitas alterações, exceto quando um histórico mais longo tiver um valor concreto para a recuperação. Mantenha os arquivos com poucas alterações numa agenda diferente, para que uma política global não desperdice espaço onde os pontos de recuperação frequentes acrescentam pouco valor.
Estime a Quantidade de Alterações Mantida pelos Instantâneos Antigos
Meça o valor USED dos instantâneos, os dados escritos entre instantâneos e o espaço livre do pool de destino antes e depois de grandes eliminações, movimentações, substituições de ficheiros multimédia ou reescritas de máquinas virtuais. Um instantâneo pode manter blocos antigos ativos depois de os dados ativos desaparecerem.
Uma nota sobre replicação do TrueNAS alerta que a alteração frequente dos instantâneos retém blocos antigos, mesmo quando o conjunto de dados ativo atual fica mais pequeno.
Utilize essa taxa de alteração para dimensionar a retenção. Um destino com 30 dias de imagens de máquinas virtuais em rápida alteração pode precisar de muito mais capacidade do que outro conjunto de dados com o mesmo tamanho ativo, mas composto sobretudo por fotografias de família às quais apenas são acrescentados ficheiros.
Reserve Espaço de Margem no Pool para a Próxima Replicação
Defina um limite operacional de espaço livre que tenha em conta o maior incremento recebido realisticamente, o crescimento dos instantâneos locais e a sobrecarga normal do sistema de ficheiros. Emita alertas antes de atingir o limite, e não quando o pool já estiver quase cheio.
A discussão da Oracle sobre retenção de instantâneos salienta que a retenção controla o crescimento dos instantâneos, em vez de tratar os instantâneos como gratuitos só porque a sua criação é inicialmente barata.
Suspenda ou reduza a retenção não crítica antes de o destino atingir um estado de emergência. Um destino de replicação precisa de espaço para receber e consolidar novos blocos, pelo que deixar apenas o espaço suficiente para o conjunto de dados ativo atual não é um plano de capacidade seguro.
Utilize Marcadores Quando Estes Preservarem o Histórico Incremental
Quando a sua versão do ZFS e as ferramentas de replicação forem compatíveis com marcadores, avalie se um marcador pode preservar a referência de envio incremental depois de um instantâneo antigo deixar de ser necessário como ponto de recuperação local completo.
Um projeto de cópia de segurança externa mostra como os marcadores preservam bases incrementais, permitindo que a retenção de instantâneos permaneça independente.
Não substitua todos os instantâneos por marcadores. O histórico de recuperação no destino continua a exigir instantâneos reais e as ferramentas de replicação variam na forma como gerem as bases comuns. Utilize marcadores apenas quando estes simplificarem o lado da origem sem enfraquecer o objetivo de recuperação do destino.
Proteja Apenas os Instantâneos de que a Replicação Ainda Precisa
Identifique o instantâneo comum mais recente partilhado pela origem e pelo destino antes de efetuar a limpeza. Quando as ferramentas utilizarem retenções ou proteções equivalentes, confirme que as tarefas de limpeza as respeitam e que as retenções obsoletas acabam por ser libertadas.
O manual do FreeBSD sobre ZFS explica que as retenções protegem instantâneos partilhados até serem explicitamente libertadas.
Não mantenha todos os instantâneos históricos simplesmente porque é necessária uma única base comum. Proteja o pequeno conjunto de que a replicação realmente precisa e deixe que a política de retenção do destino governe os pontos de recuperação independentes mais antigos.
Audite os Instantâneos de Replicação Separadamente do Histórico de Cópias de Segurança
Algumas ferramentas criam os seus próprios instantâneos de sincronização além dos instantâneos horários ou diários agendados. Apresente ambas as classes no destino e certifique-se de que o conjunto gerado pela ferramenta não pode crescer sem uma regra de limpeza.
Uma discussão sobre Sanoid e Syncoid explica que os instantâneos de sincronização funcionam como salvaguardas, em vez de cada instantâneo de replicação se destinar a ser um histórico de cópias de segurança de longo prazo.
Reveja o destino mensalmente ou depois de qualquer movimentação significativa de conjuntos de dados. A política é saudável quando os pontos de recuperação esperados permanecem disponíveis, o próximo incremento tem uma base comum válida e o espaço livre do pool se mantém acima do limite definido. O artigo relacionado da ZimaSpace sobre diagnóstico do espaço ocupado por instantâneos é o caminho de recuperação quando o destino já está inesperadamente cheio.
Perguntas Frequentes
O destino deve manter exatamente os mesmos instantâneos que a origem?
Não necessariamente. Um destino de cópias de segurança pode manter um histórico mais longo, mas a diferença deve ser intencional, testada em termos de capacidade e regida pela sua própria política de retenção.
A eliminação de ficheiros na origem liberta imediatamente espaço no destino?
Não. Os instantâneos replicados podem continuar a referenciar blocos antigos depois de o ficheiro ativo desaparecer. O espaço só é libertado quando nenhum instantâneo retido ou outra referência precisar desses blocos.
A eliminação do instantâneo mais antigo liberta sempre mais espaço?
Não. O espaço dos instantâneos é partilhado entre os pontos de recuperação. Estime ou meça o espaço referenciado exclusivo e proteja qualquer instantâneo comum ainda necessário para a replicação incremental.
Suporte e Dicas
Mais para Ler

O Plex pode partilhar uma GPU com outro contentor Docker?
O Plex e outro contentor conseguem frequentemente aceder à mesma GPU, mas é necessário testar o suporte dos controladores, o mapeamento de dispositivos, a...

Como saber se um erro do Plex vem do cliente ou do servidor
Reproduza o mesmo item noutro cliente, compare o percurso da sessão e, em seguida, recolha provas do servidor apenas depois de o âmbito lhe...

Como configurar a cache do Plex e o armazenamento temporário de transcodificação
Proteja o estado persistente do Plex enquanto coloca os ficheiros temporários de transcodificação num armazenamento local adequado e, em seguida, verifique a limpeza, o...

