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

Backups diários protegem seu cluster Elasticsearch contra falhas que as réplicas não podem corrigir: exclusões acidentais, mapeamentos incorretos, dados corrompidos, atualizações com falha e perda total do cluster. As réplicas ajudam na disponibilidade, mas os snapshots são o que permite voltar a uma cópia boa conhecida.

Estas melhores práticas para operações diárias de backup e restauração no Elasticsearch cobrem a configuração do repositório, o Snapshot Lifecycle Management (SLM), testes de restauração e os lugares onde o Index Lifecycle Management (ILM) se encaixa.

Compreendendo o Mecanismo de Snapshot do Elasticsearch

Os snapshots do Elasticsearch não são simples 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.

Os snapshots capturam dois componentes principais:

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

1. Estabelecendo o Repositório de Snapshots

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 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 mestres 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. Algumas distribuições e versões agrupam esses tipos de repositório; outras exigem a instalação do plugin de repositório correspondente em cada nó.	Ambientes de produção, recuperação de desastres.	Suporte de repositório adequado à versão e credenciais IAM/principal de serviço apropriadas.

Exemplo: Registrando um Repositório S3

Para ambientes de produção, o armazenamento em nuvem geralmente é a melhor escolha para durabilidade e recuperação fora do local. Confirme o suporte do repositório para sua versão do Elasticsearch, configure as credenciais com segurança e registre o repositório através da 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 pontuais, 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 serem incluídos (ou excluídos) 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 de Configuração do SLM:

• schedule: Usa sintaxe cron Quartz (ex.: 0 30 1 * * ? executa diariamente à 01:30). Agende durante horários de baixo uso.
• include_global_state: false: Para backups de dados diários, geralmente é melhor excluir o estado do cluster para evitar reversão acidental do estado durante a restauração.
• retention: Define o cronograma 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 de suas políticas para garantir que estejam sendo executadas com sucesso.

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

3. Integrando com o Index Lifecycle Management (ILM)

Para grandes dados de série temporal, como logs e métricas, o Index Lifecycle Management (ILM) gerencia índices desde a criação até a exclusão. O ILM não substitui os snapshots diários do SLM, mas pode ajudar a coordenar a exclusão com uma política de snapshot concluída.

ILM e Hierarquia de Dados

Antes que o ILM exclua índices antigos, você pode fazer a fase de exclusão aguardar a execução de uma política SLM. Isso dá à sua política de snapshot diária ou de longo prazo a chance de capturar os dados antes que o índice seja removido do cluster.

1. Crie uma política SLM que faça snapshot do padrão de índice relevante.
2. Referencie essa política SLM da fase de exclusão do ILM com wait_for_snapshot.

...
"delete": {
  "min_age": "90d",
  "actions": {
    "wait_for_snapshot": {
      "policy": "daily_archive_policy"
    },
    "delete": {}
  }
}
...

Isso aguarda um snapshot bem-sucedido da política SLM nomeada antes que o ILM exclua o índice. Se você usar fluxos de dados, teste o fluxo do ciclo de vida em um ambiente de teste para saber quais índices de suporte são cobertos pela política de snapshot.

Se seu objetivo é manter dados pesquisáveis mais antigos em armazenamento mais barato em vez de excluí-los, veja a ação de snapshot pesquisável na fase fria ou congelada. Esse é um padrão diferente de um snapshot simples de recuperação de desastres:

...
"cold": {
  "min_age": "30d",
  "actions": {
    "searchable_snapshot": {
      "snapshot_repository": "my_s3_daily_repo"
    }
  }
}
...

Use um padrão de ciclo de vida por objetivo: SLM para backups recuperáveis, wait_for_snapshot antes da exclusão e snapshots pesquisáveis quando você precisar de acesso de pesquisa de menor custo.

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

Uma rotina de backup é 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 Tempo de Objetivo de Recuperação (RTO).

Ambiente de Teste de Restauração

• Não teste restaurações diretamente em um cluster de produção ativo. Use um ambiente de teste ou homologação dedicado que execute uma versão compatível do Elasticsearch e tenha espaço em disco suficiente para os fragmentos restaurados.
• Frequência: Teste a restauração pelo menos trimestralmente, ou após grandes atualizações/alterações de configuração.

Executando uma Restauração

A restauração pode ter como alvo índices específicos ou todo o estado do cluster.

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 os í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 a saúde dos fragmentos e as contagens de documentos. Uma correspondência de contagem é útil, mas também execute uma consulta de amostra da qual seu aplicativo depende.

GET /_cluster/health/restored-logstash-2024-05-01?wait_for_status=green&timeout=60s
GET /restored-logstash-2024-05-01/_count

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

Segurança

• Acesso ao Repositório: Certifique-se de que as credenciais usadas pelo Elasticsearch para acessar o repositório sigam o princípio do menor privilégio para o caminho do repositório. Na prática, o gerenciamento de snapshots precisa de permissões de leitura, gravação, listagem e exclusão para os objetos que possui, especialmente quando a retenção exclui snapshots antigos.
• Criptografia: Utilize repositórios seguros (como S3) com criptografia do lado do servidor ativada (SSE-S3 ou SSE-KMS).

Limitação de Desempenho

Snapshots podem ser intensivos em E/S. Se você notar degradação de desempenho durante a janela de snapshot, limite o tráfego de snapshot no nível do repositório. Para muitos tipos de repositório, as configurações relevantes são max_snapshot_bytes_per_sec e max_restore_bytes_per_sec ao registrar ou atualizar o repositório.

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

indices.recovery.max_bytes_per_sec controla o tráfego de recuperação de pares e snapshots, portanto, ajuste-o apenas quando entender o efeito na recuperação de fragmentos. Mantenha os agendamentos de snapshot fora das janelas de pico de indexação e pesquisa, quando possível.

Fluxo de Trabalho Diário de Backup

1. Configure um Repositório Durável: Use armazenamento em nuvem (S3/Azure/GCS) para ambientes de produção.
2. Defina uma Política SLM: Agende snapshots (ex.: diariamente às 1:30 AM) usando SLM, garantindo que regras de retenção apropriadas sejam definidas.
3. Coordene o ILM (se aplicável): Use wait_for_snapshot antes da exclusão ou snapshots pesquisáveis para um histórico pesquisável de menor custo.
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: Trimestralmente ou semestralmente, realize uma restauração completa em um ambiente segregado para validar a prontidão do RTO.

O backup útil é aquele que você pode restaurar. Mantenha a política SLM diária simples, monitore falhas e agende exercícios de restauração com frequência suficiente para que sua equipe saiba os passos exatos antes de um incidente.