Snapshot y restore de Elasticsearch (repository fs / S3, SLM)

Configura los snapshots (copias de seguridad) de un cluster Elasticsearch 8.x / 9.x ya instalado y explica la recuperación: repository en sistema de archivos compartido (NFS + path.repo) o S3 (keystore), activación con rolling restart y verificación, snapshot manual (indices, include_global_state, feature_states), snapshots programados y retención con SLM (expire_after/min_count/max_count), restore con un nombre nuevo o sobre un índice cerrado, restore de feature states, supervisión y traslado a otro cluster registrando el mismo repository en solo lectura. El resultado son snapshots diarios automáticos cuya restauración se ha comprobado. En Elasticsearch el snapshot es la única copia de seguridad válida; para cambios de mapping/shards dentro del mismo cluster se usa reindex, y para recuperar rápidamente un único índice, los escenarios de la guía de operación.

Topología: Cluster Elasticsearch 8.x / 9.x (1–N nodos) + directorio compartido (NFS) o almacenamiento de objetos compatible con S3

Antes de empezar

• El cluster está sano (green) y tiene la contraseña de elastic (o de un usuario con privilegios manage + snapshot). Como el ajuste del repository obliga a reiniciar los nodos, asegúrese de que el cluster tolera la pérdida de un nodo (replicas asignadas).
• En cada nodo existe el archivo de la CA de HTTP (…); las llamadas a la API se verifican con esta CA.
• … está montado desde el mismo recurso compartido (NFS) en todos los nodos master y data y es persistente en fstab. El UID/GID del usuario elasticsearch debe ser el mismo en todos los nodos, o el recurso debe asignarse a un único usuario con all_squash,anonuid=…,anongid=…; si no, los nodos no pueden leer los archivos que escriben los demás. Un directorio local (no compartido) falla en la verificación del repository en un cluster de varios nodos.
• Se ha creado el bucket …; la clave de acceso (access key / secret key) tiene los permisos s3:ListBucket, s3:GetObject, s3:PutObject, s3:DeleteObject, s3:AbortMultipartUpload, s3:ListMultipartUploadParts y s3:ListBucketMultipartUploads sobre este bucket. Los nodos pueden llegar a … por HTTPS.
• El recurso compartido tiene espacio libre suficiente: el primer snapshot ocupa tanto como el tamaño en disco de los índices; los siguientes solo añaden los segmentos que cambian (incremental).
• Se conocen las reglas de versión: un snapshot se restaura en un cluster de la misma versión o una más nueva; no puede restaurarse en una versión anterior. Un índice puede restaurarse como máximo en la versión principal siguiente a aquella en la que se creó (un índice creado en 8.x pasa a 9.x; uno creado en 7.x no llega a 9.x como índice normal).
• Dispone de acceso root en todos los nodos y de una ventana de mantenimiento para el rolling restart.

Fases de la guía

• Acceso a la API (todos los nodos) — Archivo temporal de credenciales para la API · Comprobar el cluster y los repositories existentes
• Preparación del sistema de archivos compartido (todos los nodos) — Montar el recurso NFS · Ajustar los permisos del directorio y probar la escritura · Añadir el ajuste path.repo
• Credenciales y ajustes de cliente S3 (todos los nodos) — Añadir las claves de acceso S3 al keystore · Añadir los ajustes del cliente S3
• Registrar y verificar el repository — Registrar el repository · Verificar el repository
• Snapshot manual — Crear el índice de prueba · Tomar un snapshot · Seguir el estado del snapshot
• Snapshots automáticos con SLM — Crear la política SLM · Ejecutar la política ahora · Comprobar el estado y las estadísticas de SLM · Ejecutar la retención a mano
• Restore — Restaurar el índice con un nombre nuevo · Seguir el restore y comparar el número de documentos · Borrar la copia restaurada · Cerrar el índice y restaurarlo en el sitio · Restaurar el feature state
• Traslado a otro cluster — Preparación del cluster de destino · Registrar el repository en solo lectura · Restaurar los índices en el cluster de destino · Borrar el archivo de credenciales del destino
• Supervisión y mantenimiento — Supervisar el estado de los snapshots · Limpieza del repository · Borrar los archivos de credenciales · Simulacros periódicos de recuperación