[moved-to-gitea]evobackup

Depuis la version 1.0, le mode "normal" de sauvegarde d'un cluster Elasticsearch n'est plus "copie de /var/lib/elasticsearch".
Les commandes liées au translog… ne fonctionnent plus, cf. https://www.elastic.co/guide/en/elasticsearch/reference/current/backup.html

Il faut utiliser un système de snapshot vers un dossier de backup (façon mysqldump) et sauvegarder ces fichiers de snapshot.
Un exemple d'un tel backup est visible sur autrement-hh4

https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-snapshots.html

En gros, il faut configurer Elasticsearch pour qu'il connaisse en dépôt de stockage de snapshots, en ajoutant une ligne comme ça dans la config générale (/etc/elasticsearch/elasticsearch.yml) : path.repo: ["/home/backup-elasticsearch"].

Ensuite il faut initialiser le dépôt de snapshots :

# curl -XPUT 127.0.0.1:9200/_snapshot/evobackup -d '{"type": "fs", "settings": {"location": "/home/backup-elasticsearch/evobackup", "compress": true}}'

Dans la tache de backup, on peut faire un snapshot "horaire" comme ça :

date=$(date +%H)
curl -s -XDELETE "127.0.0.1:9200/_snapshot/evobackup/h${date}" | grep -v acknowledged..true
curl -s -XPUT "127.0.0.1:9200/_snapshot/evobackup/h${date}?wait_for_completion=true" -o /tmp/es_snapshot_h${date}.lo

Ainsi à chaque fois que le script est joué, le snapshot nommé est supprimé et recréé.
En exécutant la tache plusieurs fois par jour, on augmente le nombre de snapshots.

Je recommande de déporter les taches de dump local dans un script tiers (par exemple /usr/shar/scripts/dump_databases.sh) qui est appelé plusieurs fois par jour.

Le script evobackup quant à lui ne fait les sauvegardes distantes qu'une fois par jour.