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

Les sauvegardes quotidiennes sont la pierre angulaire d'une gestion fiable des données, en particulier pour les systèmes distribués critiques comme Elasticsearch. Bien qu'Elasticsearch offre une haute disponibilité grâce à la réplication, une stratégie de cliché instantané (snapshot) fiable est essentielle pour se prémunir contre les erreurs opérationnelles, la corruption des données et les défaillances catastrophiques du système.

Ce guide détaille les meilleures pratiques pour la mise en œuvre de sauvegardes quotidiennes automatisées et robustes à l'aide de l'API Snapshot and Restore d'Elasticsearch, en se concentrant sur l'automatisation via la gestion du cycle de vie des clichés (Snapshot Lifecycle Management - SLM), l'intégration avec la gestion du cycle de vie des index (Index Lifecycle Management - ILM), et l'exigence critique de tests de restauration réguliers.

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

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

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

1. Établir le référentiel de clichés instantanés (Snapshot Repository)

Avant de prendre tout cliché, vous devez enregistrer un référentiel (repository) – l'emplacement sécurisé où les fichiers de cliché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	Exigences
`fs` (Système de fichiers partagé)	Lecteur 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 (nécessite l'installation du plugin respectif sur tous les nœuds).	Environnements de production, reprise après sinistre.	Installation du plugin 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 fortement recommandé pour la durabilité et la récupération hors site. Vous devez installer le plugin de référentiel (par exemple, repository-s3), puis enregistrer 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
  }
}

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

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

Les clichés instantanés manuels sont acceptables pour des opérations ponctuelles, mais les sauvegardes quotidiennes de routine doivent être automatisées à l'aide de la gestion du cycle de vie des clichés (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 clichés.

Définir une politique SLM

Une politique quotidienne typique définit une planification, les index à inclure (ou à exclure) et la durée de conservation des cliché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 du matin). 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 afin d'éviter un retour en arrière accidentel de l'état lors de la restauration.
retention : Définit la politique de nettoyage. L'exemple ci-dessus conserve les clichés pendant 30 jours, garantissant qu'au moins 5 et au maximum 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 la gestion du cycle de vie des index (ILM)

Pour les grandes quantités de données de séries temporelles (comme les journaux), la gestion du cycle de vie des index (ILM) gère les index de la création à la suppression. Les clichés quotidiens doivent s'intégrer à ILM pour l'archivage à long terme.

ILM et hiérarchisation des données

La meilleure pratique consiste à prendre un cliché des index juste avant qu'ils ne soient définitivement supprimés ou déplacés vers un niveau froid/gelé gourmand en ressources. Vous pouvez intégrer l'opération de cliché directement dans la phase de suppression de votre politique ILM.

Définir une phase de politique : Créez une phase (par exemple, delete) dans votre politique ILM.
Ajouter l'action de cliché : Spécifiez le référentiel et le modèle de nom de cliché.

...
"delete": {
  "min_age": "90d",
  "actions": {
    "forcemerge": {},
    "shrink": {},
    "rollover": {},
    "delete": {
      "snapshot": {
        "repository": "my_longterm_archive_repo",
        "name": "ilm-archive-{{index}}"
      }
    }
  }
}
...

Cela garantit que les données de plus de 90 jours sont archivées avant que les index ne soient supprimés du cluster, répondant ainsi aux exigences de conformité sans conserver d'énormes quantités d'anciennes données sur un stockage primaire coûteux.

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

Ne restaurez jamais directement sur un cluster de production. Utilisez un environnement de pré-production ou de test dédié qui imite la configuration de production (même version d'Elasticsearch, topologie réseau).
Fréquence : Testez la restauration au moins trimestriellement, ou après des mises à niveau/changements de configuration majeurs.

Exécuter une restauration

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

Étape 1 : Obtenir les détails du cliché

Identifiez le nom du cliché 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 pendant la restauration afin d'é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 du succès de la restauration

Après la restauration, vérifiez que les index sont au statut 'green' et que les décomptes de documents correspondent à la source de données originale.

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 (par exemple, les identifiants S3) adhèrent au principe du moindre privilège – elles ne devraient avoir qu'un accès en écriture pendant le processus de cliché et un accès en lecture pendant la restauration.
Chiffrement : Utilisez des référentiels sécurisés (comme S3) avec le chiffrement côté serveur activé (SSE-S3 ou SSE-KMS).

Limitation des performances (Throttling)

Les clichés instantanés peuvent être gourmands en E/S. Par défaut, Elasticsearch limite les téléchargements de segments simultanés. Si vous remarquez une dégradation des performances pendant la fenêtre de cliché planifiée, vous pouvez ajuster les paramètres de limitation (mais évitez de les rendre trop permissifs) :

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

Avertissement : Augmenter max_bytes_per_sec trop haut peut avoir un impact négatif sur la réactivité du cluster pour les requêtes client et les opérations d'indexation.

Résumé du flux de travail de sauvegarde quotidienne

Configurer un référentiel durable : Utilisez le stockage cloud (S3/Azure/GCS) pour les environnements de production.
Définir la politique SLM : Planifiez les clichés (par exemple, quotidiennement à 1h30 du matin) à l'aide de SLM, en veillant à ce que des règles de rétention appropriées soient définies.
Intégrer ILM (si applicable) : Utilisez ILM pour archiver les index plus anciens dans un référentiel à long terme avant leur suppression.
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 vers un environnement isolé pour valider la préparation au RTO.