Copias de seguridad en elasticsearch, el API de snapshot y restore

Elasticsearch

El API de snapshot y restore de elasticsearch nos permite hacer copias de seguridad de los datos y el estado de

  • todo el cluster o
  • algunos indices

sobre un repositorio compartido, que puede ser

  • Amazon S3
  • Sistema de ficheros compartido
  • HDFS
  • Azure
  • etc

En cualquiera de los casos, independientemente del repositorio elegido, éste tiene que ser accesible desde cualquier nodo del cluster.

Elasticsearch soporta multitud de repositorios compartidos, todos ellos a través de la instalación de un plugin.

Nosotros vamos a ver como crear un snapshot y restore en un sistema de ficheros compartido.

El proceso de snapshot es incremental. Eso significa que el primer snapshot se realiza completo, mientras que el resto de snapshot solo tiene en cuenta la diferencia entre el último snapshot y los nuevos datos del cluster añadidos o modificados.

Registrar el path del sistema de ficheros

Antes de registrar el repositorio compartido, el cual hemos elegido en nuestro caso el sistema de ficheros, debemos registrar su ubicación. Recordemos que esta ubicación debe ser visible y accesible por todos los nodos del cluster.

Esta configuración debe ser añadida igualmente en todos los nodos del cluster.

Para ello editamos el fichero de configuración

$ES_HOME/config/elasticsearch.yml

y añadimos la configuración

path.repo: ["/mnt/fs-shared/backups/"]

Registrar el repositorio compartido

Una vez tenemos configurado la ubicación en todos los nodos del cluster, procedemos a registrar el repositorio compartido

# Petición
curl -XPUT 'http://localhost:9200/_snapshot/backups' -d '{
    "type": "fs",
        "settings": {
            "location": "/mnt/fs-shared/backups/"
    }
}'

# Respuesta
{
   "acknowledged": true
}

Donde podemos definir las siguientes características

  • location, puede ser un path relativo, en cuyo caso es relativo al path especificado en la configuración path.repo
  • compress, true o false. true por defecto. Indica si comprimir los ficheros de metadatos, es decir, los mappings, settings etc. Los ficheros de datos sin embargo no se comprimen
  • chunk_size, para dividir los ficheros grandes en otros más pequeños

Obtener información del repositorio compartido

# Petición
curl -XGET http://localhost:9200/_snapshot/backups

# Respuesta
{
   "backups": {
      "type": "fs",
      "settings": {
         "location": "/mnt/fs-shared/backups/"
      }
   }
}

Obtener información de todos los repositorios compartidos

curl -XGET http://localhost:9200/_snapshot

curl -XGET http://localhost:9200/_snapshot/_all

Verificación del registro de un repositorio

Cuando registramos un repositorio compartido, automáticamente se verifica su configuración en todos los nodos de cluster. Este comportamiento lo podemos modificar mediante un parámetro durante el registro del repositorio, evitando que este chequeo se realice. En esos casos, podemos lanzar posteriormente el proceso de verificación mediante la llamada al API:

# Petición
curl -XGET http://localhost:9200/_snapshot/backups/_verify

# Respuesta
{
   "nodes": {
      "NhD89B4NR1eI1kgl56TwQQ": {
         "name": "Architect"
      }
   }
}

Y como respuesta obtendremos la lista todos los nodos que han podido verificar el repositorio.

Creación de un snapshot de todo el cluster

Por defecto el snapshot se realiza del cluster completo. Exactamente de todos los índices abiertos.

# Petición
curl -XPUT http://localhost:9200/_snapshot/backups/backup_1?wait_for_completion=false

# Respuesta
{
   "accepted": true
}

Donde,

  • wait_for_completion, indica que no esperemos a que el snapshot termine. Aun así si el cluster es muy grande, esta operación puede tarde segundos o minutos, ya que antes de relizar el snapshot tiene que cargar en memoria la información del mismo.

Obtener información de un snapshot

# Petición
curl -XGET http://localhost:9200//_snapshot/backups/backup_1

# Respuesta
{
   "snapshots": [
      {
         "snapshot": "backup_1",
         "version_id": 1070199,
         "version": "1.7.1",
         "indices": [
            ".marvel-2015.09.24",
            "cars",
            ".marvel-2015.09.29",
            ".kibana_2",
            "pruebas",
            "usuarios",
            ".marvel-kibana",
            ".marvel-2015.10.16",
            ".kibana"
         ],
         "state": "SUCCESS",
         "start_time": "2015-11-11T16:59:43.224Z",
         "start_time_in_millis": 1447261183224,
         "end_time": "2015-11-11T17:13:31.158Z",
         "end_time_in_millis": 1447262011158,
         "duration_in_millis": 827934,
         "failures": [],
         "shards": {
            "total": 44,
            "failed": 0,
            "successful": 44
         }
      }
   ]
}

