Centro de Conhecimento DevOps
Centro de Conhecimento DevOps

Melhores Práticas para Operações Diárias de Backup e Restauração do Elasticsearch

Estabeleça uma estratégia confiável de backup diário do Elasticsearch com este guia abrangente. Aprenda a configurar repositórios duráveis, automatizar snapshots de rotina com o Snapshot Lifecycle Management (SLM) e alavancar o Index Lifecycle Management (ILM) para arquivamento de longo prazo. Este artigo detalha as melhores práticas para segurança, limitação de desempenho (throttling) e as etapas cruciais para testes regulares de restauração, garantindo que seus dados estejam protegidos e recuperáveis em qualquer circunstância.

44 visualizações

Melhores Práticas para Operações Diárias de Backup e Restauração do Elasticsearch

Backups diários são a base de um gerenciamento de dados confiável, especialmente para sistemas distribuídos de missão crítica como o Elasticsearch. Embora o Elasticsearch ofereça alta disponibilidade por meio de replicação, uma estratégia de snapshot confiável é essencial para proteger contra erros operacionais, corrupção de dados e falhas catastróficas do sistema.

Este guia detalha as melhores práticas para implementar backups de snapshot diários robustos e automatizados usando a API Snapshot and Restore do Elasticsearch, focando na automação via Snapshot Lifecycle Management (SLM), integração com Index Lifecycle Management (ILM) e o requisito crucial de teste de restauração regular.

Entendendo o Mecanismo de Snapshot do Elasticsearch

Snapshots do Elasticsearch não são simplesmente cópias de arquivos; eles são incrementais, aproveitando a estrutura interna dos índices Lucene. Isso significa que, após o snapshot completo inicial, os snapshots subsequentes armazenam apenas segmentos de dados que foram alterados desde o último snapshot bem-sucedido, tornando-os altamente eficientes em termos de tempo e armazenamento.

Snapshots capturam dois componentes principais:
1. Dados do Índice: Os segmentos Lucene reais para os índices selecionados.
2. Estado do Cluster: Metadados, configurações persistentes, modelos de índice, pipelines e funções.

1. Estabelecendo o Repositório de Snapshot

Antes de tirar qualquer snapshot, você deve registrar um repositório – o local seguro onde os arquivos de snapshot serão armazenados. A escolha do repositório é crucial para a durabilidade e velocidade de recuperação.

Tipos de Repositório

Tipo de Repositório Descrição Melhor para Requisitos
fs (Sistema de Arquivos Compartilhado) Unidade local ou montada em rede acessível por todos os nós mestre e de dados. Clusters pequenos, backups locais rápidos. Deve ser registrado em elasticsearch.yml (path.repo).
s3, azure, gcs Serviços de armazenamento em nuvem (requer o respetivo plugin instalado em todos os nós). Ambientes de produção, recuperação de desastres. Instalação de plugin e credenciais IAM/service principal adequadas.

Exemplo: Registrando um Repositório S3

Para ambientes de produção, o armazenamento em nuvem é altamente recomendado para durabilidade e recuperação fora do local. Você deve instalar o plugin do repositório (ex: repository-s3) e, em seguida, registrar o repositório via API.

PUT /_snapshot/my_s3_daily_repo
{
  "type": "s3",
  "settings": {
    "bucket": "es-backup-bucket-name",
    "region": "us-east-1",
    "base_path": "daily_snapshots/production",
    "compress": true
  }
}

Dica: Certifique-se de que o bucket ou caminho do sistema de arquivos configurado seja seguro, imutável (se suportado pelo seu provedor) e usado exclusivamente para backups.

2. Implementando Automação Diária com SLM

Snapshots manuais são aceitáveis para operações únicas, mas backups diários de rotina devem ser automatizados usando o Snapshot Lifecycle Management (SLM). O SLM é o mecanismo nativo dentro do Elasticsearch projetado especificamente para definir agendamentos, políticas de retenção e gerenciamento de snapshots.

Definindo uma Política SLM

Uma política diária típica define um agendamento, os índices a incluir (ou excluir) e por quanto tempo reter os snapshots.

PUT /_slm/policy/daily_archive_policy
{
  "schedule": "0 30 1 * * ?", 
  "name": "<daily-{{now/d}}>",
  "repository": "my_s3_daily_repo",
  "config": {
    "indices": ["logstash-*", "application-metrics-*"],
    "ignore_unavailable": true,
    "include_global_state": false 
  },
  "retention": {
    "expire_after": "30d", 
    "min_count": 5, 
    "max_count": 30 
  }
}

Pontos Chave da Configuração SLM:

  • schedule: Usa a sintaxe cron do Quartz (ex: 0 30 1 * * ? é executado diariamente às 01:30 AM). Agende durante as horas de baixo uso.
  • include_global_state: false: Para backups diários de dados, geralmente é melhor excluir o estado do cluster para evitar o rollback acidental do estado durante a restauração.
  • retention: Define o agendamento de limpeza. O exemplo acima retém snapshots por 30 dias, garantindo que pelo menos 5 e no máximo 30 sejam mantidos.

