Expiração de deslizamento do backup de snapshot do ElasticSearch - possível?

Question

Estou planejando usar o plug-in de nuvem ElasticSearch S3 para criar instantâneos de nosso cluster ES. Tudo isso parece bastante simples, mas estou me perguntando se é possível integrá-lo à nossa estratégia de backup existente.

Com nossos outros armazenamentos de dados, fazemos um backup completo a cada hora. Mantemos as últimas 24 horas, 1 para cada um dos últimos 7 dias, 1 para cada uma das últimas 4 semanas e 1 para cada um dos últimos 2 meses ...

É possível criar instantâneos dessa maneira, ou seria melhor usar o repositório de instantâneos do FS e compactar o conteúdo e conectar-me ao mesmo procedimento de upload?

Minha única preocupação é que parece que o recurso de instantâneo cria essencialmente backups incrementais, o que significa que isso não funcionaria. Seria bom saber como os outros estão fazendo backup de seus clusters ES.

Muito obrigado

    

Answer 1

Para citar a documentação :

The index snapshot process is incremental. In the process of making the index snapshot Elasticsearch analyses the list of the index files that are already stored in the repository and copies only files that were created or changed since the last snapshot. That allows multiple snapshots to be preserved in the repository in a compact form.

Tendo passado uma carreira em backup e planejamento de recuperação de desastres, entendo sua preocupação. Como todos os backups, lidar com essa estratégia requer um pouco de análise. Algumas coisas a considerar:

• Taxa de rotatividade de dados . Se você só mantiver (n) semanas de dados no índice, poderá tolerar algumas estratégias de backup. Se o índice é uma tabela acumuladora onde nada é deletado e fica maior ao longo do tempo, diferentes estilos valem a pena.
• Taxa de crescimento . Como volume de negócios, quão grande é o tempo.
• Restrições de armazenamento de backup . Muito obvio. Se forem incrementos contínuos e você tiver uma alta taxa de rotatividade, seu repositório de backup conterá muitas coisas de que não precisa.
• Restrições de E / S de backup . Enquanto a operação não é de bloqueio, ela não é de recurso zero. Incrementais são mais rápidos do que cheios, mas os fulls podem ser necessários por outras razões.

O procedimento de instantâneo é uma estratégia incremental contínua. Para uma tabela de acumulador (sem turnover), é suficiente levar um full e manter os incrementais para sempre. Exceto ...

During snapshot initialization, information about all previous snapshots is loaded into the memory, which means that in large repositories it may take several seconds (or even minutes) for this command to return even if the wait_for_completion parameter is set to false.

Este é o seu incentivo para não manter tudo. Um histórico de snapshot de uma hora, que volta dois anos, vai ocupar muito espaço. Felizmente, eles têm uma funcionalidade DELETE para podar essa história.

Se você tiver uma alta taxa de rotatividade, planeje definitivamente emitir DELETE para instantâneos mais antigos ao longo do tempo. De acordo com a documentação, o processo de captura instantânea de ES é inteligente o suficiente para manipular corretamente o processo de limpeza de dados. Sua política GFS de snapshots pode definitivamente ser feita, mesmo com um sistema de backup 'incremental contínuo'. Pense nisso como um sistema de backup em disco com desduplicação; Se você não limpar o cluster de desduplicação a cada dois meses, permitirá que o sistema de backup colete os blocos / arquivos que não são mais necessários.

Se você precisar de algo externo, copie o snapshot-repo e faça a rotação normal da mídia. O es-repo para capturas instantâneas é para backup / restauração quente. Se você precisar carregar um mais antigo por algum motivo, poderá restaurar a cópia offline sobre a cópia ativa e chamar uma restauração a partir da API ES e ela será carregada a partir dos dados que você colocar no repositório de instantâneos.