Easysearch 快照与备份的正确使用方式

在分布式搜索引擎的运维中，数据安全永远是“1”前面的那个“0”。无论是为了应对突发的硬件故障、人为的误操作，还是勒索软件的攻击，一套完善的备份恢复机制都是企业级数据架构的底线。

INFINI Easysearch 作为一款自主可控、高性能的分布式近实时搜索与分析引擎，不仅完全兼容 Elasticsearch 的快照（Snapshot）API，更在此基础上提供了**可搜索快照（Searchable Snapshots）**等企业级增强功能，帮助用户在保障数据安全的同时，大幅降低存储与计算成本。

本文将深入探讨 Easysearch 快照与备份的工作原理，并手把手教你如何“正确”地使用它们。

一、理解核心概念：快照不是简单的“复制” #

在开始操作之前，我们需要纠正一个常见的误区：Easysearch 的快照并不是简单的文件拷贝。

增量备份（Incremental）：Easysearch 的快照机制是非常智能的。它是基于 Lucene Segment（分段）进行的。首次快照是全量的，但随后的快照仅包含自上次快照以来发生变化的 Segment。这意味着高频次的快照策略并不会带来巨大的存储开销。
仓库（Repository）：快照存储的地方。支持共享文件系统（NFS）、S3 对象存储（如 Minio、AWS S3）、HDFS 等多种介质。
原子性：快照过程是原子性的，它捕获的是发起快照那一刻的集群状态。

二、环境准备：配置快照仓库 #

最推荐的备份介质是 对象存储（S3/Minio），因为它具备高可用、低成本且易于扩展的特性。以下以配置 S3 兼容的存储（如 Minio）为例。

1. 内置 S3 插件 #

Easysearch 已经内置了 S3 仓库插件。

2. 配置仓库连接 #

你需要将 Access Key 和 Secret Key 添加到 Easysearch 的密钥库（Keystore）中，而不是明文写在配置文件里，这是安全最佳实践。

# 在 Easysearch 节点上执行
bin/easysearch-keystore add s3.client.default.access_key
bin/easysearch-keystore add s3.client.default.secret_key

3. 注册仓库 #

使用 Dev Tools 或 Curl 注册仓库：

PUT _snapshot/s3_repository
{
  "type": "s3",
  "settings": {
    "bucket": "easysearch-backups",
    "endpoint": "minio.internal.corp:9000",
    "protocol": "http",
    "base_path": "prod_cluster_v1",
    "compress": true
  }
}

注意：compress: true 选项建议开启，虽然 Easysearch 自身的 ZSTD 压缩已经很高效，但在传输到远端存储时，元数据的压缩依然能节省带宽。

三、实战操作：备份与恢复 #

1. 创建快照（手动） #

适用于重大变更（如版本升级、Schema 变更）前的临时备份。

# 备份所有索引，wait_for_completion=true 表示同步等待完成
PUT _snapshot/s3_repository/snapshot_20251027?wait_for_completion=true

2. 指定索引备份 #

通常我们不需要每次都备份所有数据，可以指定索引：

PUT _snapshot/s3_repository/log_backup_snapshot_20251027
{
  "indices": "logs-*",
  "ignore_unavailable": true,
  "include_global_state": false
}

3. 数据恢复（Standard Restore） #

当发生数据丢失需要恢复时：

POST _snapshot/s3_repository/log_backup_snapshot_20251027/_restore
{
  "indices": "logs-*",
  "ignore_unavailable": true,
  "include_global_state": false,
  "rename_pattern": "logs-(.+)",
  "rename_replacement": "restored-logs-$1"
}

技巧：使用 rename_pattern 和 rename_replacement 可以将数据恢复为新的索引名，便于与现有数据进行比对，验证无误后再切换业务别名。

四、进阶必杀技：SLM 与可搜索快照 #

手动管理快照在生产环境中是不可靠的。Easysearch 的强大之处在于自动化和冷热分离。

1. 自动化：快照生命周期管理 (SLM) #

通过配置 SLM 策略，实现“每晚备份 logs，保留最近 7 天”的自动化运维。

