Meilleures pratiques pour les opérations de sauvegarde et de restauration quotidiennes d'Elasticsearch

Les sauvegardes quotidiennes protègent votre cluster Elasticsearch contre les défaillances que les réplicas ne peuvent pas corriger : suppressions accidentelles, mauvais mappages, données corrompues, mises à niveau échouées et perte totale du cluster. Les réplicas aident à la disponibilité, mais ce sont les instantanés qui vous permettent de revenir à une copie saine connue.

Ces meilleures pratiques pour les opérations de sauvegarde et de restauration quotidiennes d'Elasticsearch couvrent la configuration du référentiel, Snapshot Lifecycle Management (SLM), les tests de restauration et les endroits où Index Lifecycle Management (ILM) s'intègre.

Comprendre le mécanisme d'instantané d'Elasticsearch

Les instantanés Elasticsearch ne sont pas de simples copies de fichiers ; ils sont incrémentiels, exploitant la structure interne des index Lucene. Cela signifie qu'après l'instantané complet initial, les instantanés suivants ne stockent que les segments de données qui ont changé depuis le dernier instantané réussi, ce qui les rend très efficaces en termes de temps et de stockage.

Les instantanés capturent deux composants principaux :

Données d'index : Les segments Lucene réels pour les index sélectionnés.
État du cluster : Métadonnées, paramètres persistants, modèles d'index, pipelines et rôles.

1. Établir le référentiel d'instantanés

Avant de prendre un instantané, vous devez enregistrer un référentiel : l'emplacement sécurisé où les fichiers d'instantanés seront stockés. Le choix du référentiel est crucial pour la durabilité et la vitesse de récupération.

Types de référentiels

Type de référentiel	Description	Idéal pour	Prérequis
`fs` (Système de fichiers partagé)	Disque local ou monté en réseau accessible par tous les nœuds maîtres et de données.	Petits clusters, sauvegardes locales rapides.	Doit être enregistré dans `elasticsearch.yml` (`path.repo`).
`s3`, `azure`, `gcs`	Services de stockage cloud. Certaines distributions et versions regroupent ces types de référentiels ; d'autres nécessitent l'installation du plugin de référentiel correspondant sur chaque nœud.	Environnements de production, reprise après sinistre.	Prise en charge du référentiel adaptée à la version et informations d'identification IAM/principal de service appropriées.

Exemple : Enregistrement d'un référentiel S3

Pour les environnements de production, le stockage cloud est généralement le meilleur choix pour la durabilité et la récupération hors site. Confirmez la prise en charge du référentiel pour votre version d'Elasticsearch, configurez les informations d'identification de manière sécurisée, puis enregistrez le référentiel via 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
  }
}

Astuce : Assurez-vous que le bucket ou le chemin du système de fichiers configuré est sécurisé, immuable (si pris en charge par votre fournisseur) et exclusivement utilisé pour les sauvegardes.

2. Mise en œuvre de l'automatisation quotidienne avec SLM

Les instantanés manuels sont acceptables pour des opérations ponctuelles, mais les sauvegardes quotidiennes de routine doivent être automatisées à l'aide de Snapshot Lifecycle Management (SLM). SLM est le mécanisme natif d'Elasticsearch conçu spécifiquement pour définir des planifications, des politiques de rétention et la gestion des instantanés.

Définition d'une politique SLM

Une politique quotidienne typique définit une planification, les index à inclure (ou exclure) et la durée de conservation des instantanés.

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

Points clés de configuration SLM :

