Busindre

Para hacer copias de seguridad en ElasticSearch se recomienda encarecidamente utilizar el uso de la API de Instantaneas (Snapshots) de ES. La manera más simple de realizar migraciones (importar / exportar datos) de entornos ElasticSearch a otro clúster.

Las snapshots pueden ser completas o incrementales y se guardan siempre en lo que denominan “repositorio”, el cual suele ser un punto de montaje perteneciente a un host remoto o dispositivo de bloques. Un repositorio puede contener múltiples instantáneas y a su vez estas pueden estar asociadas a uno o varios índices, dependiendo de como queramos realizar la copia de seguridad o la migración.

Repositorio del tipo sistema de ficheros compartido (fs) con nombre “my_backup” y punto de montaje: /mount/backups/my_backup.

PUT _snapshot/my_backup 
{
    "type": "fs", 
    "settings": {
        "location": "/mount/backups/my_backup"
	"max_snapshot_bytes_per_sec" : "50mb", 
        "max_restore_bytes_per_sec" : "50mb"
    }
}

max_snapshot_bytes_per_sec: Velocidad de escritura en el repositorio, 20Mb por defecto. max_restore_bytes_per_sec: Velocidad de restauración, 20Mb por segundo por defecto.

NOTA: El punto de montaje debe ser accesible sin excepción desde todos los nodos del clúster.

Para actualizar las opciones de un repositorio se utiliza “POST” en vez de “PUT”.

POST _snapshot/my_backup/ 
{
    "type": "fs",
    "settings": {
        "location": "/mount/backups/my_backup",
        "max_snapshot_bytes_per_sec" : "35mb", 
        "max_restore_bytes_per_sec" : "35mb"
    }
}

Crear punto de acceso NFS en Centos.

yum install nfs-utils<code>
 
Nodo que comparte el directorio donde guardar las copias: configurar el fichero /etc/exports 
 
<code>/mnt/es_backups		192.168.178.0/24(rw,subtree_check)

chkconfig nfs on && chkconfig rpcbind on && service rpcbind start && service nfs start

En los nodos del clúster de ES se puede montar o definir en “/etc/fstab” el punto de montaje.

mount -t nfs 192.168.178.115:/mnt/es_backups /mnt/es_backups

NOTA: A partir de ElasticSearch 1.6, el repositorio debe estar definido en la opción “path.repo: /mnt/es_backups” de elasticsearch.yml. Si no se especifica se obtendrá el siguiente error.

{"error":"RepositoryException[[backup1] failed to create repository]; nested: CreationException[Guice creation errors:\n\n1) Error injecting constructor, org.elasticsearch.repositories.RepositoryException: [backup1] location [/mnt/es_backups/] doesn't match any of the locations specified by path.repo because this setting is empty\n  at org.elasticsearch.repositories.fs.FsRepository.<init>(Unknown Source)\n  while locating org.elasticsearch.repositories.fs.FsRepository\n  while locating org.elasticsearch.repositories.Repository\n\n1 error]; nested: RepositoryException[[backup1] location [/mnt/es_backups/] doesn't match any of the locations specified by path.repo because this setting is empty]; ","status":500}

NOTA: Si se borra un repositorio sin borrar previamente los snapshots que contiene, estos siguen ahí, no se eliminan. Si por error sucede ese, para volver a tener acceso a esas instantáneas valdría vale con crear de nuevo el repositorio con el mismo nombre de antes.

Si ya se ha definido el repositorio, es posible crear instantáneas de todos o parte de los indices del clúster ES.Un repositorio puede contener varios snapshots y estos a su vez pueden contener una copia de todos los indices o una parte, es importante darles nombres descriptivos que no induzcan al error.

Por norma las instantáneas se realizan en segundo plano una vez son solicitadas, en scripts ese comportamiento no es útil ya que lo conveniente es saber cuando el proceso se ha completado para proceder con la siguiente instrucción. Para solventar esto se debe indicar la opción “wait_for_completion=true”, la cual dejará la solicitud PUT en suspensión hasta que termine de completarse el backup (en instancias grandes puede tardar muchos minutos).

PUT _snapshot/my_backup/snapshot_1?wait_for_completion=true

Se pueden especificar indices determinados, cosa recomendable para no guardar por ejemplo indices de Marvel de estar en uso.

PUT _snapshot/my_backup/snapshot_2
{
    "indices": "index_1,index_2"
}

Monitorizar el proceso de creación de una Snapshot (Más sofisticado que la opción wait_for_completion)

Si la instantánea aún está procesándose y se consulta información sobre la misma con GET como se vio anteriormente, se mostrará información acerca de cuándo se inició, el tiempo que lleva procesándose, etc. Pero si los fragmentos son de un tamaño grande se puede tardar bastante en obtener actualizaciones del estado. Esto se debe a utiliza el mismo “ThreadPool” del mecanismo de las instantáneas.

Para obtener información más descriptiva y completamente actualizada del proceso de backup se debe usar la directiva “_status”.

GET _snapshot/my_backup/snapshot_3/_status

Se muestran estadísticas por fragmento (shard) y por índice, los shards (fragmentos) pasan varios tipos de estado a la hora de realizar una instantánea:

• INITIALIZING: Se está comprobando el estado del clúster para saber si el fragmento puede ser salvaguardado en la instantánea.
• STARTED: El fragmento esta siendo transmitido al repositorio.
• FINALIZING: La transferencia del fragmento al repositorio ha sido completada y solo faltan sus metadatos.
• DONE: Instantánea completada.
• FAILED: Instantánea fallida.

GET _snapshot/my_backup/snapshot_2
GET _snapshot/my_backup/_all