POST _slm/policies/daily-snapshots
{
  "description": "daily-snapshots",
  "creation": {
    "schedule": {
      "cron": {
        "expression": "0 8 * * *",
        "timezone": "Asia/Shanghai"
      }
    },
    "time_limit": "1h"
  },
  "deletion": {
    "schedule": {
      "cron": {
        "expression": "0 1 * * *",
        "timezone": "Asia/Shanghai"
      }
    },
    "condition": {
      "max_age": "7d",
      "max_count": 21,
      "min_count": 7
    },
    "time_limit": "1h"
  },
  "snapshot_config": {
    "date_format": "yyyy-MM-dd-HH:mm",
    "date_format_timezone": "Asia/Shanghai",
    "indices": "logs-*",
    "repository": "s3_repository",
    "ignore_unavailable": "true",
    "include_global_state": "false",
    "partial": "true",
    "metadata": {
      "daily": "snapshots"
    }
  }
}

Schedule: 每天上午 8 点自动创建一份快照,快照名称格式为 yyyy-MM-dd-HH:mm ，存储在 s3_repository 快照仓库。
Retention: 每天凌晨 1 点自动删除最早 7 天前创建的快照、超过 21 个的快照以及保留至少 7 个快照，防止存储无限增长。

2. 降本增效：可搜索快照 (Searchable Snapshots) #

这是 Easysearch 区别于传统 ES 运维的核心优势之一（参考操作文档）。

对于海量的历史日志数据（如 3 个月前的日志），查询频率极低，但又不能删除。如果全部放在热节点，硬件成本极高。Easysearch 允许你直接**挂载（Mount）**快照中的索引，使其立即可搜，而无需进行完整的 Restore 数据搬运。

优势：

秒级挂载：不需要等待数据从 S3 拷贝回本地磁盘。
极低成本：数据主要存储在廉价的对象存储中，本地仅需极少的缓存空间。

操作示例：

POST _snapshot/s3_repository/log_backup_snapshot_20251027/_restore
{
  "indices": "logs-*",
  "ignore_unavailable": true,
  "include_global_state": false,
  "include_aliases": false,
  "partial": false,
  "storage_type": "remote_snapshot",
  "rename_pattern": "logs-(.+)",
  "rename_replacement": "restored-search-logs-$1"
}

这使得 Easysearch 成为了构建 冷热温（Hot-Warm-Cold） 架构的理想底座，结合其 ZSTD 压缩 能力，典型场景下可比传统方案节省 50% - 80% 的存储成本。

五、避坑指南与最佳实践 #

在使用 Easysearch 进行备份时，以下几点经验至关重要：

不要在这个节点存，去那个节点读：
虽然共享文件系统（NFS）配置简单，但在大规模集群中，网络延迟和锁机制可能导致性能瓶颈。强烈推荐使用对象存储（S3/Minio）。
监控快照状态：
快照虽然是后台运行，但如果长期失败（如存储空间不足、网络中断），关键时刻会“掉链子”。

建议通过 GET _slm/policies 定期检查执行状态。
使用 INFINI Console 等统一管控平台进行可视化监控和告警。

全局状态（Global State）的取舍：
在 include_global_state 为 true 时，快照会包含集群的持久化设置和索引模板。

建议：定期做包含全局状态的全量快照；但在日常高频索引备份中，设为 false 以减少冲突风险。

速度限制：
快照和恢复过程会占用网络带宽和磁盘 I/O。为了不影响在线业务，应设置限流：

PUT _cluster/settings
{
  "persistent": {
    "indices.recovery.max_bytes_per_sec": "100mb"
  }
}

安全加密：
备份数据也是数据。如果备份到公有云 S3，务必开启服务端加密（Server-Side Encryption）。

结语 #

Easysearch 的快照与备份机制不仅是数据的“救生圈”，更是企业降本增效的利器。通过合理配置 SLM 策略和利用可搜索快照技术，我们可以在保证数据 100% 安全的前提下，将海量冷数据的存储成本降至最低。

记住：没有经过恢复测试的备份，只能称为“薛定谔的备份”。 请务必定期演练恢复流程，确保在危机时刻，您的 Easysearch 集群能够迅速重回正轨。

标签