schedule : Utilise la syntaxe cron Quartz (par exemple, 0 30 1 * * ? s'exécute quotidiennement à 01h30). Planifiez pendant les heures de faible utilisation.
include_global_state: false : Pour les sauvegardes de données quotidiennes, il est souvent préférable d'exclure l'état du cluster pour éviter un retour en arrière accidentel de l'état lors de la restauration.
retention : Définit la planification du nettoyage. L'exemple ci-dessus conserve les instantanés pendant 30 jours, garantissant qu'au moins 5 et au plus 30 sont conservés.

Surveillance de SLM

Vérifiez régulièrement l'état de vos politiques pour vous assurer qu'elles s'exécutent avec succès.

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

3. Intégration avec Index Lifecycle Management (ILM)

Pour les grandes séries de données temporelles, telles que les journaux et les métriques, Index Lifecycle Management (ILM) gère les index de la création à la suppression. ILM ne remplace pas les instantanés SLM quotidiens, mais il peut vous aider à coordonner la suppression avec une politique d'instantané terminée.

ILM et hiérarchisation des données

Avant qu'ILM ne supprime les anciens index, vous pouvez faire en sorte que la phase de suppression attende l'exécution d'une politique SLM. Cela donne à votre politique d'instantané quotidienne ou à long terme une chance de capturer les données avant que l'index ne soit supprimé du cluster.

Créez une politique SLM qui capture le modèle d'index pertinent.
Référencez cette politique SLM à partir de la phase de suppression ILM avec wait_for_snapshot.

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

Cela attend un instantané réussi de la politique SLM nommée avant qu'ILM ne supprime l'index. Si vous utilisez des flux de données, testez le flux du cycle de vie dans un environnement de préproduction afin de savoir quels index de support sont couverts par la politique d'instantané.

Si votre objectif est de conserver des données consultables plus anciennes sur un stockage moins cher plutôt que de les supprimer, examinez l'action d'instantané consultable dans la phase froide ou gelée. Il s'agit d'un modèle différent d'un simple instantané de reprise après sinistre :

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

Utilisez un modèle de cycle de vie par objectif : SLM pour les sauvegardes récupérables, wait_for_snapshot avant la suppression et les instantanés consultables lorsque vous avez besoin d'un accès de recherche à moindre coût.

4. Meilleures pratiques pour les tests de restauration

Une routine de sauvegarde est incomplète sans une stratégie de récupération éprouvée. Vous devez tester régulièrement votre processus de restauration pour valider l'intégrité des données et atteindre les objectifs de temps de récupération (RTO).

Environnement de test de restauration

N'effectuez pas de tests de restauration directement sur un cluster de production en direct. Utilisez un environnement de préproduction ou de test dédié qui exécute une version compatible d'Elasticsearch et dispose de suffisamment d'espace disque pour les fragments restaurés.
Fréquence : Testez la restauration au moins une fois par trimestre, ou après des mises à niveau majeures ou des modifications de configuration.

Exécution d'une restauration

La restauration peut cibler des index spécifiques ou l'état complet du cluster.

Étape 1 : Obtenir les détails de l'instantané

Identifiez le nom de l'instantané que vous devez restaurer.

GET /_snapshot/my_s3_daily_repo/_all

Étape 2 : Exécuter l'opération de restauration

Pour restaurer des index spécifiques, utilisez le paramètre indices. Il est souvent nécessaire de renommer les index lors de la restauration pour éviter les conflits avec les index actifs (en particulier dans un environnement de test).

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

Vérification de la réussite de la restauration

Après la restauration, vérifiez l'état des fragments et les nombres de documents. Une correspondance de nombre est utile, mais exécutez également une requête échantillon dont votre application dépend.

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

5. Considérations de sécurité et de performance

Sécurité

Accès au référentiel : Assurez-vous que les informations d'identification utilisées par Elasticsearch pour accéder au référentiel suivent le principe du moindre privilège pour le chemin du référentiel. En pratique, la gestion des instantanés nécessite des autorisations de lecture, écriture, liste et suppression pour les objets qu'elle possède, en particulier lorsque la rétention supprime les anciens instantanés.
Chiffrement : Utilisez des référentiels sécurisés (comme S3) avec chiffrement côté serveur activé (SSE-S3 ou SSE-KMS).

Limitation des performances

Les instantanés peuvent être intensifs en E/S. Si vous remarquez une dégradation des performances pendant la fenêtre d'instantané, limitez le trafic d'instantané au niveau du référentiel. Pour de nombreux types de référentiels, les paramètres pertinents sont max_snapshot_bytes_per_sec et max_restore_bytes_per_sec lors de l'enregistrement ou de la mise à jour du référentiel.

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 contrôle le trafic de récupération entre pairs et d'instantané, donc ajustez-le uniquement lorsque vous comprenez l'effet sur la récupération des fragments. Dans la mesure du possible, maintenez les planifications d'instantanés en dehors des fenêtres d'indexation et de recherche de pointe.

Flux de travail de sauvegarde quotidien

Configurer un référentiel durable : Utilisez le stockage cloud (S3/Azure/GCS) pour les environnements de production.
Définir une politique SLM : Planifiez les instantanés (par exemple, quotidiennement à 1h30) à l'aide de SLM, en définissant des règles de rétention appropriées.
Coordonner ILM (le cas échéant) : Utilisez wait_for_snapshot avant la suppression ou des instantanés consultables pour un historique consultable à moindre coût.
Surveiller l'état : Vérifiez régulièrement l'exécution de la politique SLM via les API _slm/policy et _slm/status.
Tester la récupération : Trimestriellement ou semestriellement, effectuez une restauration complète dans un environnement isolé pour valider l'état de préparation au RTO.

La sauvegarde utile est celle que vous pouvez restaurer. Gardez la politique SLM quotidienne simple, surveillez les échecs et planifiez des exercices de restauration assez souvent pour que votre équipe connaisse les étapes exactes avant un incident.