Como vemos el snapshot ha terminado con correctamente state=SUCCESS, y tenemos todos los índices del cluster. Además al estar utilizando kibana y marvel tenemos los índices que estos plugins crea automáticamente.

Creación de un snapshot pero solo de determinados índices

# Petición
curl -XPUT 'http://localhost:9200/_snapshot/backups/usuarios_y_cars_1' -d '{
  "indices": "usuarios,cars"
}'

# Respuesta
{
   "accepted": true
}

En este caso podemos indicarle las siguiente propiedades
– ignore_unavailable, si un índice no esta disponible el snapshot falle o no
– include_global_state, para no incluir o ignorar la información del estado del cluster

Igualmente podemos obtener la información del snapshot utilizando el mismo API Rest, pero en este caso, veremos solamente los indices seleccionados en el snapshot

# Petición
curl -XGET http://localhost:9200/_snapshot/backups/usuarios_y_cars_1

# Respuesta
{
   "snapshots": [
      {
         "snapshot": "usuarios_y_cars_1",
         "version_id": 1070199,
         "version": "1.7.1",
         "indices": [
            "usuarios",
            "cars"
         ],
         "state": "SUCCESS",
         "start_time": "2015-11-11T17:24:04.625Z",
         "start_time_in_millis": 1447262644625,
         "end_time": "2015-11-11T17:24:04.781Z",
         "end_time_in_millis": 1447262644781,
         "duration_in_millis": 156,
         "failures": [],
         "shards": {
            "total": 10,
            "failed": 0,
            "successful": 10
         }
      }
   ]
}

Información de todos los snapshot

curl -XGET http://localhost:9200/_snapshot/backups/_all

Borrado de un snapshot o parada de un snapshot

Esta operación se puede lanzar tanto para borrar un snapshot, como para parar uno que se encuenta en ejecución.

# Petición
curl -XDELETE http://localhost:9200/_snapshot/backups/backup_1

# Respuesta
{
   "acknowledged": true
}

Restaurar o recuperar un snapshot

Es la operación de restore. Debemos antes cerrar el índice o índices para poder realizar el restore. Además debemos asegurarnos que el número de shards no ha cambiado.

curl -XPOST http://localhost:9200/cars/_close
curl -XPOST http://localhost:9200/usuarios/_close
curl -XPOST http://localhost:9200/_snapshot/backups/usuarios_y_cars_1/_restore

# Respuesta
{
   "accepted": true
}

Una vez se ha restaurado el snapshot, los índices son abiertos automáticamente.

Por defecto se restauran todos los índices junto con el estado del cluster. Pero también se puede seleccionar del snapshot que índices queremos restaurar.

Por ejemplo, podemos restaurar solo el índice usuarios.

curl -XPOST http://localhost:9200/usuarios/_close
curl -XPOST 'http://localhost:9200/_snapshot/backups/usuarios_y_cars_1/_restore' -d '{
    "indices": "usuarios"
}'

# Respuesta
{
   "accepted": true
}

Restore nos permite otras funcionalidades, como la de poder hacer el restore en un cluster diferente, renombrar los índices etc

Determinar el estado de un snapshot

Tanto durante la ejecución de un snapshot como cuando ya ha termiando, podemos saber su estado.

La operación como siempre se realiza con el API Rest, y en la respuesta tenemos toda la información que necesitamos. Entre ellas nos encontraremos con la propiedad

  • state

cuyos valores no dicen el estado actual del snapshot, que pueden ser STARTED, SUCCESS, etc

# Lanzamos el snapshot
curl -XPUT http://localhost:9200/_snapshot/backups/all_cluster/

# Pedimos su estaso
curl -XGET http://localhost:9200/_snapshot/backups/all_cluster/_status

# Respuesta
{
   "snapshots": [
      {
         "snapshot": "all_cluster",
         "repository": "backups",
         "state": "STARTED",
         "shards_stats": {
            "initializing": 18,
            "started": 2,
            "finalizing": 0,
            "done": 25,
            "failed": 0,
            "total": 45
         },
         "stats": {
            ...
         },
         "indices": {
            ...
      }
   ]
}

Recordemos que un snapshot en ejecución o en proceso puede ser parado con el API Rest de borrado de snapshot.

Si te ha gustado este artículo o lo has encontrado interesante no olvides compartirlo en tus redes sociales. Esto nos ayuda a seguir mejorando.

Anuncios