Monitorando o SLM

Verifique regularmente o status das suas políticas para garantir que estão sendo executadas com sucesso.

GET /_slm/status
GET /_slm/policy/daily_archive_policy

3. Integrando com o Index Lifecycle Management (ILM)

Para grandes volumes de dados de séries temporais (como logs), o Index Lifecycle Management (ILM) gerencia índices desde a criação até a exclusão. Os snapshots diários devem se integrar ao ILM para arquivamento de longo prazo.

ILM e Camadas de Dados

A melhor prática é tirar o snapshot dos índices um pouco antes de serem permanentemente excluídos ou movidos para uma camada fria/congelada com uso intensivo de recursos. Você pode incorporar a operação de snapshot diretamente na fase de exclusão da sua política ILM.

  1. Definir uma Fase da Política: Crie uma fase (ex: delete) na sua política ILM.
  2. Adicionar a Ação de Snapshot: Especifique o repositório e o padrão do nome do snapshot.
...
"delete": {
  "min_age": "90d",
  "actions": {
    "forcemerge": {},
    "shrink": {},
    "rollover": {},
    "delete": {
      "snapshot": {
        "repository": "my_longterm_archive_repo",
        "name": "ilm-archive-{{index}}"
      }
    }
  }
}
...

Isso garante que dados com mais de 90 dias sejam arquivados antes que os índices sejam removidos do cluster, cumprindo os requisitos de conformidade sem reter grandes quantidades de dados antigos em armazenamento primário caro.

4. Melhores Práticas para Teste de Restauração

Uma rotina de backup está incompleta sem uma estratégia de recuperação comprovada. Você deve testar regularmente seu processo de restauração para validar a integridade dos dados e atingir as metas de Recovery Time Objective (RTO).

Ambiente de Teste de Restauração

  • Nunca restaure diretamente em um cluster de produção. Use um ambiente dedicado de staging ou teste que imite a configuração de produção (mesma versão do Elasticsearch, topologia de rede).
  • Frequência: Teste a restauração pelo menos trimestralmente, ou após grandes atualizações/mudanças de configuração.

Executando uma Restauração

A restauração pode visar índices específicos ou o estado do cluster inteiro.

Passo 1: Obter Detalhes do Snapshot

Identifique o nome do snapshot que você precisa restaurar.

GET /_snapshot/my_s3_daily_repo/_all

Passo 2: Executar a Operação de Restauração

Para restaurar índices específicos, use o parâmetro indices. Muitas vezes é necessário renomear índices durante a restauração para evitar conflito com índices ativos (especialmente em um ambiente de teste).

POST /_snapshot/my_s3_daily_repo/snapshot_20240501/_restore
{
  "indices": ["logstash-2024-05-01"],
  "rename_pattern": "(.+)",
  "rename_replacement": "restored-$1",
  "include_aliases": false
}

Verificando o Sucesso da Restauração

Após a restauração, verifique se os índices estão verdes e se as contagens de documentos correspondem à fonte de dados original.

GET /restored-logstash-2024-05-01/_count

5. Considerações de Segurança e Desempenho

Segurança

  • Acesso ao Repositório: Garanta que as credenciais usadas pelo Elasticsearch para acessar o repositório (ex: credenciais S3) adiram ao princípio do menor privilégio – elas devem ter apenas acesso de escrita durante o processo de snapshot e acesso de leitura durante a restauração.
  • Criptografia: Utilize repositórios seguros (como S3) com criptografia do lado do servidor ativada (SSE-S3 ou SSE-KMS).

Limitação de Desempenho (Throttling)

Snapshots podem ser intensivos em I/O. Por padrão, o Elasticsearch limita os uploads de segmentos concorrentes. Se você notar degradação de desempenho durante a janela agendada do snapshot, você pode ajustar as configurações de throttling (mas evite torná-las muito permissivas):

PUT /_cluster/settings
{
  "persistent": {
    "indices.recovery.max_bytes_per_sec": "100mb", 
    "snapshot.max_bytes_per_sec": "100mb"
  }
}

Aviso: Aumentar o max_bytes_per_sec demais pode afetar negativamente a capacidade de resposta do cluster para consultas de clientes e operações de indexação.

Resumo do Fluxo de Trabalho de Backup Diário

  1. Configure um Repositório Durável: Use armazenamento em nuvem (S3/Azure/GCS) para ambientes de produção.
  2. Defina a Política SLM: Agende snapshots (ex: diariamente às 1:30 AM) usando SLM, garantindo que regras de retenção apropriadas sejam definidas.
  3. Integre o ILM (se aplicável): Use o ILM para arquivar índices mais antigos em um repositório de longo prazo antes da exclusão.
  4. Monitore o Status: Verifique regularmente a execução da política SLM através das APIs _slm/policy e _slm/status.
  5. Teste a Recuperação: Trimestral ou bianualmente, realize uma restauração completa para um ambiente segregado para validar a prontidão do RTO.