Migliori Pratiche per le Operazioni di Backup e Ripristino Giornaliero di Elasticsearch

I backup giornalieri proteggono il tuo cluster Elasticsearch dai guasti che le repliche non possono risolvere: cancellazioni accidentali, mapping errati, dati corrotti, aggiornamenti falliti e perdita completa del cluster. Le repliche aiutano la disponibilità, ma gli snapshot sono ciò che ti permette di tornare a una copia nota e funzionante.

Queste migliori pratiche per le operazioni di backup e ripristino giornaliero di Elasticsearch coprono la configurazione del repository, Snapshot Lifecycle Management (SLM), il test di ripristino e i punti in cui Index Lifecycle Management (ILM) si inserisce.

Comprensione del Meccanismo di Snapshot di Elasticsearch

Gli snapshot di Elasticsearch non sono semplici copie di file; sono incrementali, sfruttando la struttura interna degli indici Lucene. Ciò significa che dopo lo snapshot completo iniziale, gli snapshot successivi memorizzano solo i segmenti di dati che sono cambiati dall'ultimo snapshot riuscito, rendendoli altamente efficienti in termini di tempo e spazio di archiviazione.

Gli snapshot catturano due componenti principali:

1. Dati dell'Indice: I segmenti Lucene effettivi per gli indici selezionati.
2. Stato del Cluster: Metadati, impostazioni persistenti, template degli indici, pipeline e ruoli.

1. Creazione del Repository di Snapshot

Prima di eseguire qualsiasi snapshot, devi registrare un repository: la posizione sicura in cui verranno archiviati i file degli snapshot. La scelta del repository è cruciale per la durabilità e la velocità di recupero.

Tipi di Repository

Tipo di Repository	Descrizione	Ideale per	Requisiti
fs (File System Condiviso)	Unità locale o montata in rete accessibile da tutti i nodi master e dati.	Cluster piccoli, backup locali rapidi.	Deve essere registrato in elasticsearch.yml (path.repo).
s3, azure, gcs	Servizi di archiviazione cloud. Alcune distribuzioni e versioni raggruppano questi tipi di repository; altre richiedono l'installazione del plugin del repository corrispondente su ogni nodo.	Ambienti di produzione, disaster recovery.	Supporto del repository appropriato per la versione e credenziali IAM/entità servizio corrette.

Esempio: Registrazione di un Repository S3

Per gli ambienti di produzione, l'archiviazione cloud è solitamente la scelta migliore per durabilità e recupero fuori sede. Conferma il supporto del repository per la tua versione di Elasticsearch, configura le credenziali in modo sicuro, quindi registra il repository tramite l'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
  }
}

Suggerimento: Assicurati che il bucket configurato o il percorso del file system sia sicuro, immutabile (se supportato dal tuo provider) e utilizzato esclusivamente per i backup.

2. Implementazione dell'Automazione Giornaliera con SLM

Gli snapshot manuali sono accettabili per operazioni una tantum, ma i backup giornalieri di routine devono essere automatizzati utilizzando Snapshot Lifecycle Management (SLM). SLM è il meccanismo nativo all'interno di Elasticsearch progettato specificamente per definire pianificazioni, politiche di conservazione e gestione degli snapshot.

Definizione di una Politica SLM

Una politica giornaliera tipica definisce una pianificazione, gli indici da includere (o escludere) e per quanto tempo conservare gli snapshot.

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 
  }
}

Punti Chiave di Configurazione SLM:

• schedule: Utilizza la sintassi cron di Quartz (ad es., 0 30 1 * * ? viene eseguito ogni giorno alle 01:30). Pianifica durante le ore di basso utilizzo.
• include_global_state: false: Per i backup giornalieri dei dati, è spesso meglio escludere lo stato del cluster per prevenire un rollback accidentale dello stato durante il ripristino.
• retention: Definisce la pianificazione della pulizia. L'esempio sopra conserva gli snapshot per 30 giorni, assicurando che ne vengano conservati almeno 5 e non più di 30.

Monitoraggio di SLM

Controlla regolarmente lo stato delle tue politiche per assicurarti che vengano eseguite con successo.

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

3. Integrazione con Index Lifecycle Management (ILM)

Per grandi dati di serie temporali, come log e metriche, Index Lifecycle Management (ILM) gestisce gli indici dalla creazione alla cancellazione. ILM non sostituisce gli snapshot SLM giornalieri, ma può aiutarti a coordinare la cancellazione con una politica di snapshot completata.

ILM e Tiering dei Dati

Prima che ILM cancelli gli indici vecchi, puoi far sì che la fase di cancellazione attenda l'esecuzione di una politica SLM. Questo dà alla tua politica di snapshot giornaliera o a lungo termine la possibilità di catturare i dati prima che l'indice venga rimosso dal cluster.

