Sauvegarder une instance ELK🔗

Sauvegarder une instance ELK

Une fois que vous avez mis en place votre cluster Elasticsearch, vos agents logstash et Kibana, il est temps de sauvegarder tout ça. En effet, même si Elasticsearch permet de répartir les données entre les noeuds du cluster, il faut tout de même prévoir l'incident majeur où votre cluster est HS et que vous devez remonter des logs sensibles à partir d'une sauvegarde.

Concrètement, pour sauvegarder notre instance ELK, il faut se concentrer sur Elasticsearch. En effet, ce dernier stocke l'ensemble des données de log ainsi que la configuration et le contenu des dashboards de Kibana. C'est donc la partie la plus complexe à sauvegarder.

Pour sauvegarder Kibana, il faut juste sauvegarder son fichier de configuration. Il en est de même pour Logstash qui ne stocke aucune donnée. Pour ces deux éléments, la sauvegarde du fichier de configuration permettra de remonter une instance complète. Sauvegarder un fichier est une action simple que tout sysadmin doit savoir faire. Je n'y reviendrais donc pas.

Intéressons-nous à la sauvegarde du cluster Elasticsearch…

Elasticsearch dispose d'une API de snapshots. Grâce à cette technique, il est possible de faire des sauvegardes incrémentielles d'un cluster Elasticsearch et de les déposer dans un système de stockage distant. En effet, la nature distribuée du cluster Elasticsearch implique de sauvegarder les données sur un autre stockage que celui des noeuds. Il existe 4 méthodes de stockage (montage distant, Hadoop, AmazonS3 et Azure Cloud). Dans notre cas, nous allons conserver la méthode du montage distant car elle est simple à mettre en oeuvre et assez robuste (et puis, je ne vais pas monter un cluster Hadoop pour le fun !).

En fait, le point de montage n'est pas forcément distant: on indique juste un endroit où faire le stockage. Cet endroit est un point de montage sur le noeud.

L'API snapshot est disponible au niveau du cluster. Donc, finalement, les snapshots sont des actions sur le cluster. C'est pourquoi, on ne configure pas ces snapshots dans le fichier de configuration. Cela permet une plus grande souplesse. Par exemple, si vous voulez ajouter des stockages de snapshot, ce sera possible sans avoir à redémarrer le cluster, ce qui est une bonne chose.

Néanmoins, il faut respecter l'ordre des instructions suivantes:

• Déclarer un chemin vers l'emplacement de snapshot dans le fichier de configuration d'Elasticsearch.
• Déclarer et configurer un emplacement de snapshot via l'API snapshot.
• Lancer le snapshot d'un ou de plusieurs index.

Pour le fichier de configuration d'Elasticsearch, vous devez simplement ajouter un chemin pour la variable repo. Ceci est rendu nécéssaire pour empêcher n'importe qui de déclarer un emplacement de stockage n'importe où. Rappelez-vous que par défaut, n'importe qui a accès à l'API snapshot via une simple requête HTTP.

Il faut juste ajoute une ligne du type:

# Path to the backup repo
path.repo: /media/data/backup

Ensuite, il faut déclarer l'emplacement de stockage via l'API snapshot. Dans notre cas, nous allons créer un emplacement de stockage assez basique, de type fichier:

curl -XPUT http://localhost:9200/_snapshot/backup -d '
{
"type": "fs",
"settings": {
"location": "/media/backups/ELbackup"
}
}'

Ici, on créé un point de stockage de snapshot qui se nomme "backup": c'est la ligne 1. Ensuite, on le paramètre en lui indiquant qu'il s'agit d'un snapshot de type système de fichier ('fs') et pour ce dernier, on lui indique l'emplacement de stockage. Une fois que l'emplacement de stockage est référencé, on peut commencer à lancer un snapshot.

curl -XPUT http://localhost:9200/_snapshot/backup/snapshot_a -d '
{
  "indices": "index_1,index_2"
}'

Une fois que vous avez terminé votre backup, vous voudrez sans doute effectuer un test de restauration. Pour cela, si votre cluster est actif, la commande qui suit permettra de relancer une restauration complète:

curl -XPOST http://localhost:9200/_snapshot/backup/snapshot_a/_restore

C'est vraiment très simple !

En cas de désastre complet, il vous suffit d'installer votre cluster "from scratch", de récupérer vos anciens fichiers de configuration, stockés en sûreté et de rendre disponible les fichiers de snapshots via le point de montage précédemment déclaré. Configurez ensuite un emplacement de snapshot via l'API. Lancez ensuite une simple commande de restauration et le tour est joué.

Si vous empilez les snapshots, vous allez vous retrouver saturé en espace disque occupé à un moment ou un autre. Il va falloir faire de la place. Et pour ça, il y a une commande de l'API snapshot:

curl -XDELETE http://localhost:9200/_snapshot/backup/snapshot_a

Ceci vous permettra de mettre en oeuvre un système de backup complet et progressif pour ne garder que des snapshots valides et conformes à votre politique de rétention. Si vous faîtes des sauvegardes avec un système qui gère déjà cette politique, vous pouvez simplement supprimer tous les snapshots une fois la sauvegarde réalisée.

Faire des sauvegardes reste vraiment très simple: une simple requête HTTP et le tour est joué. En cas de désastre complet, vous pouvez récupérer tous vos index en réinstallant votre cluster grâce à vos précédents fichiers de configuration et en recopiant les fichiers d'index dans sur un emplacement accessible à l'instance Elasticsearch puis en lancant une requête HTTP de restauration.

L'ensemble de ces opérations prend un peu de ressources (des accès disques principalement) mais vous pouvez les réaliser pendant que votre cluster est actif. Donc, il ne sera pas obligatoire de réaliser un arrêt de service.