Mejores Prácticas para Operaciones Diarias de Copia de Seguridad y Restauración de Elasticsearch
Establezca una estrategia confiable de copias de seguridad diarias de Elasticsearch utilizando esta guía completa. Aprenda a configurar repositorios duraderos, automatizar instantáneas de rutina con la Gestión del Ciclo de Vida de las Instantáneas (SLM) y aprovechar la Gestión del Ciclo de Vida de los Índices (ILM) para el archivo a largo plazo. Este artículo detalla las mejores prácticas para la seguridad, la limitación del rendimiento y los pasos cruciales para las pruebas de restauración regulares, asegurando que sus datos estén protegidos y recuperables bajo cualquier circunstancia.
Mejores Prácticas para Operaciones Diarias de Copia de Seguridad y Restauración en Elasticsearch
Las copias de seguridad diarias protegen su clúster de Elasticsearch contra fallos que las réplicas no pueden solucionar: eliminaciones accidentales, mapeos incorrectos, datos corruptos, actualizaciones fallidas y pérdida total del clúster. Las réplicas ayudan con la disponibilidad, pero las instantáneas son las que le permiten volver a una copia conocida y en buen estado.
Estas mejores prácticas para operaciones diarias de copia de seguridad y restauración en Elasticsearch cubren la configuración del repositorio, Snapshot Lifecycle Management (SLM), pruebas de restauración y los lugares donde encaja Index Lifecycle Management (ILM).
Comprendiendo el Mecanismo de Instantáneas de Elasticsearch
Las instantáneas de Elasticsearch no son simplemente copias de archivos; son incrementales, aprovechando la estructura interna de los índices de Lucene. Esto significa que después de la instantánea completa inicial, las instantáneas subsiguientes solo almacenan segmentos de datos que han cambiado desde la última instantánea exitosa, lo que las hace altamente eficientes en términos de tiempo y almacenamiento.
Las instantáneas capturan dos componentes principales:
- Datos del Índice: Los segmentos reales de Lucene para los índices seleccionados.
- Estado del Clúster: Metadatos, configuraciones persistentes, plantillas de índice, pipelines y roles.
1. Estableciendo el Repositorio de Instantáneas
Antes de tomar cualquier instantánea, debe registrar un repositorio: la ubicación segura donde se almacenarán los archivos de instantánea. La elección del repositorio es crucial para la durabilidad y la velocidad de recuperación.
Tipos de Repositorio
| Tipo de Repositorio | Descripción | Mejor para | Requisitos |
|---|---|---|---|
fs (Sistema de Archivos Compartido) |
Unidad local o montada en red accesible por todos los nodos maestro y de datos. | Clústeres pequeños, copias de seguridad locales rápidas. | Debe estar registrado en elasticsearch.yml (path.repo). |
s3, azure, gcs |
Servicios de almacenamiento en la nube. Algunas distribuciones y versiones incluyen estos tipos de repositorio; otras requieren instalar el plugin de repositorio correspondiente en cada nodo. | Entornos de producción, recuperación ante desastres. | Soporte de repositorio apropiado para la versión y credenciales IAM/principal de servicio adecuadas. |
Ejemplo: Registrando un Repositorio S3
Para entornos de producción, el almacenamiento en la nube suele ser la mejor opción por su durabilidad y recuperación fuera del sitio. Confirme el soporte del repositorio para su versión de Elasticsearch, configure las credenciales de forma segura, luego registre el repositorio a través de la API.
PUT /_snapshot/my_s3_daily_repo
{
"type": "s3",
"settings": {
"bucket": "es-backup-bucket-name",
"region": "us-east-1",
"base_path": "daily_snapshots/production",
"compress": true
}
}
Consejo: Asegúrese de que el bucket o la ruta del sistema de archivos configurada sea segura, inmutable (si su proveedor lo admite) y se use exclusivamente para copias de seguridad.
2. Implementando la Automatización Diaria con SLM
Las instantáneas manuales son aceptables para operaciones puntuales, pero las copias de seguridad diarias rutinarias deben automatizarse utilizando Snapshot Lifecycle Management (SLM). SLM es el mecanismo nativo dentro de Elasticsearch diseñado específicamente para definir horarios, políticas de retención y gestión de instantáneas.
Definiendo una Política SLM
Una política diaria típica define un horario, los índices a incluir (o excluir) y cuánto tiempo retener las instantáneas.
PUT /_slm/policy/daily_archive_policy
{
"schedule": "0 30 1 * * ?",
"name": "<daily-{{now/d}}>",
"repository": "my_s3_daily_repo",
"config": {
"indices": ["logstash-*", "application-metrics-*"],
"ignore_unavailable": true,
"include_global_state": false
},
"retention": {
"expire_after": "30d",
"min_count": 5,
"max_count": 30
}
}
Puntos Clave de Configuración de SLM:
schedule: Utiliza sintaxis cron de Quartz (ej.,0 30 1 * * ?se ejecuta diariamente a la 01:30 AM). Programe durante las horas de menor uso.include_global_state: false: Para copias de seguridad de datos diarias, a menudo es mejor excluir el estado del clúster para evitar una reversión accidental del estado durante la restauración.retention: Define el programa de limpieza. El ejemplo anterior retiene las instantáneas durante 30 días, asegurando que se mantengan al menos 5 y no más de 30.
Monitoreando SLM
Verifique regularmente el estado de sus políticas para asegurarse de que se estén ejecutando correctamente.
GET /_slm/status
GET /_slm/policy/daily_archive_policy
3. Integrando con Index Lifecycle Management (ILM)
Para grandes datos de series temporales, como registros y métricas, Index Lifecycle Management (ILM) gestiona los índices desde su creación hasta su eliminación. ILM no reemplaza las instantáneas diarias de SLM, pero puede ayudar a coordinar la eliminación con una política de instantáneas completada.
ILM y Niveles de Datos
Antes de que ILM elimine índices antiguos, puede hacer que la fase de eliminación espere a que se ejecute una política SLM. Esto le da a su política de instantáneas diarias o de largo plazo la oportunidad de capturar los datos antes de que el índice se elimine del clúster.
- Cree una política SLM que tome instantáneas del patrón de índice relevante.
- Haga referencia a esa política SLM desde la fase de eliminación de ILM con
wait_for_snapshot.
...
"delete": {
"min_age": "90d",
"actions": {
"wait_for_snapshot": {
"policy": "daily_archive_policy"
},
"delete": {}
}
}
...
Esto espera una instantánea exitosa de la política SLM nombrada antes de que ILM elimine el índice. Si utiliza flujos de datos, pruebe el flujo del ciclo de vida en un entorno de pruebas para saber qué índices subyacentes están cubiertos por la política de instantáneas.
Si su objetivo es mantener datos buscables más antiguos en un almacenamiento más barato en lugar de eliminarlos, consulte la acción de instantánea buscable en la fase fría o congelada. Ese es un patrón diferente a una instantánea simple de recuperación ante desastres:
...
"cold": {
"min_age": "30d",
"actions": {
"searchable_snapshot": {
"snapshot_repository": "my_s3_daily_repo"
}
}
}
...
Utilice un patrón de ciclo de vida por objetivo: SLM para copias de seguridad recuperables, wait_for_snapshot antes de la eliminación e instantáneas buscables cuando necesite acceso de búsqueda de menor costo.
4. Mejores Prácticas para Pruebas de Restauración
Una rutina de copia de seguridad está incompleta sin una estrategia de recuperación probada. Debe probar regularmente su proceso de restauración para validar la integridad de los datos y cumplir con los objetivos de tiempo de recuperación (RTO).
Entorno de Pruebas de Restauración
- No pruebe restauraciones directamente en un clúster de producción en vivo. Utilice un entorno de pruebas o staging dedicado que ejecute una versión compatible de Elasticsearch y tenga suficiente espacio en disco para los fragmentos restaurados.
- Frecuencia: Pruebe la restauración al menos trimestralmente, o después de actualizaciones importantes o cambios de configuración.
Ejecutando una Restauración
La restauración puede apuntar a índices específicos o al estado completo del clúster.
Paso 1: Obtener Detalles de la Instantánea
Identifique el nombre de la instantánea que necesita restaurar.
GET /_snapshot/my_s3_daily_repo/_all
Paso 2: Ejecutar la Operación de Restauración
Para restaurar índices específicos, use el parámetro indices. A menudo es necesario renombrar los índices durante la restauración para evitar conflictos con los índices activos (especialmente en un entorno de pruebas).
POST /_snapshot/my_s3_daily_repo/snapshot_20240501/_restore
{
"indices": ["logstash-2024-05-01"],
"rename_pattern": "(.+)",
"rename_replacement": "restored-$1",
"include_aliases": false
}
Verificando el Éxito de la Restauración
Después de la restauración, verifique la salud de los fragmentos y los recuentos de documentos. Una coincidencia de recuento es útil, pero también ejecute una consulta de muestra de la que dependa su aplicación.
GET /_cluster/health/restored-logstash-2024-05-01?wait_for_status=green&timeout=60s
GET /restored-logstash-2024-05-01/_count
5. Consideraciones de Seguridad y Rendimiento
Seguridad
- Acceso al Repositorio: Asegúrese de que las credenciales utilizadas por Elasticsearch para acceder al repositorio sigan el principio de mínimo privilegio para la ruta del repositorio. En la práctica, la gestión de instantáneas necesita permisos de lectura, escritura, listado y eliminación para los objetos que posee, especialmente cuando la retención elimina instantáneas antiguas.
- Cifrado: Utilice repositorios seguros (como S3) con cifrado del lado del servidor habilitado (SSE-S3 o SSE-KMS).
Limitación de Rendimiento
Las instantáneas pueden ser intensivas en E/S. Si nota una degradación del rendimiento durante la ventana de instantáneas, limite el tráfico de instantáneas a nivel de repositorio. Para muchos tipos de repositorio, las configuraciones relevantes son max_snapshot_bytes_per_sec y max_restore_bytes_per_sec al registrar o actualizar el repositorio.
PUT /_snapshot/my_s3_daily_repo
{
"type": "s3",
"settings": {
"bucket": "es-backup-bucket-name",
"region": "us-east-1",
"base_path": "daily_snapshots/production",
"max_snapshot_bytes_per_sec": "100mb",
"max_restore_bytes_per_sec": "100mb"
}
}
indices.recovery.max_bytes_per_sec controla el tráfico de recuperación entre pares y de instantáneas, así que ajústelo solo cuando comprenda el efecto en la recuperación de fragmentos. Mantenga los horarios de las instantáneas fuera de las ventanas pico de indexación y búsqueda cuando sea posible.
Flujo de Trabajo Diario de Copia de Seguridad
- Configurar Repositorio Duradero: Use almacenamiento en la nube (S3/Azure/GCS) para entornos de producción.
- Definir Política SLM: Programe instantáneas (ej., diariamente a la 1:30 AM) usando SLM, asegurando reglas de retención apropiadas.
- Coordinar ILM (si aplica): Use
wait_for_snapshotantes de la eliminación o instantáneas buscables para un historial buscable de menor costo. - Monitorear Estado: Verifique regularmente la ejecución de la política SLM a través de las API
_slm/policyy_slm/status. - Probar Recuperación: Trimestral o semestralmente, realice una restauración completa en un entorno segregado para validar la preparación del RTO.
La copia de seguridad útil es la que puede restaurar. Mantenga la política SLM diaria simple, monitoree las fallas y programe simulacros de restauración con la frecuencia suficiente para que su equipo conozca los pasos exactos antes de un incidente.