1. Crea una politica SLM che esegua lo snapshot del pattern di indice pertinente.
2. Fai riferimento a quella politica SLM dalla fase di cancellazione di ILM con wait_for_snapshot.

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

Questo attende uno snapshot riuscito dalla politica SLM nominata prima che ILM cancelli l'indice. Se utilizzi data stream, testa il flusso del ciclo di vita in staging in modo da sapere quali indici di supporto sono coperti dalla politica di snapshot.

Se il tuo obiettivo è mantenere dati ricercabili più vecchi su storage più economico invece di cancellarli, guarda all'azione searchable snapshot nella fase cold o frozen. Questo è un pattern diverso da un semplice snapshot per disaster recovery:

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

Usa un pattern di ciclo di vita per obiettivo: SLM per backup recuperabili, wait_for_snapshot prima della cancellazione e searchable snapshot quando hai bisogno di accesso di ricerca a costo inferiore.

4. Migliori Pratiche per il Test di Ripristino

Una routine di backup è incompleta senza una strategia di recupero provata. Devi testare regolarmente il tuo processo di ripristino per convalidare l'integrità dei dati e raggiungere gli obiettivi di Recovery Time Objective (RTO).

Ambiente di Test di Ripristino

• Non testare i ripristini direttamente su un cluster di produzione attivo. Utilizza un ambiente di staging o test dedicato che esegua una versione compatibile di Elasticsearch e abbia spazio su disco sufficiente per gli shard ripristinati.
• Frequenza: Testa il ripristino almeno trimestralmente, o dopo importanti aggiornamenti/cambi di configurazione.

Esecuzione di un Ripristino

Il ripristino può avere come target indici specifici o l'intero stato del cluster.

Passo 1: Ottieni i Dettagli dello Snapshot

Identifica il nome dello snapshot che devi ripristinare.

GET /_snapshot/my_s3_daily_repo/_all

Passo 2: Esegui l'Operazione di Ripristino

Per ripristinare indici specifici, usa il parametro indices. È spesso necessario rinominare gli indici durante il ripristino per evitare conflitti con gli indici attivi (specialmente in un ambiente di test).

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

Verifica del Successo del Ripristino

Dopo il ripristino, verifica la salute degli shard e i conteggi dei documenti. Una corrispondenza dei conteggi è utile, ma esegui anche una query di esempio da cui dipende la tua applicazione.

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

5. Considerazioni su Sicurezza e Prestazioni

Sicurezza

• Accesso al Repository: Assicurati che le credenziali utilizzate da Elasticsearch per accedere al repository seguano il principio del minimo privilegio per il percorso del repository. In pratica, la gestione degli snapshot necessita di permessi di lettura, scrittura, elenco e cancellazione per gli oggetti che possiede, specialmente quando la conservazione cancella gli snapshot vecchi.
• Crittografia: Utilizza repository sicuri (come S3) con crittografia lato server abilitata (SSE-S3 o SSE-KMS).

Limitazione delle Prestazioni

Gli snapshot possono essere intensivi in termini di I/O. Se noti un degrado delle prestazioni durante la finestra degli snapshot, limita il traffico degli snapshot a livello di repository. Per molti tipi di repository, le impostazioni rilevanti sono max_snapshot_bytes_per_sec e max_restore_bytes_per_sec quando registri o aggiorni il repository.

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 controlla il traffico di recupero peer e snapshot, quindi modificalo solo quando comprendi l'effetto sul recupero degli shard. Mantieni le pianificazioni degli snapshot al di fuori delle finestre di indicizzazione e ricerca di picco quando possibile.

Flusso di Lavoro del Backup Giornaliero

1. Configura un Repository Durevole: Utilizza l'archiviazione cloud (S3/Azure/GCS) per gli ambienti di produzione.
2. Definisci una Politica SLM: Pianifica gli snapshot (ad es., ogni giorno alle 1:30) utilizzando SLM, assicurandoti di impostare regole di conservazione appropriate.
3. Coordina ILM (se applicabile): Utilizza wait_for_snapshot prima della cancellazione o searchable snapshot per una cronologia ricercabile a costo inferiore.
4. Monitora lo Stato: Verifica regolarmente l'esecuzione della politica SLM tramite le API _slm/policy e _slm/status.
5. Testa il Recupero: Trimestralmente o semestralmente, esegui un ripristino completo in un ambiente segregato per convalidare la prontezza RTO.

Il backup utile è quello che puoi ripristinare. Mantieni la politica SLM giornaliera semplice, monitora i fallimenti e pianifica esercitazioni di ripristino abbastanza spesso che il tuo team conosca i passaggi esatti prima di un incidente.