Para borrar instantáneas se debe usar la API y nunca borrarlas a mano ya que son incrementales y pueden denecesitar de fragmentos antiguos, de borrar manualmente los datos se puede coromper el backup.

DELETE _snapshot/my_backup/snapshot_2

Para cancelar una instantánea en curso vale con ejecutar el comando DELETE para que se cancele limpiamente.

El proceso es el mismo que el de buscar fragmentos (shards) en cualquier otro nodo, solo que usando el repositorio que alberga las snapshots. Se debe tener en cuenta que no se puede restaurar un Backup utilizando el mismo nombre que índices actualmente abiertos (en funcionamiento), para ello deben ser cerrados o bien eliminados antes de poder ser restaurados.

POST _snapshot/my_backup/snapshot_1/_restore

Por defecto el comando restaurara todos los indices que la instantánea contenga, pero se puede especificar índices concretos. También hay opciones adicionales para cambiar el nombre de los índices restaurados usando otros diferentes a los originales. Es útil si se desea restaurar los datos antiguos para verificar su contenido o realizar algún otro tipo de elaboración, sin reemplazar los datos existentes.

Ejemplo de restauración de un único índice de la instantánea proporcionando un nombre de reemplazo.

• Restaurar solo el índice “index_1” de la instantánea con nombre “snapshot_1”.
• Buscar todos los indices que se van a restaurar que siguen ese patrón.
• Renombrar los indices a restaurar que coincidan con el patrón.

POST /_snapshot/my_backup/snapshot_1/_restore
{
    "indices": "index_1", 
    "rename_pattern": "index_(.+)", 
    "rename_replacement": "restored_index_$1" 
}

Al igual que con las creación de instantáneas, se puede usar la directiva “wait_for_completion=true” para bloquear la solicitud hasta que haya terminado (útil en scripts).

POST _snapshot/my_backup/snapshot_1/_restore?wait_for_completion=true

Monitorizar la restauración de Instantenas. (Para uno o todos los repositorios)

La salida listará todos los índices que están actualmente en recuperación y luego mostrará un listado de sus fragmentos, su estado y otro tipo de información como estadísticas sobre tiempos, porcentaje recuperado, bytes transferidos, etc.

GET /_recovery/restored_index_3
GET /_recovery/

Campos de interés al monitorizar restauraciones en ES.

• type: Muestra la procedencia de la restauración, por norma una snapshot.
• source hash: Describe la snapshot y el repositorio que está siendo utilizado.
• percent: Porcentajes de shards restaurados.

Para cancelar una restauración se deben eliminar con el comando DELETE los indices que están siendo restaurados. También se suprimen los datos que hayan sido restaurada en el clúster.

DELETE /restored_index_3

El mejor proceso para migrar todos o parte de los indices entre dos infraestructuras ES es utilizar las instantáneas. Por ejemplo se podría montar el mismo repositorio NFS de un clúster en el nuevo clúster donde se quieren migrar los indices y una vez montado, utilizar el comando de restauración.

Otra posibilidad es copiar el contenido del directorio (repositorio) de la instancia origen en el del clúster destino y desde este restaurar.

PUT /_snapshot/backups/
{
  "type": "fs",
  "settings": {
    "location": "/mnt/es_backups/",
    "max_snapshot_bytes_per_sec": "50mb",
    "max_restore_bytes_per_sec": "50mb"
  }
}

curl -XGET "http://localhost:9200/_snapshot/_all?pretty"
{
  "backups" : {
    "type" : "fs",
    "settings" : {
      "location" : "/mnt/es_backups/",
      "max_restore_bytes_per_sec" : "50mb",
      "max_snapshot_bytes_per_sec" : "50mb"
    }
  }
}

curl -XGET "http://localhost:9200/_snapshot/backups/_all?pretty"
{
  "snapshots" : [ {
    "snapshot" : "backup1",
    "version_id" : 1070199,
    "version" : "1.7.1",
    "indices" : [ "logstash-2015.08.23", "logstash-2015.08.28" ],
    "state" : "SUCCESS",
    "start_time" : "2015-08-29T00:23:09.226Z",
    "start_time_in_millis" : 1440807789226,
    "end_time" : "2015-08-29T00:23:09.639Z",
    "end_time_in_millis" : 1440807789639,
    "duration_in_millis" : 413,
    "failures" : [ ],
    "shards" : {
      "total" : 6,
      "failed" : 0,
      "successful" : 6
    }
  }, {
    "snapshot" : "backup2",
    "version_id" : 1070199,
    "version" : "1.7.1",
    "indices" : [ "logstash-2015.08.23", "logstash-2015.08.28" ],
    "state" : "SUCCESS",
    "start_time" : "2015-08-29T00:25:41.838Z",
    "start_time_in_millis" : 1440807941838,
    "end_time" : "2015-08-29T00:25:42.047Z",
    "end_time_in_millis" : 1440807942047,
    "duration_in_millis" : 209,
    "failures" : [ ],
    "shards" : {
      "total" : 6,
      "failed" : 0,
      "successful" : 6
    }
  }, {
    "snapshot" : "backup9",
    "version_id" : 1070199,
    "version" : "1.7.1",
    "indices" : [ "logstash-2015.08.23", "logstash-2015.08.28" ],
    "state" : "SUCCESS",
    "start_time" : "2015-08-29T00:33:51.576Z",
    "start_time_in_millis" : 1440808431576,
    "end_time" : "2015-08-29T00:33:51.841Z",
    "end_time_in_millis" : 1440808431841,
    "duration_in_millis" : 265,
    "failures" : [ ],
    "shards" : {
      "total" : 6,
      "failed" : 0,
      "successful" : 6
    }
  } ]
}